Skip to content →

Month: September 2015

Building a Microservices Architecture on Azure with .NET – Part 2

Decomposing an ecommerce solution into an Azure Microservice Architecture

In the previous article I describe the highlevel requirements of a typical enterprise architecture that needs to expose its services over more touch points. I also provided a background into Microservice architectures as it is with this type of design that we hope to tackle the problem. In this article we will expand on the discussion moving into a more concrete example using an ecommerce solution.

One of the greatest challenges in any distributed architecture is defining the boundaries that you will use to partition your application.  Domain Driven Design encourages us to separate out our solutions into “bounded contexts” which each of our models can subscribe to.

Using our example it is easy to identify Orders, Products, Inventory etc, but there are also functional requirements that our solution has to provide which do not really sit within a business domain. Image processing and full text search are examples.

Slide1

The above diagram lists all the functional components of a full multichannel ecommerce solution.  You could deliver most of these capabilities within a single .NET solution like Nopcommerce, but as retailers become omnichannel the demands on their ecommerce systems have grown to the point that they can not service all the touch points from a single solution whilst maintaining agility.

Creating a solution map of your system as above provides a good starting point for driving out all the different components of your Architecture.

The Product Page

ProductPageThumbThe first step in a customers journey usually starts with a product, so it makes a pretty good starting point for us.

If we take a look at an Amazon product page we can quickly see that there are at least 18 different domains being queried for data to build out the page.  Inventory and price may be mastered in a core back end system but product metadata, reviews and product images are probably provided by a 3rd party service.

As we start to decompose the page into its individual elements we can start to draw boundary lines to separate out the architecture.  Business domains are typically a good starting point for boundary identification but data life-cycle should also be considered, a product packshot is unlikely to change during the lifetime of the product, where as the price and inventory will change regularly.

A few years ago I worked with a team where we had large product pages, just like the Amazon one, however all product information was stored into a single datastore. This included everything from large slices of product metadata to price. As the website became more successful the business wanted to be more price competitive, this required us to deliver multiple price changes a day across the whole product catalogue. The net result was every time a price change for a product was delivered we had to remove the product from the different caches and reload it which would cause the product page to reload the entire Product Graph from the database, when the caches were cold this could almost take the website down. We solved the problem by separating out the data. Prices ended up becoming their own entity with their own life-cycle and a price change just required the publication of a new price which would automatically get picked up. Consistency was not a huge issue for us as price was always checked at the last reasonable point with a direct read from the database before the order was processed. This made sure that we did not have zombie price in the  order, due to the ecommerce funnel this final check only happened for 5% of the overall traffic,  a much more manageable number of users.

Another important point when looking at your system for natural boundaries is to consider service availability. If the product page could not render product reviews it might impact sales but only marginally, however if there is no price, product title or availability then its unlikely that you would sell the product. Therefore “service level” makes another logical boundary for separation.

We will also want to expose this data to a number of other interfaces, both user and system interfaces including our search page, basket page, order history and a screens within a mobile app. Additionally we may even expose this data as an external datafeed for 3rd party affiliates and aggregators like Google Product Search to use.

In the traditional n-tier application we would have built a service layer that would probably have included a Catalogue, basket and user service, each implemented as class. To keep things clean we may have put our services into a separate dll. This type of structure can be seen within the Nopcommerce solution **.

NopCommerce-SolutionArch

The diagram below articulates the different capabilities working together to build the product page. Its not an exhaustive list but should illustrate the point.

DigitalArchitecture- ecommerce

Following the Microservices approach we would build out each of these capabilities as a simple REST service. The product controller of our MVC application can then use an async call to each service to build out the view model and render the page.

For further scalability and optimisation some of these calls can be pushed out to ajax requests that do the call once the page has loaded or when the user starts to scroll the page, creating a snappier user experience and supporting edge caching services like Akami, but I will leave this for another post.

In this example the data within each service can change, however it is unlikely to change by the user. Instead there are external processes that will change this data. Examples include new recommendations, price changes, products reviews etc. These changes will be driven by external systems or feeds. The orange boxes in the diagram represent interfaces that would be changing the data stored in each microservice.

Slide3

So, how would we build this using Azure?

We have a number of Architectural options available to build out our Microservice Architecture.

  1. Build out the service using Virtual Machine aka IaaS
  2. Build out each service a web role within Cloud Services aka PaaS Version 1
  3. Use the Azure App Service to model the architecture with Web Apps, API Apps and possible Logic Apps aka PaaS Version 2
  4. Using Docker and ASP.NET vNext to build, host and manage the Microservices

Option 1 Building our the service using Virtual Machines aka IaaS

One of the greatest challenges of building Microservice Architectures is the provision, deployment, management and monitoring of the services. Building our Architecture on IaaS would result in us having to build out a solution for provisioning, deployment, management and monitoring. Azure would only provide an SLA at the Virtual Machine level, everything else would be up to us. Azure offers better services for deploying and managing an Application Architecture. For this reason I wont focus on IaaS here but may come back to it at a later date.

Option 2 Building Microservices using Cloud Services

As our architecture landscape grows with many services it becomes important that we manage our run costs by optimising our utilisation of cloud resources. If we were to build out the above architecture using Cloud Services each component would have to be build as an individual WebRole.

Each Cloud Service is provisioned as a single Virtual Machine. To have a high available service 2 instances of each Virtual Machine have to be deployed. Therefore the above architecture would require 42 virtual machines to be deployed. Not a very cost effective us of resources.  It is possible to host multiple WebRoles on a single virtual machine, however deployment happens at the Virtual Machine which would require a complete redeployment of a virtual machine to change a single service. This does not really subscribe to the Principles of a Microservice Architecture and for this reason alone  using Azure Cloud Services is not be recommended approach.

In my next article I will explore how we can build our product page architecture using Option 3 Azure App Service.

** I have used NopCommerce as an example of a particular type of Architectural style. My observations in no mean imply that NopCommerce is an inferior product or that they should have tackled the design differently.

2 Comments

Building a Microservice Architecture on Azure with .NET – Part 1

Microservices architectures have become a bit of a trend lately. As with all trends there are the lovers and the haters, however from my perspective Microservices as defined in the excellent book by Sam Newman describe the next evolution of application development. From my own experience building large scale ecommerce solutions Sam’s book was like a shot of clarity.

Martin Fowler has written an excellent summary of Microservices which is required reading for anybody who is thinking about venturing down this type of architecture. However, Thoughworks are still hesitant to promote a Microservices Architectures due to the inherent complexity that is created by having an application composed of many granular parts.  This complexity comes from having to provision, deploy and managed multiple applications within your eco-system.

Here is a definition from Martin Fowler’s article

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

Microservices have gained increasing popularity in the “Startup/Massively scalable” area with Netflix leading the charge. The Gilt Group is a great example of a company who capitalise on the Microservices Architecture. They are a flash sale clothing retailer who started off with a Ruby On Rails monolith. After the initial success of their company they have spent the last few years moving away from the Monolith and now have a system comprised of over 300 independent services. Netflix is supposed to have over 600 services and Hailo has about 160.

The Microservices label encompasses more than just the architecture, but also the processes and practises that are required to build these architectures. Many of the elements in Sam’s book will be familiar to .NET developers who have been following best practises over the years. Especially those that followed down the CQRS route implementing service buses like NServiceBus.

But Microservices are not just for the startups, they provide an excellent architectural model for Enterprises who now need to:

  1. expose their data and services to ever more increasing touch points.
  2. need to start scaling functions of their architecture
  3. need to start changing functions of their architecture

The image below of the Windows 10 platform displays both the opportunity and challenge in building digital services. How do you build a service that can provide an experience on every device from a smart phone to a large screen or integrate data from an IoT device yet deliver a user experience on a hololense!!!!

Windows-10_Product-Family

Traditional Architectures relied on us building a single monolithic application that probably serviced only a single touch point. As we have to service more touchpoints we will want to project our digital service to each touchpoint only exposing the user experience that is appropriate to the device.  We will also need to change touch points independently and often.

An Architectural Vision for a modern enterprise would be to have an Architecture that can provide an excellent customer/user experience through focused touch points supported by a low cost, scalable, highly available, redundent infrastructure that can support a low cost, high frequency of change with low risk.

Easy!!!

The below diagram articulates a highlevel logical architecture of a typical Enterprise scenario or the probably As-Is of your enterprise application.

DigitalArchitecture

The architecture is broken up into 5 layers.

  1. Touch points – These are the external devices that your users are going to interact with. They sit outside your firewall, and may intermittent connection to the internet
  2. Presentation Services – These are the services that your devices interact with, they could finished interfaces exposed as websites or REST services exposing the data for apps. They will most likely be HTTP end points.
  3. Frontend Services – These services provide the logic and processing for the Presentation Services. There may be a common set of services here that provide functionality to a number of Presentation services and are generally separated by their domains.  These services will have their own databases.
  4. Integration & Orchestration Services – This is the bridge between the modern, frontend world and the legacy backend services. The orchestration layer is typically provided by an enterprise service bus such as Biztalk Server, Mule or similar.
  5. Backend Services – these are the core backend services that drive and support your enterprise.

There are 2 key characteristics that separate the infrastructure requirements between the top and bottom of this architecture. The top layers need to be available 24/7, will change frequently and are open to the public and therefore need to be able to support traffic spikes and scale. The bottom layers may only require a low availability, sometimes a 9-5 schedule, change rarely and don’t need to scale as they operate on a predominantly batch based life cycle.  This is an important point when reviewing and selecting the types of infrastructure solutions to support the 24/7, frequently changing environments as this can only be achieved with high levels of automation and thus require the selected components to support automation.

As you can see from the diagram below we can use Azure services to deliver this architecture.

Slide2

In the next article we will decompose an ecommerce solution into the above architecture.

Leave a Comment