• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Risk of service spagetti, poor performance or low availability?

 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I see many advantages with Micro Service architectures but also some possible pitfalls...

When object oriented design became popular it was not uncommon to see people creating "too small" classes and methods making it very hard to understand (and debug!) the systems (when each piece of code becomes too small you need to keep to many classes and methods in your head at the same time to undestand what is going on).

Back in the days when CPUs where not as powerfull as today ther large number of "virtual" method invocations that followed from this kind of "over engineering" also created problems in performance critical code.

What are the risks of the same things happening with Micro Services - ie. can readability or performance become problems?

Can availability also become problematic when building large systems from huge numbers of small services - i.e. since the total availability of the system is no better than the aggregated availability of all the services together?

If you agree that these problem may occur is the book proposing how to possibly them (by for instance proposing how to find the right granularity and how to use redundancy etc to build micro services that are sufficently highly available etc)??

 
Saloon Keeper
Posts: 15510
363
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In general I would say that breaking a system up in smaller chunks makes it more understandable, not less. However, any design methodology can be taken to the extreme. Making classes or services that do "too little work" can definitely impair the reader's understanding of the system. It's key to identify parts of the system that naturally lend themselves for modularization. Check out this cool article by Martin Fowler: http://martinfowler.com/bliki/MonolithFirst.html

In the article, Martin Fowler explains that it's costly to set up microservices from scratch. This is the primary disadvantage of this architecture style, I think.
 
Trist Post
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:In general I would say that breaking a system up in smaller chunks makes it more understandable, not less. However, any design methodology can be taken to the extreme. Making classes or services that do "too little work" can definitely impair the reader's understanding of the system. It's key to identify parts of the system that naturally lend themselves for modularization. Check out this cool article by Martin Fowler: http://martinfowler.com/bliki/MonolithFirst.html

In the article, Martin Fowler explains that it's costly to set up microservices from scratch. This is the primary disadvantage of this architecture style, I think.



That is a very good article and I agree that "divide and conquer" generally is a good idea when building systems (and also can make maintenance easier).

With some common sense the right granularity (i.e. building micro rather than say nano services) should be possible but what about the potential with availability problems? Already building very granular distributed systems poses many new challenges and requires each part to have higher availability than a single monolitic sysystem would need. Building a system from possibly hundreds (or more) services takews this to the next level...

Deploying in the cloud makes this problem somewhat easier to solve since there are very good support (at least in AWS) for on the infrastructure level configure that several (or even an elastic number) of instances should be created and that failed instances should be autromatically re-started) making it easier to build services with very high availablity. But when runing in your own data centre you have to write scripts or use some frameworks like say Zoo-keeper etc (that you must configure and manage) to do theese things and many IT organisations lack the needed knowledge/exprerience of this today...

A similar consern applices in a way for scalability - if the services are so small that many different ones are deployed together in the same container it become more complex to scale. Lets say that microservice A (that is deployed together with B, C ... etc) starts to get a lot traffic - if scaling on the infrastructure level (as mentioned easy to do in for instance AWS) one would then create more identical containers (server instances) and in effect also create more copies of service B, C etc (that are co-deployed with A) even though this is not strictly necessary. This is in contrast to how it works if services are kept large enough to be deployed on their own server instance where scaling becomes more straight forward.

Once agin cloud providers may (perhaps already do?) offer advanced containers that can dynamically create additional containers that only contain "hot" microservices as needed but in your own data center this will again require "advanced plumbing" that is not trivial to set-up and manage.

This all makes me feel that the a good cloud service is, if not a requisite, at least a big advantage to use microservices optimally!

This thesis is supported by the fact that Microsofts new "micro service" based architecture is heavilly promoted towards Azure...
 
Stephan van Hulst
Saloon Keeper
Posts: 15510
363
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You raise excellent points. I agree that in an architecture geared towards micro-services it's not trivial to set up the infrastructure.

I do think however that micro-services lend themselves very well to scaling, because service A is naturally decoupled from service B and service C, so can run it in separate containers without having to duplicate instances of services B and C. In a big service where A B and C are integrated, you are forced to deploy B and C when you want to deploy just A. A disadvantage is that latency will increase when services communicating from different containers have larger round-trip times. You need to deal with this on a per-case basis. What applies to one product from one company may not for others.
 
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
To expand on Stephan's comment. It has become very common to see container service features that promote spinning servers up and down in quantity for load-handling purposes.

One of the salient aspects of this sort of approach is that often there's some sort of proxy or message-passing service to ensure that the various worker clones get evenly fed. And in turn, those services are often running either as clusters or with hot spares lest they become the weakest link.
 
Rancher
Posts: 989
9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Welcome Sam Newman! Following up on Stephan's comment and reference to Martin Fowler's monolith-first suggestion, does your book or other publications address how to identify the bounded contexts upon which to slice the application when the application is being developed from scratch?


 
I was her plaything! And so was this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic