Simplify Modernization of your monolithic application using Amazon VPC Lattice

The term “digital transformation” describes the implementation of new technologies, talents, and processes to remain competitive in an ever-changing technology landscape. Companies must embrace transformation initiatives to gain benefits such as improving productivity, improving customer experiences and reduce operational costs. A successful transformation journey involves both Migration and Modernization.  Modernization is the refactoring of legacy technology by combining modern infrastructure, architecture, organization patterns together to maximize resiliency, engineering efficiency, and business agility. Today, organizations are hyper-focused on modernization as a key technology strategy that delivers better customer outcomes, higher economic value, agility and enables innovation at speed. This blog post focuses on modernization with Amazon VPC Lattice service to help you reduce some of the additional network overhead.

Over the last decade, we have observed key challenges in cloud adoption journey that result in slowing down modernization efforts and prevent organizations from achieving cloud benefits. These include lack of developer skillsets required to modernize applications with containerization, microservices and DevOps cloud technologies. Additional challenges include existence of organizational silos and the phenomenon of “analysis paralysis”. Organizations are facing difficulties in refactoring of complex and breaking down business logic of their large, tightly coupled monolithic applications. This typically involves network and application layer complexity coupled with placement of modular components known as microservices in multiple Virtual Private Cloud (VPC) or multi-account deployment scenarios. Complex network setup and routing policies between AWS accounts or VPCs can directly impact developer’s productivity and Time to Market (TTM). Additional challenges include fear of increased complexity by way of instantiating too many AWS accounts, overlapping Classless Inter-domain Routing (CIDR) blocks and VPC Peering relationships. Organizations also worry about higher cloud operational cost and lower agility for cloud admins.

Amazon VPC Lattice is a fully managed application networking service that simplifies the way different personas such as Developers, Cloud administrators and Network administrators connect, secure and observe communication, with application layer networking between services.

In this blog post, we show how Amazon VPC Lattice simplifies complex networking architectures while modernizing your enterprise workloads on AWS.

Solution Overview

We show how VPC Lattice help with the network portion when breaking down monolith application into microservices and application/service dependency. In addition, we also cover some of the most common deployment techniques using VPC Lattice features such as weighted routing, path-based routing, and host-based routing.

Finally, we address various dimensions that determine the cost of using Amazon VPC Lattice service including cost comparisons against traditional networking constructs such as AWS Transit Gateway (TGW) and AWS Application Load Balancers (ALB).

Pre-requisites

The reader is expected to know Amazon VPC Lattice and how it works before understanding how it solves current modernization and deployment use cases. Please read about Amazon VPC Lattice in this documentation here before proceeding further.

Modernization Use case

Application Modernization strategy is driven by business goals and then focuses on technologies. A very popular strategy to modernize applications is by breaking it down into microservices. There are many ways you can decompose monoliths – by business capability, subdomain, transactions, services per team, strangle fig etc. Please take a look at the AWS prescriptive guidance to decompose the monoliths into microservices. A common strategy is to decompose by business functionalities.

Figure 1 Breaking down .NET based e-commerce app into microservices

Alt Text: The above diagram shows a .NET based monolith e-commerce app broken down in to several microservices (auth, billing, inventory, cart) based on its business functionalities.

Let’s take an example of a .NET based e-commerce monolithic application that is tightly coupled with several business functionalities such as billing, auth, cart, or inventory services etc. Customers often use AWS Microservice Extractor for .Net to refactor old .NET based monolithic applications into microservices. This would mean breaking it down into billing, cart, auth, inventory microservices etc.  But deploying microservices in to multi-account or multi-VPC environment often pose the following challenges:

1.     Hard to connect microservices and applications together.

2.     Complex deployment strategy for microservices that are spread across many VPCs

Let’s see how VPC Lattice helps solve the above challenges when breaking down monoliths into microservices.

Modernization with VPC Lattice

In this section, we will cover 2 modernization scenarios for the .NET e-commerce application (Breaking down monolith and app dependency) and how Amazon VPC Lattice solves the network portion of it.

Use case – VPC Lattice in the microservices architecture

VPC Lattice help establish connectivity between microservices, or consumers and microservices that are located in more than one AWS account or VPC without requiring customers to setup any network devices. VPC Lattice also allows developers to implement application layer networking that provides access granularity.  Let’s see how you can configure VPC Lattice to allow consumers of the application to connect to microservices in different accounts.

Figure 2. VPC Lattice in the microservices architecture solving application layer networking

Alt Text: The above diagram shows a VPC Lattice Service Network in service network account connecting consumers of the app to the auth and cart microservices in two distinct provider accounts.

As you can see in the above diagram, you have consumers of the application in consumer account and cart & auth services in provider account A and B respectively.

1.     Create a VPC Lattice Service Network. Most organizations create a shared service network account when designing a multi-account strategy so it is recommended to utilize this AWS account for creating a VPC Lattice Service Network as shown.

2.     Create target groups for the auth and cart service and register the targets.

3.     Create VPC Lattice services for your microservices (auth and cart) in the VPC Lattice console and add the listener configuration.

4.     Share the Lattice service network with other AWS Accounts (Consumer Account, and Provider Accounts A & B) using the AWS Resource Access Manager (AWS RAM) service.

5.     Once the Lattice service network is shared, create service associations from the service network to the auth and cart VPC Lattice services as shown with red lines in the above diagram.

6.     Create a VPC association from the consumer account to the service network as shown in yellow line in the above diagram.

7.     Setup access policies for the service network and the individual VPC Lattice services.

8.     After associations are established, consumers of the application can now access the microservices in different accounts using VPC Lattice and without setting up any additional network devices.

Use case – VPC Lattice solving Application/Service Dependency

Figure 3. VPC Lattice solving application/service dependency

Alt Text: The above diagram is a generic model showing App and Service dependency mapping. 

In an organization’s cloud environment, applications and services are dependent on each other as shown in the above diagram.  Applications send logs/metrics to a logging or monitoring service. When migrating such interdependent applications and services, it is important to discover and collect the dependency mapping data by using a discovery tool before initiating the migration. After gathering the discovery and dependency data, you need to carefully plan to deploy the applications or services across different accounts or VPCs. Developers deploying services in one AWS account often worry about the connectivity with others and they have to work with cloud admins for every single deployment. With VPC Lattice, developers can create services within VPC Lattice, define routing rules, and also associate services with the service network without relying much on cloud admins. Now let’s see how Amazon VPC Lattice helps with connecting applications or services together.

Figure 4. VPC Lattice in the microservices architecture solving application/service dependency

Alt Text: The above diagram shows a VPC Lattice Service Network in service network account connecting the inventory, billing and cart microservices together in three distinct provider accounts. The service association of VPC Lattice services with VPC Lattice service network is shown in red color. Based on use case (which microservice talks to the other), the VPC associations are made in orange color. For eg.the billing service wants to talk to the inventory service, so the billing VPC is associated with the service network.

In the above .NET e-commerce example, the application is broken down into inventory, billing & cart services and placed in three different AWS accounts. These services are dependent in such a way that billing service will talk to inventory service before placing the order, the inventory service will talk to the cart service for updating product catalog. But the billing service will not talk to cart service. To meet the application dependency needs, developers can follow the below steps:

1.     Create a VPC Lattice Service Network in the shared service network account.

2.     Create target groups for the inventory, billing, and cart services and register the targets.

3.     Share the VPC Lattice service network with other AWS Accounts using the AWS Resource Access Manager (AWS RAM) service.

4.     Create VPC Lattice services for inventory, billing, and cart and associate these services with the VPC Lattice service network as shown in red lines.

5.     Create VPC associations with service network (yellow lines).

Note – Since the billing service will be talking to the inventory service, billing service’s VPC will be associated with the service network. Also, inventory service’s VPC will also be associated with the service network so it can talk to the cart service.

6.     Since the billing service cannot talk to the cart service, a service policy or service network policy can be implemented to block the traffic from billing to the cart service. Please take a look at how you can manage access to services to implement service blocks.

Deployment using VPC Lattice

VPC Lattice allows you to implement advance traffic controls such as request level routing or weighted targets for blue/green and canary deployments. In this section, we will cover deployment techniques for deploying the microservices for the .NET e-commerce application and how Amazon VPC Lattice helps with it.

Weighted Routing (B/G deployment)

Customers can configure a routing policy within VPC Lattice to split the traffic between VPC Lattice services using weight in the same AWS Account.

Figure 5. VPC Lattice using weighted routing for microservices deployment

Alt Text: The above diagram shows a VPC Lattice Service Network in service network account connecting consumers of the app to the auth and cart microservices in same provider account but different VPCs. A new version of the cart service (cart++) is deployed and the VPC Lattice Service implement weighted routing to split the traffic 80:20 between old cart and new cart (cart++) service.

For the .NET e-commerce application, let’s assume that a new version of the cart service i.e. cart++ needs to be deployed. In order to deploy the latest version of the cart functionality using B/G deployment, developers can follow the below steps:

1.     Create a new target group for the cart++ service and register the target.

2.     Update the listener configuration for the existing VPC Lattice cart service to split the traffic between original cart and new cart++ target.

At this point, developers can choose to implement a Canary, or Linear or All-at-once deployment type using a weighted routing policy.

Finally, cutover 100% of the traffic to the cart++ service and decommission the cart service.

Path/Host Based routing

Customers can configure a custom routing policy to cutover the traffic from the old cart service to the new cart service.

Figure 6. VPC Lattice using path/host based routing for microservices deployment

Alt Text: The above diagram shows a VPC Lattice Service Network in service network account connecting consumers of the app to the auth and cart microservices in same provider account but different VPCs. A new version of the cart service (NewCart) is deployed and the VPC Lattice Service can implement path or host based routing to cutover the traffic from old cart to the NewCart service.

With VPC Lattice, you can setup host-based or path-based routing policy to route the traffic on the application layer. For the .NET app example above, when developers want to deploy a new version of the cart service, they can follow the below steps:

1.     Create a new target group for the NewCart service and register the target.

2.     Modify the listener configuration on the existing VPC Lattice cart service to reflect the target group as NewCart service for the existing VPC Lattice cart service and cutover the traffic all-at-once to the NewCart service, subsequently decommissioning the old cart service.

Amazon VPC Lattice pricing considerations

Three dimensions determine the cost of using Amazon VPC Lattice: number of services provisioned, data processing charges for traffic to and from each service, and number of requests that each service receives. For exact pricing details, please refer to VPC Lattice Pricing page.

Prior to launch of AWS VPC Lattice service, customers until now have been using traditional networking constructs such as AWS TGW and using ALBs for interconnecting VPCs and running HTTP/S based applications on AWS. In these types of networking architectures, there are mainly 2 types of charges; one is the per hour charge: for TGW attachments and for ALB. The second type of charge is data processing charge applicable for TGW and for ALB. Refer to the AWS Transit Gateway Pricing as well as Elastic Load Balancing Pricing for details.

Depending on your specific use-case, existing AWS networking architecture, and technical requirements, you can further optimize AWS cost using AWS VPC Lattice service or continue to leverage TGW/ALB based networking constructs for interconnecting service residing across multiple VPCs on AWS.

Conclusion

In this blog post, we discussed how you can use Amazon VPC Lattice to solve common challenges when modernizing applications using iterative modernization solutions and architecture patterns. We reviewed the following VPC Lattice use cases in the context of modernization to AWS:

a.     Breaking down monoliths to microservices

b.     Application/Service Dependency

We also reviewed deployment techniques using VPC Lattice when deploying microservices:

a.     Weighted Routing (B/G deployment)

b.     Path-based/Host-based Routing

Finally, we walked through cost considerations of VPC Lattice service. If you have questions about this post, start a new thread on AWS re:Post, or contact AWS Support. For more information about Amazon VPC Lattice, you can refer to the documentation and additional blogs.

About the authors: