Scaling engineering efforts in software
Organizational benefits of microservices
We’ve all been there, growing software products with large and complex codebases, adding more engineers seems to slow down the development rather than speeding it up. It would seem that the project have reached a point of diminishing returns. So how can we alleviate this and prevent imminent disaster?
“Big teams usually wind up just wasting everybody’s time”
— J. Richard Hackman, Harvard University
As a software product grows bigger, the supporting engineering efforts usually have to scale with it. At this point it’s not uncommon for new team members to struggle grasping the codebase and understanding implied technical choices, which in turn leads to a loss of productivity.
Two pizza rule
When the team grows beyond a certain point it’s not uncommon for prior productive members to be impeded, partly by the extra strain put on them from mentoring new members in an ever growing team. But also from the extra load put on team members from communication throughout the now much larger team.
To mitigate the loss of productivity we need to keep our teams lean and swift at an optimal size. A good rule of thumb here is “The Two Pizza Team”-approach established by Amazon. The gist of the concept is that no team should be larger than one that could be fed by two pizza pies.
“I think that kind of decentralization is important for innovation because your hands are closer to the knobs of what you’re trying to build”
Of course keeping teams at this size when the product needs and business are growing isn’t sustainable either. Therefore I’m going to discuss an architectural approach which not only allows teams to remain lean and concentrated but is also decentralized.
The remedy — microservices
By migrating to microservice architecture we take one large software product and split it into several smaller services, each with greatly reduced complexity. This can be achieved by keeping individual services loosely coupled and speaking over a stable and well defined contract, more than often a so called REST-API.
What is a microservice?
Taking the word micro too literary is a common misconception which will lead to major headaches down the road. Instead these services should cohere the Domain Driven Design (DDD) principles. Think of the name as domain specific services, where each service is responsible for a particular business domain of the product.
Now you may be thinking that you’ve already got a successful product and you’d rather not start from scratch. Don’t worry, in fact this is the perfect stage to start. At this stage we simply stop adding new features to the existing monolithic core. Instead we’ll develop them as new services, thus building a façade around the old core. These services will slowly strangle the old monolith and we end up with a successful microservice architecture.
Technical independence, distribute ownership
One of the greatest benefits of a microservice architecture is the possibility of technical independence due to the loose coupling and strong contracts employed by individual services. This enables every team to truly own the technological choices made within their service, something Sam Newman discusses in his book Building Microservices.
Team ownership of the services as their own products establishes an environment which fosters both responsibility, creativity as well as a deeper sense of purpose. This environment is crucial for ambitious engineers to thrive and remain resourceful.
Move fast
We often hear it; move fast, adapt and iterate. In today’s technological environment we always need to keep on our toes, ready to pivot when the market requires it.
By employing the microservice architecture we are no longer constrained by previous technological choices, thereby neither slowed down by them. We’ve then created a setting which allows teams to move at a considerably more rapid pace, constantly adapting to new developments. They can iterate rapidly and scrap the old; something which often is key in the quickly evolving and highly technical industry.
We can now easily task new teams with creating new services, no longer having the need to understand a large prior codebase and the complex internal relationship this implies. Once relieved from this burden, the team is blessed with greater freedom to make quick decisions, leading to useful product additions; ergo, producing a major advantage when growing the organization.
Launching sibling products
Of course, once we’ve implemented a microservice architecture we’d want to utilize new opportunities. You probably know of at least one small part of your product which stands out on it’s own merit. The complexity of launching these parts as separate smaller products at this stage is greatly reduced since the core codebase can share the same software service modules as the core product. Reflect a moment and just consider all the new possibilities this enables.
Having these sibling products enables us to extract individual core values from the product and market them for a broader customer base who wouldn’t use the larger product. As some of these customers grow they might wish to use more of our new products or even convert to the full platform. The maintenance costs of these new products are a fraction of the parent product as these siblings share an ample amount of code, hence developments in the parent product can be directly applied downstream.
Conclusion
The essence of this article is that by applying a microservice architecture to a software platform, great benefits can be achieved in organizational scalability. This is a result of the possibility to decentralize decision making and responsibility through modularizing. This while also reducing complexity by communicating through strong contracts (APIs) and ensuring loose coupling (no interprocess communication). Consecutively teams can be smaller and operate as separate organizational entities.
Further reading
In this article the technical side of things have deliberately been kept at a minimum, the more intricate parts are omitted. However I’ve attached some more technical material below for those of you who wish to explore the details of the subject.
About the author
Alexander Hultnér is the Lead Product Developer at Cetrez Group HQ and has been leading multiple microservice projects in the past couple of years.
