Hey there, my name is Ryan Jones. I’m a Serverless Application Developer and I also where the CEO hat for running the day to day operations of a Cloud Consulting company called, Serverless Guru. Above is a photo from a recent talk I did at DevOps PDX on the effect of Serverless on the software development lifecycle.
In this short article, we are going to cover a topic which is near and dear to my heart. The impact Serverless has on Developer Velocity (boom, used the title). Velocity meaning acceleration and acceleration meaning speed. I love to harp on how Serverless can speed up development because it’s frankly just the truth. Hopefully, I can give you some of my reasons in the paragraphs below.
We are all fully aware that automation is a key ingredient to increasing developer velocity. We usually do this in the form of bash scripts, python scripts, IAC, CI/CD pipelines and so on. In more traditional organizations the developers are only responsible for the application code. Then all the other factors are handed off from team to team. Each hand off slows down the delivery time, causes more duplicated steps, and involves more meetings.
Why is Serverless application development different?
The developers are writing ALL of the automation. This is a good thing for numerous reasons. The biggest being the developers understand the full range of the application from the code to the deployment to the CI/CD and on down the line.
When you combine multiple disciplines together. It requires reimagining how things are done. It requires thinking about how to scrape away long winded processes in favor of the most linear path. This means leveraging services which lean almost entirely towards the fully managed paradigm.
The core of Serverless application development is leveraging as many fully managed services as possible to remove the overhead of needing to know the inner workings of every system your application code leverages. This dramatically increases the speed of development for new projects as well as existing projects when new functionality is required.
When you leverage a fully managed service on a cloud provider. You’re choosing to worry more about your product then the infrastructure supporting the product. The decision is not something new. Even organizations who are on the opposite spectrum of Serverless application development still leverage services on their chosen cloud provider to handle any number of tasks.
We are just taking it to the extreme. Leveraging as many fully managed services as possible to lower the overhead of running applications at scale and speeding up every supporting process.
Serverless isn’t the first solution which uses templates to do things. Templating is in every layer of application development. All though, when you’re building Serverless applications you are (should be) building the IAC (Infrastructure as Code) at the exact same time you’re writing the application code. IAC defines the resources that your application uses in a repeatable template that can be torn down and redeployed with no manual steps (ideally).
Why does this matter?
When you’re writing application code and also building the IAC to deploy the resources that your application code will use. You’re skipping a lot of steps (e.g. hand offs to other teams) and also empowering your developers to learn more about how the application deployment, networking, and hosting is built and configured.
While at the same time, creating a library of reusable infrastructure templates that can then be recycled to build out POC’s (Proof of Concepts) extremely quickly. Which is a beautiful thing. Taking an idea to a reality is hard, usually MOST of the work has nothing to do with the product. It’s a lot of foundation laying and setup.
Why does this have an “impact”?
As the developers become more comfortable writing IAC patterns then they also become better equipped to think deeply about how to optimize their code base and how to prevent the software development disease of constantly reinventing the wheel. From my experience, when you have more understanding of the parts that consume your application code then you choose services which extend your code while reducing the things on your plate.
The best code, is the code you don’t write
In an environment where everything is handed off to other individuals and to other teams. A common pattern arises, people can become complacent. They start handing things off and treating the whole process as a black box. Where you put something in the box, then it either gets rejected or accepted. It’s far to easy to start handing things off which are not at a high quality because “it’s not your job”.
Service Ownership as a bi-product?
When Serverless application developers are writing the code and IAC, deploying supporting resources to the cloud (e.g. databases, buckets, queues), and writing automation as well as CI/CD pipelines to accelerate pushing new code out into the world. The two pizza team concept that Amazon pushes can be incorporated at a small scale into a single individual. That’s powerful, especially for startups.
There are a lot of benefits to Serverless application development. This article has only touched on a few of these benefits, but each one could be expanded into it’s own article.
Thanks for reading 🎉 🎉
- Industry Predictions for 2019
- Best Practices for Serverless Development
- Serverless CI/CD
- Serverless Web Applications — AWS v GCP
- Serverless Impact, Developer Velocity
- Guide, First Serverless Project
What does Serverless Guru do?
Serverless Guru helps companies build scalable and cost-effective applications on the cloud. We help train companies on how to leverage IAC, serverless, and cloud-native services. We help migrate existing applications to the cloud and optimize existing applications on the cloud to be more cost-effective. We are a Serverless development partner and an AWS Consulting partner.
What did we miss?
When you leave your answer make sure to either comment below or tweet your answer to @serverlessgurux on Twitter.
Founder — Serverless Guru
LinkedIn — @ryanjonesirl
Twitter — @ryanjonesirl
Thanks for reading 😃