Microservices architectures speed up innovation in government. Instead of spending months or years building monolithic applications, developers quickly build a suite of small services, each running as an independent process in its own logical machine or Linux® container. As government needs change, developers replace, upgrade, scale, and deploy individual microservices—in far less time than they would need to change the entire application.
But who owns the data in a microservices architecture—the database team or the application team? The answer determines how much agility you will gain from microservices.
In most government organizations, application teams submit schema change requests to the database team. Then they wait while the database team evaluates the request to be sure it will not interfere with performance, security, or resilience. Conflicting priorities create tension: Application teams prize speed while database teams value caution.
The Red Hat® solution meets both teams’ goals. With Red Hat Data Virtualization, the database team creates reusable virtual databases for each application team. Application teams more quickly introduce new features because they can freely edit the schemas in the virtual database and include them in the continuous integration/continuous delivery (CI/CD) pipeline. Database teams retain complete control over physical datastores. With Red Hat Data Grid, resilience improves because microservices can continue writing and reading to in-memory data grids even if the central datastore goes down.
IMAGINING THE IDEAL DATA MANAGEMENT SOLUTION FOR MICROSERVICES
Government developer teams want control over their application’s data schema and role-based access control (RBAC). But replicating data into dozens or hundreds of databases—one for each application—is not practical. Problems include security risks, high management overhead, and loss of data integrity. Replication erodes the single source of truth.
What if it were possible to give application teams ownership of data without replicating data? In this vision, application teams could:
- Define database schemas without having to own or maintain a physical database.
- Provide role-based access to data.
- Include schemas and changes as part of the CI/CD pipeline.
- Define transactional boundaries, such as percolating application requests across several microservices.
CREATE VIRTUAL DATABASES AND DATA GRIDS WITH RED HAT MIDDLEWARE
Government IT teams can safely give data ownership to application teams by using Red Hat Middleware to create virtual databases and data grids. Table 1 summarizes how this architecture compares to existing government architectures.
TABLE 1. COMPARING GOVERNMENT APPLICATION ARCHITECTURES
|APPLICATION ARCHITECTURE||DATABASE ACCESS||DATA OWNERSHIP|
|Monolithic||Real-time connection between application and central datastore||Database team|
|Microservices||Real-time connection between microservice and central datastore||Database team—risk of schema
changes is higher because changes
affect multiple microservices
|Microservices plus virtual databases||Each microservice connects to its own virtual database, which is exposed as a representational state transfer (REST) endpoint or JavaTM database connectivity (JDBC) service Real-time connection between virtual database and central datastore||Developers—they can freely edit
schemas and compositions and
then update the mappings between
the virtual database and the
Virtual databases neatly solve the data ownership problem by giving application owners ownership of their data views and access control. But there is one problem: If the underlying database goes down, so do all of the virtual databases.
ADDING RESILIENCE WITH AN IN-MEMORY DATA GRID
Red Hat Data Grid makes virtual databases resilient. An in-memory, distributed, NoSQL datastore solution, Red Data Grid synchronizes copies of data across multiple servers (Figure 1). Virtual databases connect in real-time—not to the physical database, but to the distributed data grid. The data grid becomes the source of truth for applications built from microservices.