How to understand a complex system - Dylan Beattie

How to understand a complex system - Dylan Beattie - https://www.youtube.com/watch?v=tl9YPdk-PB0

Someone comes to you as the architect and says, we want to build a system that does this. We want to decouple like a login system so we can build different microservices that use common authentication. How can we do that? And your job is to come up with a way of doing it. First of all, what have you got now? A lot of time in organizations and software teams, there will be two versions of the truth. There will be what people think they have because they paid someone a lot of money for a high performance transaction processing system. And there will be what they actually have, which is 100,000 lines of ruby that doesn't work properly, you know, and you need to understand these disparities. Now, the best way I've found of doing this is to look at the borders, the boundaries between the different systems. You want to understand the traffic that is flowing between the components of these systems. Don't worry too much about the code, don't worry about the spec. And, you know, when people tell you what something does, take it with a pinch of salt. It's useful, but it might not be 100% accurate. Here is the simplest possible systems diagram I can think of. Now, as an architect, you don't care whether that website is php or.net or Pearl or Ruby or whatever, and the Internet, that's someone else's problem. But this thing in the middle, HTTP, how many questions can you ask about that? How many transactions does it cope with? Is there HTTPs on it? When does the certificate expire? Does it cope with get put post? What if I put a proxy in there? How much of this stuff can we cache? Are we using etags on the traffic that flows across it? Just by putting a network trace on on that HTTP and watching it for half an hour will tell you more about how this website actually works than any number of hours spent reading the code and going, oh, this module looks interesting. Oh, it's never been run. We don't know why it's here. Traffic is real. Traffic is the lifeblood of living systems. You don't care what anything was designed to do. Your Gene Krantz in Apollo 13, you care what it can do. You need to understand the actual capabilities of the systems, not what was in the spec. And sometimes this will be disappointing, like our high performance authentication system can only cope with six users a minute. Sometimes it'll be pleasantly surprising. You'll dig into AWS and be like, there's a whole redis cluster in here that I didn't know we had. This is brilliant. We can start using this to speed up all kinds of things. We can put varnish in front of our web server and boom. Instant acceleration. And we can start rewriting stuff. You know, there will be pleasant surprises as well as disappointments. It's well worth taking the time to do this.