Someone said the dreaded architecture word and you’re Not-An-Architect?
Scared when someone challenges your understanding of computation...
For further actions, you may consider blocking this person and/or reporting abuse
Microservices are not architecture and term "microservices architecture" is misleading. Overall microservices is a great example of how to mix different layers into one ball of mud and then spend enormous efforts in the attempt to organize them.
Microservices are part of an architectural style ( en.wikipedia.org/wiki/List_of_soft... ) derived from Service Oriented Architecture. So no, it's not misleading :)
"Layers" also implies a specific architectural style (n-tier, literally, the cake analogy).
There are plenty of valid critiques of microservice architectures, but "it's not an architecture!" isn't one of them. 🖤
Sorry, but I disagree. It's definitely not an architecture and not an architectural style either. And it's easy to prove - it's enough to make another packaging option and put all services into one application. With more or less decent design, which allows abstracting out communication method, it should not be a problem to replace communication via HTTP/REST with direct calls. And now you have monolith, but there are no changes in the architecture. Another direction: most modern recommend microservices best practice is to start as monolith and later split system as necessary into microservices. If architecture of the system remains the same, monolith or microservices have nothing to do with architecture. They are just packaging options.
Sounds like you've experienced some of the hype and pain of a microservices initiative in an organisation? As David notes in the article:
If you haven't already seen it, I would recommend this comprehensive description from James Lewis & Martin Fowler, it goes into more background and reasoning on what drives the approach and why you would or would not use it: martinfowler.com/articles/microser...
hope this helps..
Sounds like you decided that I'm against microservices. This is not so. They have their place and sometimes they are really necessary.
As of "these qualities". They are not specific to microservices, but just regular properties of traditional SOA. Lets look at them one by one:
I see how often people, who discover distributed systems to themselves via microservices, focus on (new for them) low level implementation details like circuit breakers and transport protocols. They get an impression that those minor things are something new, specific to microservices and making microservices special. They are not. Distributed systems existed long before term "microservices" was coined up.
Let's sum up: properly designed SOA system is indistinguishable from properly designed microservices. And properly designed SOA can be reconfigured to be deployed as monolith or as set of microservices without any changes in architecture. This leads to the conclusion I've already mentioned - microservices have no relation to architecture, it's just a packaging option. Just like monolith.
From the original post:
"Microservice architectures are just the “third wave” of Service Oriented Design."
Though where we differ in opinion is that those "minor things" the actual cloud architecture patterns, are things that provide the resilient capabilities of decent Microservice architectures.
You don't have to take my word for it though - docs.microsoft.com/en-us/azure/arc... Microsoft P&P has a great rundown of why they're so important.
"properly designed SOA system is indistinguishable from properly designed microservices" - I totally disagree with this statement though - 1st Gen "Traditional" SOA was all about n-tier architecture - Microservices archtectures tend towards consteallations of co-operating bounded contexts. It's a different topology, and the interactions between the services are different.
Ian Cooper does a great overview of the history and contrast between the two here - youtube.com/watch?v=Z9NtB7JMquY
I think if the whole world describes microservices, and SOA, as an architectural style, pedantically sitting at the "it's not an architecture!" end of the spectrum isn't going to convince anyone.
Thanks for engaging 🖤
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!
First post I see on Dev that actually talks about REST while assigning it to Roy Fielding instead of some random post in the internet.
I suggest linking to original sources like the Roy Fielding dissertation for Architectural Styles/REST and the Soundcloud post from Phil Calçado for the ideas of BFF
Wow, thanks so much for writing this! You explain things in such a clear and entertaining way. Just out of plain curiosity, what would the process of scaling things yourself look like? Adding more servers, connecting them together in some sort of way, etc. etc.?
Scaling means lots of different things to different people, and it's one of the most commonly misunderstood things in software.
When a programmer says "scaling" - they might mean "making the code more available or perform faster". When a product owner means scaling, they might mean "scaling the business model", when sales say scaling they might mean "can we onboard thousands of users right now" and when a technical manager says scaling, they might mean "how many people can I meaningfully have working on this codebase".
Most software doesn't need to scale technically. Most software doesn't really have high volume traffic problems. For the majority of people, vendor provided autoscaling (think Azure App Services autoscale, or AWS Elastic beanstalk, or Heroku) are more than enough, set a memory and CPU scale out threshold and let the platform do it for you. The same goes for K8S, albeit with more operational complexity.
The more difficult form of scaling from a software perspective is scaling concurrent contributors - and this is all related to the size of your codebase, how well compartmentalised it is, and how well it avoids change hot-spots (files that get changed in every commit are scary files).
Then the even more difficult form of scaling (yes! more difficult than the technical one!) is scaling your operational processes around user onboarding.
So while "scaling is mostly commoditised" in todays managed cloud platforms, all the knock on effects of maintenance, support and human factors are an equal sized hurdle to just adding more computers to a piece of software.
🖤
30+ minutes of a good read.
Thanks for sharing!
Also, what do you think about Sam Quinn's Bulletproof Architecture softwareontheroad.com/ideal-nodejs...
I'd never read the bulletproof architecture piece before. It reads like some relatively sane advice, but I think perhaps it doesn't account for context or the size of a problem.
Some of the stuff in it is essential in mid-large size applications, but would count as bloat on a smaller surface area of code. It's always super important to pick a style that fits the size of your code, and to be prepared to change it as your application evolves.
As a good rule of thumb, for every two orders of magnitude increase in scale (in any dimension of scale - users, performance, team size, business domain), I would expect a program to change it's topology or architecture.
Useful article - thanks. Makes a lot of sense!
Was this sentence "Use vendor provided, cloud abstractions like Google App Engine, Azure Web Apps or AWS Lambda with autoscaling support enabled if you can possibly avoid it." supposed to say "without" autoscaling?
No :) The implication was meant to be that these environments offer you trivial autoscaling with next to zero configuration vs the competition (k8s, specifically).
"That’s a non-exhaustive list of some of the pattern jargon you’ll hear. There’s nothing special about design patterns, they’re just the 1990s version of an accepted and popular stackoverflow answer."
Great one ! Thanks!
This is incredible, THANK YOU, I might have to read it 20 times to get a good grip of all the concepts and do some extra reading but this is such an amazingly clear resource.
Yes, this discussion has pre-built next weekend's reading list :)
Great article! For more on distributed systems, Udi Dahan's very popular course is currently free, I'm really enjoying it myself: particular.net/adsd this week.
Great article!
Beautiful article! I always go back to this blog post by Roy Fielding when I'm confused what REST means.
roy.gbiv.com/untangled/2008/rest-a...
But to be honest I often only get more confused :)
Errrm.... there's a lot of truth in here, and a lot of things to agree or disagree with. The architecture of the aticle is a bit missing - you could've made it clearer perhaps by defining what architecture is. I know that's just a matter of adopting the definition, but a lot of people that run into the issues you describe forget to have a look at what architecture means before having an opinion about it. ;-)
Nice to see a meaty post on architecture getting some props!
This article will be sent to the next "real software engineer" that uses a "real programming language" and who tells me that web development is script kiddie stuff.
All programming is real programming 🖤
I learned a lot and got a lot more questions! Thank you for sharing this and pointing the way to learn more. ;)
This is amazing article thank you