Microservices – the Insider Perspective. Part 1:


Fourteen years of working in the IT industry have changed everything, starting with our perspectives. Our experiences has grown, and our naive enthusiasm for hypes and fashions has faded. Great, because IT is a tool, nothing more and nothing less, and the value of newly designed tools is not their being new, it is their capacity to solve problems.

Take Microservices for an example: They have been the talk of the industry for years, and at times praised as the ultimate solution for really, really everything IT. For J-IT, they have gathered steadily growing importance. Wherever we apply them, customer reactions are indeed enthusiastic, mostly because we recommend migration only if the problem justifies the effort and only after all organizational and technical requirements are covered.

We recommend Microservices for their huge potential in revitalizing IT landscapes that have grown organically over years and decades and have become too large, too complicated and immobile to adapt to changing environmental conditions. Jurassic Systems, so to speak.

The most glaring symptom of such an acute system growth crisis is a skyrocketing error rate, with varying teams are tampering with an essentially unmanageable application, implementing new features that have little to do with each other. Which does not matter anyway, because nobody in the company really understands the business logic of the application anymore, at least not in its entirety. The escalating complexity makes coding interventions in development and maintenance difficult, expensive and risky: even smallest changes cause unexpected effects in seemingly uninvolved, remote regions of the system. The growing risks inhibit necessary development steps. The company loses its agility, soon to be left behind by the market.

Microservices offer a perfect remedy here, being compact, autonomous services that collaborate with each other, minimizing the coupling between services while maximizing cohesion within each service. This IT architecture really fulfills the principle of single responsibility: “Do one thing and do it well”. Its advantages are obvious:

Compact, manageable services allow for easier, quicker, low-risk overhauls, throughout their whole lifecycles and by always the same team, marking a leap towards realizing the dev-ops vision. Implementing new services and modernizing individual services using specialized technologies is quite effortless. Performance-critical services are individually scalable. Ongoing, rapid, low-risk deployments reduce the time-to-market. Services can be linked to create new functionalities.

Figuratively speaking, Microservices replace cumbersome dinosaur systems with highly agile swarms of bees.

That’s what we tell our customers, but never without mentioning that this new agility carries a pricetag, and no, we are not talking initial investments, rather a wholly changed risk landscape: Migrations to Microservice architectures will always involve the characteristic challenges of complex distributed systems – think distributed transactions, ACID, and consistencies. Consult Bill Joy and his classic “Eight Errors Regarding Distributed Systems.”

Mind that we haven´t even begun discussing the organizational and technical requirements for Microservice migrations – but in part 2 of this blog series, we will do just that.