I really impressed with a number of sources you're providing to prove your point of view. Unfortunately none of them explain how it is possible to have same application built as monolith and as microservices without any changes in architecture.
As for "cloud architecture patterns": they unavoidable once you switch to distributed system and let services communicate directly via unreliable channels. These patterns are not specific to microservices and often used without them. Moreover, resilience and other cloud-specific properties are achieved by means external to application and application architecture (various deployment/orchestration platforms, cloud services, etc.)
While talking/reading about microservices I often have feeling that a lot of things from different levels/layers are mixed into one big ball of mud and then declared as "advantages of the microservices architecture".
Software consultant. Bestselling Author. Loves rum, alt culture, games & metal.
Formerly Head of engineering, chief technical architect, head principal engineer, lead dev, etc.
Location
London, UK
Work
Independent Software Consultant at Electric Head Software
Well argued Sir :) FWIW I hadn't assumed you were against microservices, but that you may have been victim of over enthusiastic architects (and hoping that isn't me!)
I suspect we are all violently agreeing that certain ways of doing things (whatever we call them) are sometimes appropriate (eg: if you are Amazon, Netflix or Monzo), and sometimes not (eg: if you are Stack Overflow: nickcraver.com/blog/2016/02/17/sta...).
Terminology, as in 'what is architecture' and what isn't, has probably come between us, as I also believe that well designed SOA is indistinguishable from microservices. What makes the difference for me is the human impact of these design decisions, where we might place higher important on team autonomy (eg: AWS 12-pizza teams), and thus focus on packaging and deployment, team responsibility and ownership, as these are often areas where large teams collide. In other organisations or groups this may not be the concern, and thus working with more efficient, coupled designs works just fine.
Thanks for keeping thing civil!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I really impressed with a number of sources you're providing to prove your point of view. Unfortunately none of them explain how it is possible to have same application built as monolith and as microservices without any changes in architecture.
As for "cloud architecture patterns": they unavoidable once you switch to distributed system and let services communicate directly via unreliable channels. These patterns are not specific to microservices and often used without them. Moreover, resilience and other cloud-specific properties are achieved by means external to application and application architecture (various deployment/orchestration platforms, cloud services, etc.)
While talking/reading about microservices I often have feeling that a lot of things from different levels/layers are mixed into one big ball of mud and then declared as "advantages of the microservices architecture".
I feel like you're conflating software architecture and systems architecture here to be honest.
Well, it's not me, but proponents of "microservices architecture".
Sorry, don't want to look rude. Just too tired with microservices histeria which often causes so much harm although creates a lot of jobs for devops.
Well argued Sir :) FWIW I hadn't assumed you were against microservices, but that you may have been victim of over enthusiastic architects (and hoping that isn't me!)
I suspect we are all violently agreeing that certain ways of doing things (whatever we call them) are sometimes appropriate (eg: if you are Amazon, Netflix or Monzo), and sometimes not (eg: if you are Stack Overflow: nickcraver.com/blog/2016/02/17/sta...).
Terminology, as in 'what is architecture' and what isn't, has probably come between us, as I also believe that well designed SOA is indistinguishable from microservices. What makes the difference for me is the human impact of these design decisions, where we might place higher important on team autonomy (eg: AWS 12-pizza teams), and thus focus on packaging and deployment, team responsibility and ownership, as these are often areas where large teams collide. In other organisations or groups this may not be the concern, and thus working with more efficient, coupled designs works just fine.
Thanks for keeping thing civil!