Sinclair is CEO and cofounder of Apprenda, a leader in enterprise Platform as a Service.
With all of the talk these days about microservices and distributed applications, monolithic applications have become the scourge of cloud systems design. Normally, when a new technical trend emerges to replace a previous one, it is due (at least in part) to evolved thinking. The odd thing with monolithic application architecture, however, is that nobody ever proposed it as a good idea in the first place.
The idea of loosely coupled services with clear boundaries has been around for decades in software engineering. So, how did we end up with so many apps “designed” as monoliths? In a word – convenience.
The fact is, in many use cases, monolithic architectures come with some non-trivial and durable benefits that we can’t simply discount because it doesn’t adhere to a modern pattern. Conversely, microservices can introduce significant complexity to application delivery that isn’t always necessary.
As a fan of microservices, I fear enterprises are blindly charging forward and could be left disappointed with a microservices-based strategy if the technology is not appropriately applied. The point of this post isn’t to pour FUD onto microservices. It’s about understanding tradeoffs and deliberately selecting microservices based on their benefits rather than technical hype.
Debugging and testing
Generally speaking, monolithic applications are easier to debug and test when compared to their microservices counterparts. Once you start hopping across process, machine, and networking boundaries, you introduce many hundreds of new variables and opportunities for things to go wrong – many of which are out of the developer’s control.
Also, the looser the dependency between components, the harder it is to determine when compatibility or interface contracts are broken. You won’t know something has gone wrong until well into runtime.
If your shiny new mobile app is taking several seconds to load each screen because it’s making 30 API calls to 30 different microservices, your users aren’t going to congratulate you on this technical achievement. Sure, you can add some clever caching and request collapsing, but that’s a lot of additional complexity you just bought yourself as a developer.
If you’re talking about a complicated application being used by hundreds of thousands or millions of users, this additional complexity may well be worth the benefits of a microservices architecture. But, most enterprise line-of-business applications don’t approach anything near that scale.
Security and operations
Fortune 500 enterprises I work with struggle with managing the relatively coarse-grained application security IT departments use today. If you’re going to break up your application into lots of tiny services, you’re going to have to manage the service-to-service entitlements that accompany this plan. While managing “many as one” has time tested benefits, it’s also contrary to the motivation behind microservices.
Planning and design
Microservices have a higher up-front design cost and can involve complicated political conversations across team boundaries. It can be tricky to explain why your new “pro-agile” architecture is going to take weeks of planning for every project to get off the ground. There’s also a very real risk of “over-architecting” these types of distributed solutions.
Having said all of this, microservices can absolutely deliver significant benefits. If you’re building a complicated application and/or work across multiple development teams operating in parallel and iterating often, microservices make a ton of sense.
In fact, in these types of situations, monolithic applications simply serve as repositories of technical debt that ultimately becomes crippling. There is a clear tipping point here where each of the advantages of monolithic applications I described earlier become liabilities. They become too large to debug without understanding how everything fits together, they don’t scale, and your security model isn’t granular enough to expose segments of functionality.
One way to help reduce and in some cases even eliminate the technical “tax” associated with microservices is to pair them with an enterprise Platform as a Service (PaaS). A proper enterprise PaaS is designed to stitch together distributed services and takes deployment, performance, security, integration, and operational concerns off the developer and operators’ plates.