The way we build software products changes all the time. Serverless architecture opens up new opportunities to create awesome products faster. Not only that, serverless applications are more scalable, secure and maintainable – all with much less code.
Serverless is the future of development and you should get ready for it.
But what does it mean to be a serverless developer? What do you need to understand before jumping into the serverless pool?
My journey into serverless
Over the past decade, I’ve worked as a traditional enterprise developer creating security and performance monitoring products used by a variety of Fortune 100 companies.
Most of the products were built using technologies like Java, Spring, MongoDB, Postgres, ActiveMQ, CentOS, and so on. All very common, well-understood, battle-proven enterprise technology stacks.
A few months ago I decided to make a big change and joined Lumigo, a pure serverless company. Lumigo is a cool young startup in the serverless world and a far cry from what I was used to.
This change helped me get out of my comfort zone and open myself up to new architecture opportunities. The technology stack at Lumigo is very different from what I was used to, a mixture of Python, Node.js, DynamoDB, Kinesis, AWS Lambda, API Gateway, etc. But it wasn’t just the technology that was new and unfamiliar…
Serverless changes everything
The first thing to know about building an application using serverless architecture is that it means using managed services instead of writing or managing them yourself.
Let’s take as an example a simple application which has one flow: returning the current value of a specific stock. The concurrency of this application needs to be 5,000.
A naive solution would be to build a Java application where our application would handle 5,000 tasks in parallel by having a thread per request.
The number of threads you can create in a single JVM depends on the amount of memory you pre-allocated for the JVM and the amount of CPU you have on your machine.
In AWS Lambda, you can auto-scale to 5,000 concurrent requests without pre-allocating CPU or memory resources.
Great! Problem solved. Serverless is awesome, right?
Not so fast. Beneath that seemingly simplified workflow lies a whole host of new challenges waiting to trip up the unprepared.
Debugging
If until now you could simulate your desired scenario and use your favorite debugging tools, with AWS Lambda that’s no longer an option. The highly distributed nature of serverless architecture and the involvement of managed services means that traditional debugging tools are off the table.
This means that the best way to debug your application is by using logs and dedicated tools.
For example, consider a simple flow like this:
Debugging this simple flow might require you to use any or all of the following tools:
- Cloudwatch
- Lambda logs
- API Gateway logs
- Cloudformation logs
- Serverless framework logs
- AIM logs
- etc..
When it comes to more complicated flows, distributed tracing is another option. But it’s still a challenge, and could involve changes to your codebase.
Configuration vs Coding
In the past, your business logic code and the architectural decisions were written in the same code scope, while in a serverless application, the architectural decisions are decoupled from the scope of your business code.
To achieve the above concurrency in traditional Java development you would simply create a thread pool with 5,000 threads. Pretty easy.
On the other hand, when using serverless your Lambda code will probably be focused on handling a single request and concurrency will be configured outside the Lambda scope.
Cost
In traditional architectures, you would ask for the right box for the job, and it’s easy to calculate the price of the specific box.
In the serverless world, you’ll need to become familiar with an entirely new concept: “Pay As You Go“.
It is one of the most appealing features of FaaS platforms, and – in most cases – it should help you save money in the long run.
But it raises the challenge of cost estimation. It is much harder to calculate the future cost of your operation, and this means that you need to set some limitations on your expenses.
You need something that will protect you from a cost explosion, otherwise a bug or unforeseen circumstances could end up costing you a lot of money.
Testing
In serverless, your production runs on an environment provided by your cloud vendor of choice. So, to ensure your application runs correctly you must validate your code in a real cloud environment.
This means that your current system and integration testing infrastructure will run on the cloud and will probably use a cloud provider API.
Your traditional testing infrastructure likely won’t be a good fit for serverless application testing and this means you might need to redesign it.
Security
Cloud services can help you create a much more secure application. The tradeoff is that you should get to know your cloud provider role and policies system because not understanding this mechanism can cause security holes and potentially break your code.
Context switching
In the traditional app stack, context switching is minimal, as most of the coding and configuration are part of you same scope (Spring for example). This means you stay in the same context to do most things. In the serverless world, even when creating a simple application you will end up with different languages and frameworks for the BL code and the configuration code, which causes a lot of context switches.
Best practices
Serverless is a new architectural style and, despite the fast adoption rate, there are still many best practices missing. This will get better as time goes by but if you are used to getting all the answers with a quick Google search, think again.
An Open Mind
As you probably understand by now, the move to serverless will have a huge impact on the way you develop. It will force you to drop old habits and gain new ones. You should come with an open mind and be ready to learn new stuff because a lot is going to change.
Summary
If you are thinking about making the jump from traditional to serverless architecture you should understand that it is not a quick win, it is a journey and like any journey, you should get prepared for it.
I hope this article helps you understand which topics you have to pay attention to when starting with serverless development.
For me, serverless is a great solution to many of the architecture challenges I had before. It is a real refresh from the traditional developments stacks. If you haven’t tried serverless before, by all means, you should give it a try 🙂
Thanks for reading! If you have any questions about moving to serverless, or would like to share your own experiences with making the move, get in touch on Twitter.