If you work in IT and don’t live under a stone, it is likely that you will have come across the term Microservices. It is the new saviour of Enterprise IT. It doesn’t matter what question you ask; the answer currently seems to be Microservices. Out in the Enterprise, SOA and N-Tier architectures are being rebadged as Microservices and the conversations around applying heavyweight governance to Microservices architectures are starting. In the Hype Cycle we are probably near the top of the curve at the Peak of Inflated Expectation and it won’t be long before we are rapidly descending to the Trough of Disillusionment.
I’m not going to use this post to define Microservices nor am I going to try to outline what challenges you might encounter when delivering a Microservices architecture. Instead I’m going to build on some previous posts.
These posts cover how it is important to understand the context when making big strategic bets and also how many technically savvy organisations don’t really understand what it means to build a distributed application. They also talk about that reconfiguring your architecture doesn’t remove complexity it simply moves it.
If there is one thing you need to think about when doing Microservices it is the inherent distributed nature of the system that will be produced. Therefore, you need to accept the fallacies and be comfortable thinking about the styles in which your services will integrate.
There is a reference manual for people working in the field of integration. Enterprise Integration Patterns has been around for some years but the patterns it describes don’t just exist at enterprise level, they are still appropriate at application level when those applications leverage a Microservices architectures.
The first section of the book talks about Integration styles. It discusses the journey from File Transfer, to Shared Database, into Remote Procedure Invocation and then to Messaging. Microservices architectures sit somewhere in between remote procedure invocation and messaging. You might use REST APIs or you might use some type of message queue. There is also the question of whether to use synchronous or asynchronous communication. Messaging would sit on the asynchronous side whilst REST tends to be more synchronous.
This transition of styles represents a journey. It is important to understand the benefits that remote procedure invocation gives over a shared database model. It is important to have felt the pain of not being able to make a simple change to a database schema due to the fear of breaking something important. You need to have felt the sinking feeling when you encounter table names such as customer1, customer2 & . And you need to have experienced the frustration in senior stakeholders when they realise that that simple change is going to have to take a big chunk out of their IT budget.
It is the same when considering messaging over remote procedure invocation. When you have experienced the temporal coupling that causes your whole SOA to fail because a single shared service is unavailable you start looking for alternatives. When you see with your own eyes the cascading failures caused when services are available but are taking a long time to respond.
There are two forces at play. Many young developers are unlikely to have experienced of the pain us oldies had in the past. There is a risk that they make the same mistakes again. Secondly many oldies are now in senior positions riding on the success of past projects and have conveniently forgotten about the pain. In hierarchical organisations they are the decision makers and are creating the same systems over and over with different names, N-Tier, SOA and Microservices.
When embarking on a Microservices project look around you. What styles do other projects use, which projects are successful and which are not? What do senior and influential stakeholders understand about modern integration styles and architectures.
If you conclude the rest of the organisational landscape uses a shared database model, you need to ask yourself whether pure message based event driven Microservices architecture is the way to go. Shared database integration is about building a canonical central data model and forcing (ermm, governing) everyone to use it. An event driven approach is very different. It is asynchronous, disconnected and autonomous by design and can take a bit of getting used to. It is possible to deliver a successful project this way, but buy in and experience across the whole team is required. The project team just wanting to go this way is not enough, they must be wide and deep seated experience within the team.
Ask yourself – who is driving this change? If it is the client maybe there are simpler ways to solve their problems. If it is the project team, are they biting off too much which may cause problems in the future? The reality is that the client may be moving too far from their current maturity level. This increases the risk of failure. It is though you are swinging a pendulum too far and at any moment it could swing back. Swinging back may mean the project has to change its integration style at a late stage or is left with a hybrid model, some parts of the system using messaging and others going back to old styles such as shared database.
In summary, most organisations are most comfortable with shared database and remote procedure invocation because they are based on mental models that most people can get their heads around. Whilst some organisations will get asynchronous messaging, care must be taken when introducing the for the first time. Using REST in a Microservices architecture seems a good compromise. It provides a mental model that most people understand however it is possible to layer on more advanced integration styles if the application or business domain requires it.
Assess the context in which the project is being delivered and keep it simple.