Abstract

Cloud computing provides scalable infrastructure services which ensures that applications deployed on the cloud will feature greater availability, as the infrastructure can expand based on the usage of the application.

This elastic feature is key to cloud environments and ensures that users can always access a cloud based application, irrespective of increase in total volume of users or a spike in concurrent usage of the application.

But to avail the advantages of this scalable and elastic infrastructure, the existing applications running on the on-premise data centers needs to migrated to the cloud infrastructure. The migration is easy as each cloud providers provides lot of tools which will help with the migration.

The migrated applications running on the cloud VMs may not be effectively utilizing the features offered by the cloud. To avail this, the applications has to be re-designed and re-architected, so that they’re decoupled from the physical resources, which help the applications to scale based on usage and user traffic.

A classic example of how an application can leverage the scalability of the cloud, by being ported to a cloud native format – is Ecommerce applications.

Ecommerce applications today are a hub that interact with multiple back-end applications such as like warehouse, inventory, etc.. in addition to serving end-users. The traffic to Ecommerce applications are often un-predictable and the variance can be quite large (for e.g., massive spikes during holiday season).

This whitepaper is about the study of an Ecommerce application running in on-premises environment and how to re-architect it to make it a cloud native application system. The whitepaper also covers the interaction between the other back-end systems such as a warehouse portal by means of a native, Enterprise Service Bus (ESB), in addition to using multiple de-coupled, native cloud services.

What is a cloud native Application:

Cloud computing opened a new era by providing various infrastructure components that are scalable and most importantly, de-coupled or abstracted. What that means is that the cloud can provide various infrastructure components as a services that can then be consumed by an appropriate business logic or storage requirement in an application, based on the exact usage requirement of computing, storage, bandwidth, etc.

This advantage can be taken only when the application is written with the cloud deployment at the heart and are hence called cloud native applications.

Cloud native applications (CNA) are designed to take advantages of cloud computing frameworks which are composed of loosely coupled cloud services.

Cloud native apps use elastic infrastructure

Cloud native apps are able to scale up and down

Cloud native apps have the ability to detect and work around failures

Cloud native apps can be built with redundancy at every layer (application, database, messaging, etc…)

Cloud Native Characteristics

Clean contract with underlying OS to ensure maximum portability.

Scale elastically without significant changes to tooling architecture or development practices

Resilient to inevitable failures in the infrastructure and application.

Instrumented to provide both technical and business insight.

Utilize cloud services e.g. Storage, queuing, caching etc.

Rapid and repeatable deployments to maximize agility.

Automated setup to minimize time and cost for new developers.

Cloud native applications using AWS

With Amazon Web Services, we can build a highly available ecommerce website with a flexible product catalog that scales with usage at multiple levels.

For this purpose, have considered a popular OSS Enterprise Ecommerce application called Broadleaf (Java based). We have adapted this eCommerce framework and deployed it onto AWS after re-architecting the application to make use of the some of the native infrastructure features offered by AWS.

Additionally, in order to showcase asynchronous integration with another system, the application also uses an Enterprise Service Bus and with queuing systems to talk to a back-end warehouse application.

Typical Ecommerce system:

The above diagram describes the data flow between various systems.

Ecommerce application should be open to the public via browser or mobile app.

Warehouse application is the one which gets the customer order details and their shipping address from Ecommerce application.

This application also need to be privately hosted. The staff/administrators who will check the customer order and ship the product to the customer address via courier or by other means.

There might be many other flows will be there, like product inventories servers, analytics servers who runs the Hadoop jobs on the user’s traffic/search patterns etc. These systems need to be service oriented in nature and to be scalable based on the needs. Cloud solves most of the problems in procuring the hardware, scaling etc.

We have considered a popular ecommerce open source application, warehouse and open source enterprise Service bus and adopted in a cloud native way. The systems are loosely coupled in nature.

Traditional Ecommerce Architecture (On premise)

The above picture describes the components of Ecommerce application on the on-premise infrastructure.

E-Commerce on AWS: (Cloud native System)

Components of the Cloud Native System

Application:Broadleaf Commerce

Broadleaf is an open source framework that can be used for a commerce solution. Broadleaf’s community edition includes basic commerce features and administrative tools in a modern development framework suitable for small business needs.

Cloud Provider: Amazon Web Services (AWS)

Amazon Web Services is the leading cloud provider in the cloud computing space. AWS has more than 70 services including compute, storage, networking, database, analytics, application services, deployment, management, mobile, developer tools for the Internet of things.

We have used Amazon Web Services (AWS) major public cloud provider in order to deploy the Broadleaf commerce application in a cloud native way.

EC2– Web Server software running on the EC2 instance routes the traffic to the set of application servers running on another fleet of EC2 instances.

Auto Scaling– used to scale up and scale down the fleet of EC2 instances as per the traffic.

Elasticache – a memcached engine used to store the HTTP sessions. This will help the application to be stateless.

SQS– Amazon Simple Queue Service (Amazon SQS) is used to transfer and receive messages to or from other systems. The usage of queue services makes the system loosely coupled.

RDS – Amazon Relational Database Service (Amazon RDS) makes it easy to set up, operate, and scale a relational database in the cloud. This service is used to store the data of the application in the RDS with MySQL engine running on it.

S3 – Amazon Simple Storage Service (Amazon S3) is storage for the Internet. This will help to store static content of the application like images, videos, PDF’s etc.

VPC– Virtual Private Network is used to logically isolate the instances with the desired IP range using public and private subnets.

SES – Simple Email Service used to send email notifications to the customers.

Enterprise Service Bus provider: Mule

Mule is a lightweight open source Java based enterprise service bus (ESB) and integration framework. It enables easy integration of existing systems, regardless of the different technologies that the applications use, including JMS, Web Services, JDBC, HTTP, and more. The ESB can be deployed anywhere, can integrate and orchestrate events in real time or in batch, and has universal connectivity.

Mule ESB supports Amazon SQS as a queue service provider. Using the SQS connectors we can easily integrate Mule ESB with SQS.

Creation of Orders done in Ecommerce and Shipment will be made in warehouse application. Both the system needs to be in sync. To do this, we have used Mule ESB in between the warehouse and Broadleaf Ecommerce in order to exchange the customer orders as a loosely coupled Service Oriented Architecture.

Warehouse Application: custom

We have a created a simple Warehouse application for this demo. Our warehouse application has the following menu items in it which does the basic operations of what warehouse application will do today.

“Read Order Items” accepts the type of the orders whether Submitted (new orders yet to ship them) or Shipped (Shipped items). Once the user clicks this button, an order details which have the specified status type will be fetched from MongoDB and displays in the UI.

“Update the Order Items”– This field is used update the status of the given order number along with the specified Tracking number.

“Sync with Ecommerce”– This will be used as a EOD (End of Day) operations in order to sync all the shipped orders with the Ecommerce for that day. Internally, ESB will transfer the SHIPPED item details back to the Ecommerce via Queue service.

Ecommerce will send an email to the user stating that the placed order has been shipped along with the tracking number. Also, Ecommerce update the order status as SHIPPED in its database.

Process Flow of the Cloud Native System

Users access the Ecommerce web portal; Route 53 a DNS service routes the request to the registered elastic load balancer.

Amazon CloudFront is a content distribution network (CDN) with edge locations around the globe. It can cache static and streaming content and deliver dynamic content with low latency from locations close to the customer.

Elasticache service – a memcached engine is used to store the HTTP sessions. This makes the application to be stateless. This helps that the session not to be sticky to a particular server. The session information can be accessible by the fleet of web servers.

Amazon Simple Storage Service (Amazon S3) stores all static catalog content, such as product images, manuals, and videos, as well as all log files and clickstream information from Amazon CloudFront and the e-commerce application.

Amazon Simple Email Service (Amazon SES) is used to send transactional email, such as order and shipped confirmations, to the customer.

To provide high availability, the database of the application is hosted redundantly on a multi-AZ (multi Availability Zone) deployment of Amazon Relational Database Service (Amazon RDS) within private subnets that are isolated from the public Internet.

As soon as the order is made by the user, application transmits the order details as a messages to an Amazon Simple Queue Service queue for further processing by other the fulfilment applications.

Mule ESB receives the order details from Simple Queue Service and stores it into a NoSQL database ex: MongoDB.

Warehouse admins access the Order management system to log order information and to submit the status of each order as “SHIPPED” along with the tracking number once the order has been shipped to the customer.

Mule ESB will transmits the SHIPPED order items to Amazon Simple Queue Service (SQS) in the JSON format. Mule ESB will call the Ecommerce application using exposed REST API’s.

As soon as the Ecommerce API gets invoked, Ecommerce will fetch the order status details from Simple Queue Service and continue further processing includes but not limited to sending an email to the customer via Simple Email Service with the shipment tracking details and updating the details in to the database.

Scalability in cloud native systems

Cloud native applications are designed specifically for the cloud platforms.

Applications must be architected differently for horizontal rather than vertical scale. The applications running in the infrastructure needs to be ephemeral in nature. We should be able to create the application instances easily and quickly and also we should be able to dispose the underlying application instances quickly and safely.

Usually the user sessions are stored in a particular instance. If that instance goes down, the session cannot be recovered. This will be a problem to horizontally scale the applications over a fleet of similar instances.

The hallmark of cloud native applications is the externalization of sessions state to in-memory data grids, cache servers and in persistent object stores.

Stateless applications can be quickly created and destroyed as well as attached to and detached from external state management systems.

The external state management systems should also need to be scalable. Most of the cloud providers provides managed services which we can make use of as a plug and play device store.

Amazon web Services offers various managed systems to store the sessions are

In this case study, we have used ElastiCache Service with memcached engine configured to have a minimum 2 nodes.

To store the static contents like images, HTML pages etc in the local file system makes the system to unable to scale horizontally, we have used a highly available and durable AWS S3 system to store and retrieve the static contents instead of having in the local store.

Conclusion:

Ecommerce applications need to be “always-on”, 24/7 and will the ability to serve all their user requests equally, irrespective of the usage patterns and infrastructure outages. Infrastructure required for the Ecommerce application will always vary over based on multiple parameters and ensuring elasticity is of paramount importance.

It is equally important an ecommerce application to communicate with the external systems, with the same scale and elasticity.

The eCommerce applications then, need to be loosely coupled with the ability to scale based on load at multiple layers.

Customizing your application to a Cloud Native Format ensures that users can be served consistently, across the world ona 24×7 basis, while ensuring that the application leveraging the highly scalable, elastic Cloud services that provide various infrastructure components as services and can be designed from ground up to combat failures at different levels.

This case study shows how to make an existing application – a cloud-native application on the Amazon Web Services Cloud.