Do you remember that time when the term fullstack developer started to make waves? A fullstack developer is a software engineer who owns both front-end and back-end components of a web application. They were (and currently still are) the unicorn of the modern software development world. 51.9% of developers across the world identify as fullstack, which ranks as the majority of developers in the 2019 StackOverflow developer survey.
However, a new unicorn has arrived. As software development has become simpler, the responsibilities of a developer have also increased to include the full lifecycle of their code. A widestack developer is the modern version of a fullstack developer in that they own the development, deployment, operations, and monitoring of their application stack. In other words, as a fullstack developer owns more of what they’re building, the widestack developer also owns more of getting their code into production.
“A widestack developer is the modern version of a fullstack developer in that they own the development, deployment, operations, and monitoring of their application stack.“
Traditionally, a fullstack developer owned the front-end components and back-end components of their application stack. For example, a web application would contain the following:
This would be the essential components to get an entire application up and running. Not only do you have to understand a programming language, but you also have to understand the context in which it executes: the operating system, the database, and the webserver. Since your application is outputting all of the client-side code (e.g., HTML), you would begin to own all of the client-side logic as well. This is how a fullstack developer came to be. Naturally, the more mature and seasoned engineers took ownership of the entire stack.
Who benefited from this? The advantages were:
The economics were clear. A fullstack developer was/is the unicorn of choice that every company was going after.
In today’s modern application ecosystem, organizations have dozens, hundreds, or even thousands of services that operate on the back-end to make an application function. Thus, developers are no longer focused on the “fullstack” as they are on the “widestack.” In other words, developers aren’t as interested in owning more of their environments as they are in owning the full operations of deploying their code.
Historically, as a developer, I only wrote code and checked it into Git. That was it. I trusted that the process was good enough to know what to do with my code as it made its way into production. Today, I own much more of that process. Why? Because development has gotten so damn easy. I’ll give you some examples.
The world was introduced to elastic cloud hosting environments. Infrastructure, compute power, and server resources were no longer an issue. Developers could easily manage their infrastructure without the need for a traditional ops team. You can easily spin servers up and down, and you can do it at scale. The science of operations has been abstracted in a pretty little UI made available by AWS, Azure, and Google Cloud. I can provision my infrastructure at scale using tools like Terraform and Ansible. I can configure my deployment environments using tools like Chef or Puppet. I can package, maintain, and configure my microservices at scale using tools like Docker, Kubernetes, and Helm.
Monitoring your software has also become easier. Instrumenting application runtimes and full-blown APM tools (e.g., AppDynamics, New Relic) has made it easy to monitor, detect, and diagnose application issues in production. By the time an error creeps its way into production, I have full diagnostics behind what went wrong, down to the line of code.
I don’t necessarily have to wait until traffic hits my applications in production because I can use Synethic monitoring tools to sniff out my bugs before they impact customers.
Heck, why even wait until production?
I can use chaos engineering techniques to replicate disaster scenarios and have resiliency built into my application and operations. I can leverage pre-production testing and simulate worst-case production nightmares to ensure that only bullet-proof code and scalable systems can find its way into production, and eventually our customers.
The introduction of automated test suites that can quickly and swiftly test code on multiple layers has easily enabled developers to write and test their software. The isolation of the responsibilities of developers and QA no longer exists. QA engineers can now join the rest of the development team and focus on value-added features rather than focus fulltime on QA.
As quickly as a feature is built, the tests for that feature are also written. By the time the feature makes it into production, the automated test coverage is already there to ensure optimal performance.
What can honestly be more painful than having to write — and maintain — your deployment pipelines manually? Luckily, the entire CI/CD process is abstracted via modern platforms that fully automate the entire process. The result of automating your CI/CD process is that developers are now fully equipped to deploy their own code autonomously.
“The result of automating your CI/CD process is that developers are now fully equipped to deploy their own code autonomously.”
I don’t mean to plug Harness here, but I’m definitely going to plug Harness here. With Harness, you can easily abstract all of the painful manual scripts that you rely on into fully automated CD pipelines that swiftly deploy your services into production. The end result is that thousands of developers within large organizations are now unleashed and fully deploying their code autonomously.
To prove my point, I performed a search for a “fullstack developer” using stackoverflow. I found the following posts with specific statements indicating a clear trend in the direction of a widestack developer. Each job posting had a clear indication that the role they’re hiring for owns the entire software development lifecycle. Each bullet is part of the job description that applicants must know and have experience with.
Well, you might be right... in the short term. Do you remember a time when system administrators had to replace and upgrade CPUs manually? Or plugin and connect network switches with CAT5/6/7/8 cables?
Good times, right?
No. Hell no. Of course not. They weren’t good times.
And even if they were, you sure as hell don’t remember them because you were probably not even graduated from high school yet. That was way before your time.
Technology changes. It evolves. The responsibilities continue to isolate, become abstracted, and fade into the abyss of some data center or a sophisticated new platform that comes along to make things easier and better. So how is the modern stack any different? There is a trajectory that alludes towards continued abstraction and reduced barriers to deployment. All you have to do is connect the dots, and you can easily see a trend.
If you’re interested in automating your deployment pipelines, give Harness a spin. You’ll be amazed at how easily you can do cool things like:
Enjoyed reading this blog post or have questions or feedback?
Share your thoughts by creating a new topic in the Harness community forum.