What are microservices? 

While there are several definitions of what exactly is a microservice architecture, the basic high level infrastructure is built around small pieces of code with just one responsibility and that perform a single task. Those individual pieces of code are combined to achieve more complex tasks. You can think of it as building blocks. While the individual building blocks cannot do much on their own, they can be used to build grand structures

How do microservices compare to traditional applications?

Traditional applications are built as a single code base. All the pieces are intertwined into a single package which, at a simplified high level, interacts with an end user on one side and the database on the other. Microservices applications are built using a multitude of small codebases that work together to deliver results to the end user. Each microservice could be connected to its own database to manage its own data, though they do not need to be. For example, a simple number adding microservice would receive numbers as inputs and return a result without needing a database.

The clear advantages and reasons why microservices are becoming so popular are:

• Maintainability: Maintaining small pieces of code with few, if any, dependencies is simpler than maintaining a large code base with lots of dependencies

• Reusability: Microservices are small pieces of code with a single purpose in life and can easily be reused in other projects

• Modularity: Since each service is independent of the rest of the application, it can de be upgraded and deployed independently

• Fault isolation: Properly designed microservices isolate issues from the rest of the application

• Scalability: Microservices are scaled independently without scaling the whole application

• Cost: As a corollary to the scalability of microservices, scaling small microservices requires less resources than scaling the whole application. This translates to lower costs, especially in the world of cloud computing, where costs are based on resource usage.

Increased architecture complexity

While individual microservices are significantly less complex than a traditional application, the overall architecture of an application increases significantly in mainly two ways:

• Number of moving parts: Beyond the large number of microservices that need to be maintained, additional software modules are required to allow the microservices to work and perform reliably. In our simple high level overview in figure 1, we introduced a reverse proxy (to allow simple external communication with the external world) and queues (to allow messaging between services). But that is only the tip of the iceberg. We could also introduce logging/monitoring agents, API gateways, secret management and multiple databases among other things.

• Network traffic: In a traditional architecture, applications move data internally and unless the application itself fails, data is guaranteed to be processed. With microservices, that guarantee no longer exists. Communication between microservices is dependent on a network transport across potentially multiple network nodes. Since networks introduce both latency and failures, it is important for the microservices to be built with additional resiliency and the ability to withstand unreachable downstream services. Items like circuit breakers, retries and timeout management become critical for the application to function properly and manage errors gracefully

Microservices architecture opens a world of possibilities when it comes to large distributed systems. It provides a number of significant advantages over traditional monolith architecture. However, like most things in life, it does come with some significant baggage. While this is not a silver bullet, it is a compelling new tool in the software development arsenal.