'Monoliths Are Not Dinosaurs' (allthingsdistributed.com) 53
Amazon CTO Werner Vogels, writes in a blog post: Software architectures are not like the architectures of bridges and houses. After a bridge is constructed, it is hard, if not impossible, to change the way it was built. Software is quite different, once we are running our software, we may get insights about our workloads that we did not have when it was designed. And, if we had realized this at the start, and we chose an evolvable architecture, we could change components without impacting the customer experience. My rule of thumb has been that with every order of magnitude of growth you should revisit your architecture, and determine whether it can still support the next order level of growth.
A great example can be found in two insightful blog posts written by Prime Video's engineering teams. The first describes how Thursday Night Football live streaming is built around a distributed workflow architecture. The second is a recent post that dives into the architecture of their stream monitoring tool, and how their experience and analysis drove them to implement it as a monolithic architecture. There is no one-size-fits-all. We always urge our engineers to find the best solution, and no particular architectural style is mandated. If you hire the best engineers, you should trust them to make the best decisions.
I always urge builders to consider the evolution of their systems over time and make sure the foundation is such that you can change and expand them with the minimum number of dependencies. Event-driven architectures (EDA) and microservices are a good match for that. However, if there are a set of services that always contribute to the response, have the exact same scaling and performance requirements, same security vectors, and most importantly, are managed by a single team, it is a worthwhile effort to see if combining them simplifies your architecture.
Evolvable architectures are something that we've taken to heart at Amazon from the very start. Re-evaluating and re-architecting our systems to meet the ever-increasing demands of our customers. You can go all the way back to 1998, when a group of senior engineers penned the Distributed Computing Manifesto, which put the wheels in motion to move Amazon from a monolith to a service-oriented architecture. In the decades since, things have continued to evolve, as we moved to microservices, then microservices on shared infrastructure, and as I spoke about at re:Invent, EDA.
A great example can be found in two insightful blog posts written by Prime Video's engineering teams. The first describes how Thursday Night Football live streaming is built around a distributed workflow architecture. The second is a recent post that dives into the architecture of their stream monitoring tool, and how their experience and analysis drove them to implement it as a monolithic architecture. There is no one-size-fits-all. We always urge our engineers to find the best solution, and no particular architectural style is mandated. If you hire the best engineers, you should trust them to make the best decisions.
I always urge builders to consider the evolution of their systems over time and make sure the foundation is such that you can change and expand them with the minimum number of dependencies. Event-driven architectures (EDA) and microservices are a good match for that. However, if there are a set of services that always contribute to the response, have the exact same scaling and performance requirements, same security vectors, and most importantly, are managed by a single team, it is a worthwhile effort to see if combining them simplifies your architecture.
Evolvable architectures are something that we've taken to heart at Amazon from the very start. Re-evaluating and re-architecting our systems to meet the ever-increasing demands of our customers. You can go all the way back to 1998, when a group of senior engineers penned the Distributed Computing Manifesto, which put the wheels in motion to move Amazon from a monolith to a service-oriented architecture. In the decades since, things have continued to evolve, as we moved to microservices, then microservices on shared infrastructure, and as I spoke about at re:Invent, EDA.
Sudden outbreak of common sense (Score:2)
Slashdot-ism says it all.
Definition fight in 3...2...1... (Score:4, Interesting)
> TFA: "My rule of thumb has been that with every order of magnitude of growth you should revisit your architecture, and determine whether it can still support the next order level of growth."
It should be pointed out that the vast majority of businesses will not grow by more than a factor of 2 or 3 within a decade. Designing for mass scale-up is thus usually a YAGNI violation. Don't let glory daydreaming gum up your design
A start-up may be different, but perhaps it's best to get the current version finished so you can survive for the next stage. It's like building car garages for your 10 beemers before you even can buy one. Maybe keep an eye on scaling issues and "leave room" for expansion if it's a minor addition, but don't over-engineer.
As far as the definition of "monolith" and "microservices", here is a contentious prior Slashdot discussion. [slashdot.org] I don't see a consensus.
In my opinion the concept of microservices should be split up into smaller definitions or concepts, because they are too loosely related to be force-bundled. For example, you can make a module be "independently managed & deployable" without using JSON or web services.
Re: (Score:2)
unless you know what you are building is going to need to be huge. I would say start with a monolith for new things.
Its going to be a lot simple get it working and its going be a better performer while you implement features in a naive / understandable fashion than some micro-services approach is going to give you. Additionally unless you have large team you are not going to be working on multiple change areas at once, you don't really need gain anything from such a hardline approach to decoupling.
You can
Re: (Score:2)
If you build you monolith with clean internal interfaces and only the internal dependencies that are actually needed, it may be pretty simple to turn parts of it into a service later. If you actually turn out to need that. Service Oriented Architectures certainly do not fit every situation. As so often, they are just one tool in the toolbox and any competent software architect has a range of things in there.
Re: (Score:2)
Right.
A method call can be extended to an rpc call but only if that method is using clean interfaces.
It's momentarily faster to go mucking around in memory you should not but it's hard to even get past debugging the first version and save time, much less the first refactor.
Often the first refactor shows up before the first release anyway.
Re: (Score:2)
Clean interfaces are the one thing you should really, really never go without, regardless of monolith or not. Too many coders do not understand that though. The only exception I accept is if you really, really need that extra bit of performance and no other solution is possible. That almost never happens though.
Re: (Score:2)
unless you know what you are building is going to need to be huge. I would say start with a monolith for new things.
This is the typical (good) advice given, even in books about microservices. I'd even go further and say that unless you already have the need for massive horizontal scaling, starting with a monolith is the right option.
But that doesn't mean you have to be dumb about it - there are ways to build a monolith that doesn't immediately turn into a big ball of mud. I really like the modular monolith [shopify.engineering] (which is really just fancy-speak for "well-designed monolith"). It avoids all the overhead and problems with usi
Re: (Score:1)
Re: (Score:3, Insightful)
I don't know about your domain, but for "typical" biz CRUD, the database is usually the performance bottleneck, and if it's not, then most likely you are doing something wrong.
> It is best to write efficient code from the start without relying on bloated frameworks.
But that's where the jobs & money are, unfortunately. This industry loves their bloated frameworks.
Re: (Score:2)
Re: (Score:1)
If the biz logic is a lot of nitty gritty conditionals or parsing, I agree it's usually better done in app code. Often times a relatively simple query can do say 80% of the work and the app code the rest.
Re: Definition fight in 3...2...1... (Score:2)
ah the script kiddies who never used a large database before.
Re: (Score:3)
It is best to write efficient code from the start without relying on bloated frameworks.
Obviously.
So you do that 3 times. The third time you realize: WTF, I did that before, and you copy/paste some code from project 1, and adapt it to project 3.
So the 4th time, you realize: WTF, I did that before and copy/paste a bit code from Project 2 and Project 3.
And the 5th time, you realize: WTF, I did that before, and I copy pasted already from Project 1, 2 and 3!
So in Project 6 you try to put the stuff you copy/past
Re: (Score:2)
For those who do not know what a Framework is: It s a program, and a library, that has all the relevant infrastructure *already programmed out* but has no business logic. Everywhere where something interesting - aka business - is supposed to happen: the framework has a _hole_ You fill that hole with your code. And if you do not use the Framework - up. to you - then you have to program all the stuff the framework provides to you: yourself.
If you have more than 2 years CS education behind your back: I expect you to take 5 days and read up about the paradigm of your framework: AND USE IT.
The general problem with frameworks is they tend to poorly reinvent the wheel in order to cast everything into their particular "paradigm". Rather than achieving progress one can easily end up with just another redundant system within a system that does very little except increase complexity while reducing performance and choice/freedom vs simply leveraging the underlying system.
The notion decision to or not to use a framework means having to code any more or less is without merit. One could simply use the
Re: (Score:2)
The general problem with frameworks is they tend to poorly reinvent the wheel in order to cast everything into their particular "paradigm".
You mixed it up. The general rule of not using a framework is having to reinvent the wheel. Usually mediocre. Usually full with bugs. the framework already has covered that for you.
while reducing performance
How could a piece of code, from a framework - that you would have written the exact same way if you had written it yourself - reduce performance?
Code is code. Does n
Re: (Score:2)
You failed to add a few details, that are rather important:
- Project 1 and Project 9 are completely different beasts. They share nothing. Yet your framework has to allow you to implement both, thus bloat.
- You change languages and/or infrastructure (platform, database) every 2 or 3 projects. Sometimes from project to project, sometimes during the life of the project. But you cannot take your framework with you.
- Some projects implement the sa
Re: (Score:2)
you failed to add a few details, that are rather important:
Don't pretend to be an idiot.
- Project 1 and Project 9 are completely different beasts. They share nothing. ...
Yes they do, facepalm. Otherwise I would not have picked them
- You change languages (1) and/or infrastructure (platform, database(2)) every 2 or 3 projects. Sometimes from project to project, sometimes during the life of the project. But you cannot take your framework with you.
1) Language? Unlikely. Platform? Perhaps. 2) Database? Seriousl
Re: (Score:2)
Perhaps you should die the slow death and indeed write your own framework, and then switch to a mature one. Or stay a copy paste programmer for ever: your choice.
In 30 years, I have done the 3. I have used a fair share of "mature" frameworks (the kind that stop being updated because there was a new one that was all the rage), I have helped to write a couple of custom ones (which took indecent time to write, and failed to realise any payback) and "copied and pasted" the code that made sense. Guess which of the three options I'm still using today. Hint: I don't use frameworks unless clients insist *a lot*.
Re: (Score:2)
There are plenty of Frameworks that make sense.
E.g. Qt.
Or if you insist to call Spring a framework, it is pretty mature now. Same for Hibernate.
Re: (Score:2)
tell them: "because it is not done - it will be done when it is done - partial functionality will not be accepted".
There is no "agile method" on the planet that accepts an item as "done" when it is "not done" defined by your "definition of done" (DoD).
What DoD means is up to your organization, but typically it is:
- peer reviewed before "committed to a source control repository"
- has an automatic test before "committed to a source control repository"
- committed to a source control repository (After: see abov
Re: (Score:2)
Unironically uses the the phrase "100% bug free code"
Calls other people blind.
Now I think I get what GP meant by the "agile horny" epithet.
Re: (Score:2)
Oh, obviously it meant: "perceived 100% bug free" and not "proven 100% bug free".
As I only had 1 bug slipped into production in my 40 years career ... go figure.
The parent thinks agile means "what ever he thinks" ... and agile has nothing to do with bad coding habits or delivering sloppy code.
If you think the same: go to hell, too :P
Re: (Score:1)
Re: (Score:1)
The point is not having a bug free program.
The point is: delivering bug free code into production.
We had plenty of bugs, but we shipped only *one*.
Too difficult to grasp the difference?
Re: (Score:2)
And I'm sure everybody on the bus clapped.
Re: (Score:1)
Doing stuff in memory (Score:5, Insightful)
Is what this seems to be mainly saying.
Yup.
Also saying consider doing this when the different components should scale at the same rate. It also says.
Re: (Score:2)
Re: (Score:1)
Yes. For our business analytics, deciding arbitrarily to scale horizontally to handle workloads we'll never see would kill performance when it works incredibly fast as a monolith. I even use shared memory instead of local sockets for communication in some cases because it's faster than copying buffers into and out of a socket.
"Oh but you'll regret all of that when you need to scale out!" Nah, I sleep like a baby confident in my current design decisions. I'll scale out where it makes sense, and won't where i
Re: (Score:2)
I was actually surprised that these blogs got published, because it seems to go contrary to the AWS push to microservice all the things.
Ultimately, what it boils down to is that Prime chunked their chock wrong: they didn't understand the most efficient way to break down the service functionality. It just happens that a monolithic design (if you can call EC2 that) is a better approach.
Prime's Football is a Terrible Example (Score:3, Informative)
I don't know about anyone else, but I could not watch Prime's Thursday night coverage live last season, it streamed like a bad VHS tape from the 1980s quality wise. Lots of people reported this on social media (checked while I was watching bad VHS football).
This was a consistent issue for at least half the season, at which I switched "Thursday Night Football on Friday" and that had good quality.
I wouldn't be bragging about it, it was terrible from an end-users perspective (no matter how advanced the back end was).
Re: (Score:1)
Prime && Disney streaming performance vs Netflix is atrocious. Everyone involved should be flogged until morale improves
They have brought shame to their families...
If you hire the best engineers... (Score:2)
Re: (Score:1)
Re: (Score:2)
One possible way to interpret it is "if you ask junior dev's what architecture they want, they'll stuff it with buzzwords so they can do Resume Oriented Programming in order to find a better paying job elsewhere."
Problems with this advice (Score:2)
1) It seems bloody obvious.
2) It's not applicable to the business plan of the standard tech startup. Those aren't really designed to scale or even be viable products... they only attempt to appear viable - as long as you don't look too closely - and exist for the sole purpose of getting bought out so the founders can make a pile of money.
Re: (Score:2)
Agree to all of this, and also it doesn't apply to most software or development regardless. It is arrogant and ignorant.
Re: (Score:2)
Re: (Score:1)
MicroEdgeGPT, uses AI to partition your apps for you.
> Must be written in RPG2 or Cobal
You mean "cabal"? Microsoft! ;-)
Re: (Score:1)
> They are meant for VB type programmers who don't have any idea what the computer is doing or how it is doing it
That's how it *should* be. If you are not doing anything "enterprise" or web-scale, then ideally the computer will manage resources efficiently so humans don't have to. Web-shit requires micromanaging too much minutia. Great for IT job security, but a money-drain for biz. We need an alternative standards to DOM for office GUI/Crud.
Ask this CTO what is a Monolith? (Score:1)
From his blog post "If you hire the best engineers, you should trust them to make the best decisions." yes, exactly. And when you hire the best engineers and trust them maybe don't try and act like you know what the hell is technically going on.
Am I the only one (Score:5, Funny)
who thought this would be about large, black, rectangular objects of relative dimensions 1 x 4 x 9 ?
Consistency? (Score:1)
> If you hire the best engineers, you should trust them to make the best decisions.
Insight from the CTO of the elite (Score:2)
The vast majority of all software is embedded, none of this applies.
It is insulting to programmers from someone like this to pretend to be an expert while generalizing so myopically.
It's about costs (Score:2)
A corporation's job is to minimise costs over time. This includes hardware, software and buzzware.
Often fashionable business ideas are purely that, just fashion.
The linux kernel is monolithic in many ways and it works. When it was created microkernel architectures were all the rage however they are fundamentally less efficient for many operations.
Similarly distributed architectures suffer the costs of message passing so it's always a good idea to look at your system and figure out from what perspective is i
Lambda, serverless / stateless computing (Score:2)
Actually this is a major pie in the face to AWS's Lambda serverless processing. It's ironic when an Amazon service is rejoicing at saving 90% of their own AWS hosting costs by avoiding Lambda.
This article puts it in the proper perspective. Amazon Prime Video team throws AWS Serverless under a bus [thestack.technology]