Minimum Viable Architecture • Randy Shoup • YOW! 2022
ฝัง
- เผยแพร่เมื่อ 7 มิ.ย. 2024
- This presentation was recorded at YOW! 2022. #GOTOcon #YOW
yowcon.com
Randy Shoup - VP Engineering & Chief Architect at eBay @randyshoup46
RESOURCES
/ randyshoup
/ randyshoup
/ randyshoup
www.randyshoup.com
ABSTRACT
There is no such thing as a one-size-fits-all architecture. For example, most large-scale web companies have over time evolved their system architecture from a monolithic application over a monolithic database to a set of loosely-coupled microservices connected by asynchronous events.
This presentation introduces the idea of a "Minimal Viable Architecture". As a company and product evolves, its architecture needs to evolve as well. We talk about the different phases of a product -- from the idea phase, to the starting phase, scaling phase, and optimizing phase. For each phase, we discuss the goals and constraints on the business, and we suggest an appropriate software architecture to match. Throughout the presentation, we use examples from eBay, Google, StitchFix, and others [...]
TIMECODES
00:00 Intro
02:10 eBay architecture
04:54 Amazon architecture
06:33 Takeaways
08:33 "Prototype" architecture
11:08 "Just Enough" architecture
12:51 Monolithic architecture
15:57 Modular monolith
17:00 Continuous delivery
18:00 Feature flags
20:42 When to rearchitect?
23:10 Scalable architecture
26:17 Microservices
29:06 Incremental migration
34:46 Carving up the monolith
36:34 Extracting microservices
40:54 Stable architecture
42:10 Outro
42:21 Q&A
Download slides and read the full abstract here:
yowcon.com/sydney-2022/sessio...
RECOMMENDED BOOKS
Mary & Tom Poppendieck • Lean Software Development • amzn.to/3CxlMUq
Ron Kohavi, Ya Xu, Diane Tang • Trustworthy Online Controlled Experiments • amzn.to/3qIsTaa
Simon Brown • Software Architecture for Developers Vol. 2 • leanpub.com/visualising-softw...
David Farley • Modern Software Engineering • amzn.to/3GI468M
Dave Farley & Jez Humble • Continuous Delivery • amzn.to/3ocIHwd
Woods, Erder & Pureur • Continuous Architecture in Practice • amzn.to/2QWAmkl
George Fairbanks • Just Enough Software Architecture • amzn.to/3uZzVo0
/ gotocon
/ goto-
/ gotoconferences
#SoftwareArchitecture #MinimumViableArchitecture #ModularMonolith #Monolith #Microservices #FeatureFlags #ContinuousDelivery #RandyShoup #SoftwareEngineering #Programming #SoftwareDevelopment #YOWcon
Looking for a unique learning experience?
Attend the next GOTO conference near you! Get your ticket at gotopia.tech
Sign up for updates and specials at gotopia.tech/newsletter
SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.
th-cam.com/users/GotoConf... - วิทยาศาสตร์และเทคโนโลยี
Randy delivered a great talk as usual. Way too many startups these days start with a microservice architecture because it’s “considered a best practice”.
In fact, people who defaults their choice to microservices are considered Great architect in my organization. Sad Indeed!
Cargo cult practices are the norm and why most software projects fail
Can’t outsource your method, you have to think. Avoiding this only ends in doom
It works both ways because way too many mature companies are still struggling along with the big ball of mud that results from ignoring Martin Fowler's "The best code you can write now is code you'll DISCARD in a couple of years time".
Great talk.
One thing I’d like to subscribe to:
Try to (enforce) modularity in the monolith.
Totally agreed. People tend to follow trends like mad men. I'm so glad there are reasonable people out there to balance it out.
Great talk. Agree with every word! The biggest problem in all teams I saw is that they think that they are already at second stage. But usually people just want to try something new only because it sounds cool
Love that talk! If people knew it the world would be a better place.
One point I'd like to add, is that if you did the modular architecture right, so it won't be hard to find a seam later.
That 16k method C++ architecture still leading to a successful business tells me architecture doesn't matter 😂
Really good talk! I’ve definitely experience over engineering the first phase as if I am on the second which became problematic
Very insightful!!
Bravo!
The problem comes when you skip the Martin Fowler quote at 11:47.
When you build this prototype and rather than discard it in a couple of years time, you're still trying to patch all manner of production needs into it 10 years later.
Instead of step-by-step moving from no architecture to a little bit of architecture to a "properly" architected system you're caught between a rock and a hard-place - either a big ball of mud or a big rewrite.
I'm tempted to print that slide on a big piece of paper and stick it to my wall.
With the speed of tech today, software that is build now might be retired before it hits the 10 year mark. I am working on products that are 5 years old and already considered obsolete...
35:44 savage persuasion
Couldn't agree more with what he's saying...
Randy is just wow
Awesome talk
If you cannot write a clean maintainable monolith, why do you think you can write maintainable microservices? That should be a guideline
what was the previous talk ?
which video?
Great talk. 15 years ago using Rails or PHP for "the Just Enough" phase made sense. Today you have languages like Go that scales well, is more maintainable, and is safer all without sacrificing short term agility.
Great talk!
16K methods per class :o
that's some next level lunacy, and it's me saying this watching this at 4 am
After all, what is the Minimum Viable Architecture? I don't get it.
i
I may require more experience, but is it really microservices THAT slower than monolith?
I mean, if you do a "clean" monolith, it means you have been making it modular, so the team can parallel their effort.
If that is the case, how is it different the efficiency of both workflows? As I see it, when working with any of those, you start with some "quality assurance" repo, which provides a time save on the coding, with that in mind, the impact of that previous work is actually higher on microservices, so it could even be faster.
This first part of the talk confuses me a bit, I think it applies only to starting enterprises, with no previous works and in search of their product.
If you work with a monolith, you just skip the whole messy deploy/latency/availability/distributed derived problems. Not to mention that you can simply work faster with things like MVC or similar.
I'm afraid this kind of mentality of deliberately starting with a crappy architecture to fix it later has also killed many companies. Very few ones can afford the cost of recovering from a full rewrite such as the one Twitter made when moved out of Ruby and MySQL.
It's not crappy, it's just enough. Over-engineering is a mistake some companies do and the result is them throwing millions (instead of 100-200k) out the window.
I watched the first 25min, contrary to most commentators i cannot find anything spectacular in this talk. This seems rather a listing of anecdotes than a logical coherent or in any other way scientific approach. At some point we were down to phrases like "write solid code". For example at 19:28 there is no value in stating that 2/3 of features are "flat or negative" unless you clarify how you measured these "figures" and what you mean by "flat" and "negative". At 22:31 he poses a question on himself that he doesnt even answer. And his assumption here, which is also mentioned in his beginning examples, that "rearchitecting is a sign of success", does not encounter a single point validation throughout his speech other than "I think that..." and then he just repeats his statement 23:02.
Lastly, I cannot believe that someone truly thinks that the specific architecture of say ebay and AMZ was the reason for their success. At some point they had to scale yes, but they probably could have chosen a slightly different architecture as well and the main reason that had to scale in the first place was that these companies fullfilled a need - shopping online so you dont have to go to a physical store - that turned out to be a mass market. They could have stayed on perl for the next 100 years if what i just said was not true.