Editor's note: Lenny Pruss is a Principal at RRE Ventures, where he focuses on early and expansion stage investments across multiple technology verticals, with a concentration on datacenter infrastructure, developer tools, SaaS and security. You can find him on Twitter and writing on his personal blog.
Since my last post exploring the platform shift happening in today’s datacenter, the question I’ve been asked most often is, “sure, microservices, distributed architectures and containerization might make sense for the Google’s and Facebook’s of the world, but what about everyone else who doesn’t operate at Web scale?”
It’s true that the never-before-seen scale requirements thrust upon this generation’s consumer Internet companies necessitated a redesign of applications and their underlying systems, but scale is only part of the explanation. Rather, the wholesale changes seen at the infrastructure and code levels and across the software development lifecycle were born out of the fundamental desire to win, which ultimately comes down to delivering the best software to millions (or billions) of end-users fastest.
Scalability is top-of-mind, but just as important is creating organizational and software development structures that support innovation, agility and resilience. After all, I would argue that Facebook became Facebook because Zuck was maniacal about 1) maintaining hacker culture to buoy innovation which enabled the company to bring superior software to market faster than the competition and 2) eliminating downtime which he knew would be a growth killer. Without this focus on agility and resilience, Facebook’s ability to scale would be moot.
As enterprise IT has been consumerized, the lessons learned by the IT pros at places like Twitter and AirBnB have made their way to the Fortune 2000. And while enterprise apps don’t necessarily need to scale to even hundreds of thousands of users, business agility and risk mitigation are always top-of-mind strategic initiatives for CIOs. It follows that as every organization becomes a software organization, competitive advantage will be characterized by companies’ ability to innovate, bring product to market faster and navigate risk.
So, how and why does this relate to the adoption microservices in the enterprise?
To level set, microservices implies an architectural choice to build and deploy applications as suites of discreet, modular services, each running its own process with a minimal amount of centralized management. Microservices encourage devs to decouple software into smaller, functional components with the expectation that they fail but don’t bring down the entire app. This, at least in theory, results in applications that are highly available, faster to build and easier to maintain. And consequently, adopting this architectural paradigm enables organizations of all sizes to innovate faster and mitigate risk. To fully appreciate this, it’s helpful understand how enterprise applications have been traditionally built and deployed and why and how this has evolved.
The Challenge of the Monolith
Enterprise app architecture hasn’t fundamentally changed for decades. Most apps are built using the three-tier model which became the dominant methodology in the client/server era. The idea is to split applications into independent, functional code bases consisting of the front-end (presentation tier), the back-end (logic tier) and data storage (data tier). See below for more details:
However, there’s a common saying that goes something like, “every successful application is an architectural nightmare.” Problems arise when systems become too big and unwieldy. The reason being that as the application grows and features, integrations, etc. are added, it’s not uncommon for the code base to balloon to millions of lines of code.
There’s nothing inherently flawed with this; far from it. However, in a today’s world where scalability is table stakes and new releases are expected weekly or daily, managing these giant monoliths becomes a…nightmare. Any change, no matter how tiny, to any module requires rebuilding and testing the entire application. This, in turn, creates downtime, which we know is a killer. Moreover, because the functional components of the application are packaged together as a single unit, the only way to respond to changing levels in user demand is to scale the entire application; another giant headache.
The Promise of Microservices
The concept of building applications as series of composable, modular services is nothing new, dating back as far as the first UNIX operating systems. However, two more recent phenomena explain the uptick in adoption.
First is the ascension of open source software and the corresponding comfort of devs integrating external libraries and APIs into their applications. Second is the rise of containers – namely Docker – which offer a light-weight form of virtualization making applications fast and portable across infrastructure. The beauty of containers lies in this portability and the idea of “code once, run anywhere.” Because containers hold the application logic and all of its dependencies, running as an isolated process, they execute the same in any environment. This creates parity between dev and production, and enables developers to confidently break up apps into discreet chunks knowing they’ll run the same from their terminal to test to production. Suffice to say, containers have been a key enabler of microservices adoption.
You can see from the chart below that interest in microservices has grown in lock-step with interest in containers.
So what are the actual benefits of microservices architecture?
A few weeks ago I had the opportunity to visit with Mike Bryzek, co-founder and CTO of Gilt. Mike and his team are one of the most forward-looking technical organizations in the world, let alone New York. They were early adopters of continuous delivery methods and were successfully using Docker containers in production almost a year before Docker released v1.0. Today, Gilt’s platform is composed of over 400 unique applications, spanning the gamut from pure RESTful APIs to full stack databases and applications.
The primary goal of this massive technical transformation was to become a product-centric, developer-driven organization. To do so meant to enable individual tech teams across Gilt to drive innovation as quickly as possible, providing isolation for each team which, in turn, enabled safe iteration. Further, Mike characterized the shift to microservices as enabling three organizational initiatives:
Growth – Innovation drives growth; organizations should strive to maximize opportunities to innovate. Microservices enabled Gilt to create self-contained teams that are responsible for their discreet application. Test and QA are performed within each team who then also determines release cycles, thereby owning the end-to-end product experience. This sense of ownership, in turn, drives quicker decision making and higher levels of innovation. Finally, empowering developers has proven to be a key selling point in attracting top technical talent.
Agility – Gilt’s platform is composed of 400+ independent services, implying the organization can release and respond to bugs and feature requests faster.
Risk – Gilt characterizes the expected cost of risk as follows:
R = Probability(bad event) * Cost(bad event) * Duration(bad event) where bad event means anything degrading the customer experience. Microservices, if designed properly, provide significant isolation. As a result applications are built such that any and all dependencies between services are remote with the expectation that dependencies will fail. Whereas in a monolith a bug can bring down the whole app (“cascading failure”), in a microservices architecture only the compromised service goes down. As a result “bad events” are not so bad, so risk “R” is minimized.
There are advantages to adopting microservices in your organization that go far beyond scale, but let’s be clear: microservices are not a panacea for all that ails your software org and come with added complexity. Instead of managing across three or four tiers and, you’ll have dozens or hundreds of disparate services to build, test, deploy and run, likely in polyglot languages and environments. This creates significant operational and technical overhead.
From an investor’s standpoint however, this also creates immense opportunity. Microservices represents not only a shift at the code and infrastructure levels of how software is designed and deployed, but also an organizational shift in how software development pipelines are constructed and managed. Therefore we’re likely to see not only a new set of tools to manage applications through dev, test and production, but also a new organizational tool kit for managing people and processes. In my mind, this trend promises to produce dozens, if not hundreds, of exciting new companies.comments powered by Disqus