In this article, we’ll be giving you tips while discussing the steps in each stage of migrating to serverless—from preparation to migration to post-transition.
The Cloud Spectrum
To understand more easily the wider context of migrating legacy systems into a serverless form, we should first understand the cloud spectrum. This spectrum ranges from on-premises workloads to virtual machines, containers, and cloud functions. Serverless typically falls within the cloud functions area, as function as a service (FaaS), but now it’s an umbrella term growing to include back-end as a service (BaaS), such as fully managed databases.
The first thing when looking at legacy transitions is understanding where you are on the cloud spectrum.
Despite being four or five years old, we are starting to get into a cycle where even serverless apps are becoming legacy systems as well. Anybody that writes Node.js knows that if you make no updates for two years, you’re going to have dependencies breaking all over the place.
Your Serverless Experience
The next question to ask is: does your team already have serverless experience?
There are two different routes here:
- Yes: We already have serverless experience and we already have cloud experience. In this case, you need to identify the key team members who can help drive and evangelize the serverless migration, including training, pattern development, and so on. The engineering hours involved in the transition can all be streamlined by having the patterns, the documentation, and the training.
- No: If you don’t have that serverless or cloud experience internally, you would benefit from finding a consulting partner that specializes in serverless migrations (such as Serverless Guru or Theodo) or serverless adoption to help retrain and retool existing employees and help them grow.
The Serverless Acceleration Team
Following this, you would need to develop the serverless acceleration team. This would be a working group that will help accelerate the rest of your organization, which will focus on:
- building reusable infrastructure as code
- practices around building serverless apps
- processes around development workflow
Drawing Service Boundaries
Next, you need to identify a common service or use case. For that, you can ask the following question: what service represents 80% to 90% of how other services are built in the legacy system?
Let’s take a monolithic API as an example. If we have 100 endpoints and 10 of them are related to account and 10 of them are related to users and 10 of them are related to feeds, we can draw three service boundaries there. We could find that the APIs that are being done 100 times, one of them looks the same as the rest of the 100. With these service boundaries, we can start chunking this migration up into pieces. That makes it easier to migrate!
If we develop a pattern for one service boundary and it’s composed of 10 endpoints and there’s nine more of those services that all have 10 endpoints each, we know that if we can develop one, we can reuse it across the rest of them.
#devops #aws #serverless #serverless adoption
