In this article, we are going to be talking about migration to serverless. This topic is becoming more widely needed as more companies start adopting serverless into their companies. Typically, people learn about serverless from events, such as AWS re:Invent or ServerlessConf, or through community thought leaders.
Once people learn about the benefits of serverless it becomes hard to unlearn that serverless exists. Serverless is the cloud singularity that the industry has been headed towards since the release of AWS Lambda back in 2014.
So let’s go ahead and dive in, starting with why you would even consider serverless.
Companies want to move quickly, adapt quickly to changing environments, and focus less on everything else that doesn’t directly benefit their product. For a long time, focusing on your product meant building a robust server or container orchestration system. Now we don’t need to do this. The serverless movement has lowered the barrier of entry for new developers while supercharging senior developers to ship features faster than ever at a higher quality.
The move to serverless, like any technology migration, requires careful thought to understand the core purpose for the move. If you have not first taken the time to understand where your problems lie and where serverless will help then you should step back and ask a few questions.
- Why do we want to move to serverless?
- Why do we think serverless will solve our problems?
- Why should we move to serverless now?
Once you have a clear understanding of why serverless then you should move on to how serverless.
Now that we know why you should consider serverless let’s talk about how to implement serverless.
When thinking about “how” to work with serverless and how to get your company started down that path, we need to spend time first understanding what is and isn’t a good fit for serverless.
At a high level, if you have unpredictable workloads or processes that only run a few times a day. Then you have a good fit for serverless. For example, Comic Relief’s use case is extremely matching with serverless. They accept their highest peaks several times a year and it’s peaceful for the rest of the year. Your use case might not be that extreme in terms of traffic but that should give an idea.
If your applications are handling high levels of traffic throughout the entire day or they are long-running processes then you should hesitate. The same goes for the makeup of your development team and how much cloud experience you have in-house. If you are starting from zero, it will probably be worth it to start a conversation with a serverless consulting company that can help you lay a foundation to build upon. (I know some good ones, please reach out to me on Twitter for more information)
If you want to make the move yourself, then take time to understand how all of your services will map into this new environment and identify a single service that is small enough to get an early success.
Once you have a single service migrated, take the learnings and apply them to a slightly larger service. An important step to ensuring that your serverless migration is successful comes from building solid tooling into your development at the onset.
Thundra is a great tool to help you monitor your migration as you move individual services. The Thundra platform will help your development team see insights quickly into how the migration is performing against your production traffic. Thundra will also help you set up alerts that can quickly notify your entire development team on what issues are popping up for customers. Moreover, Thundra is being used by many companies to monitor and secure the serverless and non-serverless parts of their architecture. This gives important flexibility during migration to serverless because you can see how your new serverless applications communicate with the non-serverless legacy system. In the following figure, you can see Thundra’s architecture view that shows AWS Lambda applications playing with Spring boot applications on Amazon ECS and other non-AWS resources such as a Redis cache.
The biggest advantage of having a tool like Thundra at the beginning is the baked-in best practices which would take quite a lot of time to build from scratch. After all, you are choosing serverless to focus more on your product and less on everything else. Treat your observability the same way. Leave it to the Thundra team to help offload your operations.
Okay so you’ve decided why serverless is for you and how you will get started, but now let’s talk about what serverless actually is.
What is Serverless
Serverless is purely an abstraction. It reduces the overhead on the individual development team by leveraging fully managed services provided by one of the many cloud providers. These cloud providers will create services that solve specific needs then open up the usage in a pay-per-use model where you’re billed for each invocation or request.
For example, when you use a cloud function, all you need to worry about is the application code. Everything else is handled by the cloud provider. When a request is made to your serverless API or cloud function, the cloud provider will handle installing your application code onto a container. When the request is finished and your backend system has finished processing, you will no longer be billed.
That is the beauty of serverless services. They allow you to do advanced development through leveraging services that are straight forward plug-n-play interfaces.
However, these “cloud legos” as some may call serverless service, can start to become too much to manage as your team scales and starts creating hundreds of cloud functions and supporting resources such as databases, asset storage, etc.
This is where the need for an observability tool like Thundra really comes even more into play during a serverless migration. The observability gained into how not only your application is behaving, but how your application is architected pays large dividends downstream.
Thundra has a generous free tier which will likely get you through the first few services migrated to serverless.
If you would like to get started with your serverless journey and use Thundra as your observability partner, follow this link.
Understanding that serverless is the correct solution for your organization is only the first part of the equation. Then begins the complexity of the migration itself and overcoming the hurdle of having sufficient and detailed observability thorough enough to evaluate the migration progress in real-time. There are limited options when it comes to implementing a single monitoring solution for the entire migration process, but this is where Thundra can come into play and ensure your organization is following best practices surrounding observability.