We'll look at factors to consider when migrating existing applications to serverless, as well as common ways to extend serverless.
Migration Patterns
At a high level, there are three migration patterns you could use to transition your legacy applications to a serverless model.
Leapfrog
As the name implies, you skip the intermediate steps and proceed directly from an on-premises legacy architecture to a serverless cloud architecture.
Organic
- As the name implies, you skip the intermediate steps and proceed directly from an on-premises legacy architecture to a serverless cloud architecture. In a "lift and shift" model, on-premises applications are moved to the cloud.
- Existing applications are kept intact in this model, either running on Amazon Elastic Compute Cloud (Amazon EC2) instances or with minor rewrites to container services such as Amazon Elastic Kubernetes Service (Amazon EKS)/Amazon Elastic Container Service (Amazon ECS) or AWS Fargate.
- Developers test Lambda in low-risk internal scenarios such as log processing or cron jobs.As you gain experience, you may be able to use serverless components for tasks such as data transformations and process parallelization.You take a more strategic look at how serverless and microservices might address business goals like market agility, developer innovation, and total cost of ownership at some point along the adoption curve.
- You gain support for a longer-term commitment to invest in modernising your applications and choose a production workload as a test case.Adoption accelerates as a result of early success and lessons learned, and more applications are migrated to microservices and serverless.
Strangler
1.The strangler pattern decomposes monolithic applications incrementally and systematically by creating APIs and building event-driven components that gradually replace components of the legacy application.
2.Distinct API endpoints can point to old vs. new components, and safe deployment options (such as canary deployments) allow you to safely point back to the legacy version.
3.Legacy components can be decommissioned as they are replaced, and new feature branches can be "serverless first."
This pattern represents a more systematic approach to serverless adoption, allowing you to move to critical improvements where you see benefits quickly but with less risk and upheaval than the leapfrog pattern.
Considerations for Legacy-to-Serverless Migration
• What is the purpose of this application, and how are its components organised?
• How can you divide your data requirements according to the command query responsibility (CQRS) pattern?
• How does the application scale, and what components drive the required capacity?
• Do you have tasks that must be completed on a specific schedule?
• Do you have workers listening to a queue?
• Where is it possible to refactor or improve functionality without affecting the current implementation?
Micro services Principles
• Have capabilities in your org to do things like rapidly provision, monitor, and use rapid deployment.
• (DevOPs Culture is a must)
• Be able to scale based on it’s needs
• Accept that the service going to evolve
• Handle their own data needs
Micro services Patterns
Technical
Have a decision process
Consider using events where it makes sense and
how you might scale commands & queries
Protect against cascading failures
Operational
Bootstrap services with organizational capabilities
(Logs, Tracing)
Low friction deployment, Finer-grained execution
environments, speed, isolation
Application Load Balancer vs. API Gateway for directing traffic to serverless targets
Ownership cost
When comparing ownership costs, consider three factors:
• The infrastructure cost to run your workload (for example, the costs for your provisioned EC2 capacity vs. the per-invocation cost of your Lambda functions)
• The development effort to plan, architect, and provision resources on which the application will run
• The costs of your team's time to maintain the application once it is in production
Top comments (0)