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.
Blog 
Twitter 
LinkedIn ![image[7][2][2][2]](https://paascommunity.com/wp-content/uploads/2013/04/image7222.png?w=20&h=20 "image[7][2][2][2]")
Facebook ![clip_image002[8][4][2][2][2]](https://paascommunity.com/wp-content/uploads/2013/04/clip_image00284222.jpg?w=26&h=23 "clip_image002[8][4][2][2][2]")
Wiki
Technorati Tags: SOA Community,Oracle SOA,Oracle BPM,OPN,Jürgen Kress
PaaS Community Blog 