Microservices: Principles and in Practice

by Sysco LABS Articles 22 April 2016

An Introduction: What are Microservices?

In this Innovation Session, Kalinga Dissanayake and Azeem Mumtaz from the Platform team give an insight to microservices. According to Sam Newman the author of “Building Microservices”, microservices are a group of small autonomous services that work together and are modelled around a business domain.

Microservices vs Monolithic Applications

When comparing microservices with monolithic services, a monolithic application puts all its functionalities into a single process, while a microservices architecture puts each element of functionality into a separate service. Also, monolithic applications scale by replicating the monolith on multiple servers, while the microservices application scales by distributing these services across servers, replicating them as needed.  One principle of microservices is that it has to be autonomous.  A service with the same dependent functionality cannot be broken into multiple services.  CAKE’s platform is an example of the microservices principle: there is the Merchant API that is merchant specific, the Consumer API that is used for online ordering, the Admin API,  and the Payment API which deals with transactions.
Key Features of a “Microservices” Model

Small Autonomous Services

APIs have a lot of functionality within one particular component or process, and they deploy together. The Merchant API for example has the Wallet API, Notifications, Menu Related APIs, Rewards API, CINCO Onboarding API, and Employee Management API. This forms an ideal use case for microservices where it will be broken into individual services.  In the concept of business domain based modeling, what happens usually is when a requirement comes up, a team is set up horizontally to cater to that need. For instance, if a requirement comes up to support online ordering, it is the responsibility of the API team (who is dedicated to creating the APIs for the whole company) to do the needful.

Business Model Based Modeling

Microservices are broken down according to the business need. This allows different teams to work in different areas, allowing independency. In the event that the microservices is broken into smaller services, it will definitely increase the number of components. One basic principle to support microservices is to create a culture of automation.

Culture of Automation

A culture of automation is important because each API cannot be tested independently using functional testing – there should be a set of automated testing that covers the complete process. The next factor is continuous delivery. Continuous delivery together with continuous integration are crucial elements if this model is to work. Although the components are independent, there should be a lot of automated testing up and running as well as continuous integration to make sure everything works as expected.

The disadvantage of microservices is that it is difficult to apply to an already existing (monolithic) platform. The upfront work for a transition is huge. If there is a monolithic application where the merchant API gets many client calls, it is hard to switch that monolithic application to a microservices model in a short time. This disadvantage of microservices makes it hard to apply to an already existing platform.

Hiding Implementation Details

We see many APIs that call the same database simultaneously – a single update on the database will cause changes to the entire set of connected APIs.  In microservices, it is important to hide the implementation details. For example, the Data level API will access the database but that database will change to meet the business domain. That particular responsibility will be hidden and will be within the data level API only. This concept also reduces the need for making changes to the existing infrastructure.


Do we still need to rely on another party to create a new server instance? If a team is responsible for developing 2 microservices and it needs to be scaled, plus it also depends on the team’s availability. Do we still rely on another party for deployment? Currently yes, and because of the Deployment team, the Platform team survives, depending on the team’s area of focus. All changes and implementations are communicated to all other teams in the CAKE ecosystem for us to push a release. This allows teams to focus on different areas individually. It is not a one-man show, since this incorporates the full dedication and work from all teams involved. Decentralization however does not mean decentralizing everything.

Consumer First

With the consumer first approach, service discovery is another important factor. Swagger is used for this and featured by Industry Standard – Open API Initiative (OAI) that has announced an open governance model around the Swagger Specification under the Linux Foundation. Swagger also has the largest community and has been around since 2011. Swagger can be used as an interactive sandbox, used to generate stubsand conduct live documentation demos. Swagger is 100% open source. There should be a way to discover these services so that developers know the specific APIs that are available to them.

Isolate Failure, Observe, and Debug Failure

The next concept is isolating failures as well as observe and debug failures. Since there are many components, isolating, observing and debugging is a tough task. Log aggregation tools such as Logstash help with this to a great extent. Tools that can be used for monitoring are Cacti, Nagios, Graphite and Grafana to name a few. AWS Autoscaling is also important for this requirement. It allows health checks and spawns new instances to take care of the situation, such as running out of memory. The concept of correlation IDs is an ID which is sent with 1 request, goes through the whole flow and returns to the client. This is important in the microservices architecture as there will be an easy way to trace all intercommunication. The last principle is independently deploying the component. The team deploying a component should be able to take that particular service from development to production.

Deploy Independently with Docker

In the subject of microservices, a key word that keeps coming up is container. This is mentioned in many tech talks and articles that talks about their importance. In virtual machines, containers are isolated, but share the OS and bins/binaries where appropriate, which is faster, very lightweight and has less overhead. Docker is the standard in the industry for creating/managing containers. Docker allows the developer to package an application with all of its dependencies into a standardized unit for software development. This is called a Dockerfile. The Docker engine enables the containers to share the underlying infrastructure including the kernel and is lightweight, open and secure, which adds another layer of security on top of the host OS. Docker accelerates developer onboarding, which helps in eliminating environment inconsistencies. Docker also allows developers to share work easily and collaboration on applications, and helps to ship more software faster.

AWS Elastic Beanstalk

To manage the microservices infrastructure, an AWS product called AWS Elastic Beanstalk is used. Beanstalk allows to create an environment for the application that has auto scaling, load balancing and even security services. All Amazon provided services can be used with Beanstalk. Beanstalk reduces management complexity without restricting choice or control as well as allows quick deployment and managing applications in the AWS cloud. The underlying architecture of Beanstalk uses the Amazon Container Services called Amazon ECS. The following video shows an introduction to Amazon’s EC2 Container service:





Leave a Comment