youri babakhanians - Fotolia
How do microservices API gateways aid monolith migrations?
How do you move a set of REST resources to microservices? One way is to use an API gateway. Follow this example to learn how migrate to microservices-oriented architecture.
You've been asked to transform a monolithic application into one with a microservices-oriented architecture. How would you go about making the transformation? An API gateway for microservices is often the piece organizations need to solve the microservices migration puzzle.
Let's use this example to show how an API gateway for microservices works. The following monolithic application, as shown in Figure 1 below, is represented by a set of REST resources hosted by the fictitious API provider MyCoolVehicles.com.
The purpose of the API is to facilitate viewing, buying, selling, trading and registering activities for vehicles. You've been asked to transform the monolith API into a microservices-oriented API.
One of the popular ways to refactor a monolithic REST API is to use an API gateway for microservices.
In a monolithic REST API, all resources are housed within the same application domain. In practice, this means that an HTTP request to a URL endpoint representing a REST resource is sent to a web server, which in turn forwards the particulars of the request to an application server that contains the logic associated with the given resource. You can see this play out in the figure below.
Logic for all the resources lives inside the monolith. When it comes time to scale the REST API, it's a matter of creating more instances of the same web and application servers and running them behind a common load balancer, as shown in Figure 4.
Monolithic REST APIs are hard to revise, because their release cycle is dependent upon that of all constituent resources.
However, publishing all the URLs for the entire REST API in an API gateway makes it so that each REST resource can be realized by a distinct microservice.
Each microservice is represented by web and application servers that are internal to the network. Thus, each constituent resource of the overall REST API is independent of the other resources. This means the revision speed of the overall REST API increases.
The microservices are independent of each other. Hence, the release of a given microservice depends only on its own revision activities, not on the activities of other external microservices.