I have been trying to come up with a way to describe what I think a microservice is and I think I have come up with something. I am writing this article to see if this way of describing it works and if others agree that I have captured the key properties of microservices.

I want to imagine a web-application in the following way, with technical parts like user interface, reverse proxies, data stores, etc. going from left to right, and business functionality drawn vertically. Something like this:

With micro-services I want to eliminate technical people/teams making technical decisions without an holistic view of the problem the business is trying to solve. I will try and draw what I mean on top of this diagram.

This is the way we might build a web-application today in my organisation today:

All the functionality has dependencies at each level and although parts of the stack are independently deploy-able; business functionality is not. This gives us something I would call a monolith. Teams looking after this are stack based and make decisions based on the part of the stack they work with. Maybe during development they were not stack based and the project bought together all the relevant people, but as we go forward and look after the business functionality everyone is isolated into their own area of concern focusing on their part of the stack. So no one technical is looking holistically at the business problem! (Sure, non-technical people are but they aren't aware of a lot of the technology that can solve the problems; and architects might be but they never cover particular applications at the level required to be aware of the individual details that matter.)

Changing the design of systems built like this is hard and slow:
- You have to sort out the underpinning people processes and convince lots of people to change their part
- What you have is interconnected. e.g. One small change in the data model can affect all the services. So stuff breaks when change happens
- Everything is considered 'un-breakable', e.g. processes are put into place to ensure that no part of the system breaks even if the business actually doesn't care if some functions aren't as reliable as others.

I think this model is a great way to do things where individual parts of the stack are and costly to deploy and maintain, and needs their own set of engineers keeping them running. (E.g. Oracle databases are very complex and powerful tools which require technical experts to keep them running.)
But I also think that in this model you lose a lot of potential value from the technical skills in the organization since the technical brains are concentrating on thinking vertically not horizontally. A lot can be gained by getting technical brains to address the business problems rather than the 'technical' problems (and politics).

The business doesn't care about the stack. The business needs the functionality to evolve and move forward. Container technology means that the stack become commoditized and I think micro-services are a way of leveraging this to reacting to the business and deploy business functions rather than applications. I sort of think it could look like this:

The main benefit of this is that the technical teams become full stack and as they are much closer to the business function they can make holistic decisions, thus removing the politics. (However notice the fudge on the left side of the diagram where I have the cross service UI which does eventually link the services together - Still want to experiment with this.)

Technical Implications of this

Aside from the organisational structure changes this has a lot of implications on the technical design of systems that are built.

In theory every function can have it's own datastore, and changing data store is easy. I started imagining using cloud databases/dbaas, mySQL, mongoDB, cassandra, but as I think about it more there are more options than that. What about using online file systems like one drive as the backend? You could even use services like confluence as your datastore.

The middleware is also interesting. Python/Node/Java/Clojure app running in docker container? What about using FAAS so we don't have to maintain docker containers?

In fact if you use this model you can even change one complete horizontal business function with an entire service. What about using Confluence as a backend and frontend for a reporting system? There is already a confluence mobile phone app your users can use all you need is to correctly set the permissions.

From a technical point of view I want to answer the questions of what datastore to use, what middle-ware, what security model and what UI on a function by function basis. Confluence as a datastore might be a great low cost solution for one service but might be inappropriate for something else. If I was in a small full stack team empowered to choose the tech I can imagine making much better choices.

Anyway, I have probably regurgitated a lot of spottily model, full stack, microservice stuff but I think I have achieved the goal of organizing my thoughts in a slightly better way, so I am going to publish this and see what people think.

tldr;

In summary I think a micro-service is an independently deployable tech stack focused on a single business function. No new or big ideas here but this post is helping me set context to explain what I am trying to achieve when building a SAAS security microservice which can be used as a component in many webapps.