The big don’t eat the small, the fast eat the slow. In today’s hyper-competitive digital economy, organizations succeed or fail based on their agility: the velocity at which they can deliver the new products, services, and features that meet the changing needs of their market.
But how can an organization develop this agility? It requires a solid foundation of organizational and technological capabilities. The software delivery paradigm now known as “microservices” addresses both of these areas, uncompromisingly. What is still debated, however, is exactly how those capabilities are to be built.
Implementing a successful microservice architecture
The agility of a digital organization is unquestionably affected by the architecture of its underlying software systems. According to its early adopters, microservice architecture has enabled organizational agility at web native companies like Netflix, Amazon, Google, Uber, and more; so it stands to reason that their approach is a sound one.
However, when it comes to implementation outside of that Silicon Valley bubble, innovation execution becomes less clear, and the promise of microservices is soon overshadowed by the lack of a prescribed path and the inherent risks that creates. It’s arguable that part of the reason the path is so uncertain is in the overloading of the term “microservices” itself. Has adoption been hindered by conflating the goals and focusing on enabling technologies such as containers or service mesh, reactive systems, and domain driven design? Or perhaps the main obstacle to successful microservice architecture implementations lie in that lack of a path and a supporting ecosystem of knowledge and technology, which is why at MuleSoft we invest in our Anypoint Platform and Outcome Based Delivery to minimize adoption risk for our customers.
In that way, to overcome the high barrier to entry, we need to revisit the scope of the debate. More often than not, because of the breadth of the architecture, the debate starts and ends in the trenches of the technical. Implementers argue about containers versus serverless, APIs versus event distribution, monorepos versus segregated source code, and on and on. As a result, the business is conflicted on if and when to invest. If the size of a service, noun/verb separations, whether or not event-based systems, or some other functional thing creates a religious divide, artificial constraints develop that can eventually usurp the actual business outcome.
The debate shouldn’t begin with the technical tenants, a pure academic definition of a microservice, or with perceived required enabling technologies; alternatively, technology decisions should be informed by an internalized understanding of the outcomes desired.
Why this reframe is important to the industry
There is a 800-pound chaos gorilla invited into the board room by the microservices movement, and if not confronted head on, will crush all good-intentioned transformation conversations with the CXO. The chaos, of course, is created by a shift in IT thinking, where the traditional paradigms of speed versus efficiency versus stability are upended.
The incongruence between business objectives and IT priorities is squarely on velocity. Enterprise IT continues to struggle balancing business velocity with long-established and accepted models of efficiency and stability. Even the biggest transformative IT goals have a very weak link to the actual activities of the organization because the balance is an undoubtedly a hard thing to achieve.
In response, enterprises will often try to apply legacy thinking, which requires certain organizational and technical actions to modern architectures, ultimately creating more technical debt, further hindering acceleration – this is the premise for part two of my microservices blog series, which will also detail MuleSoft’s approach to microservices.
In the meantime, check out our whitepaper on microservices best practices.
Matt McLarty contributed to this post.
