Home United States USA — software Simplify Your Microservices Architecture With a Data API

Simplify Your Microservices Architecture With a Data API

174
0
SHARE

In this post, learn how adopting a data API gateway dramatically reduces development and maintenance costs for microservices architectures.
Join the DZone community and get the full member experience.
This is an article from DZone’s 2022 Microservices and Containerization Trend Report.
For more:
Have you encountered challenges in how to manage data in a microservices architecture? In this article, we examine traditional approaches and introduce the data API gateway (also sometimes known as a « data gateway »), a new type of data infrastructure. We explore the features of a data API gateway, why you should implement it, and how to apply it to your architecture. 
First, let’s consider how data is managed in microservices architectures. A common pattern is a layer of data services that perform « CRUD » (create, read, update, delete) operations. For example, consider the notional hotel reservation application shown in Figure 1. 
Figure 1:  Data services in a sample microservice architecture
This microservices architecture includes a layer of data services which manage specific data types including hotels, rates, inventory, reservations, and guests, and a layer of business services which implement specific processes such as shopping and booking reservations. The business services provide a primary interface to web and mobile applications and delegate the storage and retrieval of data to the data services. The data services are responsible for performing CRUD operations on an underlying database. 
While there are many ways of integrating and orchestrating interactions between these services, the basic pattern of separating services responsible for data and business logic has been around since the early days of service-oriented architecture (SOA). 
The typical approach to developing these microservices has included steps like the following: 
Many early SOA architectures included services that interacted with a single legacy relational database schema. An unfortunate consequence of this was a tendency to « integrate by database, » where services might read and write freely to multiple tables. This lack of strong ownership often led to data integrity issues that were hard to debug. 
As the move toward large-scale microservices architectures in the cloud began in the 2010s, large-scale innovators, including Netflix, advocated strongly for independent services managing their own data types. One consequence of this was that individual data services were free to select their own databases, a pattern known as polyglot persistence. An example of what this might look like in our hypothetical hotel application is shown in Figure 2.

Continue reading...