How Microservices Architecture Impacted the Culture of Software Development
And why it’s more than just a way of structuring code
Microservices stumbled into the world of web development with a bang. The topic caused heated debates, endless posts, many comparisons to the monolithic architecture, and even use cases coming from big organizations. However, whenever the topic comes up, developers tend to focus mostly on the technical aspects of the microservices revolution rather than the cultural changes that it sparked. While the technology that grew around it is indeed very cool, I find the cultural changes to be more disruptive.
I was lucky to get onto the bandwagon relatively quickly, around 2014, and I still remember how exciting it was to migrate old monoliths into the new cool and sexy microservices. Like many, I was overly focused on technological aspects to begin with — after all, it was a very exciting time (e.g., Docker had just come around).
However, after a couple of years and despite how much things have changed in terms of technology, I believe that code ownership and feature teams had the biggest impact on how software is developed within organizations that adopted microservices.
Even though it was possible to have cross-functional feature teams within monolithic architectures, organizations would typically split the teams based on their technical capabilities (e.g., front end, back end, sysadmin, database development, etc.) Thus, developers rarely had access to the production environment, leading to split responsibilities when it came down to production and maintenance. James Lewis and Martin Fowler point directly to this notion within the article that initially defined the concept of microservices architecture.
Microservice proponents tend to avoid this model, preferring instead the notion that a team should own a product over its full lifetime. A common inspiration for this is Amazon’s notion of “you build, you run it” where a development team takes full responsibility for the software in production.
In addition, bringing people with other specialties to the team (e.g., product/marketing) allows for the scope to be increased far beyond technological aspects. Being able to monitor customer feedback, user adoption, and commercial value makes teams fully accountable and responsible for every aspect of the feature and its functionality. By following this model, teams can see the impact they have on the product and within the business itself.
I always like to think about programming as a form of art (or at least craftsmanship). When I started my adventure with programming, I spent years working on small projects like games, desktop/web applications, and websites. It felt liberating to transfer ideas from my head into the code. However, when I started my professional career in software development it felt more like working at a pizza joint than creating art.
Besides fuzzy accountability, having a centralized code base and data storage was also a limiting factor when choosing technologies. Decisions about framework, language, design patterns, or database engines had to be global. In short, it’s hard to get creative when one has no control over any of these aspects.
Microservices architecture brought about the concept of small code bases. Creating dozens of smaller repositories instead of a big one made it possible to set clear owners for specific repositories. Obviously, code ownership doesn’t have to mean that a single team or individual is responsible for maintaining the entire code. Other teams can also submit pull requests if needed (inner sourcing). However, the owner of the code guards the quality of the solutions and makes sure that all pull requests follow the code standards and API contracts.
In my opinion, having smaller teams with clear ownership brings a lot of joy to the day-to-day development work and gives developers the kind of freedom that sparks creativity. Also, working with small code bases feels like being involved with smaller projects again, even when working within a big organization.
Don’t get me wrong, there are no silver bullets. And while microservices-oriented architecture facilitates the possibility of having code ownership and feature teams, it is certainly not for everyone. After all, it’s possible to have these features within monolithic codebases, it just requires more organizational involvement to make it happen.