Understanding The Role of APIs In Microservice Architectures

This is the second part of a two part series on microservice architectures, how they are used in application development and the role that APIs play within them. The first part looked at microservice architectures and how they are used in application development.

In part 1, we talked about microservice architectures and how they can be used to build scalable applications. We talked about building separate domains of responsibility to allow your growing development organization to work on a single application without overlapping responsibilities.

This diagram illustrates how these microservices can be constructed in order to keep away from overlapping responsibilities:


Microservice APIs

Each of the arrows between microservices is the use of an API that is exposed by one microservice and used by one or more consuming microservices. Too see this, let’s expand and see what microservice “E” looks like closer:

Here we see microservice “E” expanded. There are two microservices (“B” and “H”) that make service calls to microservice “E”, and microservice “E” makes service calls to microservice “J”.

The left part of microservice “E”, is an API that other microservices can use to call microservice “E”. This API is an internal API that is only available to other microservices within your application. In order to implement the separate domains of responsibility we talked about in the first article in this series, this API must be a well defined API that implements all the required functionality needed to provide benefit from using microservice “E”. This API describes the one and only way of communicating with microservice “E” from within the application.

Each and every microservice in your system must have a well defined and documented API. This API is the “contract” that exists between different service owners. In our example, microservice “B” is owned by “Dev Team 1”. They use the API defined by microservice “E” in order to communicate with the service, and this API defines a contract between the service consumer (Dev Team 1) and the owner of microservice “E” (Dev Team 4, in our example).

This article is continued on page 2.

Lee Atchison Lee is Principal Cloud Architect and Advocate at New Relic, where his job is to understand and drive the industry in the areas of cloud architecture, microservices, scalability, and availability. He is the author of the O’Reilly book Architecting for Scale and author the blog Lee@Scale. Lee has 28 years of industry experience and over a decade of building high-scale Web applications, having worked for seven years at Amazon and four at New Relic.