Rule Your Microservices with an API Gateway: Part I
Traditionally web applications have been implemented so that one application includes all of the business logic. These monolithic applications are very easy to build and start with smaller codebases and they are relatively easy to test. Also, IDEs have good support for monolith applications and they are faster to develop in the beginning.
Monolithic applications can be successful, but increasingly people are feeling frustrated with them. Every change requires the whole application to be rebuilt and deployed. Also, Monolith applications can only be scaled horizontally. So, you end up running multiple instances of the entire monolith application on multiple servers behind a load balancer.
Explode Your Monolith into Microservices
Using the microservice architectural paradigm allows you to develop a single application as a set of loosely coupled, collaborating services. Each service implements a set of narrowly, related functions and communicates with lightweight mechanisms, such as a HTTP resource API. So instead of having a codebase that handles all of the entities, now you have different services that are being deployed and scaled independently from each other.
Microservices are relatively small and easier for a developer to understand. They provide better architecture for large applications and better isolation for scalability and damage control. However, they contain more moving parts and are harder to test. Developers must also pay attention to complexity, security, network latency and connectivity issues that are coming with microservices. Also debugging is harder when dealing with loosely coupled services. Microservices are not answer to every use case. Sometimes monolith can be better solution.
The best foundation for running a microservices application architecture is application containers. Containers encapsulate a lightweight runtime environment for the application, presenting an isolated and consistent software environment. Containers provide faster initialization and execution and they are easy to scale up and down. However, containers themselves do not make sense without an orchestrator service such as Kontena, Docker Swarm or Kubernetes which delivers the desired application functionality.
With microservices architecture most of the API calls are internal. Thus, running microservices requires a good overlay network, service discovery and a load balancer. Typically, these are provided by the orchestrator service or by using and configuring external tools or add-ons. For example, Kontena provides these out of the box.
Rule Microservices with an API Gateway
When having lots of services, controlling the total flow can become hard. A Service might be updated and the address of the service could change. This requires changes to other related services as well. Also, dealing with different kinds of clients that have different kinds of requirements can be problematic. Systems might need also centralized authentication and security. The solution to these problems is to use API gateways.
An API gateway provides a single, unified API entry point across one or more internal APIs. Rather than invoking different services, clients simply talk to the gateway. In other words, it insulates the clients from how the application is partitioned into microservices. It also adds an additional layer of protection by providing protection from attack vectors.
The API gateway enables support for mixing communication protocols and decreases microservice complexity by providing authorization using API tokens, access control enforcement, and rate limiting.
The API gateway is responsible for request routing, composition, and protocol translation. All requests from clients first go through the API Gateway. It then routes requests to the appropriate microservice.
However, the API gateway increases the complexity of the system by adding yet another moving part that must be managed. Also, it increases response time due to the additional network hop through the API gateway.
Building Microservices != Running Microservices
Building and running microservices are different things. Building microservices is the architectural pattern that requires that services are designed to be independent and isolated. Without a good design there is a risk that users end up building a monolith that is divided into multiple tightly coupled services. When services are ready and tested, users definitely wants to run and monitor them.
Running and monitoring microservices require the right tools. Without the right tools it can become time-consuming and maintaining the microservice platform itself can take more time than maintaining the application itself.
In the next part of this blog post series, we will show how to setup, run and monitor an API gateway and microservices very easily with Kontena.
About Kontena
Want to learn about real life use cases of Kontena, case studies, best practices, tips & tricks? Need some help with your project? Want to contribute to a project or help other people? Join the Kontena Forum to discuss more about the Kontena Platform, chat with other happy developers on our Slack discussion channel or meet people in person at one of our Meetup groups located all around the world.
Originally published at blog.kontena.io on September 15, 2017.
