On January 6, 2018
In my last article, we covered how the software monolith is the result of a successful software project that delivers good results, causing it to receive more development attention until it becomes too large.
It can be frustrating for a large team to work in the same code base
Because there are dozens of engineers adding code and dependencies to the same application, builds take several minutes or even hours. Tests are very flaky because they rely on dozens of dependencies that may or may not be working at any given time. Software releases have too many unrelated changes, so they are fragile and can take a long time to ship to users.
As a result, the company wastes money and the team becomes frustrated. People want to avoid working on that weird code base, so the team might find it hard to retain talent.
The dream of microservices
Companies are moving to a microservices architecture to gain a competitive edge. Monoliths are hard to change. Microservices are smaller, easier to understand and promote faster development cycles, reducing maintenance costs.
This paradigm shift is just starting but companies are finding many challenges with this approach:
- Adopting microservices leads to an explosion in the number of services, which can increase maintenance cost if the management and setup of services aren’t fully automated.
- Legacy development workflows do not work with microservices because testing now requires bringing together a large number of independent services that interact in complex ways.
- Microservices are much harder to operate in production because they produce many more distinct targets for monitoring and debugging.
- Debugging failures is much harder because of the distributed nature of request-handling in a microservices architecture.
The open source ecosystem has created incremental solutions for many of these problems, but those tools don’t directly address higher-level targets such as developer productivity, service level objectives, and business goals. Unsurprisingly, it’s difficult for development and operations teams to create a coherent platform to run their own services.
As a result, companies have been reluctant or slow about moving to the microservices model by the fear that they might end up missing out on substantial business advantages they could have.
The path followed by teams that successfully transitioned from monoliths has been to move to smaller deployment units and use a well-engineered platform that is committed to the organization’s goals. See Netflix, Lyft, Uber and Google’s internal platform. Invariably, those platforms have done the following:
- Replace the large monolith with smaller communicating applications that are released independently.
- Fully automate the setup and management of these services to avoid ops overload.
- Apply best practices to avoid introducing new problems and technical debt when developers start using the new architecture.
What to do next
Moving to a new architecture can take some time. But I believe we can make this a lot easier if we provide well-engineered tooling to help.
If we provide a transition path and make it easy for people to get started, development time will quickly transition to the new stack. Developers will create new projects in the better, more agile infrastructure. This process can be further accelerated with careful planning by senior engineers and architects that understand the product roadmap and know what pieces are worth carving out and moving to the new stack.
It’s time for an open source microservices platform
Our team is working on a platform for microservices development with the explicit goal of helping companies move away from software monoliths. We are starting small and the challenge is huge, but I think it’s a good time to start something that will have a real impact. The project is still in early stages but we will invite everyone to use and contribute to the open source project, soon.
If you’re interested in this space, let’s connect and chat!