Microservices are small, autonomous services that work together.


Microservice architecture, or simply microservices, is a distinctive method of developing software systems that tries to focus on building single-function modules with well-defined interfaces and operations. The trend has grown popular in recent years as Enterprises look to become more Agile and move towards a DevOps and continuous testing. Microservices can help create scalable, testable software that can be delivered weekly, not yearly.

Alt Text

Microservices architecture (courtesy: Cloud Application Architecture Guide and smartbear).

  • Sam Newman : “Microservices are small, autonomous services that work together.”
  • Frye:The idea with microservices is to focus on building individual services that do one thing and one thing well.
  • Nic Grange, CTO at Retriever Communications: “Microservices are an approach to designing software systems that are made up of small independent services that each have a specific purpose.”
  • Ali Hussain, CTO at Flux7: “Microservices are an approach to addressing a large or complex business problem using a set of smaller, simpler services that work together; a microservice runs its own unique process that contributes to an overarching business goal.”
  • Dr. Ratinder Ahuja, Founder and CEO of ShieldX Networks: “Microservices are an approach to application development in which a large application is built as a suite of modular services. Each module supports a specific business goal and uses a simple, well-defined interface to communicate with other sets of services.”
  • Dustin Horning, Solutions Engineer at Zesty.io: “Microservices are to software what factories are to manufacturing. Instead of having one person [or] machine build a whole car, each area is specialized in its task: This one hammers rivets, this one paints.” AND “Microservices is breaking down one large objective into its parts, and having those parts be accomplished independently.” (OK, that was two explanations, but we’ll let it slide.)
  • Justin Bingham, CTO at Janeiro Digital: “Microservices are components of an application or broader ecosystem architected to operate independently – each responsible for a specific business or technical domain.”
  • Michael Ducy, Director of Product Marketing at Chef: “It’s breaking down the development and release of applications into smaller pieces of work.”
  • Kong Yang, Head Geek at SolarWinds: “Microservices are a method of developing software applications which are made up of independently deployable, modular services. Each microservice runs a unique process and communicates through a well-defined, lightweight mechanism, such as a container, to serve a business goal.”
  • Microservices allow an organization to reduce dependencies, develop faster, and scale.—Aviran Mordo

Microservices Definition by Lewis/Fowler:

  • As a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API
  • Services are built around business capabilities
  • services are independently deployable and scalable
  • Bare minimum of centralized management of these services
  • Services may be written in different programming languages(polyglot development).
  • Services should use separate data storage (polyglot persistence ).

“Microservices are important simply because they add unique value in a way of simplification of complexity in systems. By breaking apart your system or application into many smaller parts, you show ways of reducing duplication, increasing cohesion and lowering your coupling between parts, thus making your overall system parts easier to understand, more scalable, and easier to change. The downside of a distributed system is that it is always more complex from a systems standpoint. The overhead of many small services to manage is another factor to consider. ” ― Lucas Krause,

The Microservices approach is about breaking your system (“pile of code”) into many small services, each typically has its own:

  • Clear business-related responsibility
  • Running process
  • Database
  • Code version control (e.g. git) repository
  • API (the protocol how other services / clients will contact the Microservice)
  • UI


  • Microservice make our system loosely coupled, i.e. if we need to update, repair, or replace a Microservice, we don’t need to rebuild our entire application, just swap out the part that needs it.
  • To built each Microservice can use different languages and tools. Microservices communicate with well defined interface
  • The communication should be stateless for scalability(copies of Microservice) and reliability(one copy fail other copy can serve), the most common methods for communication between Microservices are HTTP and messaging. Each Microservice should have it’s own datastore.
  • Small team capable to work on design, web development, coding, database admin and operations.


Consider this architecture style for:

  • Large applications that require a high release velocity.
  • Complex applications that need to be highly scalable.
  • Applications with rich domains or many subdomains.
  • An organization that consists of small development teams.



Sam Newman in Building Microservices, enumerates the key benefits of Microservices as following:

Technology Heterogeneity

With a system composed of multiple, collaborating services, we can decide to use different technologies inside each one. This allows us to pick the right tool for each job, rather than having to select a more standardized, one-size-fits-all approach that often ends up being the lowest common denominator.


A key concept in resilience engineering is the bulkhead. If one component of a system fails, but that failure doesn’t cascade, you can isolate the problem and the rest of the system can carry on working. Service boundaries become your obvious bulkheads. In a monolithic service, if the service fails, everything stops working. With a monolithic system, we can run on multiple machines to reduce our chance of failure, but with microservices, we can build systems that handle the total failure of services and degrade functionality accordingly.


With a large, monolithic service, we have to scale everything together. One small part of our overall system is constrained in performance, but if that behavior is locked up in a giant monolithic application, we have to handle scaling everything as a piece. With smaller services, we can just scale those services that need scaling, allowing us to run other parts of the system on smaller, less powerful hardware.

Ease of Deployment

A one-line change to a million-line-long monolithic application requires the whole application to be deployed in order to release the change. That could be a large-impact, high-risk deployment. In practice, large-impact, high-risk deployments end up happening infrequently due to understandable fear.

With microservices, we can make a change to a single service and deploy it independently of the rest of the system. This allows us to get our code deployed faster. If a problem does occur, it can be isolated quickly to an individual service, making fast rollback easy to achieve.

Organizational Alignment

Microservices allow us to better align our architecture to our organization, helping us minimize the number of people working on any one codebase to hit the sweet spot of team size and productivity. We can also shift ownership of services between teams to try to keep people working on one service collocated.


One of the key promises of distributed systems and service-oriented architectures is that we open up opportunities for reuse of functionality. With microservices, we allow for our functionality to be consumed in different ways for different purposes. This can be especially important when we think about how our consumers use our software.

Optimizing for Replaceability

If you work at a medium-size or bigger organization, chances are you are aware of some big, nasty legacy system sitting in the corner. The one no one wants to touch. The one that is vital to how your company runs, but that happens to be written in some odd Fortran variant and runs only on hardware that reached end of life 25 years ago. Why hasn’t it been replaced? You know why: it’s too big and risky a job.

With our individual services being small in size, the cost to replace them with a better implementation, or even delete them altogether, is much easier to manage.


Team Communication Overhead –

Microservice architecture reduces the team management complexity, but it is not able to diminish the need of team communication. They need to make sure an update in one’s service is not breaking some other functionality. We can find this problem in monolith architecture applications too.

Non uniform application –

We can choose a different technology stack for a different component (polyglot). It leads to the problem of non uniform application design and architecture. It may can increase maintenance cost in the long run.

Dev Ops complexity –

We need to have a mature Dev Ops team to handle the complexity involved in maintaining Microservice based application. Due to several moving parts of the application, it becomes complex and requires a high level of expertise. Increased Resource use – Initial investment to run these applications are high because all the independently running components need their own runtime containers with more memory and CPU.

Increase Network communication –

Independently running components interact with each other over a network. Such systems require reliable and fast network connections. Marshalling and Un marshalling – When one component needs data from another component, the sender marshals the data in some standard from its internal representation, while the receiver un-marshalls data into its own representation before use. This definitely requires more processing compared to conventional application architecture.

Network Security –

Inter Service Communication needs to be secured to avoid any inter communication security breach. Due to several moving parts, these applications are more prone to security vulnerabilities.

Testing –

Testing of such application is definitely harder compared to a monolith application.

Production monitoring –

Unavailability of the right tools are also an issue to be considered.

Log analysis –

Need log analysis tool for log analysis ,Splunk or ELK stack

Alt Text

 (Image courtesy:pivotal)