Microservices vs. APIs: How they differ and work together
Enterprises still rely on monolithic systems, but apps increasingly require speed, scale and flexibility. Here's how microservices and APIs achieve that, separately and together.
The days of monolithic applications as an enterprise norm are approaching an end. An increase of virtualized environments, combined with a modern organization's demands for rapid change, have created an expectation that app features and functions must change on an ongoing basis.
This new world of rapid app changes drives the adoption of microservices as a more flexible means to provision and manage IT services across an organization's overall IT platform. Microservices make continuous development and continuous delivery more manageable and effective across such virtual environments. The very nature of a microservice-based architecture is to manage workflows by aggregating microservices into a composite app that meets the workflow's needs.
There are other pathways an organization can take to modernize their applications in a world that increasingly depends upon software-based services. Many app architectures are now built with APIs that standardize and facilitate the exchange of data and services, whether these interactions involve end customers, business partners or strictly internal users.
These two concepts, microservices and APIs, differ in many ways, but they also work in concert. Let's review their individual roles and how an organization can design an architecture that utilizes their advantages.
This article is part of
What are microservices? Everything you need to know
What is a microservices architecture?
A microservice is a chunk of functional code that fulfills one or more specific actions -- anything from a calendar to payment reconciliations. Multiple microservices chained together fulfill the needs of an overall workflow. Microservices should not grow large enough to fulfill a complete business process in themselves -- if they do, they are essentially monolithic applications again.
A business might spin up a microservice on the overall platform or call to an existing instance to deal with a requirement. If implemented correctly, a single microservice can be swapped out for a more functional or up-to-date one with no impact to the overall workflow.
What is the role of an API?
All of this flexibility requires microservices to talk to each other. APIs offer this capability, as long as they are carefully implemented, used and managed.
An API offers a standardized means for a system to access applications, services (and microservices) or data outside of the code's direct environment. One microservice can use an API to access the functionality of another microservice.
Unfortunately, not all APIs are standardized or follow the same format. There is general acceptance and use of some protocols and application code -- such as representational state transfer, simple object access protocol, JavaScript object notation and extensible markup language -- but a developer can build these "standardized" environments with pretty much anything, which complicates communication between apps and services.
How microservices and APIs work together
Computer science guru Andrew Tanenbaum once said, "The nice thing about standards is that you have so many to choose from." This truism has caused many issues in the world of IT, including microservices and APIs.
Using APIs to directly enable microservices to talk to each other is not a good idea. Trying to maintain multiple API methods between one calling and multiple responding microservices is a recipe for problems, not least is a return to numerous repetitive testing processes to make minor changes.
Instead, microservices should only talk with a single environment -- and this is where API gateways come into the mix. They manage the interactions between one microservice and all other microservices through normal API calls, translate any calls between dissimilar APIs, and monitor and manage the microservices' availability and security.
Again, this is not perfect. API gateways, by default, accept many different APIs from known sources but cannot cover all possible iterations, such as home-grown or customized from developers who have decided to go their own way, come what may. In these cases, it may be necessary to write a specific connector to make the gateway work, but it is far better to avoid such proprietary systems in the first place.
A good starting point to use microservices and APIs is to implement an API gateway with the functions that your organization needs, such as security, scalability and basic API interoperability. Build microservices on top of this architecture so the gateway also monitors and reports on all aspects of API transactions.
Consider that all microservices interactions must go through the API gateway -- whether this is between a front-end, web-based service to a back-end service or between back-end services. This provides the flexibility required for a fully managed API environment, and establishes a full audit of interactions should it be necessary.
This overall architecture sets up an enterprise to not only efficiently implement and run a microservices environment, but also to more easily provision and manage new microservices as demanded by the organization's needs.
