A DevOps tutorial on migrating to microservices
A comprehensive collection of articles, videos and more, hand-picked by our editors
In software, nearly everything is considered to be related. Unfortunately, most new software concepts seem to develop...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
as though that's not true. Microservices and their management are hot and so is API brokerage and management. But can we consider both at the same time and relate the management solutions?
The answer is yes. Doing so requires starting with a good definition of both API and microservices management, creating an API gateway model to harmonize API and microservices management goals and managing risks to ensure both API and microservices benefits are protected.
Defining APIs and microservices management
For two decades or more, it's been the practice of software architects and development teams to think of applications as collections of distributed services. All the techniques and architectures emerging from this viewpoint boil down to two issues: componentization and binding. In this case, componentization refers to how you frame the software components you call services, and binding refers to how these distributed components are discovered and accessed.
Software componentization facilitates reuse of code, and in the era of the cloud, it also promotes better scalability and resiliency for applications. Service-oriented architecture (SOA) was the original blueprint for distributable components, but most software professionals now believe that software design practices have rendered many of SOA's principles obsolete. Microservices are the replacement.
In SOA, services are discovered through a directory and accessed through a structured API that includes security, access rights management and other features. SOA services were typically not granular in nature, meaning that they performed fairly complex tasks, and so the overhead associated with the API management process wasn't considered to be a problem.
Microservices are very granular. A microservice is generally seen as a component that performs a single specific business function, and many development teams actually divide business functions into technical steps to create microservices. Microservices are typically accessed through a simple RESTful API, and each microservice access involves a network back-and-forth, which takes time. Thus, microservice applications have to not only take care to not create too much granularity and impact performance, they also have to manage security and compliance. That's microservices management.
The simple APIs in microservices don't provide the features that SOA APIs provided, and most applications will be composed of many microservices. This means that what might have been a single SOA service could now be a half-dozen or more microservices. Does the client device now have to make one service call for each microservice and assemble the result? How does the client even know where they are and how to reach them? How do you prevent unauthorized use or interception of data? That's API management.
The API gateway strategy
An increasingly popular strategy, called the API gateway, has emerged as a framework for addressing both API management and microservices management, while protecting the benefits of both. API gateways are implementations of the façade design pattern; they present an API upstream to a user or client device and invoke downstream APIs to microservices. API gateways offer a path to harmonizing API and microservices management.
First and foremost, an API gateway presents a single API to a device to mask a complex series of microservice access processes. This unloads the device of the work of assembling microservices, takes microservices traffic off the device link (usually the most easily congested) and allows microservices to be placed behind a firewall to reduce access security and compliance risks. The single gateway API is still exposed, but that API can be more easily secured.
There are risks in the gateway strategy, however. One is that an API gateway is now, in effect, an application that consumes microservices, and loss of the gateway component will kill access to the microservices it represents. Another is that compromising the gateway compromises all the microservices. Finally, there is risk is that performance issues in the gateway can reduce the application's quality of experience (QoE). All of this argues for implementing the API gateway as a microservice with full scalability and resiliency and taking care not to overload the gateway with features that will limit QoE.
Managing the risks
Best practices for API gateway implementation have to consider a state-event structure, because the calls to the front-end API by the user are asynchronous with the back-end calls, and back-end API calls may be asynchronous and dependent relative to each other. You can easily see how complicated fulfilling a single API gateway request could become. Each user request has to be viewed as an individual, multiphase activity, which means it has to be represented by a state-event structure or developed through a reactive programming design pattern.
API gateways can be used to create a unique façade for each type of device, or even for different worker roles. Each façade can then limit the functionality of the application by regulating which microservices are used to compose the application as that particular user sees it. This is a powerful tool in security and compliance -- and in API management overall.
The flip side is that API gateways can explode the number of APIs and microservices. The gateway itself is comprised of one or more APIs, and if software teams are encouraged to develop device- and role-specific façades, then they may run wild and create an unmanageable number of APIs. Also, the fact that microservices are now hidden behind the gateway and out of view of actual users and high-level application designers may encourage excessive microservice componentization, impacting performance and creating the risk for duplication of logic and effort.
API management and microservices management goals overlap, but they're not totally congruent. You have to beware of optimizing one at the expense of the other. Microservices management demands a performance-to-componentization balance, and API management requires a security-and-compliance balance. If you look at both issue sets holistically, you can get it right.
A roundup of leading API management tools
What should you look for in an API management platform?
Access our essential guide to microservices management