Author: Abhay Patra

The advent of multiple asynchronous and event-driven technologies has influenced a paradigm shift in the traditional three-tier web architecture infusing changes in each layer of the architecture. Frontend web development has been supported by React JS, Micro Frontend jQuery, etc. The unique requirements to differentiate the user experience in the web application require significant architectural shifts in the controller, business, and backend layer and most importantly require an event-driven and asynchronous approach. In modern global user experience applications typically used by front desk or customer online applications, these architectural shifts are ubiquitous. This article provides strategic guidance for architectural decisions on choosing AWS services and further finetuning the performance of such responsive and performant web applications based on some real and practical production scale solution developments and deployment experience.

Solution Approach

Cloud-native application development in AWS often requires complex, layered architecture with synchronous and asynchronous interactions between multiple components, e.g., API Gateway, Microservices, Serverless Functions, and system of record integration. Performance engineering requires analysis of the performance and resiliency of each component level and the interactions between these. While there is guidance available at the technical implementation of components, e.g., for AWS API Gateway, Lambda functions, etc., it still mandates understanding and applying end-to-end best practices for achieving the required performance requirements at the overall component architecture level. This article attempts to provide some fine-grained mechanisms to improve the performance of a complex cloud-native architecture flow curated from the on-ground experience and lessons learned from real projects deployed on production.

Problem Statement

The mission-critical applications often have stringent nonfunctional requirements for concurrency in the form of transactions per second (henceforth called “tps”). A proven mechanism to validate the concurrency requirement is to conduct performance testing.

Runtime Fabric (RTF) is a particular deployment model based on container service where the Mule runtime can be deployed on the cloud (AWS/Azure/GKE/OpenShift) or on a data center (on-premise). It provides all cloud (PaaS) benefits, such as high availability, automatic failover, rolling updates, etc.

This article provides the prescriptive steps to migrating Mule CloudHub to RTF on EKS Deployment Model. It also describes changes to the application, process, ASM/Monitoring, or Observability required to harness the power of RTF.

This article is a part of a series that looks at serverless from diverse points of view and provides pragmatic guides that help in adopting serverless architecture, tackling practical challenges in serverless, and discussing how serverless enables reactive event-driven architectures. The articles stay clear of a Cloud provider serverless services, only referring to those in examples (AWS being a common reference). The articles in this series are published periodically and can be searched with the tag “openupserverless”.

Overview

The Serverless compute model has reached the “Early Adopter” stage in the Hype Curve and moving very fast towards attending the “Early Majority” stage. While the evolution of Serverless has been rapid and phenomenal, enterprises are lacking in strategy in adopting Serverless and leveraging its advancement in technology and architecture for an efficient IT ecosystem. This article attempts to provide simplified decision guidance for Serverless Architecture Adoption while not prescribing specific detailed guidance on the decision matrix of specific FaaS, BaaS, and other serverless services provided by Cloud Service Providers (CSPs) e.g., Serverless Databases, API Gateways or Edge services.