Microservices: what they are and why your business should care

The enterprise software landscape is littered with buzzy technologies. We've written about plenty of them, be it blockchain, low code development, or other emerging trends that are

changing the way we work. One new buzzword you may not have heard of before is "microservices." That's by design. Microservices are a different way to architect software based

on a set of interwoven modular components rather than the traditional idea of a "monolith"—an application made up of one ever-growing mountain of code. Microservices-based apps

don't look any different from the user interface (UI) side, whether it's in a complex data center app or a web or mobile app hosted on scalable cloud infrastructure. The reason

businesses should care about microservices is that, behind the scenes, the architecture can help your development and IT teams work and innovate faster, manage infrastructure, and reduce the

cost and complexity of adding new features and functionality to an app. Al Hilwa, Program Director for Application Development Software Research at IDC, explained how he would pitch

microservices to an exec while keeping in mind both the cultural and tech challenges. "When building new systems, probably the key point is to recognize that a single microservice

should be built by a small team," said Hilwa. "Secondly, a tolerance of diversity in programming languages and developer workflows is often implied by the independent nature of an

overall microservices culture. The main pitch to an exec is to build software incrementally using small teams, with each building a coherent module with a published interface. The advantage

is that the independent modules can be evolved at a much faster pace independently as long as the published [application programming interfaces] APIs are managed in an organized way."

MORE FROM PCMAG WHAT ARE MICROSERVICES, REALLY?Hilwa authored a 2015 IDC report entitled, "The Emergence of Microservices as a New Architectural Approach to Building New Software

Systems." In the report, he defines microservices as a granular software architecture where app components are designed and evolved independently to meet API-defined interoperability

requirements (meaning, tied back into the app as a whole). Microservices don't exist in a vacuum, though. A new architecture requires strong organizational support and a shift in IT

culture. Microservices also isn't defined by any one specific technology but as the evolution of the longstanding concept of service oriented architecture (SOA) augmented by the advent

of containers and the rise of automation through development approaches such as continuous delivery (CD) and continuous integration (CI). "Organizations using microservices today are

typically motivated by the desire for a faster pace of service evolution," said Hilwa. "Thus, in most such cases, microservices are using CI/CD automation to a great degree.

However, the piece of actual deployment may be different between the services. I think the key is to take a good look at the internal culture and be sure that you are willing to tolerate

greater decentralization and diversity in the technology stack." By "internal culture" Hilwa is largely referring to DevOps, a philosophy that combines software development,

IT operations, and quality assurance (QA) into a single, collaborative workflow. DevOps software startup HashiCorp and its founders have long been proponents of microservices. The company,

which recently secured a $24 million round of Series B funding, counts companies such as Cisco, DigitalOcean, Mozilla Pinterest, and Stripe among its open-source users and enterprise

customers. Microservices are core to how HashiCorp approaches DevOps infrastructure development and app workflows across its popular open-source tools and growing enterprise product suite.

Armon Dadgar, CTO and co-founder of HashiCorp, broke down the difference between monoliths and microservices by using a simple analogy: Amazon and eBay. "Think about Amazon and eBay as

single applications. From the end user perspective, they look similar but, behind the scenes, the companies took opposite approaches in how they built and architected their

applications," said Dadgar. "Amazon from the beginning has been a bundle of microservices; it acts as a single app. But if you take the search, the product catalog, shopping cart,

invoices, [and] order flows, and split those functions, the two applications are running on different machines." The Amazon analogy also extends to how Amazon itself is structured.

Dadgar explains technology approaches like microservices as being tools to support the larger process movement toward DevOps. Jeff Bezos's "Two Pizza Rule" works out so that

only between five and eight people are on any given Amazon team. If the team gets larger, then it splits into two. Amazon's organizational hierarchy starts mapping toward what Dadgar

described as a "decomposition of functionality." Separated on both an organizational and a modular architecture level, every team then has the ability to develop and experiment

more freely, without the need to coordinate on every change—all the while still functioning as part of a single cohesive app. "eBay took the monolithic approach; they built all of eBay

as a long, 50-million line of code application," said Dadgar. "The microservices approach is more painful in the beginning because the problems of modularity and interoperability

are ones that don't exist in a monolith. But things start breaking down when the app grows too large. In a monolith, there is no decomposition. "Think about hundreds or thousands

of developers collaborating on a single codebase and trying to coordinate. A QA team adding functionality on one side of the application could break something way over on the other side

because there's no clear separation of roles and responsibilities. To fix it, you start needing more and more coordination between the project managers and a QA process that can take

weeks and bottleneck development, no matter how fast that team works. It's too many cooks in the kitchen." CONTAINERS AND MICROSERVICES IN A DEVOPS WORLDThe way in which your

business implements a microservices architecture will go a long way toward determining whether or not the investment pays off. Microservices are a lot of work upfront, particularly in the

API integration it takes to make sure all of the services talk to each other. Hilwa explained that it's even more complicated when trying to integrate microservices into an existing

system; he recommends that enterprises build new systems whenever possible rather than re-architecting a legacy monolith app for microservices. "Traditional system architectures

typically involve large, complex database systems of record with elaborate normalized schemas," said Hilwa. "Factoring such systems into smaller components with their own

independent systems requires a lot of database design work and effectively rewriting most of the core application logic. This is generally cost- and time-prohibitive in most cases." If

you do re-architect a legacy app, then Hilwa advises you do it incrementally. Though even more important than the API integration, microservices don't work without the DevOps culture

behind it. HashiCorp's Dadgar said that, when it comes to the larger umbrella of DevOps, microservices become a tool to facilitate a larger process shift toward fundamentally changing

the workflows by which we deliver apps. He pointed to the Tao of HashiCorp laid out when he and co-founder Mitchell Hashimoto started the company: simple, modular, and composable.

"DevOps in some sense is an even more overloaded term than microservices," said Dadgar. "But a business is composed of people with different specialties of knowledge:

developers, operators, security officers. And then you have process, the way you organize those people. Then you have the tools to support that process, which is where microservices and

containers come in." Containers, popularized by the open-source explosion of Docker, are far from being the only tool enterprises can use to facilitate microservices. IDC's Hilwa

said containers are used in modern apps as part of the CI/CD workflows and, in some cases, while deploying to production. But he said microservices can leverage virtual machines (VMs) as

well, without the need for containers. That said, when it comes to the ways in which business clouds are evolving, Docker containers and microservices are a potent tooling combination

that's being embraced by business of all shapes and sizes—from startups such as HashiCorp to enterprise giants like Oracle. HashiCorp's Dadgar said containers are the convenient

means by which Dev and Ops (and, by association, different teams and services) communicate with each other. "What is the artifact we're passing between the developers and

operators? What are we flowing thorough and building around? Containers are a convenient unit to pass around," said Dadgar. "Think about a global enterprise shipping product around

the world. Whether it's a freighter ship, a cargo train, or a truck, it's the same unit flowing through the whole system." DevOps and microservices are still far from

widespread enterprise adoption but the market is only growing. According to the IDC report, the microservices architecture will enter a maturation phase over the next five years. This

maturity will happen on the heels of DevOps culture reaching 50 percent of organizations by 2020, the continued evolution of software automation tools, and the domination of cheap, scalable

cloud infrastructure provided by the likes of Amazon Web Services (AWS) and Microsoft Azure. Dadgar said that, even with the small fraction of enterprises embracing DevOps and microservices

at the moment, HashiCorp is already vastly oversubscribed. It hit its first seven-figure revenue after only nine months of enterprise sales, on top of an open-source community on GitHub of

several million monthly active users. Microservices are only a part of HashiCorp's workflow app tooling pipeline and larger DevOps infrastructure roadmap. But the modularity and

interoperability beneath everything the company builds has fueled the meteoric rise of one of the hottest software startups in Silicon Valley. "Four years ago when we started, we would

go into meetings and pitch our vision for how infrastructure would be managed," said Dadgar. "We weren't exactly laughed out of the room; we knew it was early on. But now our

tools like Terraform are on their way to becoming industry standards. What we'll see is a domino effect of competitive pressure and, in the long term, our role will be working with CIOs

and CTOs to understand the process shift they need to take. "Think about Toyota back in the day," Dadgar continued. "You had a bunch of car companies building products but

the cost was higher than it should be. Toyota didn't reinvent what a car was; they were just more rigorous and incremental about the process, and went from laughingstock to powerhouse,

forcing the rest of the industry to adopt the same set of practices to remain competitive. Right now, we have industry leaders asking how they can get a competitive edge, and their answer is

to adopt the practices of the Googles and Amazons of the market. At some point, it will hit a critical mass." This article originally appeared on PCMag.com.