The world is full of ‘best practices’. Things that are accepted as always being the ‘right’ way to do things across a range of different industries. And yes, whilst there are things that might nudge you in the right direction, blindly following something because everyone else is doing it misses a lot of nuance.
Before I joined AWS I did quite a bit of freelance software development, mostly with startups. At the time, I had mostly been building monolithic .NET applications (and a bit of SQL Server DBA-ing) and had started to hear about this thing called microservices. The startup I was working with at the time had reasonably good domain boundaries, and pretty obvious splits in the functionality. “What an excellent opportunity to take on this current industry best practice” I thought.
It was not!
Because yes, microservices are a good way of building software. Smaller units that run independently and are easier to understand. In principle, it sounds great. What is often missed when talking about microservices though, is the wider system. What is the environment like around the software, and how does that impact your decisions. This is what I missed.
Because at the time, I was in a development team of 1. Me. And the startup was also pivoting as the needs of it’s customers changed. What was a logical split today, caused pain later as two domains ended up needing to be smashed back together.
Ross Ashby was a psychologist and cyberneticist, and he stated “if the complexity of the environment exceeds the systems capacity to respond, the environment will always win and the system will die”. You see this play out in the natural world. The climate is changing rapidly, ecosystems can’t respond, the ecosystem dies.
Initially, you might think microservices allow you to respond to a changing environment more quickly. And yes, in some cases, they might. In many cases, they won’t. Here, the changing environment led to domains completely changing. Pieces of functionality disappearing, new ones appearing, and some joining together. Having independent codebases, independent deployments, and independent functionality hindered the system’s ability to respond.
That’s not to say microservices are bad. Not at all. The important thing to remember is to always think about the second order impacts of your decisions. What changes could happen later and how might that affect my decision today?
There’s probably a lesson for life in there as well.
James