BT

A Critical Look at Microservices for the Enterprise

by Jan Stenberg on Nov 29, 2014 |

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.

The Microservices Conference is the first on the subject arranged by Skills Matter, in London. Next year's conference is open for registration.

Rate this Article

Relevance
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Excellent by Hermann Schmidt

Right on the spot. There is and has always been too much love for infrastructure without purpose. The real value is in the logically adequate structure of applications with the simplest possible solution. Only then it is economical and close to the customer's requirements.

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 by Jan Stenberg

The presentation is now available at: skillsmatter.com/skillscasts/5235-keynote-an-in...

Ah! First time I hear something interesting by Erik Gollot

2000% agree...
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 !!

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

3 Discuss
General Feedback
Bugs
Advertising
Editorial
Marketing
InfoQ.com and all content copyright © 2006-2016 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT