Microservices is not just a new buzzword in software design discussions waiting to fade away in the near future. Microservices are here to stay. The idea is not new and has been around for many years disguised as service orientated architecture or other proprietary nomenclature. So what has happened and how can the recent success of microservices be explained?


For our company it is all about the cost of software development, deployment and maintenance, for some it makes distributed development teams manageable. Whatever the motivation the result of changing to a microservice architecture is a simplification of the sometimes daunting task of managing a software team and providing long term service.

Microservices are small, manageable chunks of software easily implemented, enhanced or even replaced.

This implementation is as simple as starting a new process. The new process logs into a service management process which distributes resources (communication ports, database connections and more). Another microservice provides a watchdog function and the new service is monitored. A further microservice supplies a logging functionality and the new process has enhanced the system faster than it took to read the last three sentences. The process can be stopped and restarted for test purposes with no negative effects on the rest of the system which continues to run.

Once tested the new microservice exposes it's interfaces (APIs) to the other services. All microservices and all of their interfaces use the same syntax so it is quite easy to modify older services to make use of the new interfaces. Hence the new microservice takes on "responsibility" within the system and other microservices become "dependent" upon this functionality.

So what if the new process breaks under pressure?

Are we building a house of cards waiting for one card to bend? This should not happen. Well designed systems will continue to run using older versions of the microservice or avoiding the new interface altogether.

Redesign or replacement necessary?

Not the problem it used to be. You are only throwing away a small piece of code, in our case maybe as little as one page of code. This really does simplify things. It takes the headache out of system enhancements and speeds up the software management cycle.