The microservices architecture pattern is a method to develop applications that are composed of smaller applications, each of which is developed as a small service and has independent lifecycle management. These smaller services are loosely coupled together to form a larger application. When you consider whether an application should use microservices architecture, you should carefully evaluate whether it makes sense for the smaller functions to exist as independent microservices. Since each of the constituent micorservices in a microservices-based application has its own lifecycle management, you will have DevOps for each of the services managed independently.

One of the things you need to consider before you break your application down into microservices is the granularity required. Breaking it down into too many granular units would increase the operations overhead, while breaking it down into too few units would increase the application's complexity and failure points. Careful consideration of the requirements, outcome, and operations overhead would need to be taken before any application can be considered for design using a microservices pattern.

In a microservices pattern, each of the services should be able to achieve a certain viable functional completeness. The means to share data between each of these microservices will have to be consistent and reliable, and independent of any failures that may occur in any of the constituent microservices at any point in time.

This architectural pattern is a very useful pattern for application development on cloud platforms such as Bluemix. Application developers can now leverage portions of functionality from value-added services on such cloud platforms and can build only the application logic that is required for their business. This expedites application development timelines and provides the impetus required to bring innovative applications to the market faster than would otherwise be the case.

The following screenshot shows the visual representation of what a monolithic application is, as opposed to what a microservices-based application is:

You will see that the monolithic application has all the necessary functionality built into the same deployable module or unit, which eventually runs on the same infrastructure. However, in the case of a microservices-based application, you will see that each of the functions of the application is broken down as a deployable application unit, and each of them can run in their own infrastructure. The failure of one microservice does not bring all the other microservices down. The composition of individual microservices forms the new microservice-based application.

Since each of the microservices is a deployable unit by itself and has an independent and individual DevOps, or lifecycle, you will notice that each of the microservices can also be scaled individually, as opposed to the need to scale the entire application, in the case of a monolithic application. This gives the ability to only scale those services that consume greater resources with increase in load. Microservices that are low or static in resource consumption in response to load increase or decrease can be configured to scale to a lesser number of nodes, or can afford to not have additional nodes associated, as shown in the following screenshot: