OSGi, Modularisation and Micro-services

I have now refreshed my memory on OSGi thanks to Richard Nicholson's comments. Richard is correct of course. Modularisation is a key component of scale too. But in todays world of Docker, Kubernetes, OpenShift and the plethora of other DevOps/CDCI related modules, we only deal with the software and hardware infrastructure and not the behaviour of a solution to a business problem. Now that we have execution venues (PaaS and SaaS) we can focus more of our attention in the complexities of delivering that behaviour over a collection of loosely coupled micro-services. 

For read-only (stateless) we have an internet-scalable pattern that works well, is transparent (that is we can monitor and understand in the business domain with little additional effort) and is flexible against changing need, through DevOps and CDCI pipelining.

But for stateful behaviours we are less equipped and often try to map stateful to stateless idioms to achieve scale, but at the cost of flexibility and transparency. The purpose of scribble is to bridge that gap and make it just as easy to build, if not easier, stateful solutions that are closer to the business domain that they support with no less flexible.

That is to say, that with scribble, we can be deployed just as fast as stateless solutions so we do not slow the velocity of change, we reduce any additional effort to monitor in the business domain by keeping ensuring our stateful interactions are a reflection in the business domain, and enabling rapid recovery in the event of a "modular" container by being able to instantiate on the fly and in a specific state.

From a Total Cost of Ownership (TCO) perspective we reduce the cost of development by removing errors related to stateful interaction and moving SIT into a virtual SIT world, we maintain the same cost of deployment into test and production environments, we reduce the cost of monitoring in the business domain and add further value by being able to measure what we observe against what was expected and we lower the operational costs associated with tenancy through lazy, just-in-time behavioural instantiation.

A Living Chronology on scaling micro-services

I decided to post this because I wanted to give more context to my previous blog entitled "Scaling micro-services with scribble types".

This chronology, which I kick off today, is all about the journey to solving some of the hardest problems in scaling stateful micro-services, of which the first entry in the chronology was that previous post. In the next entries I will chart the progress, describe the challenges along the way and how they get resolved. It so doing I plan to take input from anyone. The blog is one means of gathering suggestions, which if you do give any, I would like to share.

Having looked long and hard at the gap between practitioners and academics in this digital world and having looked at how we try to overcome and improve through lean and agile ways of working, I think that involving as many as I can will lead to better tangible results for some key academic gains in recent years. Foremost of these gains is session types, which derive from Robin Milners pi-calculus.

In effect we take session types, embodied in scribble and use scribble to help us implement just-in-time, behavioural serverless architectures that lower the cost of ownership, to help us write better collections of micro-services which work faster, to help to lower the cost of value delivered whilst increasing the quality of what get delivered, and to help us understand the processes that get enacted by micro-services on our behalf in real-time, which results in lower cost and higher volumes of business transactions.

There may well be many pitfalls ahead but thus far it is all looking good. I look forward to wider collaboration.