In the good old, bad old days traditional, single tiered monolithic apps were the norm as they were fast to develop, easy to integrate and offered user interface similarity.  Whilst successful, the approach had its disadvantages with the key drawback being they were big and inflexible.  So what’s the alternative?  Enter the architectural world of Microservices where it is common to break up applications into single function, discrete services.  Not necessarily new, but an approach that has grown in popularity when you have to support a range of platforms spanning web, mobile, internet of things and wearables.

In a monolithic development world, whenever you make a change to a small part of an application, it requires the entire monolith to be rebuilt and deployed. This makes it hard to retain a solid modular structure due to the scaling required for the entire application rather than the parts. Microservices architecture puts each element of functionality into a separate service and scales by distributing these services across servers, only replicating as needed.

Whilst it would seem that the alternative to the monolithic approach is a whole bunch of services to manage, keeping them all in tip top shape may be quite a challenge.  A better way to look at it might be to compare microservices to a circuit breaker. If one microservice fails, then you can isolate it, but the rest of the application would continue to operate.

So who are the major players who have adopted the microservices approach? Think along the lines of Amazon, Netflix and eBay, all of whom have moved on from the monolithic approach to microservices architecture.

Owen Garrett of Nginx, whose company’s web servers powers in the region of one in every five of the top one million websites, offers a good example of microservices capability.  Type in “Nike shoe” on Amazon and over 170 individual applications get triggered potentially from that search – everything from pricing to images of the shoes to reviews of the shoes to recommendations of other products you may want to purchase. Each one is an individual service or sub feature of an application or an overarching experience, and all are connected via HTTP.   They may be all built in different languages and each one may have different requirements in terms of the data store, scaling and automation. And they are all fundamental elements of microservices architecture.

Microservices may have its detractors but it can reap dividends.  Services can be updated individually, new applications can be built quickly from existing services and your IT management has greater clarity on who is responsible for what.  Experience is ultimately the decider.  If your organisation can make the right adjustments, then you will be able to realise the benefits of microservices.