Microservices architecture: Choosing your approach

As competition escalates and user expectations continue to evolve, companies are recognizing the limitations of the old “monolithic” approach to enterprise architecture. Because monolithic applications exist as a single unit, even minimal changes can require a significant amount of time, inhibiting the organization’s ability to adapt quickly to changes in the environment.

Shifting to a microservices approach allows a company to launch and integrate assets more quickly, adapt more easily to market changes, and scale more efficiently. According to a recent survey, more businesses are catching on, with 68 percent of organizations either using or investigating microservices, and one-third currently using them in production.

Recently we led a webinar on how banks and other financial services organizations can differentiate themselves using microservices architecture. One of the issues we discussed was choosing an approach to microservices — deciding how to carve up those monolithic applications. Today I’ll explore two of the most popular approaches, plus a third option that leverages the benefits of both.

Traditional approaches to designing microservices

As organizations recognize the benefits of a microservices architecture approach, they face the question “How do we divide up our monolithic applications into more manageable pieces?” Most companies answer this question in one of two ways.

The top-down approach involves a functional decomposition of the application, beginning at the business level. The architect separates out functionalities based either on domain (domain-driven design) or on business capability. A bank, for example, may create separate microservices for lending, wealth management, and online banking.

The bottom-up approach is purely technical, using the availability of development resources as the basis for microservice designation. The architect may look at service functionalities — such as a bank’s deposit functions — and bundle them together to create a single microservice. Or he may divide up larger applications by technology, such as Java or Node.js, and create microservices based on those groupings.

Each approach offers a distinct set of advantages — top-down is more easily understood by non-technical decision makers, and bottom-up makes more efficient use of existing development resources. However, each encompasses its share of challenges as well.

Challenges of the top-down-only approach

Organizations that have adopted a top-down-only approach to microservices architecture have encountered a series of complications. For example, if the organization creates an independent microservice for every operation or function, they could wind up with a sprawling architecture that’s difficult to manage. Furthermore, since each service requires its own infrastructure, they may need to add servers or other resources, driving up their infrastructure costs.

Another challenge related to the top-down-only approach is that the resulting service inventory may not align with the organization of development and support teams. Deploying and supporting a single service — such as online banking — may require coordination among several IT teams, resulting in a less efficient use of technology resources.

Challenges of the bottom-up-only approach

While relying solely on a bottom-up strategy offers the potential to utilize technology resources more efficiently, it offers its own share of headaches. The resulting services, for example, may be misaligned with business function ownership, since a single microservice — such as deposits — may span several different lines of business.

Problems may also arise around the timing of releases. Some business units may want to have more aggressive release cycles, and if services are not aligned to those cycles, releases could be held up while the development team waits on other departments.

A better way: The blended approach

When we work with clients to design their microservices architecture, we recommend a blended approach that leverages the greatest benefits of each traditional strategy:

• Begin with a domain model or functional decomposition, which gives you the candidates for your services.
• Optimize your services inventory using a technical approach, either separating or folding functions together from the operational perspective, to determine how you’re going to manage those services.

One advantage of this approach is that it involves both IT and the business at the highest level. Both teams work together from the very beginning to designate microservices that make sense from the business perspective, but are also efficient for IT to manage on a day-to-day basis.

As more organizations make the shift to a microservices architecture, we can expect to see greater competitive pressure for other organizations to jump in as well. When you choose the right approach, your organization stands a far greater chance of realizing the benefits that microservices have to offer and improving your ability to adapt to a rapidly changing landscape.

Dmitriy Buslovich has over 17 years of experience in project and program management leading cross-functional teams primarily focused on business intelligence, business analysis, and software development.