Architectural Models & Microservices | Simon Brown and Hannes Lowette In The Engineering Room Ep. 5
Вставка
- Опубліковано 28 тра 2024
- In this episode of "The Engineering Room", Dave Farley talks to Hannes Lowette and Simon Brown. Simon is the creator of the C4 Model and author of "Software Architecture for Developers".
Simon, Hannes and Dave have a wide-ranging discussion about Software Architecture: how to do 'just enough' up-front design; why most teams should NOT do Microservices; learning to be a Software Architect; and, the impact of Modern Software Engineering.
Thanks to GOTO, who recorded this conversation at their Conference in Copenhagen - check out their links below.
The Engineering Room is a series of wide-ranging conversations with thought-leaders from across the software engineering industry, published on the last Sunday of every month.
Catch up with earlier episodes of The Engineering Room, with Martin Fowler, Trisha Gee, Gojko Adzic and Martin Thompson ➡️ • The Engineering Room
Download Dave's FREE guide "How To Get Started with Microservices" when you join our mail list ➡️ www.subscribepage.com/microse...
📧 Keep up to date with the latest discussions, free "How To..." guides, events, online courses and exclusive offers.
_____________________________________________________________
📚 BOOKS:
📖 "Software Architecture for Developers" by Simon Brown ➡️ leanpub.com/b/software-archit...
📖 Dave’s NEW BOOK "Modern Software Engineering" is now available here ➡️ amzn.to/3DwdwT3
📖 "Continuous Delivery Pipelines" by Dave Farley
paperback ➡️ amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd-pipelines
📖 The original, award-winning "Continuous Delivery" book by Dave Farley and Jez Humble ➡️ amzn.to/2WxRYmx
NOTE: If you click on one of the Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.
-------------------------------------------------------------------------------------
🎓 CD TRAINING COURSES
If you want to learn Continuous Delivery and DevOps skills, check out Dave Farley's courses
➡️ bit.ly/DFTraining
_____________________________________________________
GOTO ➡️ / gotoconferences
Looking for a unique learning experience?
Attend the next GOTO conference near you! Get your ticket at gotopia.tech
/ gotocon
/ goto-
/ gotoconferences
_____________________________________________________
VIDEO CHAPTERS
00:00 Intros
01:13 What has enabled you to do better things in SW architecture in last 10 years?
03:27 Just enough up-front design
04:16 What does a good architecture do?
06:37 What should you focus on first?
09:16 “With great power comes great responsibility”
09:39 How to get microservices wrong from the start
10:44 Microservices & Modular Monoliths
13:17 The most scalable way of building big systems
14:14 The need for competent architects
14:45 Use “Bounded Context” to steer design
16:24 C4 Model and map to system architecture
17:20 The separation of essential and accidental complexity
18:58 Actor based systems
20:40 Stateful serverless systems - future of the cloud?
21:17 Leaky abstractions - Consider the trade-offs
23:06 Design trumps Tools
24:21 Learning to be an architect
26:40 The impact of real Software Engineering
28:02 Magpie development
29:23 Misapplication of sound principles
32:12 Software Engineering is not the same as other engineering disciplines
38:00 Learning from our mistakes - Наука та технологія
Great talk. Thank you. In industry where you can call someone senior after 3 years of learning the basics I don't really be suprised that we get it wrong so often.
Excellent, more in the minute 17 when he talks about one particular technology and implementation and you properly explain him that you are going one step further of abstraction
Marvelous!
I had the incredible luck to learn programming in a shop that practiced something very close to what you describe as Continuous Delivery down to having a group devoted to what is now called DevOps. A decade before I started in the 70s, they worked with IBM to create CICS and maintained an in-house version called Pronto. I learned to write code for distributed systems by fixing production bugs and rewriting parts that suffered from the entropy of earlier misguided fixes. The data was distributed over time, not space. We were the electric utility for Chicago and surrounding suburbs. The customer dataset was so large that it took a week of nightly runs to process the entire thing and everything happened in cycles of various lengths. Anyway, I just wanted to point out that CD is a great but not necessarily new idea.
Dave, you are really in your element here. Very articulate, noticeably more than even in your own videos. Perhaps you could do more of a question and answer format (you can edit as much as you want to keep if flowing for your final cut), and get someone else to handle the recording so you are not constantly aware of it.
Thanks, and thanks for the suggestion. We do a Q&A show for Patreons at the moment, but it's a thought.
Hi Dave: I would love to hear your answer to a question that has been bothering me for a long time. What is the fundamental problem that "software design" solves?
For a long time, I have been thinking about the lack of continuing education and software design training in the software industry. It bothered me that I needed about 10 years and some good luck before I really learned how to do software design well (and another five years or so to understand it well enough to be able to explain to someone else how it works and why it is important). I have often wondered why there are not better materials out there for the apprentice software developer. I was equal parts surprised and relieved to hear you and Simon discuss that same problem in the middle of this interview.
When I started thinking about how to fill the gap, I was forced to think about the fundamentals of software design--starting with why do we need design? Here is my conclusion: Software design is the only tool that we have to try to constrain entropy. As briefly as I can, here is how I landed there: Computers are state machines. There is a wide variety of state transitions that are permitted by the computer, the set of allowable state transitions is the instruction set. The number of possible states and the number of possible state transitions is each so large that both of them are effectively infinite. In other words, the system is unconstrained. The unconstrained nature of the machine makes it a very powerful tool because it can be used to represent a very wide variety of problems. However, for a specific problem only a vanishingly small number of machine states is valid. A bug causes the system transition to a random invalid state (random in the sense that the bug can cause any state transition allowed by the instruction set). Over time, bugs move the state of the system further and further toward the most common states and away from the small number of valid states. In other words, bugs raise the entropy of the system state. Software design puts rules in place that constrain the allowable state transitions to a set small enough for a human to understand. Having such constraints makes the problem easier to understand and also makes bugs (violations of the constraints) easier to identify and understand.
From this I define Sofware Design (as a verb) to fundamentally be the process of creating a set of constraints that serve to reduce the scope of the problem within a given context by restricting the set of valid state transitions available to the software developer.
Thanks for the books (Continuous Delivery changed the way I think about my career) and the UA-cam channel (I reference it frequently to my colleagues). You are doing good work.
I think that software design is primarily there to allow us to continue to change the code. Which is another way of say to reduce, or at least constrain, the entropy. The hallmark of high quality design is that the code based is easy to change, safely. That is really the topic of my "Modern SW Engineering" book.
Thank you for the video. During whole video I have smile in my face because you named a bunch of things that I see are wrong in our industry. I totally agree with everything you said. If I can add just one thing the rootcause of all of the issue is lack of proper education.
My ears and eyes are ready!
Great Talk
Great talk!
I'd like to add my opinion that the negative comparison between software "engineering" and the other kinds of engineering needs to be a little adjusted. Not because the software engineering is fantastic (of course is not), but because the quality of the rest of engineering is also really debatable. The comparison with buildings come in discussion over and over. I've seen a ton of new buildings with cracked walls, the miracle of architecture called Stata Building at MIT has serious issues of various kinds, jumping industry there are decades of issues with AlfaRomeos (not my personal experience), Teslas have some really funky (and maybe not that important) issues like not closing the trunk very well (personal experience), and so on. Basically is not that software engineering sucks and the rest of "engineerings" are so much better, but it seems that everything relevant and worth trying will probably have problems. And software is definitely an industry which tries to do new stuff all the time (and when is doesn't, it's fairly ok, I don't think there were many bugs in Wordle)
Great talk, but I wish Hannes had not interrupted as much
agreed, he is super-disturbing - apart from that, an interesting talk
I didn't see any interruptions, but a skilled moderator ensuring a fluid, broad and lively discussion. If you wanted more detail from Simon and Dave, they both have a number of technical lectures available here on UA-cam
Toooo much insist on architects role. It's about architecture not architects
I don't think I said that it is about architects, because I don't believe that it is. Do check out this week's upcoming episode, released on Wednesday, which talks about this in more detail.
@@ContinuousDelivery Thanks for the reply Dave. True, you didn't mention it. I just got this impression from the initial parts of the video. Looking forward to your new episode!