Should I use microservices?

Despite the drive in some quarters to make microservice architectures the default approach for software, I feel that due to their numerous challenges, adopting them still requires careful thought. You need to assess your problem space, your skills, technology landscape, and understand what you are trying to achieve before deciding if microservices are right for you. They are an architectural approach, not the architectural approach. Your own context should play a huge part in deciding if you want to go down the microservices path.

That said, I do want to outline a few situations that would typically tip me away from—or toward—picking microservices.

Where microservices don’t work well

Given the importance of defining stable service boundaries, I feel that microservice architectures are often a bad choice for brand new products or startups. In either case, the domain that you are working with is typically undergoing significant change as you iterate on the fundamentals of what you are trying to build. This shift in domain models will in turn result in more changes being made to service boundaries, and co-ordinating changes across service boundaries is an expensive undertaking. In general, I feel it’s more appropriate to wait until enough of the domain model has stabilized before looking to define service boundaries.

I do see a temptation for startups to go microservice first. The reasoning goes: “If we’re really successful, we’ll need to scale!” The problem is that you don’t necessarily know if anyone is even going to want to use your new product, and even if you do become successful enough to require a highly scalable architecture, the thing you end up delivering to your users might be very different from what you started building in the first place. Uber initially focused on limos, and Flickr spun out of attempts to create a multiplayer online game. The process of finding product market fit means you may end up with a very different product at the end than the one you thought you’d build when you started.

The challenge of microservices for startups is compounded by the fact that normally your biggest constraint is people. For a small team, a microservice architecture can be hard to justify, as there is work required just to handle the deployment and management of the microservices themselves—some people have described this as the “microservice tax.” When that investment benefits a lot of people, it’s easier to justify—but if one person out of your five-person team is spending their time on these issues, that’s a lot of valuable time not being spent building your product. It’s much easier to move to microservices later on, once you understand where the constraints are in your architecture and what your pain points are—then you can focus your energy in using microservices in the most sensible places.

The last situation I encounter surprisingly often is organizations creating software that will be deployed and managed by their customers. Microservice architectures can push a lot of complexity into the deployment and operational domain. If you are running the software yourselves, you are able to offset this new complexity by adopting new technology, developing new skills, and changing working practices. This isn’t something you can expect your customers to do. If they are used to receiving your software as a Windows installer, it’s going to come as an awful shock to them when you send out the next version of your software and say, “Just put these 20 pods on your Kubernetes cluster!” In all likelihood, they will have no idea what a pod, Kubernetes, or a cluster even is.

Where microservices work well

Probably the single biggest reason I see organizations adopt microservices is to allow for more developers to work on the same system without getting in each others’ way. Get your architecture and organizational boundaries right, and you allow more people to work independently from each other, reducing delivery contention.

A five-person startup is likely to find a microservice architecture a drag—a 100-person scale-up that is growing rapidly is likely to find their growth is much easier to accommodate with a microservice architecture properly aligned around their product development efforts.

Software-as-a-service (SaaS) software is, in general, also a good fit for a microservice architecture. These products are typically expected to operate 24×7, which creates challenges when it comes to rolling out changes. The independent releasability of microservice architectures is a huge boon in this area. Further, the microservices can be scaled up, or down, as required. This means that as you establish a sensible baseline for your system’s load characteristics, you get more control over ensuring that you can scale your system in the most cost-effective way possible.

The technology-agnostic nature of microservices ensures you can get the most out of cloud platforms. Public cloud vendors provide a wide array of services and deployment mechanisms for your code. You can much more easily match the requirements of specific services to the cloud services that will best help you implement them. For example you might decide to deploy one service as a set of functions, another as a managed virtual machine, and another on a managed platform-as-as-service (PaaS) platform. While it’s worth noting that adopting a wide range of technology can often be a problem, being able to try out new technology easily is a good way to rapidly identify new approaches that might yield benefits. The growing popularity of function as a service (FaaS) platforms is one such example—for the right workloads, it can drastically reduce the amount of operational overhead, but at present, it’s not a deployment mechanism that would be suitable in all cases.

Microservices also present clear benefits for organizations that are looking to provide services to their customers over a variety of new channels. A lot of digital transformation efforts seem to involve trying to unlock functionality hidden away in existing systems—the desire is to create new customer experiences that can support the needs of users via whatever interaction mechanism makes the most sense.

Above all, a microservice architecture is one that can give you a lot of flexibility as you continue to evolve your system. That flexibility has a cost of course, but if you want to keep your options open regarding changes you might want to make in the future, it could be a price worth paying.