Why RESTful APIs Can’t Compete with the Event-Driven Approach to Microservices

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.

The Rise of Microservices + RESTful APIs

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 3^rd 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.

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.

Tight Coupling and Orchestration Limit Your Real-Time Interactions with Microservices

** ** 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:

1. The Storefront app service calls inventory to reserve the product
2. The app service waits for the response from inventory
3. When the inventory system confirms availability, the app service then calls the billing service to validate and charge the customer credit card
4. The app service waits for the response from billing
5. When billing confirms that the transaction has succeeded, the app service then calls the shipping service to ship the order

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:

• Poor Customer Experience – Response time to the user is a cumulative sum of response times of the inventory, billing, and shipping services. Any issue with either of these services means the user does not get a response.
• Cascading Failure Scenarios – If the ”Back In-Stock Notifier” service fails, users will not be notified and the inventory service will never be updated. This would result in a lost order.
• Lack of flexibility – To add new business capabilities/services (like fraud detection), you need to change the Storefront service or the billing service.
• Poor Scalability/Resource Utilization – The shipping service becomes a bottleneck. To scale the shipping service, you also need to scale the Storefront and the inventory services since they are blocking it – a waste of resources because they are still in a blocked/wait state.

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.¹ _

Let’s explore how event-driven architecture addresses these limitations and delivers on the real-time experience.

The Benefits of an Event-Driven Approach over RESTful APIs for Microservices

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:

• Real-time Customer Experience/Better Response Times : Inventory, billing and shipping services are invoked asynchronously. Services can be executed in parallel, making the response time much faster. Real-time transmission of events (push vs. pull) means services interact with each other in a very robust and efficient manner.
• Increased Flexibility and Agility: New services (like fraud detection) can be added without impacting other services. Microservices architecture and independent CI/CD pipelines for each means faster time-to-market for new business capabilities.
• Improved Operational Efficiencies and Resiliency: If the ”Back In-Stock Notifier” service fails, the message is stored by the event broker and can be delivered when the service comes back online. Reliable delivery ensures eventual consistency and no data loss. A stateful intermediary also allows for additional fault tolerance, speed mismatches, and shock absorption during peak volumes.
• Increased Versatility and Future Proof : If the shipping service becomes a bottleneck, it can be scaled by simply spinning up another instance quickly, making it a highly scalable architecture.

And most importantly, it doesn’t just stop here.

How an Event Mesh Supports Event-Driven Architecture

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:

• Hook into your enterprise’s ERP, CRM, MDM, supply chain, analytics, AI, and ML applications
• Provide edge connectivity to your IoT devices and sensors running at the retail stores, warehouses, distribution centre, and suppliers
• Connect your services across environments, from on-prem to different private/public clouds

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.}

The post Why RESTful APIs Can’t Compete with the Event-Driven Approach to Microservices appeared first on Solace.