Align the Pain with the Solution – InApps 2022

Microservices are a type of service-oriented architecture (SOA). More specifically, microservices are an architectural style in which applications are decomposed into loosely coupled services. With fine-grained services and lightweight protocols, microservices offer increased modularity, making applications easier to develop, test, deploy, and, most importantly, change and maintain.

Microservices have an inviting appeal “in theory.” In practice, results vary dramatically. Some organizations love them, and some sink under the weight of costs, overhead and missed deadlines. Microservices mean more than modularity with easier development, test and deployment features. They can also mean dramatically increased complexity, dependencies and cost.

So how do you decide if microservices are the right direction for your organization?

A Cautionary Tale

Recently, a friend expressed disbelief to me that a stable, working, low-cost solution to manage health care data that he had developed in a few months, using free and off-the-shelf software, was being redeveloped into a custom microservice-based solution and would take five developers a year to complete. The issues around protected health information (PHI) data were not addressed in the development plan, so he had a feeling the lack of data governance would blow up the project as well. Plus, the development and AWS costs for the year were well over a million dollars. Not to mention the long-term overhead, given that the entire software development organization is only about 100 developers strong.

I’ll keep saying this … if people can’t build monoliths properly, microservices won’t help.

-Simon Brown @simonbrown

When he asked why this was happening, his manager — who had recently moved into the role with a background in Facebook, Amazon, Apple, Netflix and Google (FAANG) engineering — told him that going forward, all of their software stack would be based on state-of-the-art microservices and leverage AWS services. This would be the new standard. When he asked his manager about the cost of the project, his manager dismissed the question and cited his FAANG background and experience as an indicator of the long-term value of the project.

When Would It Make Sense to Use Microservices?

The demarcation where microservices make sense can be seen in the size of the supporting software organizations. A large-enough software engineering organization that struggles with communication and/or coordination can certainly use microservices. Companies like Facebook and Apple employ tens of thousands of engineers, and they have massive resources, so microservices can reduce dependencies between teams and support scaling up. This is where the overhead of microservices can be worth the extra investment at scale.

But what about all small and medium-sized software engineering organizations? This is where the details and the context of the use case matter. Small to medium engineering organizations have a similar focus: creating reliable applications that deliver business value efficiently, especially considering that engineering resources are limited. Engineering time affects every decision and should help determine whether investment in microservices is worth it. From what I’ve observed, engineers who leave large engineering organizations for smaller organizations tend to lack the ability to understand the constraints for organizations with a hundred or fewer engineers.

Adopting microservices shifts the complexity, but does not remove it. In some places, the shift is worth it. But if your system’s resources are too small, your engineering time is too limited. Plus, if the problems you’re facing aren’t coming from large team coordination and communication, then splitting your application up into lots of pieces will likely create more headaches than it’s worth.

When Does It Make Sense to Consider Microservices?

For small- to medium-sized engineering organizations, it can make sense to adopt some principles of microservices. One way to do this is to match the pain you’re feeling with a move to something like a microservice. For example, is your pain the result of a monolithic application with thousands of lines of C that require a blood sacrifice to the gods every time you update it?

Another example: Does your pain come from your application bundling a ton of unrelated features? If so, then break up your application into smaller monoliths instead of completely breaking down every feature into a smaller service. Break down your features into something your team can support long term — big engineering best practices be damned.

Bottom Line

To the small and medium-sized development managers and architects, please match the solution with the pain, and make sure the solution is something your existing team can support. Being fashionable and following trends works in the fashion industry, but not so much with software teams. You can protect teams and provide value to your business by making smart, thoughtful decisions.

Photo by Ketut Subiyanto from Pexels.