A Critical Look at Microservices for the Enterprise
After many years of Service-Oriented Architecture (SOA) applied across systems, the same philosophy is now being applied within the systems themselves using Microservices, Udi Dahan stated taking a critical look at microservices in a presentation at the Microservices Conference in London.
Udi, an authority on service-oriented architecture and creator of NServiceBus, starts by describing two common problems that microservices, and any other technology, will not solve:
- Wrong requirements. In Udi’s experience a common theme is that developers are not good at understanding when the requirements they get are wrong. The vast majority of the time requirements presented are really solutions to some business objective stakeholders wants to achieve.
- Bad habits and sloppy code. Without discipline and maturity around software development no technology is going to solve this. There is no “discipline in a box”. The way developers interact with the business has a huge impact on the ability to implement the system the right way for the right requirements.
In general we view tight coupling as bad and loose coupling as good, but although the principles are well-known Udi often finds that they are applied in a too simplistic way. With a logical relationship between two components inside one process, dividing this up with the components in separate processes, e.g. microservices, is not changing anything; the coupling is still the same, what may happen though is that we hurt the performance. Udi emphasizes that whatever architecture we are evaluating we must clearly differentiate between the logical and the physical architecture; evaluate the two independently and if we find the coupling to be the same then we have to realize we have accomplished nothing. A risk at this point that Udi warns for is that smart developers can get too creative and instead of removing the coupling trying to hide it. This is where a lot of enterprises have ended up with their enterprise architecture, instead of calling a system directly the call is hidden in layer upon layer.
Another important term Udi brings up is cohesion. Sometimes a concept you deal with is meant to be a highly cohesive piece of code, and when it’s meant to be together don’t try splitting it up. Also when looking at one thing we might sometimes identify elements of loose coupling where things that deal with one set of data don’t care about other sets of data, e.g. in a retail domain code that deals with product names, description and images is not that coupled to the pricing of a product and the discounting rules for it. By starting with looking for things that really want to be coupled to each other and around these trying to find the boundaries to things that are loosely coupled, then you have the potential of along these boundaries separate your domain into highly cohesive, loosely coupled microservices.
Udi claims that the problem with a lot of the microservices discussion is that we have blinders on; we only look at one system at a time. If we take a wider perspective on the problem we are solving, across the enterprise, we will find that a lot of the same kind of data is used in many systems. Taking a step back looking at the whole enterprise we will find microservices responsible for a given concept in different systems that we can put together forming one microservice responsible for that concept. We will then end up organising services around business capabilities, ignoring system boundaries, instead spanning the whole organisation. This raises a question if we really should call them microservices now that they are not really that small. Udi thinks we should stop worrying about size and lines of code, instead focusing on the appropriate unit for delivery of business capabilities since this is what the business care about.
I observe too much self-indulgence among developers. Software development is about giving our clients useful, adequate and working tools quickly so that they can make money with them as soon as possible. It is not about finding the most sophisticated abstractions on the planet, which nobody asked for. It is not about throwing more complexity on top of complexity. It is not about us developers.
Ok, that was a little off-topic, but I am really tired of IT fashions which dance around the wrong problems.
Presentation is available
Ah! First time I hear something interesting
Technical solution never solve functional problems. Yes functional cohesion is key for good services and performance. Splitting a problem just to split will lead to many problems and will just give you the illusion of independence.
Thanks Udi !!