Minimum Viable Architecture • Randy Shoup • YOW! 2022

[@dway89]

Finally found a serious talk about how to architect an MVP and scale eventually...great tips.

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”.

[@ayanSaha13291]

In fact, people who defaults their choice to microservices are considered Great architect in my organization. Sad Indeed!

[@ChrisAthanas]

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

[@edgeeffect]

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".

[@deanschulze3129]

@@ChrisAthanas - I like the phrase "cargo cult" software. It reminds me of that bad old days with EJB 2. EJB 2 was cargo cult software. You had to implement interfaces that you weren't going to use.

[@josefpharma4714]

Great talk. One thing I’d like to subscribe to: Try to (enforce) modularity in the monolith.

[@josemonge4604]

Totally agreed. People tend to follow trends like mad men. I'm so glad there are reasonable people out there to balance it out.

[@IgorVe]

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

[@fabiomirgo]

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.

[@asandor83]

That 16k method C++ architecture still leading to a successful business tells me architecture doesn't matter 😂

[@nerdative]

Couldn't agree more with what he's saying...

[@edgeeffect]

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.

[@ForgottenKnight1]

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...

[@kousheralam8657]

Very insightful!!

[@vrjb100]

If you cannot write a clean maintainable monolith, why do you think you can write maintainable microservices? That should be a guideline

[@xdman2956]

35:44 savage persuasion

[@richardfrimpong5891]

Randy is just wow

[@tsh4k]

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.

[@branmuller]

Really good talk! I’ve definitely experience over engineering the first phase as if I am on the second which became problematic

[@ValeriyaSerdyukova]

Awesome talk

[@tylerhudson6195]

Bravo!

[@lordkopi603]

what was the previous talk ? which video?

[@ianhayes9101]

Great talk!

[@vichoohciv9443]

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.

[@asdasadsfa2]

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.

[@steav677]

After all, what is the Minimum Viable Architecture? I don't get it.

[@xdman2956]

16K methods per class :o that's some next level lunacy, and it's me saying this watching this at 4 am

[@dbaltor]

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.

[@ForgottenKnight1]

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.

[@FlamencoDeniz]

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.

[@aslkdjfzxcv9779]

i