Given all the hype about microservices, what role should microservices database architecture play in your organization?
Microservices replace monolithic software architectures, which are common and can still be successful when the overall solution is relatively small. The management of growth is the critical issue. As often demonstrated in real-world examples, a monolithic application can easily become complex, unreliable, and difficult to maintain. Java WAR files or similar structures provide some modularization. However, these techniques easily become inadequate as scale increases to the size of a modern web-based application.
Microservice-based modernization requires both a microservices application architecture and a microservices database architecture. And generally, each microservices application architecture requires its own microservices database architecture. Microservice application components use REST APIs to communicate with one another and with essential services like load balancers. Each microservice is responsible for a specific sub-function like order service, accounting service, or fulfillment service.
Microservices vs. SOA
Before microservices, enterprises implemented Service-Oriented Architecture (SOA) as the preferred way to break up monolithic applications. SOA requires complex technologies like SOAP, web services, and an Enterprise Service Bus (ESB) to integrate business logic and message processing. Most significantly, SOA applications use a global data model and shared database.
In contrast, in a microservices database architecture each microservice uses its own database with its own data domain model. Since microservice database architectures can have hundreds of small services each with its own database, scalability and maintainability becomes critical.
Using either monolithic applications or SOA architectures, services are not independently deployable or scalable. A failure in one service could bring down the whole system. Microservices fix these issues. With microservices, developers can continuously deliver and deploy new software versions for each service continuously and independently.
Converting monolithic databases
Migration to a microservice architecture requires two significant changes. First, microservices require breaking up a monolithic database so that each service has its own database instance. In most cases where the schemas are large, schema conversion is the natural place to start. Second, microservices require breaking up a monolithic application into an API-driven architecture where components operate as services.
Using Griddable, schema and data migration can be achieved through the Griddable policy engine. Policy rules can easily re-architect schemas and the associated data from a monolithic database into many microservice database architectures. Each of the databases may need to also independently scale via sharding. As a result, Griddable supports database sharding on both the source and target using its relay and consumer-based policies.
Changing the database
Microservices database architecture may also require a change of database type. Since microservices require many more database instances, the cost of legacy databases like Oracle may be prohibitive. Instead, many implementers choose an open-source database appropriate for the workload. Furthermore, each microservice can make independent choices for the database best suited for its particular use. For example, each microservice could choose InfluxDB for time-series data, RocksDB for heavy appends, or MemSQL for in-memory data performance.
In a microservices architecture, two alternatives exist to support transactions that span across multiple databases. First, two-phase commit (2PC) using XA-compliant databases can support distributed transactions across shared databases. Alternatively, the microservices database architecture must perform appropriate compensating transactions after transaction failures. For example, a compensating delete transaction may be required for a failed insert.
Griddable creates a data grid with heterogeneous databases. Griddable infrastructure can evolve gradually because each Griddable endpoint is dynamically pluggable. Thus, developers can gradually rollout the new microservices database architecture as development and testing progresses.
Finally, microservices database architecture requires individual sharding mechanisms for each service. With Griddable, moving data from Oracle to a sharded MariaDB with a MariaDB spider node is a simple UI exercise. After resharding, developers can take months re-architecting the application offline. Griddable speeds the development effort by creating a QA sandbox of live data continuously synchronized from the legacy Oracle source. During development, Griddable will mask personally identifying information (PII) in transit that cannot be seen by developers. Once the application re-architecture is complete, switchover occurs in nearly zero time to the new microservices database architecture.
To see Griddable in action, click the “Demo Now” button for a 10 minute, no-obligation tour.