At Contino, we have delivered and advised on many software projects that are designed in a Microservice style and architecture. Though we've said previously that Microservices are not a free lunch, the benefits are however so compelling that interest is continuing to grow in this way of working. Here are the main drivers that we see for this:


In a Microservice architecture, you should be able to deliver new functionality and iterate on the system faster than you would be able to on a more monolithic architecture. This is because on a monolithic platform, a number of changes would be batched together into a release, tested as a release and deployed as a release. In a Microservice world however, changes to the platform are decoupled. We can modify just one system component, test it, and then push it to production outside of any centrally mandated release cycle. This is a much faster and more agile way to ship new software features.

Use The Right Tool For The Job

Because of the isolation and independence of the Microservices, individual services can be polyglot in terms of programming language, giving us the ability to use ‘the right tool for the job’. An example of this might be a Node.js service interacting with the frontend via asynchronous web sockets, Clojure services doing some data transformation, and Java services doing some of the back end integration work. Because of the isolation, we can also switch the implementation languages over time as needs change and technology moves forward. The right tool for the Job principle also extends to the data stores. There is no need for a monolithic data store with everything forced into a relational or NoSQL structure. Instead, we allow services to have their own datastores in a format that is most appropriate to it’s needs. This is useful as more persistence options come along with the NoSQL movement.

Dynamism and Flexibility

Microservices are well suited to a dynamic, cloud environment where we want to scale up and down in response to application load. In a monolithic architecture, we tend to scale the monolith horizontally by adding new nodes. In a Microservice world we can be much more flexible and scale individual services up and down as necessary, giving the system a much more dynamic property that is well suited to an elastic cloud environment.


Microservices give us similar benefits that we get from object orientation – encapsulated services that communicate via well defined interfaces. This is good design principle at the code and class level, but also at a systemic level - making the system constituents simpler and easier to reason about whilst aiding reuse.


Both the Microservice architecture and the way it is usually approached typically gives us a high degree of resilience as a property of the system. We will typically deploy many instances of a Microservices into the system for load balancing and resilience purposes. Because the Microservices tend to communicate via REST and Asynchronous message buses, they tend to degrade gracefully as the system comes under more load.



DevOps Insights Directly to Your Inbox!

Join thousands of your peers and subscribe to our best content, news, services and events.

  • Benjamin Wootton

    Co-Founder and CTO

    Benjamin Wootton is the Co-Founder and CTO of Contino. He has worked with tens of enterprise organisations on DevOps transformation and is a hands-on DevOps engineer with expertise in cloud and containers.

    More Articles by Benjamin