Service Fabric Use case: E-commerce
To bring new services to their customers and optimize their operations, e-commerce/airline companies are adopting cloud computing as a key element in their long-term strategy. The systems supporting their website enable people to make add products to cart/reservations, look up products/travel information, manage their plans, get customer support, and more.
Customers provide personal information and make payments through the website, so the e-commerce companies design their system to be fault tolerant and extremely secure. One such architectural design is API-driven strategy. APIs support reuse and enable them to scale features and services independently. APIs also provide a single point of business logic regardless of the device customers use to access services.
This is one such use case to improve and modernize their implementation by porting discreet services into Azure. The process got a lot easier when they adopted Service Fabric, a microservices platform.
Evolution from monolithic to micro-services based service delivery
Traditionally development teams have been creating monolithic systems and hosting them on premises for years. To ease reuse and increase agility of specific business functions, the team has been gradually splitting many of these systems apart by porting aspects into discreet services. Microsoft development technologies and platforms with the help of Microsoft Azure provide an architectural approach that can help make this possible.
The most straightforward approach, they decided, was to pull out common aspects of their back-end systems and turn them into ASP.NET Web APIs. Over time supporting large number of customers and emerging mobile-based delivery models becomes an impossible task. Loss of services caused by networking, hardware, or virtual machine issues, and performance impacts due to governed usage to maintain up time requirements. To address these scale and capacity issues, one can extend their hosting model by adopting several Azure services–notably, Azure App Service for hosting their ported APIs, Azure API Management for secured access to those hosted APIs, and Redis Cache for session management.
The next challenge
Azure App Service makes it easy to extend web apps to support mobile clients but customer demand outpaces the system’s ability to scale the more demanding back-end services and high request volume for the API services. The problem was a design flaw that prevented the system from recovering gracefully from failures on top of the inconsistent performance of APIs and downstream dependencies. The immediate resolution can be horizontal scaling.
For example: Imagine a Shopping Cart API, an absolutely critical business component, service disruptions aren’t acceptable. Typically shopping cart are api components which might not be built using microsoft based platform. Any downtime in the API means lost bookings, lost revenue, and unhappy customers. During peak usage times requires hundreds of virtual machines, or nodes, are needed to host this service to ensure zero interruptions. Azure App Services did not support this level of horizontal scaling.
A possible solution
Azure Service Fabric has rapidly gained traction with a wide variety of customers from financials, to healthcare, gaming, and especially IoT. Service fabric is container orchestrator for both Windows and Linux.
Service Fabric cluster can be self hosted on a local machine and in Azure. Service Fabric can be datacenter-agnostic and provide a way to move forward for hosting their ported APIs. This architecture also offered the capabilities and flexibility they needed for their new service delivery platform.
Taking the example of a shopping cart API, Say the The API required Internet Information Services (IIS) and is not built using .Net Core and it makes it incompatible with Service Fabric, which isn’t supported as an application host, since Service Fabric expects workloads to be self-hosted. This is yet again an other challenge.
The solution to this challenge involved yet another technology –Windows Server Containers. The combination of containers and Service Fabric provided a solution for the Shopping Cart API that didn’t require refactoring or rewriting the service. Containers combined with Service Fabric’s upgrade and management capabilities resolved another issue as well – helps in keeping their images up to date in production.
Instead of changing the core software or the platform (IIS) hosting their distribution, we can simply adde a few steps during their VSTS build pipeline, incorporating a Docker image build activity (that incorporated their software package and IIS distribution) and a push of that image to their private Azure Container Registry using PowerShell.
Improved performance and reliability
Reliability at all times is one of the important factor deciding on containers and service fabric. Correcting errors manually is too slow to be acceptable. Service Fabric provides a highly available application up time environment by monitoring each node and self-correcting when a node or the services on the node fails. Service Fabric cluster relies on Virtual Machine Scale Sets to handle availability and auto-scaling based on custom metrics. For example, virtual machine instances can be restored within a cluster during a failure event. Service Fabric also re-balances every node in the cluster and ensures it’s operational before that node and its service are allowed to accept incoming requests.
Savings at scale
The Shopping Cart API isn’t necessarily CPU-intensive, so vertical scaling is less important than bandwidth for the many incoming connections and requests. Service Fabric guarantees that container services get deployed on all nodes in the cluster. Because scale sets are set up for the different types of nodes in their Service Fabric cluster, each type of node can be scaled out independently and easily managed either by specific performance characteristics or by predicted peak load times.