Much has been said recently about how digital “unicorns” owe much of their ability to deliver, iterate, pivot and scale to microservice architectures built using containers and APIs. This, in turn, has led to some backlash, with sceptics questioning the broader business value of this approach and implying that microservice architecture is essentially a fad.

While it’s always good to be a little skeptical about new tech trends, this reaction is, frankly, shortsighted. Various myths have developed around the perceived limitations of microservice architecture, which have led some to underestimate the potential business value of microservices. So, let’s see if we can’t debunk a few of those myths.

Microservice Myth #1: This Container Business is a Fad

In common usage, the terms “microservice” and “container” are sometimes used almost interchangeably. This is an oversimplification of both the range of uses for container technology and the architectural requirements for deploying microservices. Nevertheless, it’s true that containers represent an essential component in this kind of architecture.

The idea that the container is a new phenomenon—and one that will not last—is certainly shortsighted. Firstly, containers far predate microservices. The type of process isolation that containers provide can be traced back to the 1970s and something called chroot. The IT world has been trying to crack this nut ever since, commonly via virtual machines (VMs).

What’s new about the container paradigm is that it is a uniquely effective and sustainable approach to process isolation. Docker and similar Linux containers provide by far the best implementation to date. They are smaller than VMs, support any language and run across the three primary operating systems—all good indicators that they will be around for some time.

Microservice Myth #2: Microservice Architecture is Just SOA Repackaged

Service-oriented architecture (SOA) is an enterprise IT paradigm that gained a lot of traction in the early 2010s but has since fallen somewhat out of favor. In SOA, core functionality is made available for use across a range of different applications via interfaces known as “web services”, which are similar to the APIs used in microservices.

So, is this just SOA trying to sneak in through the back door? Not really. Microservice architecture is a technique for breaking down an application into discrete components, which operate independently but form a single coherent app. Therefore, you could build a service for SOA out of microservices but not vice versa.

Microservice Myth #3: Containers are Good for New Apps but That’s All

Sure, containers can be great for building new applications. But it should be a certain type of application, ideally one built from the ground up using microservices integrated via APIs. For traditional, “monolithic” enterprise applications, using containers is somewhat beside the point and doesn’t really add much value.

This takes us back to the relationship between SOA and microservices. Both upset the monolithic paradigm of enterprise architecture by using REST interfaces to integrate loosely-coupled components. Therefore, it would be quite possible to introduce containers into existing SOA services. Indeed, it could be a great way to start your microservice journey.

Microservice Myth #4: Microservices Only Work for SaaS Applications

It is true that using microservices, containers and APIs is a great way to build web-based applications on the software-as-a-service (SaaS) paradigm. In SaaS, you can really take advantage of the benefits that such a container-based approach offers for maximizing development velocity.

However, it’s simply not true that the benefits of containers are limited to SaaS. Some of those unicorns have built pretty much everything with microservice architecture. While using containers for on-premises applications may require some additional tooling, this is no reason to miss out on the business benefits of a microservice approach.

The True Value of Microservice Architecture

All of which begs the question: What are the business benefits of microservices? At a high-level, microservice architecture provides a range of technical benefits that contribute to development velocity and product quality in software projects, while also contributing to overall business agility. Let’s drill down into some specific technical benefits, to see how this works.

A microservice-based approach makes it possible to build applications from multiple components, using whatever programming language best suits the functionality required from any given component. This leads to higher-quality software products. It also increases development agility and allows developers to experiment with different approaches.

Microservice architecture also helps maximize deployment velocity and application reliability by making it possible to maintain a consistent environment across development, testing and production. Essentially, if something works on a developer’s computer, it’s going to work in the real world—which helps you be quicker to market with more reliable products.

This also helps non-developers on the team. In the past, devs might have had to set up shadow applications, so that other team members could see work in progress. With containers, it’s much simpler to download and execute the latest build of an app. Again, this can significantly streamline the process of getting high-quality apps to market.

A microservice architecture approach is ideal for the kind of continuous delivery expected in the age of DevOps. Application components can be replaced in seconds, ensuring little—or even zero—downtime for users. Once new features are in production, troubleshooting is simplified and the disruption involved in fixing any issues identified is minimal.

Myths Dispelled, Lessons Learned

In a sense, the myths surrounding microservices and containers are useful because—in dispelling them—we must inevitably touch upon the technical and business value that microservice architecture offers to software-focused enterprises. And while this approach will have a different value for each unique use case, the broad benefits should now be clear.