Houses, Forcing Functions, and Containers

In my last post, I talked about microservices compared to houses. A giant house with lots of stuff in it is hard to find anything. A small house with lots of stuff in it is hard to find anything. A small house with the right amount of stuff in that house makes it easy to find that stuff. In fact, labeling and putting everything in its place helps even more.

Jimmy Bosse wrote:

I think the nooks and crannies are a natural result of years of maintenance and the rotation of team members. Each class is essentially the most micro of services. Moving to a micro service feels like it’s neater just like moving to a new home is neater. You’ve just gone through all the crap and cleaned house in order to move. Over time those micro services will build their own books and crannies as features built under deadlines pile on team members move on to greener pastures. Entropy is coming for everything. No architecture can stop it.

Jimmy Bosse, “A house small enough to fit everything in”

I love this comment because who among us hasn’t had this happen multiple times? It’s almost a rite of passage to have your system live long enough to become the villain and there to be people that want to move to a new system. How many times have you or someone you’ve worked with advocated a rewrite with that same thought in mind?

That’s what we’re trying to stop, right? No one in the business ever wants the code rewritten, and the longer you spend in this industry the more you realize a rewrite is in the same vein as a self-licking ice cream cone: it sounds nice but when you think about it is on some level absurd and another level impossible. (Why do we rewrite software? So we can avoid rewriting software!)

That’s why I think event-driven architecture especially and services-oriented architecture (SOA) and microservices topologies in particular have a leg up on our past efforts. Our problem previously was there was no size constraint: all boundaries were soft boundaries. Since everything was deployed together in a monolith, eventually you’d end up with a big blob of software. With SOA, you now had to name those blobs and make a hard separation point at a network boundary, and of course there was more than one of them. This was better because of course we’d rather fight 10 chicken sized horses, than fight one horse-sized chicken. And then we got microservices and now we have 100 chicken-sized horses and we realized that was enough slices.

So there has to be a balance: You can’t just divvy items up and put them in containers and expect everyone to find what they’re looking for — especially if at some point you start naming that container “utility”, you have to actually spend time naming and planning, in any case. But at least with event-driven architecture you get two things you didn’t have previously: No one can reach into someone else’s box, and the network boundary is well-defined.

The bottom line is that entropy comes for us all; Jimmy’s right about that. We’ve tried soft boundaries, and they didn’t work. We tried hard boundaries and they seem to work a little better; but that coupling is a problem. With Event Driven architecture we can truly finally have a loosely coupled system enforced more easily than the soft boundaries we had before.

P.S. I got what appears to be a concussion over my vacation and so there’s a lot of weird association (and fogginess) going on in my mind right now. I’m going to proof-read this in the morning before I hit post; but if it’s too out there, don’t hold it too much against me.

Leave a Reply