{"id":3983,"date":"2021-12-24T13:59:00","date_gmt":"2021-12-24T12:59:00","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=3983"},"modified":"2021-12-22T16:13:49","modified_gmt":"2021-12-22T15:13:49","slug":"gradual-migration-and-refactoring-of-applications-to-serverless-leveraging-amazon-api-gateway","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/gradual-migration-and-refactoring-of-applications-to-serverless-leveraging-amazon-api-gateway\/","title":{"rendered":"Gradual migration and refactoring of applications to serverless leveraging Amazon API Gateway"},"content":{"rendered":"\n

Nowadays, more and more apps, services, and projects are developed following the serverless approach.<\/p>\n\n\n\n

Several applications may leverage the serverless paradigm to improve performance while achieving both high availability and elasticity. Still, they need to be migrated and heavily refactored.<\/p>\n\n\n\n

Migrating an application to serverless often involves a partial rewriting of the codebase to implement an execution model suitable for the FaaS service chosen. Also, the overall architecture should embrace microservices and an event-based flow, favoring, when possible, asynchronous processing and high decoupling using messaging services.<\/p>\n\n\n\n

To achieve the above specifications, especially in the case of complex applications, the effort and time required can easily reach impressive magnitudes.<\/p>\n\n\n\n

Sometimes, it’s simply not feasible to completely refactor a whole application before its deployment.<\/p>\n\n\n\n

This article will illustrate a technique that uses API Gateway to perform the routing and adaptation of user’s requests, allowing the gradual migration and refactoring of complex applications without affecting their availability.<\/p>\n\n\n\n

Why API Gateway?<\/h2>\n\n\n\n

Amazon API Gateway is a managed service that serves as the front door of your application. It acts as a managed gateway for the backend; it can also directly integrate with other supported AWS services to push the payload into the appropriate processor or message system. API Gateway can handle hundreds of thousands of concurrent API calls and perform traffic management, CORS support, authorization, access control, throttling, monitoring, and API version management. <\/p>\n\n\n\n

The technique illustrated in this article leverages API Gateway capabilities to act as a proxy for the entire application, accept the requests, make the required changes to the payload format, and perform the routing between the legacy application and the refactored endpoints.<\/p>\n\n\n\n

Gradual replatforming and refactoring in theory<\/h2>\n\n\n\n

The method we propose in this article is to map all the application endpoints undergoing migration to a single API Gateway which will act as a centralized access point for the application.<\/p>\n\n\n\n

Once all the requests flow towards a single infrastructural object, it will be possible to maintain two distinct versions of the application: the legacy one and the new version, which we can implement incrementally.<\/p>\n\n\n\n

<\/p>\n\n\n\n

\"infrastructure<\/figure><\/div>\n\n\n\n

<\/p>\n\n\n\n

Once we have mapped all the endpoints to the Gateway API, we must configure it to proxy the current application infrastructure.<\/p>\n\n\n\n

To do so, we can use a specific integration called “HTTP”, which you are required to enable the proxy option as shown in the following image.<\/p>\n\n\n\n

<\/p>\n\n\n\n

\"enable<\/figure><\/div>\n\n\n\n

<\/p>\n\n\n\n

At this point, API Gateway can become the only access point of the solution. It should be possible to operate the DNS to point the domain to the new entry point and see all the traffic flow through the Gateway without any application change required.<\/p>\n\n\n\n

We can now start to rework parts of the application; a good strategy may be to move single microservices if possible. In the case of extensive services or monolithic applications, there is also the option to migrate single endpoints, refactoring them to serverless, and change the setting for those endpoints to route the relevant requests to the new version.<\/p>\n\n\n\n

We can also do simple A\/B testing, gather metrics about the new endpoint performances and user experience, and switch back to the legacy application if, for any reason, the new one is not suitable.<\/p>\n\n\n\n

Since all traffic passes through API Gateway, it is possible to obtain valuable metrics from the service, such as traffic volume, response times, and error rates.<\/p>\n\n\n\n

Additionally, we can leverage CloudWatch to monitor requests and configure alarms and push notifications.<\/p>\n\n\n\n

Special considerations on monolithic applications<\/h2>\n\n\n\n

The technique exposed in this article is pretty simple; however, there are some considerations for migrating a monolithic application. For this type of application, it is generally necessary to provide extra effort to “break” the monolith and implement changes to the existing infrastructure to take full advantage of Cloud services.<\/p>\n\n\n\n

It is not always necessary to break monolithic applications to migrate them to serverless; for example, migrating a backend application that exposes simple RESTFUL and stateless APIs. In that case, it is possible to take several roads, including:<\/p>\n\n\n\n