Why microservices and monoliths are not simple by Phil Wilkins


Microservices are inherently more complex because they are distributed and shared less, and therefore, require a better foundation.

It’s a bit controversial to say that microservices are not simple given how much is said about using them to simplify and accelerate software delivery. So can this statement even be made? It is, in Chris Richardson’s excellent new book, “Microservice Patterns” (here) and indirectly in Eric Evan’s “Domain-Driven Design” (here). Martin Fowler also agrees that they come at a premium in one of his blogs (here).  So, I’m not the first to say it, and I won’t be the last.

But the assertion that microservices done right are simpler and allow rapid delivery and evolution of solutions is a bit of a contradiction. Since a picture is worth a thousand words, take a look at this:

To make a change with the monolith and understand the impact of the change, you need to have a greater appreciation of how the entire solution works (area highlighted in gray). If changes are implemented without understanding or adhering to the design strategies and patterns, or if changes are rushed to address some urgent need (business deadline, bug, and so on), the design erodes and the effort to understand the change impact for future changes is accelerated. In effect, the monolith becomes difficult and unwieldy.

Microservices are inherently more complex because they are distributed and shared less, and therefore, require a better foundation. So, not only do you need to understand the programming language, and a simple app container, such as Tomcat; you also need Docker and something like Kubernetes or Istio. It is important that the isolation between the different services be more robust; no longer can you just add another import or another method overload on class. It takes more effort and it is easier to govern the points of exposure. As a result, the risk of design degradation is reduced – but not removed.

Moreover, understanding any one part of a solution requires less understanding of the whole. The net result is that there is less temptation to use shortcuts to deliver urgent solutions for just one area. Regardless of whether the solution is a monolith or microservices, sooner or later the solution will reach a point where dedicated skills in those non-functional areas are needed. But in the monolith world, the platform specialist doesn’t have to struggle with the big picture while tuning resources – i.e., some parts of a monolith may be memory-hungry while others need I/O performance. In the microservices world, the Kubernetes specialist only needs to master one set of dependencies at a time in order to optimize deployment and deliver value. Furthermore, there is the possibility that different microservices will have related demands – so they can share infrastructure most suited to those demands and host the microservices with different demands on infrastructure meeting its needs.

Which brings us back to our original statement: since there are moving parts, there is complexity, but it is easier to master any one part because it is smaller. As the solution grows and becomes more effective, it becomes possible to have specialists for each component and layer. While Martin Fowler’s diagram (below) doesn’t show this, I suspect it holds true. Read the complete article here.


PaaS Partner Community

For regular information on Oracle PaaS become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

clip_image003 Blog clip_image005 Twitter clip_image004 LinkedIn image[7][2][2][2] Facebook clip_image002[8][4][2][2][2] Wiki

Technorati Tags: SOA Community,Oracle SOA,Oracle BPM,OPN,Jürgen Kress

About Jürgen Kress
As a middleware expert Jürgen works at Oracle EMEA Alliances and Channels, responsible for Oracle’s EMEA Fusion Middleware partner business. He is the founder of the Oracle SOA & BPM and the WebLogic Partner Communities and the global Oracle Partner Advisory Councils. With more than 5000 members from all over the world the Middleware Partner Community is the most successful and active community at Oracle. Jürgen manages the community with monthly newsletters, webcasts and conferences. He hosts his annual Fusion Middleware Partner Community Forums and the Fusion Middleware Summer Camps, where more than 200 partners get product updates, roadmap insights and hands-on trainings. Supplemented by many web 2.0 tools like twitter, discussion forums, online communities, blogs and wikis. For the SOA & Cloud Symposium by Thomas Erl, Jürgen is a member of the steering board. He is also a frequent speaker at conferences like the SOA & BPM Integration Days, JAX, UKOUG, OUGN, or OOP.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: