Can RESTful APIs with microservices deliver when it comes to the critical real-time customer experience? Businesses in all industries and sectors have all sorts of real-time events coursing through them, including human actions, command and control instructions, sensor readings, news feeds, stock ticks, interest rate changes, process alerts, workflow notifications, fault detection, fraud detection – the list goes on!
The number of such events is increasing at an exponential rate. The challenge lies in sensing and capturing and responding to these events in real-time so you can deliver a higher quality of service, offer a better customer experience, and make more informed business decisions. In this post I aim to explain the limitations of RESTful APIs through an ecommerce microservices example. I also explain how an event mesh can help overcome the challenges. Read on to find out more.
To meet the demands of this real-time responsiveness and extreme scale, businesses recognized the need to innovate, modernize and digitally transform. As architectures and technologies evolved, monolithic applications got broken into coarse-grained services (service-oriented architecture) and now into fine-grained services (microservices).
Business capabilities can now be encapsulated as small, autonomous services and exposed via APIs that can be easily consumed by customers, partners, and 3rd parties. Docker and Kubernetes simplified the containerized deployment and orchestration of services, making it easier to scale and manage them.
The loosely coupled, cloud-native, flexible nature of using different technology stacks and containerized deployments across private cloud, multi-cloud, PaaS, serverless, IoT and edge computing devices have made microservices very popular.REST vs Messaging for Microservices – Which One is Best?Event-driven microservices should be considered more often by developers and architects as they provide the foundation to build awesome systems and applications.
RESTful APIs became a common choice for enabling interactions between microservices because of simplicity – services communicate directly and synchronously with each other over HTTP. Developers who have always programmed by making function/method/RPC calls and database read/writes found it easier to design resource-based APIs using the CRUD actions. And off course rich tooling like OpenAPI (Swagger) made it all quick and easy to use.
As an example, let’s take a look at the RESTful API approach to a microservices use case for processing a customer order on an ecommerce platform.
A customer initiates an order via the Storefront Web app, which acts as the orchestrator by invoking the inventory, billing, and shipping services before acknowledging the order to the customer.
This is the sequence of events:
As request/reply interactions, the communications between these microservices using REST APIs are inherently synchronous, so they need to happen one at a time, in a pre-arranged sequence, and each interaction blocks progress of the process until its completion. The interactions between different services, and updates to multiple services, are coordinated by an orchestrator, introducing a single point of failure.
The RESTful API approach for the Storefront Web App microservices architecture described above results in these limitations:
A recent Gartner Report states:
Applications become harder to scale and the web of connected APIs harder to manage, leading to ever-more tightly coupled systems. To move beyond the connected APIs and to enable more scalable, contextual and responsive digital business, application leaders add event-driven architecture (EDA) to the core of their platform and design capabilities.1
Let’s explore how event-driven architecture addresses these limitations and delivers on the real-time experience.
We can look at processing the same customer order from our previous example but, this time, with an event-driven approach.
The Storefront App, inventory, billing, and shipping services all connect to something called an event mesh. An event mesh is a network of interconnected event brokers that forms a configurable and dynamic infrastructure layer for decoupled applications, systems, and devices. In this case, the event brokers are Solace PubSub+ Event Brokers.
All communications between these services are loosely coupled, asynchronous events. The one-to-many publish/subscribe messaging pattern allowed for data to be published once and received by multiple, interested subscribers simultaneously. Services do not rely on a central controller, i.e. an orchestrator, to send and receive data.
Using this event-driven approach, these are some of the benefits the Storefront App can capitalize on:
And most importantly, it doesn’t just stop here.
Although financial services have been the early adopters of event-driven architecture for market data and pricing distribution, event-driven thinking can help every business to deliver a quality service and real-time customer experience to gain a competitive advantage in their market. You can easily scale and extend an event mesh to:
Solace also offers an event portal called PubSub+ Event Portal that makes it easier to design, develop and manage event-centric applications.
Think about your first morning coffee experience at a coffee shop. If the coffee shop followed the one-to-one model of RESTful API interactions with the microservices – one employee serving one customer – the same employee takes the order, serves the coffee, and takes the payment. In this instance, you would be waiting for your favourite coffee until all of the customers ahead of you are served by that one employee. Waiting time is directly proportional to the length of the queue.
If the coffee shop adopted the one-to-many model instead, each employee serves multiple customers. In this model, one employee will take the orders and the payments, and delegate tasks (making the coffee, serving the coffee) other employees— truly an event-driven advantage! Each customer is served quickly and efficiently instead of waiting for one person to do all the work.
Over the years, Solace has helped and continues to help businesses in financial services, aviation, retail, transport, manufacturing, pharmaceuticals, field services, energy, telco, and more in their event-driven journey. If you would like to learn more, it only takes an event (phone call, sms, email) to reach us!
1 Source: Gartner “The 5 Steps Toward Pervasive Event-Driven Architecture” 28 June 2019, Yefim Natis, Massimo Pezzini, Keith Guttridge, Roy Schulte.
As one of Solace’s most trusted solutions architects, Meshvi leverages her in-depth knowledge of enterprise application integration, enterprise messaging, iPaaS and other middleware technologies to help customers achieve the benefits of event-driven architecture in the areas of business process management, supply chain management and more.
Prior to her work with Solace, Meshvi served as a middleware consultant with Credit Suisse and held technical leadership positions with Barclays Capital and Infosys. In addition to achieving her Solace Solutions Consultant and EDA Practitioner certifications, she is also Sun Certified Java Professional. She holds a bachelor of science (electronics) from Gujarat University, along with a masters in information technology and a diploma in business management.[position] => [url] => https://solace.com/blog/author/meshvi/ ) )
Sign-up to get access to:
Messaging Services – One Enterprise Developer Service with up to 100 connections/queues, 8 Gbps of throughput and 2 GB of storage
Event Portal – 150 Editor Users and 15,000 objects (an object is defined as an event, schema, or app)