Tinker's thoughts~

About Blog GitHub

14 Feb 2016
Understanding Microservices in Context of a Kitchen

Look to your left, you find microservices, look to your TV, Netflix is on microservices. Microservices have seeped into the technology matrix like a silent assassin over the years. The Unix mantra of “Do one thing and do it well” is applied to microservices thus making it leaner. Microservices architectural style composes of few key principles that address how services will be developed and deployed. 

My metaphor to explain microservices is to use a restaurant. Imagine if Mr. Krabs (the owner) of Krusty Krab from the Sponge Bob franchise decided to implement a microservices-based approach to his restaurant.

Krusty Krab (the Monolith)

Let’s take the current situation — a customer visits the restaurant and leaves orders at the front desk(manned by Squidward). The front desk bills the customer and queues the kitchen for a Krabby Patty (a Burger). The customer waits at the counter till his food is ready.

In the kitchen — one man (or rather a sponge) take the receipt from the queue and begins the process to make the burger. He gets the ingredients from the stores, grills the patties and makes a burger. He calls the Front desk back saying that the patty is ready.

At the front desk, Squidward hands the burger to the customer. The customer finds a seat and enjoys the burger.


In the current scenario, the restaurant cannot scale easily for a large number of customers. Also, the front desk and kitchen of the restaurant are built in a monolithic manner. We can think of Squidward at the front desk as the front-end UI of the application that the customers interact with. Spongebob is the backend that grills the tasty patty and assembles the Krabby Patty.

In this model — it’s not very easy to scale the restaurant to support many more customers. The counter (Front-end) of the restaurant can easily be scaled up by hiring a few people to work with Squidward (aka spinning up new instances to handle the UI traffic). As for the Kitchen (backend) — we can also hire a few people to do the exact work Sponge Bob does.

But the kitchen is different from the counter. Kitchen involves division of labor where different people need to do different tasks. One has to grill the patty. One has to heat the buns. One has the make the fries. Due to this Mr. Krabs needs to be able to scale different divisions.

Micro-services based approach

In the micro-services architecture, we approach the problem differently. We try to understand the components of a business operation. In our case, the kitchen. Below are some identifiable components of the kitchen.

  • Burgers section
  • Fries section
  • Salads section (Let’s milk money off the Vegetarians!)

One thing you’d notice is that the components we chose can execute without any inter-dependencies.

We can also fine tune the business process to improve the customer experience. Right now, the customer has to wait near the counter while his order is getting ready. How about we implement the system where the customer can listen to an announcement for his receipt number. This would be a better approach for our kitchen since the kitchen doesn’t have to get blocked for serving a single customer. We could serve multiple customers faster.

Martin Fowlers’s characteristics applied

According Martin Fowler there a few characteristics that make good microservices. 

  • Componentization via Services
  • Organized around Business capabilities
  • Products not projects
  • Smart endpoints and dumb pipes
  • Design for failure
  • Decentralized governance & Data management
  • Evolutionary design
  • Infrastructure automation

Componentization via Services

According to our example, we can have each section become a service. Eg:- Burger service. Each service is exposed to the front office via remote calls. This would be the receipt received by the burger section. In the tech world, remote calls are called over the network. Practical modes of this could be types of communication such as HTTP, AMQP, MQTT or Thrift.

Organized around Business capabilities

Our services are based very specifically on the sections of the kitchen. In the business world, this would require us to think a bit more since there are inter connections between business capabilities. We’re not going to have a maintenance service in our services list since that’s not focused on business capabilities. Each service is responsible for cleaning up it’s own resources.

Products not projects

This is mostly about a point of reference. When we look at the burger service as a product instead of a project, we would look at the support and maintenance of the product. Products will live for a lifetime. In our case, as long as the Krusty crab is making Krabby Patties, our burger service is going to be utilized.

Smart endpoints and dumb pipes

What this means according to our example is that the counter would call each service to get the items ready. When the customer give an order of a Pork Krabby Patty, 2 vegetable salads and medium fries, the counter will invoke each service with the properties. It will respond to the customer based on the output of the service calls to the microservices. Kasun Indrasiri’s his blog post on Microservices in Practice explains a few more methods of communicating between services. He mentions, “Therefore, for complex Microservices use cases, rather than having point-to-point connectivity or a central ESB, we could have a lightweight central messaging bus which can provide an abstraction layer for the microservices and that can be used to implement various non-functional capabilities. This style is known as API Gateway style.”

Design for failure

Since our business use cases are isolated into services — our front-end system can be built for failure. The burger can still be cooked even if fries are not available. The front end can make a refund for the fries rather than canceling the order.

Decentralized Governance & Data Management

Governance is a method of controlling and standardizing procedures. Governance ideally happens differently according to different business units. The standard of preparing a burger is different from the standard for preparing fries. Also, we don’t have to hire only Brits to make fish and fries, we can hire an Indian too. In the real world governance is decentralized. In the services world, we can actually build our burger service in Java and fries service in Python. It’s a polyglot paradise.

Data management can also be set up separately. The burger section can manage it’s data in Excel while the fries section can use the old school notebook. Our services also don’t have to worry about a central database. One service can be backed up via MySQL and the other via MongoDB.

Evolutionary design

Our design & policy decisions don’t have inter-dependencies with other services. Due to this new freedom, our design can evolve at a much faster pace. Mr Krab can buy a machine for the fries section and do away with the employees. Our Fries service can use Python 3 features rather than sticking to Python 2.X.

Infrastructure automation

This is an analogy I can’t attribute to our restaurant metaphor. But nevertheless, in our service layer what this means is that we can automate deployments. This is done using small isolated containers that can run in mass hardware. A popular method is to use Docker (container technology) with Kubernetes (cluster management technology). Carlos Sanchez writes a lengthy blog post on InfoQ on this subject which is definitely worth a read. One of the key differences of SOA and microservices is the focus given to the deployment of services. Microservices are meant to be highly available and fault tolerant. The technology mix of Docker, and Kubernates allows us to efficiently do this. 

My next post would be an introduction to the new microservices framework by WSO2, MSF4j and how we can build the above mentioned Burger Service as a microservice.

Till next time mate,
Dulitha at 14:00

About Blog GitHub