Rule Your Microservices With an API Gateway: Part I
Rule Your Microservices With an API Gateway: Part I
Learn how to keep control of all the moving parts in your microservices architecture with an API gateway to decrease complexity.
Join the DZone community and get the full member experience.Join For Free
Containerized Microservices require new monitoring. Read the eBook that explores why a new APM approach is needed to even see containerized applications.
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, monolithic applications can only be scaled horizontally, so you end up running multiple instances of the entire monolithic 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 an 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 come with microservices. Also, debugging is harder when dealing with loosely coupled services. Microservices are not the answer to every use case. Sometimes a monolith can be a 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 you have 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 want 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.
Published at DZone with permission of Lauri Nevala , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.