Yeah, I guess there’s two angles on this. There’s the why is it interesting to me at sort of a high level, and then there’s the why do I think Go is a great match at a technical level.
I’ll start with the first, I guess. I was really doing microservicey type stuff for quite a long time; of course, it didn’t have that name until very recently. I really only dove into what we commonly know as microservice workloads today, when I was at Soundcloud, and we kind of made an executive decision – or at least an engineering department decision – that this was probably gonna be the future and we should probably invest some resources into building out an architecture that worked in this manner. At the beginning I think I was the first team that was using our internal platform and kind of the prototype customer, but I was really excited to try it out, because it got at something that I couldn’t quite put the word at the time, but which I really have thought a lot about, and I think I can describe it properly, now that I’m a few years removed. And that is this experience I had in previous companies where it would be my first day or my first week on the job, and I would join a team, and there would be this existing codebase that to my eyes was just massive, and full of dark corners and unexpected interactions, and a lot of legacy… Not necessarily croft, but just legacy knowledge baked into it. And the only way to become comfortable in that environment was to put in a whole lot of grunt work that you couldn’t really rush and you couldn’t really optimize.
You had to read the code, but that was never enough; you had to go and ask people why things were the way that they were, and sort of probe them with intelligent questions about, “Well, did you consider this alternative? Oh, okay, you did and didn’t work out for these reasons… What implications does that have on this other part of the system?” So for me it was always a multi-month process to get my head around a new system, and what I sort of discovered with microservices was that this cost was dramatically reduced when the size of an individual codebase with well-defined boundaries was much smaller. In my workshops I say one good definition of a microservice is “Code that you can keep in your head”, and I think that’s a really great way to delineate a boundary for this sort of thing. [00:16:03.13] It’s code that you can totally keep in your layer two cache, in your brain, or whatever, and that implies that you can pretty well describe it with a single sheet of paper and 15 minutes to a co-worker. And maybe there are a couple of edge cases and dark corners in there, but it’s not the sort of stuff you need to dedicate half a year to figuring out. And if this is true, if this is how your organization’s built, like a loose constellation of these sorts of codebases, then it’s much easier to move between them, to understand them, to understand the interaction points – at least for me, at least for the way I model software. And in turn, it gives you a lot more confidence – when you join a new team or you start a new project or you take over an existing project – to refactor it perhaps, if the requirements change, or to make changes and maintain it, and have confidence that you’re doing that in the right way.
That’s sort of the soft side, it’s why I love microservices. They make me confident again, and they give me a certain amount of happiness that I lost when I was working on gigantic years-old legacy monoliths or huge projects like that. That was a lot of talk, I’m sorry for taking the floor.