The serverless architecture market was estimated at $4.25 billion in 2018 and is expected to reach $14.93 billion by 2023, according to analyst firm Markets and Markets.
What has propelled the use of serverless? Faster deployment, the simplification and automation of cloudops (also known as “no ops” and “some ops”), integration with emerging devops processes, and some cost advantages.
That said, most people who want to use serverless don’t understand how to do it. Many think that you can take traditional on-premises applications and deem them serverless with the drag of a mouse. The reality is much more complex.
Indeed, serverless application development is more likely a fit for net new applications. Even then you need to consider a few things, mainly that you need to design for serverless.
Just as you should design for containers and other execution architectures that are optimized by specific design patterns, serverless is no exception. The most common mistake that I see is forced fit with serverless, with an underoptimized result.
Some tips for serverless design include:
- You need to break up applications into independent and short-lived services. Serverless systems run application components as discrete functions. For many this is an unnatural act.
- To that end, the serverless applications should also be stateless. This supports services such as API management, which is core to the success of serverless applications.
- Security should be systemic. Security must be a top priority when designing and building the serverless applications.
- Think testing automation, focused on unit testing. Considering that serverless applications are a collection of short-lived functions/services, that test should follow in kind. Automate testing services for the serverless development environment and understand that testing functions independently will be more valuable than testing the application holistically.
The trick to building and deploying applications on serverless systems is understanding what serverless is and how to take full advantage. We have a tendency to apply all of our application architecture experience to all type of development technologies, and that will lead to inefficient use of the technology, which won’t produce the ROI expected—or worse, negative ROI, which is becoming common.
Hopefully this was worth the three minutes it took you to read this blog.