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.