Why We Need a New Breed of Hybrid Microservices Platform

Monolith Recap

To understand where we are heading, we need to take a look at common practices used in today’s business world. Looking at some of the more conservative verticals such as Financial Services, Telecom, Healthcare, and eCommerce, we see a pattern that they are reluctant to sway away from legacy Monolithic architectures due to their advantages. 

Monolith Pros and Cons

Pros:

• Classic monolithic architectures provide better performance and strong coupling.

• Less reliance on third-party or other department services.

• Full control of your application.

Cons:

• No agility for fast deployment or scalability.

• No simple way to make it highly available.

• Nearly impossible to isolate, compartmentalize or decouple system functionalities.

Microservices Recap

Microservices is many things, one of which is the ability to decouple services into smaller components having generic APIs and technologies where each service is isolated and contains the whole stack it needs to independently deploy and operate decentralized. To expand on the concept, take a look at Martin Fowler’s fantastic article on microservices.

Microservices Pros and Cons

Pros:

• Compartmentalization and decoupling: Allow you to scale up-and-out dynamically and on-demand.

• Agile methodology: Allows you to easily make changes to the code and run tests to ensure that everything is running smoothly. Each service is separated so you can change more than one at each iteration (unlike monolithic applications where everything is tied together, including the tests).

Cons:

• Granularity control.

• Inter-process and unsafe distributed communication mechanism.

• Handle partial failure — no transaction safety (eventual consistency).

• Update multiple databases owned by different services (polyglot persistence drawback).

• Multiple APIs.

• Refactoring can be quite difficult.

• Service discovery (phonebook service).

• Performance impact caused by HTTP, de/serialization, and network overhead.

• Achieving and maintaining high availability is no easy task.

What’s Next: A Hybrid Approach Is the Way to Go

A full monolithic approach isn’t sufficient anymore for systems that need scalability, such as IoT. Also, a full microservices approach isn’t great for performance or managing the services’ life-cycle.

We see the next logical step as a hybrid approach — utilizing monolithic performance with all the advantages of microservices, all while looking forward to the future of HTAP for the true harnessing of data and event-driven architecture. And that’s exactly where we’re heading.

The Perfect Platform to Achieve High-Performance Distributed Microservices

The XAP platform is not a monolith; it’s an interoperable means to an end of how to manage the services zoo we’re seeing growing out of control in every major enterprise. Service-oriented architecture, event-driven architecture, and, most significantly, data-driven design, are hot topics these days. Given that there are common architectures, topologies, and solution platforms in the market, we need to ask ourselves, how do we build the most efficient, cost effective, and high-performance system possible to handle the ever growing real-time challenges?

XAP Microservices Platform is the only way to combine the benefits of the monolithic approach with all the advantages of microservices. XAP is a low latency, distributed microservices platform comprised of a cluster of machines that work together to create a resilient shared data fabric for low-latency data access and extreme transaction processing. Despite the fact that it runs on a cluster of machines, achieving distributed service-like processing tasks and data partitioning, the underlining infrastructure is only one platform. It may seem like a Monolithic platform from the outside, but it most certainly is not. 

6 Reason to Use XAP’s Microservices Solution 

1. Granularity control: Building microservices by using small granular components is a hassle, a management nightmare, and a performance no-no. XAP's microservices distributed platform is a no-compromise approach where one can decouple the services and increase performance at the same time.

2. Eliminates the need for communication between different processes: By addressing the first issue, granularity control, we’ve actually solved many issues out-of-the-box. Communication between different processes, though still possible with cross partition querying, is no longer needed once the logic, messaging, and the (relevant) data are coupled together. 

3. Database/remote site full consistency: Eventual consistency is a big design flaw in most systems that requires data accuracy and consistency. Consistency is maintained through all levels of the platform. Transactions may span multiple partitions, multiple data types (Customer, Product, etc.), and multiple platforms across different sites if necessary. A transaction may start on the client-side, continue on the server-side with some collocated logic, and end back at the client-side if required. Since XAP acts as the system of record (application data fabric), it must support ACID transactions including database persistency and remote site replication atomicity.

All distributed transaction items that may spread across multiple nodes are transported to the database or remote sites as one unit ensuring database/remote site full consistency. 

4. Asynchronously update multiple storage volumes: Having a platform that can support services and data for extreme microservices performance is necessary for key systems that are built for performance—i.e. payment processing, trading, IoT, customer 360, passenger re-accommodation, healthcare management, etc. Although a strong consistency is a must, often we see a need to replicate the data to storage volumes either for persistency or because a third-party application can only work with a specific storage volume. XAP can asynchronously update a variety of common storage volumes out-of-the-box, making such a task a breeze for any developer that wants this feature to be integrated with their microservices architecture. 

5. Performance impact: A microservices platform needs to support the following hybrid cloud architectures as a service: IMDG, Analytics, Compute Grid, Caching, and Replication. Only the XAP microservice architecture can tackle all of the above in one platform by using a unique mechanism called a deployment unit (DU) or processing unit (PU) underneath the hood. The XAP PU is the unit of scalability and failover. The PU supports both Java and .NET. It includes the definition of artifacts that the user would like to have in a common lifecycle. These may have some dependency. For Java-based PU, such dependency would be described via Spring IoC. XAP allows you to deploy multiple independent PUs into the same grid or deploy a composition of PUs that have some inter-dependency. In such a case, XAP will orchestrate the PUs provisioning to have the right deploy, healing, and scaling order.