Chapter 7, API Management and Consumption Patterns

Question 1

What is API Management?

Answer 1

API management is the process of creating, managing, securing, analyzing, and scaling APIs on top of existing microservices.

412

Question 2

What does API management enables consumers of your cloud native application to do?

Answer 2

• Have better engagement with the APIs you expose
• Integrate your application with other services and build new capabilities
• Monetize the consumption of your APIs
• Generate business analytics and insights
• Expose business capabilities as managed, secure, and resilient

412

Question 3

Describe the API Gateway Pattern

Answer 3

The API Gateway pattern is the most common way of exposing the business capabilities of your cloud native application to the consumer. With this pattern, you put a separate layer in front of the capabilities that are designed as microservices and that you wish to expose to consumers. With this approach, an API gateway acts as the front door to your cloud native applications.

414

Question 4

How does the API Gateway Pattern work?

Answer 4

An API gateway layer is often built on top of existing microservices. Any microservices or composite services that you develop can be exposed as managed APIs through the API gateway. The API gateway operates alongside the API control plane and developer portal.

414

Question 5

Describe the API creator/API developer role in a typical API management process

Answer 5

A person in a technical role who understands the technical aspects of the API (including interfaces, documentation, and versions) and uses the API publisher to provision APIs into the API store. The creator or developer uses the API store to consult ratings and feedback provided by API users. Creators and developers can add APIs to the store but cannot manage their life cycle.

414

Question 6

Describe the API publisher role in a typical API management process

Answer 6

Manages a set of APIs across the enterprise or business unit and controls the API life cycle, subscriptions, and monetization aspects. The publisher is also interested in usage patterns for APIs and has access to all API statistics. (In certain cases, the API creator and publisher roles may be combined into a single role.)

414

Question 7

Describe the Application developer role in a typical API management process

Answer 7

Uses the API store to discover APIs, read the documentation and forums, rate/comment on the APIs, subscribe to APIs, obtain access tokens, and invoke the APIs.

414

Question 8

Describe the API control plane admin role in a typical API management process

Answer 8

Hosts and manages the API management solution. This person is responsible for creating user roles in the system, managing databases, and ensuring security.

414

Question 9

What are the key steps of API life-cycle management?

Answer 9

1) We identify the business capabilities that we are going to expose as managed APIs.

2) The API creator (this can also be a person who develops services) creates a managed API (or API proxy) on top of the corresponding microservices of the business capability. The downstream services can be individual microservices or service compositions. The API is created at the API gateway.

3) API publishers can publish the APIs that are created so that they are available in the developer portal to be discovered by the application developers.

4) Application developers subscribe to APIs that they wish to consume through the API developer portal and learn more about the API so that they can consume applications on top of those APIs.

5) The applications that consume those APIs (such as mobile, web, or desktop applications) send requests via the API gateway to consume the business capabilities.

6) API publishers and creators control, observe, and manage the API exposed to the consumer.

415

Question 10

What are some considerations when using the API Gateway Pattern?

Answer 10

• The API gateway layer should not have business logic–related capabilities. To have better separation of concerns, the underlying service should take care of the business capabilities.
• We can have multiple API management layers to expose APIs to internal and external consumers.
• At the initial stages, you may require only an API gateway, while the API control plane and developer portal are not mandatory. API publishing, and obtaining the information on published APIs, can be supported via dedicated interfaces of the API gateway (for example, the REST API).
• As your API management requirements become more advanced, you will need dedicated API control plane and developer portal components. Depending on the requirements, you also can adopt new components to handle API monetization, traffic management, and so on.
• The API gateway layer is often used as a monolithic runtime. If the gateway layer does any heavy lifting related to security, policy enforcement, and so forth, you may have to split it into multiple runtimes. The API Microgateway pattern that we discuss next can be used in such scenarios.

420

Question 11

What are some related patterns to the API Gateway Pattern?

Answer 11

API management patterns can be used along with any of the service composition patterns that we discussed previously. We can use different variations of the API Gateway architecture to cater to specific requirements of cloud native applications. These variations are discussed in “API Microgateway Pattern” and in “Service Mesh Sidecar as an API Gateway Pattern”.

421

Question 12

Describe the API Microgateway Pattern

Answer 12

The API Microgateway pattern is a simple variation of the API Gateway pattern. The key idea is to make the API gateway a distributed component so that each API deployed in the API gateway has an independent runtime. So, the API gateway is no longer a monolithic component in this pattern.

421

Question 13

How does the API Gateway Pattern work?

Answer 13

In the API Gateway pattern, the API gateway component hosts the runtime for all APIs that we expose through our API management layer. However, when the number of APIs that we expose grows, this monolithic API gateway layer can become really bulky and will start giving us all the problems of a conventional monolithic application. And a monolithic API gateway layer goes against some of the core principles of microservices in a cloud native application.

The APIs that we expose from an API management layer represent business capabilities that are designed, developed, deployed, and managed independently. Therefore, a true cloud native application shouldn’t have a monolithic or central API gateway layer. Instead, each API should have its own runtime—called a microgateway—and we should be able to manage all these runtimes together by using a central API management plane that is exposed via a central API developer portal.

421 Figure 7-3. API management with microgateways

Question 14

How is the API Gateway Pattern used in practice?

Answer 14

A microgateway is usually implemented using a lightweight gateway runtime deployed as a container. Therefore, we can leverage containers and container orchestration systems to run microgateways.

423

Question 15

How is the API Gateway Pattern used in practice?

Answer 15

A microgateway is usually implemented using a lightweight gateway runtime deployed as a container. Therefore, we can leverage containers and container orchestration systems to run microgateways.

423 Figure 7-4. API microgateways in action

Question 16

What are some considerations when using the API Gateway Pattern?

Answer 16

The API Microgateway pattern requires support from the underlying API management platform to have such a decentralized deployment of the gateway. Since we are using one gateway for each API, the gateway runtime must be extremely lightweight. When it comes to managing and scaling such a decentralized system, we need a container orchestration system such as Kubernetes to handle the operational overhead. In most API management solutions offered as cloud services, the existence of the microgateway is transparent, and the cloud service takes care of handling it seamlessly.

424

Question 17

What are some related patterns to the API Gateway Pattern?

Answer 17

The API Microgateway pattern uses the same terminology as the API Gateway pattern.
The Service Mesh Sidecar as an API Gateway pattern is an application of the Microgateway pattern in the context of service mesh.

424

Question 18

Describe the Service Mesh Sidecar as an API Gateway Pattern

Answer 18

The key idea behind the Service Mesh Sidecar as an API Gateway pattern is that, in an environment where we use service mesh, rather than using a separate API gateway runtime, we can offload the tasks of the API gateway to the sidecar proxies running alongside each microservice.

424

Question 19

How is the Service Mesh Sidecar as an API Gateway Pattern used in practice?

Answer 19

The implementation of this pattern is taken care of by the API management solution that you use for most parts, and most of the underlying details are transparent to the users who use the API management solution. The API control plane can directly manage sidecar proxies or can use the service mesh control plane APIs to manage them. In a cloud environment that provides API management as a cloud service, the implementation details of the API gateway may become irrelevant. This pattern is used when you are already using a service mesh and want to include API management capabilities on top of it.

426

Question 20

What are some considerations when using the Service Mesh Sidecar as an API Gateway Pattern?

Answer 20

This pattern has some of the most complex distributed architecture comprising multiple distributed components. Its operational complexity is even greater than that of the Service Mesh pattern. If you are adopting this pattern, you should be ready to handle this complexity or leverage a cloud service that is already doing it for you.

426

Question 21

What are some related patterns to the Service Mesh Sidecar as an API Gateway Pattern?

Answer 21

The application of this pattern requires a solid understanding of the Service Mesh pattern, as well as the API Gateway and API Microgateway patterns.

426

Question 22

When to use the API Gateway pattern?

Answer 22

Essential in all the API management use cases.
API management plane and developer portal are optional for small-scale use cases but require those components if you plan to do end-to-end API life cycle management.

427

Question 23

When to use the API Microgateway pattern?

Answer 23

Only when the API gateway layer requires scaling and isolation per each API.

427

Question 24

When not to use the API Microgateway pattern?

Answer 24

If your cloud native application exposes a handful of managed APIs that don’t do any heavy lifting, using this pattern will incur a redundant complexity.

427

Question 25

When to use the Service Mesh Sidecar as API Gateway pattern?

Answer 25

Only when you are using a service mesh in production and want to include API management without using a separate layer. 427

Question 26

When not to use the Service Mesh Sidecar as API Gateway pattern?

Answer 26

If you don’t have a service mesh or plan to use it at the production level, using this pattern is overkill. Even if you use a service mesh, you can still use API management as a separate component. 427

Question 27

Describe the Direct Frontend-to-Microservices Communication Pattern

Answer 27

When you build a cloud native application’s backend by building a series of microservices that expose business capabilities, the frontend applications can directly consume those microservices. 428

Question 28

How does the Direct Frontend-to-Microservices Communication Pattern work?

Answer 28

To facilitate the direct consumption of microservices by the frontend application, you need to expose all the microservices required for your frontend applications as public-facing services. Figure 7-6 shows what this looks like. The frontend applications access these services via a load balancer, and extra care needs to be taken to secure these microservices as they are directly exposed to the public. Each application is directly coupled to the service interface of these microservices; client applications need to change when the service gets changed. All the cross-cutting capabilities such as authentication, authorization, and observability need to be implemented at the level of each microservice. 428 Figure 7-6. Directly exposing microservices to frontends

Question 29

How is the Direct Frontend-to-Microservices Communication Pattern used in practice?

Answer 29

This pattern is suitable if you are building a simple cloud native application with a few services and systems. This pattern is often used in small-scale microservices deployments that can’t afford to have a dedicated API management layer to expose microservices as managed APIs, which we’ll discuss in the next section. Later, when the system needs to scale for more consumers and more microservices, we can bring in the API Gateway pattern. 429

Question 30

What are some considerations when using the Direct Frontend-to-Microservices Communication Pattern?

Answer 30

As discussed, this pattern has inherent limitations, including tight coupling between the frontend and backend services, security risks of directly exposing microservices to the public, and no central place to apply cross-cutting capabilities across multiple microservices. 429

Question 31

What are some related patterns to the Direct Frontend-to-Microservices Communication Pattern?

Answer 31

This pattern often gets extended to use an API gateway instead of directly consuming the microservices. 430

Question 32

Describe the Frontends Consuming Services Through API Gateway Pattern

Answer 32

When you have to expose the business capabilities of your cloud native application, rather than exposing microservices directly to consumers, you can use an API management layer. Instead of accessing the microservices directly, frontends access microservices via the API management layer. 430

Question 33

How does the Frontends Consuming Services Through API Gateway Pattern work?

Answer 33

We implement frontend to API management layer communication by exposing all the services or business functionalities that need to be exposed to the external parties via an API management layer 430 Figure 7-7. Frontends are consuming business capabilities via an API management layer

Question 34

How is the Frontends Consuming Services Through API Gateway Pattern used in practice?

Answer 34

Most organizations increasingly adopt this API management pattern and are moving all their frontend developments to rely on the organization’s exposed APIs. When you are not using an API management layer to build your frontend applications, you should consider gradually introducing API management into the architecture and rebuild the frontends so that they use exposed APIs rather than invoking microservices directly. 431

Question 35

What are some considerations when using the Frontends Consuming Services Through API Gateway Pattern?

Answer 35

When building a frontend application using APIs, one of the limitations you face is that your frontend application has to depend on a general-purpose API rather than something specifically serving the needs of the frontend application (for example, the requirements of a mobile application versus desktop application may be drastically different). Proper design of the APIs hosted at the API management layer is critical, as well as being able to customize APIs for your frontends, which may also be required in certain use cases. 431

Question 36

What are some related patterns to the Frontends Consuming Services Through API Gateway Pattern?

Answer 36

You may further extend this pattern with the Backend for Frontends pattern, which creates a dedicated API for each frontend component. 432

Question 37

Describe the Backend for Frontends Pattern

Answer 37

With frontend applications, we expose the capabilities of our cloud native application via different frontend application types such as mobile, desktop, or web applications. When we use a general-purpose API and build all these frontend applications on top of it, we often hit roadblocks because the required functionality is not directly available in these common APIs. The Backend for Frontends pattern solves this problem by introducing APIs that are tailor-made for specific frontend applications. 432

Question 38

How does the Backend for Frontends Pattern work?

Answer 38

To build the best user experience for each frontend application type, we will need to use an API that is tailor-made for the requirements of the specific frontend application that we develop. These APIs are known as backends for frontend applications (BFFs). Rather than depending on a single general-purpose API, we can build different backend APIs for each frontend application type (Figure 7-8). These APIs may directly interact with the backend microservices (in this case, the Order microservice) or can rely on a general-purpose API that exposes the core business functionality. 432 Figure 7-8. The Backend for Frontends pattern in action: each frontend application has a corresponding backend for frontend API/service at the API gateway

Question 39

How is the Backend for Frontends Pattern used in practice?

Answer 39

The Backend for Frontends pattern is commonly used when we want to enable a different experience for consumers through different frontend applications. The frontend application requirements can drastically vary. Mobile applications want certain data formats, lightweight and free messages, and different security protocols compared to desktop applications, for instance. Therefore, when designing BFFs, you have the freedom of choosing the most suitable technology for building the best consumer experience for the business capability that you offer. 434

Question 40

What are some considerations when using the Backend for Frontends Pattern?

Answer 40

While BFF reduces the complexity of having a general-purpose API, it also adds operational overhead, as the same capability is now being offered via multiple APIs. It’s usually a good practice to use a generic downstream service or API to build a BFF, as it can be used to track the consumption of the API and to generate analytics for the API usage. This pattern has inherent drawbacks due to the proliferation of APIs when the number of APIs that we expose increases as well as the type of frontends that we support increases. You should be using BFF only when it significantly improves the user experience for your cloud native application. 434

Question 41

What are some related patterns to the Backend for Frontends Pattern?

Answer 41

BFF is commonly used along with the API Gateway and API Microgateway patterns. With this pattern, we can also leverage service composition patterns such as Service Orchestration and Service Choreography. 434

Question 42

When to use the Direct Frontend-to-Microservices Communication pattern?

Answer 42

API management is not a critical requirement. 434

Question 43

When not to use the Direct Frontend-to-Microservices Communication pattern?

Answer 43

Often you need to bring managed APIs into the picture at some point. So this approach is suitable only when getting started. 434

Question 44

When to use the a pattern?

Answer 44

The consumers are homogeneous and don’t have disparate requirements to fulfill at the frontend level. The API exposed to consumers works for all the disparate sets of consumers. 434

Question 45

When not to use the a pattern?

Answer 45

The API needs frequent changes due to frontend requirements. The successful consumption of an API largely depends on the frontend application. 434

Question 46

When to use the a pattern?

Answer 46

We want to have a unique experience for each frontend application. 434

Question 47

When not to use the a pattern?

Answer 47

You have a single type of frontend application or its requirements are homogeneous. 434