Cloud migration is the process of moving data, applications, or other business elements from an on-premises environment either partially, or fully to a cloud-based one offered by a popular cloud services provider like Azure, AWS, or Google Cloud. This post explores different approaches to building your cloud migration strategy using an API Gateway.
Benefits of moving to the cloud
For companies that undertake the process of cloud migration, the cloud can have a massive impact. This includes saving money on the hardware needed for IT infrastructure, faster time to delivery, scaling your apps per your need, securing business-critical workloads and most sensitive data, and enhanced opportunities for innovation.
Here, we summarized further benefits of migrating to the cloud:
Increased agility and flexibility
Ability to innovate faster
Easing of increasing resource demands
Better managing of increased customer expectations
Reduction in costs
Deliver immediate business results
Simplify IT
Shift to everything-as-a-service
Better consumption management
Cloud scalability
Improved performance
Cloud migration challenges
Cloud migration can bring significant benefits, but there are quite a few challenges along the way such as not having a cloud migration strategy at the beginning, complex existing architecture, long migration process, business downtime during the migration, organizational adoption, security and compliance.
Businesses move to the cloud to enjoy increased service availability, scalability, or any of the other benefits that the cloud promises. However, taking full advantage of the cloud requires careful design and planning to ensure that an organization has selected the cloud best suited to its use case.
Cloud Migration Strategies
There are a number of approaches to evolving or migrating an API-based system toward the cloud, ranging from retain (“do nothing”), to rehost, replatform, repurchase, refactor/re-architect (rewriting to taking advantage of cloud infrastructure), and retiring.
This post outlines 6 different migration strategies and is a great jumping-off point if you have been tasked with evaluating or leading a migration of your existing architecture and systems to the cloud. As APIs are often the closest business-driven component to the user—and a key point of ingress for the majority of requests—you should pay special attention to them when deciding on your approach to migration. The six Rs present a spectrum of options from “do nothing” all the way through to a complete rebuild or retiring of a system. They are:
Retain or Revisit
Rehost
Replatform
Repurchase
Refactor/Re-architect
Retire
Role of API Management in the cloud migration
Regardless of the strategy chosen for your evolutionary journey, API management can play a key role in migration and unlocking the value of APIs across and outside an organization. API managers are essentially a supercharged gateway at heart, providing various additional features for publishing and controlling APIs. API managers provide policies that enable edge concerns, such as OAuth2 challenges, content validation, rate limiting, caching, throttling, and many other features that are typical in a gateway. There are many API management tools and just be aware of how to choose the right one.
Additionally, they can provide developer portals containing a marketplace of all APIs that developers can use when building systems to consume offered APIs. Organizations can also use API management to monetize accessing APIs, both to external customers and for internal “chargebacks,” which are common in enterprises and cross-divisional deployments. Perhaps the most important part of API management is that it can offer a central point to discover APIs, while you continue to make changes behind the scenes.
API Gateway as a tool for migration
API Gateway is an essential component of API management solutions. You can read the 10 most common use cases of an API Gateway on the Apache APISIX blog. The use of an API gateway can provide location transparency for services and APIs being served, which allows the deployment of a service into the cloud and traffic to be gradually shifted from the existing service to the new one with limited (or no) impact on consumers.
Below 3 possible strategies:
One way to use an API Gateway in a cloud migration strategy is to start by creating a proxy for your on-premises services. This allows you to redirect traffic from your on-premises services to the corresponding services in the cloud, without making any changes to your existing applications. We can also do simple A/B testing, gather metrics about the new cloud endpoint performances and user experience, and switch back to the on-premise service if, for any reason, the new service in the cloud is not suitable.
Another strategy is to use an API Gateway as a façade for your cloud services. This allows you to hide the complexity of your microservices architecture from external consumers, while still allowing them to access the functionality they need.
A third strategy is to use an API Gateway to implement a service mesh that can help you implement zero-trust networks. This allows you to manage and secure communication between microservices, without having to make changes to the individual services.
The Apache APISIX's services turn out to be an efficient solution to implement above concerns, as it can act as a proxy for the entire application, or otherwise as a single access point. Acting as a proxy, API Gateway is able to efficiently handle requests and route the legacy application with refactored endpoints.
Replatforming a sample application to the cloud
Let’s assume that we have a conference application that has 5 main components: a web app, API Gateway, a legacy conference system, and two microservices (Session and Attendee). You can see the responsibility of each service in the below architectural diagram.
Your team chooses to incrementally migrate the conference app services to a cloud—rather than risk a big bang—the running of services across multiple cloud environments and on-premise data centers does present additional challenges. Given this task, you decide to “replatform” first the Attendee service. As you have already re-architected the attendees’ functionality, by extracting this to an independent microservice in the earlier stage, the refactor/re-architect strategies did not appear appropriate. However, when you are adding new functionality into the conference system in the future, re-architecting the system (potentially extracting a service) and moving this to the cloud would be an option to strongly consider. Rehosting could be a solid strategy, but we are keen to take advantage of a cloud-based database-as-a-service rather than “lift and shift” our own MySQL database instance.
Also, you need to migrate the API gateway to the cloud (Or use APIM solutions provided by cloud vendors) because, with many incremental cloud migrations, traffic will need to transit multiple networks in order to satisfy an API request made by a user. Moving the API gateway to the cloud now will also help to support API traffic being incrementally routed from the existing on-premises location to the cloud. The below diagram shows the final state of the replatformed architecture.
Summary
Overall, using an API Gateway in a cloud migration strategy can provide many benefits, such as ease of management, security, and scalability. It allows you to gradually move your services to the cloud, and it can help you to hide the complexity of your microservices architecture from external consumers. For example, Apache APISIX is a fully open-source and cloud-native API traffic management solution that you can deploy to any cloud and improve developer productivity with built-in plugins that reduce the time for your cloud migration.
Comments