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]

Microservice is part of the API Economy

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 Orchestration necessary for the deployment with other Microservice. This Bounded Context enables Continuous Development and Continuous Delivery, therefore getting much-needed features and capabilities to the consumers and delivering Business value

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 Delivery 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 a 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 Architecture [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 Continuous Delivery 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:
  • Simpler To Understand - Follow code easier since the function is isolated and less dependent.
  • Simpler To Deploy - Each Microservice can be deployed without affecting other services
  • Faster Defect Isolation - When a test fails or service goes down, isolate it quickly with microservices.
  • Reusability Across Business - Share small services like payment or login systems across the Organizational Entity.
  • Avoid locking in technologies or languages for each microservice and change on the fly with little risk
  • Teams can work in parallel on different Microservices to get things done faster

The first benefit is that microservices are much smaller and simpler than a larger, monolithic application. This means it’s easier for developers to understand and, more importantly, get right. Microservices are designed around business initiatives, so a team can really focus on perfecting it without worrying too much about other parts of the application.

Having each Microservice logically separated from the others means they can be deployed and scaled independently from the others. If your website has a promotion and gets a sudden rush of signups, the front end and the user authorization engine might get hit particularly hard that day. With a microservices architecture, you can scale up just those services rather than the entire application. Scaling horizontally in this way can save you money on expensive on demand cloud resources.

Another advantage is that a fault or bug in one Microservice will not directly affect other parts of the application. If something does go horribly wrong, that Microservice can just bow out gracefully and let all the other parts of the app keep working as normal. Rolling back to an older version is also easier.

Each team also has the luxury of choosing whatever languages and tools they want for their job without affecting anyone else. This goes for hardware too. A Microservice that is particularly database intensive can be placed on a system with good access to a database.

Developers and teams can work in parallel to get changes to production faster. Teams can test and deploy a new version of their Microservice on their own schedule. Scaling your development team is as simple as hiring another independent team for a new microservice. Amazon has thousands of teams building microservices. Smaller codebases also mean faster compiles, builds, and deployments.

Add all these together and it’s easy to see why microservices is such a strong trend.

Microservice Concerns#

Of course, as with every method of building software, there are tradeoffs. The big one for microservices is that now you are building a distributed system, which comes with a few challenges:
  • Communication between services can get difficult, especially with unreliable services
  • Writing automated tests and creating consistent test environments for multiple tests is hard but a MUST
  • There isn’t an easy way to recreate conditions where a bug occurred
  • Communication between the services can slow things down
  • Orchestrating multiple instances of different services requires good use of automation and Continuous Delivery tools
  • now that all developers are responsible their features, and nobody is safe from a late night support call.

More Information#

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