Microservices and "Microservice Architecture" has sprung up over the last few years to describe a Software Architecture Model in which large complex software applications are composed of one or more independently deployable services.

While there is no precise definition of this Software Architecture Model, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.[1]

What are Microservice [2]#

While there is no standard, formal definition of Microservice, there are certain characteristics that help identify a style. Microservice should have:

Bounded Context#

Any particular Microservice does not "know" anything about underlying implementation of other Microservices surrounding it. If for whatever reason a Microservice needs to know anything about another Microservice (for example, what it does or how it needs to be called), you do not have a Bounded Context.

Bounded Context is an absolutely essential characteristic of Microservice. We need to be able to deploy a single Microservice on its own. There must be zero coordination necessary for the deployment with other Microservice. This Bounded Context enables frequent and rapid deployments, therefore getting much-needed features and capabilities to the consumers.

Single Responsibility Principle#

Microservice need to focus on a unit of work, and as such they are small. There are no rules on how small a Microservice must be. A typically referenced guideline is the Two-Pizza Team rule, which states if you cannot feed the Delivery Team building a microservice with two pizzas, your Microservice is too big. You want to make the Microservice small enough so that you can rewrite and maintain the entire Microservice easily within a Delivery Team if you need to.

A Microservice also needs to be treated like an application or a product. A Microservice should have its own source code management Source code repository, and its own delivery pipeline for builds and deployment. Although the Product Owner might advocate the reuse of the Microservice, reuse is not the only business motivation for Microservices. There are others such as:

  • localized optimizations to improve User Interface (UI) responsiveness
  • to be able to respond to customer needs more rapidly.

Microservice granularity can also be determined based on business needs. Package tracking, car insurance quote service, and weather forecasting are all examples of services delivered by other third-party service providers, or delivered as a core competency chargeable service.


Since Microservices has a Bounded Context and they communicate with each other over protocol, there is no reason they can not be written with different programing languages, even the same Microservice could be Polyglot. This implies Microservice should be defined as an Interface Description Language

Having a Bounded Context allows using the correct tool for the correct job is important. Microservice need to be built using the programming language and technology that makes the most sense for the task at hand. Microservice are composed together to form a complex application, and they do not need to be written using the same programming language. In some cases Java might be the correct language, and in others it might be Python, for example.

Communication with Microservices is through language-neutral APIs, typically an (HTTP)-based resource API, such as REST. You should standardize on the integration and not on the platform used by the Microservice. Language-neutral makes it easier to use existing skills or the most optimal language.

Characteristics of a Microservice[1]#

While Microservice is still more of a concept than a predefined architecture with specific requirements, Lewis and Fowler say there are certain attributes that typically come with microservices, including:
  • Componentization as a Service: bringing certain components together to make a customized service.
  • Organized Around Business Capabilities: segregating capabilities for specific business areas like user interface and external integrations.
  • Development Process is Based on Products Not Projects: following Amazon’s "eat your own dog food", developers stay with the software for the product’s lifetime.
  • Smart endpoints and dumb pipes: each Microservice is Bounded Context with its own domain logic and Data Store.
  • Decentralized Governance: enabling developer choice to build on preferred languages for each component.
  • Decentralized Data Management: having each microservice label and handle data differently.
  • Infrastructure Automation: including automated deployment up the pipeline.
  • Design for Failure: meaning that more ongoing testing of "what if" has to occur to prepare for failure.

Project vs Product Mentality#

Most application development efforts that we see use a project Mentality:
  • where the aim is to deliver some piece of software or service which is then considered to be completed.
  • On completion the software is handed over to a maintenance organization a
  • project team that built it is disbanded.

The product mentality, ties in with the linkage to business capabilities. Rather than looking at the software or service as a set of functionality to be completed, there is an on-going relationship where the question is how can software assist its users to enhance the business capability.

Smart endpoints and dumb pipes#

When building communication structures between different processes, we've seen many products and approaches that stress putting significant smarts into the communication mechanism itself. A good example of this is the Enterprise Service Bus (ESB), where ESB products often include sophisticated facilities for message routing, choreography, transformation, and applying Business Logic.

The Microservice community favors an alternative approach: smart endpoints and dumb pipes.

Applications built from Microservice aim to be as decoupled and as cohesive as possible - they own their own domain logic and data and act more as filters in the classical UNIX sense - receiving a request, applying logic as appropriate and producing a response.

Typically, these are choreographed using simple RESTish protocols rather than complex protocols such as WS-Choreography or BPEL or orchestration by a central tool.

The two protocols used most commonly are HTTP request-response with resource API's and lightweight messaging. The best expression of the first is

Be of the web, not behind the web
-- Ian Robinson

Microservice teams use the principles and protocols that the world wide web (and to a large extent, Unix) is built on. Often used resources can be cached with very little effort on the part of developers or operations folk.

Microservice or something similar is a requirement to do WEB Scale products where:

  • Brand new deployments are rare.
  • New versions deployed automatically and frequently
  • No real need for general purpose orchestration
  • Each deployment is customized.

Why Microservice#

Benefits of using Microservice

Lower Learning Curve -

More Information#

There might be more information for this subject on one of the following: