“Good Enough” Architecture Part 1 • Stefan Tilkov • GOTO 2020

[@madmanX1314]

This could be one of the most important video (series) about Software Engineering in 2021.

[@TheLavaBlock]

Great Talk! Thank you, I am looking forward to the next part

[@legendofthefox86]

Great Talk. The points about over customization and unmanageable configs I'm living through currently. Look forward to pt 2!

[@efimkarelin3401]

The talk is very interesting and useful. Especially, an idea about making the full stack teams is perfect. I've just realized that this way to combine people efforts usually leads to success.

[@victorlim1561]

Looking forward to Part 2-N!

[@amirphl7834]

There's always a trade-off in size and number of services in architecture and sometimes we have to start with the simplest way then evolve our architecture to reach the best configuration.

[@ArchAnime]

Great talk!

[@christopherbird5520]

Stefan, this is great stuff, thank you.

[@itsmy17]

Please please part 2.. Question: I'm with you on the one team setup, just a question so I can hone my argument better, if we go with full stack teams, meaning having both UI devs and backend devs jn the same team, wouldn't the backend devs become blockers within that team trying to provide with APIs? I don't like the whole backend-for-frontend but lots of time the APIs become so prominent in the architecture. Thanks for the great presentation.

[@LukePuplett]

An irrelevant musing on Conway's Law: Perhaps Microsoft's products inevitably become (overly) complicated as a reflection of the organisation of Microsoft's industrial era customers. Moreover, Microsoft's own organisation is influenced by the products and features its customer demand. It's a sort of Conway's Law by Proxy. btw: One of my favourite speakers. He's also got a lovely speaking voice.

[@denesjavorek8709]

Good talk. Waiting for part 2

[@sergiob3698]

Great Talk! Thank you.

[@ArchimedesTrajano]

Content wise I like. One comment I think you need to have a room that has good sound absorption, it sounds like you are in an enclosed room so there's a light reverb in your voice. Although I am on the side of splitting frontend and backend architectures. Primarily because the front end uses a whole different technology stack. However, what should occur is the migration of thinking of services to do the work and front end acting as a dumb client (though that is usually the starting point and I would still recommend that as a starting point, but also understand that the technical debt on it is high). Once you get the starting architecture where the communications are established is when you start moving the data out of the service and into the client. But even before that, you should move your data from your core application to microservices that have specific copies of the data. This intermediate stage will then allow you to do the next bit more easily. The next bit would generally be providing a streaming communication system between the backend and the front end. GRPC allows for that. Having that allows you to push the data to the client device and let it do the work needed there. Also the other reason why you'd want to separate front and back is the front end development changes per technology or per user role. But as you noted in 27:00 we set up teams differently from architecture. Teams are *full portfolio* not just front / back, but different logical groupings and the logical groupings morph, though the front and back separation of technology and developers would make sense otherwise each developer would have two laptops one with Docker and one which can run the device emulators.

[@learningtech9934]

Great talk Would love to learn about all the other anti-patterns shown at 2:46.