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
Why Teams Don't Work
Over the past couple of decades, a cult has grown up around teams. Even in a society as fiercely independent as America…
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.
Productivity Hack Of The Week: The Two Pizza Approach To Productive Teamwork
If you’re looking for more effective teamwork, Amazon’s CEO Jeff Bezos suggests implementing a very simple trick: the…
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.
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.
Grow fast or die slow
Software and online-services companies can quickly become billion-dollar giants, but the recipe for sustained growth…
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.
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.
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.
Introduction to Microservices | NGINX
Introduction to Microservices (this article) Building Microservices: Using an API Gateway Building Microservices: Inter…
Distributed systems have become more fine-grained in the past 10 years, shifting from code-heavy monolithic…
"Microservices" - yet another new term on the crowded streets of software architecture. Although our natural…
"Microservices" became the hot term in 2014, attracting lots of attention as a new way to think about structuring…
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.