Imagine a pizza store where one person is taking orders, one is baking pizza, and a few are delivering them to the requested locations. This division of labor keeps business tasks successfully distributed across employees of the store and maximizes customer satisfaction.
Similarly, in a typical software development scenario, it is very common to create a project by assembling a team during initial design phases. These kind of services are called monolithic services. Over time, the code base for monolithic services becomes difficult to maintain, especially when project requirements compete with one another. This may also lead to accidentally creating two smaller but growing monoliths patched with a bridge to communicate with each other.
So, how do you solve the main issue of designing the deployment of independently integrated services without accidentally generating monoliths? Typically, the ideal way is to find a seam or communication point and then divide responsibilities as two halves of the system.
But it is also works to find the business functionality of the service and divide the parts based on that differentiation, which will avoid the dependency and the monolith problems.
This approach is called microservices, which essentially divides the monolithic service into different microservices that have less dependency and are independently scalable. In other words, microservices can be defined as independently deployable components of bounded scope that support interoperability through message-based communication. Microservices architecture is a style of engineering highly automated, evolvable software systems composed of capability-aligned systems.
Martin Fowler says, “A monolithic application puts all its functionality into a single process and scales by replicating the monolith on multiple servers whereas a microservices architecture puts each element of functionality into a separate service and scales by distributing these services across servers and replicating as needed.”
Why Do We Need APIs for Microservices?
APIs bring the technological way to express microservice capabilities while linking business to the technology. APIs adds value to the microservices with normalized access points for system functions, including security, composition, monitoring, and SLA enforcement. APIs help microservices bridge service modeling through domain-driven design. They also provide a consumable means of understanding the system of microservices for information hiding to reduce the accidental complexity.
Why Do We Need API Gateways for Microservices?
On a very high level, API gateways are used for threat protection, message security, transport security, orchestration, routing, and transformation.
Consider a large software application scenario where you have a bunch of microservices to form full functionality. It is very tedious to track all the microservices and manage usage over time. API gateways can be used to track and manage microservices. An API gateway makes a collection of microservices look like a single API developed to meet the specific application requirements. To the developers or an external partner, it looks like the single API, but the API gateway will trigger a series of calls to the microservices based on the needed functionality. This approach takes out the load of security, orchestration, and transformation of the microservices while the gateway forwards only the authenticated and authorized requests to the backend.
Another important role of API gateways here is protocol translation. As with the microservices development, teams have a flexibility use their own protocol to support the microservice as per the requirements. It is tedious for interconnectivity between microservices when customized accessibility must be developed for each and every microservice. An API gateway can perform protocol translation so that developers can focus on the functionality of the service rather than spending more time on connectivity.
