IT Operations Blog

Microservices Architecture: An Introduction to Microservices

Stephen Watts
by Stephen Watts
5 minute read

What is Microservices Architecture (MSA)?

Microservice architecture is a method of designing software systems which divides big software applications into many small services that can run independently. Each of the microservices has its own team working on it, so they are completely separated from each other. This allows every service to run its own unique process and communicate autonomously without having to rely on other services or the application as a whole. The ability for each microservice to be separated and recombined protects the system against architecture decay and better facilitates scalability and agile processes.

Characteristics of microservices architecture

While there is no distinct definition for the methods of microservice architecture, there are common characteristics that can be seen among the ways it is utilized. Some of these more defining characteristics include:

  • Independently deployable and scalable
  • Organized around business capabilities – such as logistics, billing, etc.
  • Made of smart endpoints and dumb pipes
  • Part of decentralized governance methods
  • Composed of decentralized data management
  • Easily replaceable
  • Autonomously developed
  • Evolutionary

Independently deployable and scalable

One of the biggest characteristics of software built as microservices is the fact that it can be broken down into multiple components. This means that each separate service can be deployed on its own, as well as modified and redeployed if the need should arise, without ever compromising the application as a whole. Teams are able to tweak a service without having to reissue the entire application.

Organized around business capabilities – such as logistics, billing, etc.

Another defining characteristic of microservices is that they are organized around business goals and capabilities versus the traditional focus on technology. Microservice architecture utilizes different teams that are making a specific product and then owning and maintaining it for its lifetime. This is beneficial as it allows services to be improved promptly by developers without having to spend large amounts of time waiting for budget approvals.

Made of smart endpoints and dumb pipes

Microservices behave somewhat like UNIX systems in that they receive requests, process those requests, and then create an appropriate response. It is then said that they have smart endpoints – which process information and apply logic – and dumb pipes – which is where the information flows.

Part of decentralized governance methods

Microservices are optimal when dealing with a variety of platforms and devices, such as web, mobile, wearables, etc. As a result of this, using methods of centralized governance aren’t ideal. Developers in the microservices community are favoring a decentralized governance model as it better helps them contribute useful tools and solutions to others in the community who may be facing similar problems. By having the answers already out there, other developers are able to solve their own issues more effectively as they don’t have to re-create the wheel. Microservice architects are also utilizing code that is already available in libraries while still being able to innovate alternative solutions when necessary.

Composed of decentralized data management

Similar to decentralized governance, microservices favor decentralized data management. What this means is that each service has its own unique database that it manages, whether it be different uses of the same database technology or different database systems entirely, and the data stays where it is created. Each team is able to localize, process, and analyze the data in an agile manner, independent of the application as a whole.

Easily replaceable

Due to the fact that many diverse services are communicating with each other, it is highly probable that one service may fail at one point or another. Services may fail for multiple reasons, including instances when the technology becomes outdated or when the code in the service cannot be developed any further. A characteristic of microservices that helps in these situations is that they are extremely easy to replace and can be reasonably managed. In fact, the smaller a microservice is, the easier it is to be replaced with a new implementation.

Autonomously developed

Microservices are autonomously developed and deployed, which allows teams to modify and implement services independently of other teams. This is beneficial as it enables the scaling of development without having to require a lot of coordination between the teams. While there is no specific upper limit of the size of a service or the team that manages it, it is recommended that a microservice should never grow so large that more than one team needs to work on it.


A final characteristic that is common in microservices is that they are evolutionary. Microservices are comprised of evolutionary designs and are perfect for situations where developers can’t completely predict what devices may be accessing the application in the future. As unforeseen requirements surface, developers will be able to make quick and controlled changes to the software without slowing the entire application down.

Monolithic vs. microservices

To fully understand the microservice style, it is vital to compare it to the classic monolithic style. Monolithic applications are built as a single unit and all change cycles are tied to each other. Enterprise Applications, for example, utilize monolithic architecture and are built in three parts: the client-side user interface, a database, and a server-side application. The client-side consists of HTML pages and runs in a browser on the user’s machine, while the server-side application handles HTTP requests, retrieves and updates data from the database, and populates HTML views that are then sent to the browser.

The problem with monolithic applications, however, is that any necessary changes to even a small section of the application require a completely new version to be built and deployed. Another issue is that in order to scale certain components, the entire application may have to be scaled.

Some developers maintain that you should begin with a monolith and then gradually add microservices, but this concept is up for debate.

Microservices are often considered to be a logical evolution of Service Oriented Architecture (SOA).  In a related blog post, we go into greater detail on the differences between SOA and Microservices.


Examples of microservices

As Martin Fowler points out, there are many large companies that now utilize microservices within their architecture. Some of these include:

  • Netflix
  • eBay
  • Amazon
  • Twitter
  • PayPal
  • SoundCloud
  • Gilt
  • The Guardian

Netflix and Amazon are known for their diverse architectures which have evolved from monolithic to microservices in order to handle their large volume of data. eBay has also gone through the same transition.

Benefits of microservices

Although some developers may be resistant to change, or hesitant about trying something different in their applications, the benefits of microservices far outweigh the potential disadvantages. Microservices are especially beneficial for large applications, enterprise applications, and even various Internet software applications. Some of the many advantages that microservices have include:

  • They give developers the ability to independently develop and deploy services without waiting on decisions regarding the entire application
  • They can be created by a small team which also has the freedom to scale the services on their own
  • Their code can be written in a variety of languages
  • They are organized around business capabilities
  • Only the necessary service needs to be modified and redeployed when a change is needed versus the entire application
  • If one of the services fails, the others will continue to work, as opposed to a monolith system, where the entire system would fail


In an increasingly complex digital age, it is vital that software architects have agile development techniques that can keep up with the intense demands of the ever-changing technology world. Developers face the problem of ensuring their applications are dynamic yet consistent, and can adapt across a wide range of devices – some which may not have even been created yet. Microservices are scalable, modular, evolutionary, and versatile, and they could be just the solution that forward-thinking developers need.

Docker & Microservices On-Demand Webinar

Webinar: Lifting the veil on microservices monitoring in Docker containers. Plan your microservices container monitoring strategy
Watch Now ›

These postings are my own and do not necessarily represent BMC's position, strategies, or opinion.

See an error or have a suggestion? Please let us know by emailing

About the author

Stephen Watts

Stephen Watts

Stephen is based in Birmingham, AL and began working at BMC Software in 2012. Stephen holds a degree in Philosophy from Auburn University and is currently enrolled in the MS in Information Systems - Enterprise Technology Management program at University of Colorado Denver.

Stephen contributes to a variety of publications including, Search Engine Journal, ITSM.Tools, IT Chronicles, DZone, and CompTIA.