Three Questions to Ask Before Recommending Microservices to Clients

5 min read

By: Jeanette Pranin

At what scale are microservices appropriate, and when they are too complex?

“Do you have any experience in microservices?”

This is a question that I have been asked countless times as a developer here at the IBM Garage—a network of physical innovation hubs where companies of all sizes are empowered to create engaging applications. We are particularly known for our industry-leading IBM Garage Method, a cutting-edge methodology for clients to deliver their products in an efficient and scalable way. This method extends all the way to the enterprise level, which has become increasingly important as the Garage takes on bigger clients who aim to modernize their product development process.

Many clients come into the Garage wanting to utilize the hottest new technology, with microservices being an often-cited choice. There are many valid reasons to utilize microservices over a traditional monolith. However, it is also important to discuss at what scale are microservices appropriate and when they are too complex.

So, what is a microservice anyway?

As described by Chris Richardson, the microservices architectural style “structures an application as a collection of services that are highly maintainable and testable, loosely coupled, independently deployable, and organized around business capabilities.”­­1 In other words, microservices separate out the functionalities of an application into bite-sized, manageable chunks that do not depend on each other’s deployment and maintenance. There are numerous benefits to this design:

  • Each microservice can be deployed and containerized independently. This means that the build pipeline and schedule of a microservice does not have any impact on other parts of an application. In the same vein, an entire redeployment of the application is not necessary if one section of the code is buggy. The faulty microservice can be reverted to a stable working version while it is being fixed, and the rest of the microservices can remain at their most up-to-date versions.

  • “A compromised microservice will not necessarily leave the application vulnerable.”2 This aspect is great for security reasons. If a vulnerability is identified, the service can be isolated, fixed, and deployed much more quickly than for a section of code in a monolith structure.

  • Microservices help to organize business logic and enable code readability and manageability in the long haul. Because each microservice is organized around a single business function, it is easy to understand how these business rules are structured and how it relates to the functionality of the overall product. This comes in handy when the codebase becomes legacy code to a new team.

For more of an overview of microservices architecture, see "Microservices: A Complete Guide" and check out our lightboarding video, “What are Microservices?”

The drawbacks of microservices

Utilizing a microservices architecture also has its downsides:

  • Microservices come with a high price point. As an example: If a team of three developers who all make $100,000 a year take four weeks to create a microservice, it will cost almost $23,000 in development time to build that microservice.3 A client must consider the maintenance cost of adding new microservices when discussing the addition of novel functionality to an application.

  • The DevOps team managing the infrastructure must be technically apt enough to take on the gargantuan task of constant deployment and containerization of each microservice.4 Not only do microservices have to be configured properly in order to successfully communicate with each other, but the platform on which these microservices are deployed must be arranged so that the upkeep of these services is manageable and scalable. Such resources do not come easily or affordably.

  • A change in the interface of one microservice could mean that many other microservices have to be updated. A microservice must have an interface—think API endpoints—that network clients, including other microservices, can use to communicate with it. If this interface is modified, all microservices that call this microservice must be updated to reflect this change or they will no longer be able to communicate with the microservice properly.

When are microservices appropriate?

With all of this in mind, when are microservices appropriate for our clients? The microservices architectural style works well with many of the Garage methodology’s principles. For example, the “Develop Code in Small Batches” principle, which touts that delivering the end-to-end functionality of a small set of code is more efficient than for a large chunk of code,5 models exactly how microservices are meant to be developed—on a “micro” scale.

Further, as per the “Design Software Iteratively” principle, microservices allows developers to continuously update microservices iteratively in an isolated, containerized way. However, for a significant majority of the Garage’s incoming clients, the engagement length can range from 8 to 14 weeks, which does not allow for much time to prop up a fully integrated microservices environment. Additionally, the client’s budget must be able to finance the construction and management costs of a microservices architecture, a cost that will remain long after the client’s engagement with the Garage is over.

Finally, although the Garage offers architecture workshops as well as DevOps support, the client should have a dedicated DevOps team in charge of the implementation of such an architecture.

The three questions to ask before you recommend microservices to your clients

Looping back to the original question, how should the Garage respond when a client asks for a microservices implementation? To answer this question, the following three questions must be answered:

  1. Does your budget suffice for the maintenance cost of this architecture?

  2. Can you dedicate the time to formalize a proper architecture and configure it accordingly?

  3. Is your DevOps team mature enough to take on the responsibility of constant set up and deployment of multiple microservices, especially if you aim to scale up in the future?

If a client answers “YES” to all three questions, then microservices are a great option for them and the Garage can effectively enable the client to instantiate such a structure. If not, then it may be beneficial to discuss other options with the client so that a fully built-out MVP can be delivered successfully by the end of their engagement with the Garage.

Interested to see how the IBM Garage can help you? Sign up for a cost-free, four-hour virtual visit here.

References:

  1. Richardson, Chris. “What Are Microservices?” Microservices.io. 2018.

  2. Churchman, Michael. “5 Reasons Not to Use Microservices.” Runscope Blog. October 25, 2018. 

  3. Lumetta, Jake. “Should you build or buy microservices?” ButterCMS.

  4. Olliffe, Gary. “How to Determine When and Why to Use Microservices.” Computerworld. June 27, 2017.

  5. Will, Scott. “Develop Code in Small Batches.” IBM.

  6. Brown, Kyle. “Design software iteratively.” IBM. 

Be the first to hear about news, product updates, and innovation from IBM Cloud