Lenny For Your Thoughts

Geoffrey Moore’s technology adoption lifecycle is gospel for tech marketers. The model describes the path of diffusion for discontinuous innovations and explains how ecosystems emerge and coalesce around IT winners.

Moore and his work have been top of mind the last couple years now as we’ve observed the rise of and hype around Linux containers.

Containers are the next evolutionary leap forward from hypervisor-based hardware virtualization, offering a way to package an application with a complete filesystem that holds everything it needs to run: code, runtime, system tools and libraries. Containers are smaller, faster, more portable and more developer-friendly than their virtual machine predecessors. In that, containerization represents a paradigm shift in how systems and applications are built, deployed and managed.

In the tech sector, paradigm shift is a euphemism for opportunity, and, appropriately, we’ve seen a flood of companies come to market with their flavors of tools and platforms to ultimately enable organizations to run container-based, cloud-native applications.

The rapid onset of this innovation cycle has been exacerbated by a trend toward faster release times. VMware got buyers comfortable with a new vSphere release every year. Then the OpenStack Foundation promised releases every six months. With Docker, CoreOS and others we’re seeing releases every three months, if not faster, as each vies to become the standards bearer (if only judged by press mentions or Github stars).

Consequently, lost in this shuffle have been customers who are struggling to keep up.

To assess the state of container adoption, it’s helpful to evoke Moore’s model. Let’s take a look through that lens:

Innovators are “willing to take risks, have the highest social status, have financial liquidity, are social and have closest contact to scientific sources and interaction with other innovators. Their risk tolerance allows them to adopt technologies that may ultimately fail. Financial resources help absorb these failures.” These are the Googles and Twitters of the world who have been running containers as part of distributed systems architectures years before Docker was open sourced. These companies battle test approaches and provide blue prints for the broader market but operate at a scope and scale that is many years ahead of it.

Early adopters are “individuals with the highest degree of opinion leadership among the adopter categories. Early adopters have a higher social status, financial liquidity, advanced education and are more socially forward than late adopters.” These ‘gear-heads,’ are the developers and infrastructure engineers who have been test-driving container technology because it’s the cool, new thing. These devs are evangelists and core open source contributors and are responsible for driving standards, best practices and use cases. Early adopters are gatekeepers for new technologies in organizations and drive bottoms-up adoption.

However, bottoms-up adoption will only take a new innovation so far, which brings us to Moore’s famous chasm. The chasm is a gap that exists between the first two adoption cohorts and the early majority, where buyers are described as “pragmatists in pain,” and adoption decisions are driven by business need.

The chasm is precisely where we stand today: developer interest continues to surge as standards and best practices are beginning to emerge, but the industry is still waiting on the applications and business cases which are requisite to drive more mainstream adoption.

Given that we’re at this critical inflection point, we urge companies competing in this market to take the pragmatic, customer-centric view. Ultimately, this all relates to a potential brewing problem in the formation of any new ecosystem or value chain: when the rate of innovation outpaces the rate of customer adoption companies fail.

Over the last several years, we’ve seen the emergence new application architecture – dubbed “cloud native” – that is highly distributed, elastic and composable with the container as the modular compute abstraction. With that, a new breed of tools has emerged to help deploy, manage and scale these applications. Cluster management, service discovery, scheduling, etc. – terms that previously were unfamiliar or, at best, reserved for the realm of high-performance computing – are now becoming part of every IT organization’s lexicon. As the pace of innovation continues at breakneck speed, a taxonomy to help understand the elements of this new stack is helpful.

The “Cloud-Native” Ecosystem presentation is the consequence of many conversations with developers, CIOs and founders who are playing a critical role in shaping this new application paradigm. It attempts to define the discreet components of the cloud-native stack and calls out the vendors, products and projects that comprise the ecosystem.

Note, this is an ever-evolving document that’s meant to be collaborative and is by no means a hardened or exhaustive industry landscape. If you have suggestions, edits and/or know of products or companies that should be included please don’t hesitate to get in touch.

VisiCalc for early PCs. E-mail for the Internet. SMS for mobile. Every major tech platform we’ve seen has had the benefit of a “killer application” that transformed it from “toy” or “cool project” into an indispensable, mainstream product. 

Now that that we’re in the midst of what looks to be another major platform shift in the datacenter – this time with the layer of abstraction moving from physical infrastructure via the hypervisor to the OS via containerization – talk has centered around Linux containers and whether they represent a paradigm shift in how we build and deploy applications or if they are simply another instrument in the DevOps toolkit.

The relevant analog for mapping out the fate of containerization seems to be virtualization. Charting VMware’s history provides a hint of how container adoption and ecosystem development may unfold, but it’s far from a perfect corollary.

In 1999, VMware released Workstation which let developers run multiple virtual machines with different operating systems locally. This solved an acute developer pain around building applications that would work across different OS’s and environments. A couple years later the company entered the server market with ESX and vMotion which enabled live migration; a fancy way of saying you could move running VMs between physical hosts without taking the whole application down. The VMware toolchain quickly spread through dev/test as developers could now build and test applications for different environments and then deploy them with a few clicks confident they wouldn’t break production (assuming proper config files were installed; hence the rise of config management tools like Chef, Puppet, etc.). In addition to this grass-roots, bottoms-up adoption, virtualization benefited from CIO-led, top-down initiatives to eliminate IT sprawl, improve server utilization and consolidate datacenters. The result, depending on who you ask today, is that anywhere from 75-90% of x86 workloads are virtualized.

Hardware virtualization, then, literally digitized the analog task of racking servers. It represented a step-function improvement over how IT could be provisioned and administered and how applications could be tested and deployed.

Now we’re seeing similar developer-led adoption of containerization, and sure enough there are myriad reasons why adopting Linux containers makes sense: from enabling application portability across compute and cloud infrastructures, to streamlining your deployment pipeline to liberating your organization from the VMware tax. But as we sit here today, many (including myself) contend that containers don’t represent as radical a step-function improvement over the tools used to solve similar problems as VMs did in the early 2000s. Nor is there a similar top-down, CTO-/CIO-led initiative to catalyze adoption. Consequently, what we’re looking for is the killer application that unlocks the value of containers for the mass-market. 

What might those killer apps be? Here are three likely candidates:

“Dropbox-ized” dev environments – One of the most nagging engineering pains is provisioning and replicating developer environments across the org and then maintaining parity between those environments with test and production. Containers offer a way to encapsulate code with all of its dependencies allowing it to run the same irrespective of underlying infrastructure. Because containers share the kernel user space, they offer a more lightweight alternative to VM-based solutions like Vagrant, thereby letting devs code/build/test every few minutes without the virtualization overhead. Consequently, orgs can create isolated and repeatable dev environments that are synced through the development lifecycle without resorting to cloud IDEs which have been the bane of many devs’ existences.

Continuous deployment – As every company becomes a software company at its core, faster release cycles become a source of competitive advantage. This was highlighted in the recent Puppet Labs State of DevOps report, where it was revealed that “high performing IT organizations” deploy code 30x faster and have 200x shorter lead times leading to 60x fewer failures than their “low-performing” peers. It’s no surprise, then, that organizations are embracing continuous delivery practices in earnest. Containers, because of their inherent portability, are an enabler of this software deployment model. Instead of complex scripting to package and deploy application services and infrastructure, with containers scripts shrink to a couple lines to push or pull the relevant image to the right endpoint server and CI/CD becomes radically simplified.

Microservices – Microservices architecture refers to a development practice of building an application as a suite of modular, self-contained services each running its own process with a minimal amount of centralized management. Microservices itself is a means not an end, enabling greater agility (entire applications don’t need be taken down during change cycles), speed-to-market and code manageability. Containers, offering lightweight isolation, are the key enabling technology for this development paradigm.

Ultimately, containerization allows companies of all sizes to write better software faster. But as with any platform shift, there is a learning curve and broad adoption is a function of ecosystem maturity. We’re just now beginning to see the emergence of best practices and standards via organizations like the Open Container Initiative and the Cloud Native Computing Foundation. The next step is for a hardened management toolchain to emerge which will allow devs and companies to begin building out powerful use cases. And it’s with those applications that we will start to unlock the power of container technology for the masses.

This article first appeared on ContainerJournal.com and can be found here.

Warren Buffet’s right-hand man and Vice Chairman of Berkshire Hathaway, Charlie Munger, credits much of his and the Oracle of Omaha’s success to an adherence to mental models, particularly in their power to guide investment decisions. Munger, in his 1994 commencement address at USC Marshall School of Business, elaborated:

…the first rule is that you can’t really know anything if you just remember isolated facts and try and bang ‘em back. If the facts don’t hang together on a latticework of theory, you don’t have them in a usable form.

You’ve got to have models in your head. And you’ve got to array your experience—both vicarious and direct—on this latticework of models…

Mental models help investors make heads or tails of fact patterns to problem-solve quickly; something that’s become increasingly important as the velocity of companies formed and funded has accelerated to breakneck speed.

Most models tend to be deductive, stringing together premises believed to be true to arrive at a logical conclusion. For example, given a startup with little or no historical performance, VCs will default to evaluating the company across its market, management team and product and gauge alignment among those variables. If each variable and alignment among them is strong then they likely proceed with the investment.

Figure 1: Market-Management-Product Prism

Another approach is inductive. This involves starting from a specific observation and moving towards broader generalizations that can be reapplied to the specifics of a given opportunity. It goes something like this: company X and Y exited for over $1 billion each and had green logos (specific observation). Therefore companies with green logos yield better outcomes (generalization). Company Z has a red logo. Pass.

Clearly the previous example is an oversimplification, but it points to the fact that inductive reasoning can be dangerous when generalizations become dogma. After all, there are exceptions to every rule and often it’s those very exceptions that become breakout successes.

However, when used appropriately inductive models can be powerful short-hands. In particular, I’ve found that enterprise IT lends itself nicely to this approach. Why? Because by its nature the enterprise IT stack is a dynamic organism where interactions between stakeholders (customers, suppliers, partners, etc.) are tightly coupled and tend to repeat in cycles. Consequently, patterns emerge which can be mapped on new opportunities.

With that, I’d like introduce a model that I’ve found helpful in sorting through enterprise opportunities efficiently. This model holds that there are three types of winners in enterprise IT: the Market Maker, the Surfer and the 10x’er. Generally, if a startup doesn’t fall in one of these buckets, it earns a pass from me. Let’s unpack this by exploring the characteristics of each type of winner in more detail:

The Market Maker

Market Makers bring a discontinuous innovation to market and thereby become synonymous with the technology they spawn. Think Cisco with LAN switching and Oracle with relational databases.

Note that these companies do not have to be responsible for the original technical innovation, but most often are the ones who commercialize it successfully. SaaS was previously called ASP (application service provider) before Salesforce starting banging the “No Software” drum. Virtualization was invented at IBM in the late 1960s before VMware brought ESX to market in 2002. Similarly the earliest iteration of containers have lived in open source Linux code for decades before Dotcloud became Docker.

The defining characteristic of these companies is that they catalyze a platform shift and, often, an accompanying outbreak of commoditization that makes its way down the tech stack.

The Surfer

Surfers leverage a market dislocation catalyzed by a more general secular trend or by a Market Maker, and take advantage of unique conditions to bring innovations to market that serve an emerging customer need.

Cloudera developed a distribution of and tooling for Apache Hadoop at a time when unstructured data growth began to outstrip the capacities and capabilities of existing data warehouses and as commodity hardware invaded datacenters. Pure Storage was founded when the price/GB of consumer-grade flash had declined sufficiently to become acceptable for deployment in high-performance enterprise workloads. New Relic correctly identified a gap in the application performance monitoring market as Ruby on Rails usage exploded and more and more workloads moved from on-prem to AWS.

Surfers most often win by taking advantage of an industry-wide technical leap forward in their own product or by resolving bottlenecks that preclude customers from capitalizing on an overarching secular trend. In doing so, the innovators in question position themselves to ride the cresting tsunami that washes over the industry.

The 10x’er

The10x’er may not have the benefit of a unique market opportunity, and, in fact, is often operating in a decelerating market dominated by one or a handful of incumbents.  However, these companies have a core innovation that enables them to bring to market a product that is an order of magnitude superior to incumbent vendors’ solutions along one or multiple key customer dimensions (performance, cost, time-to-value, etc.).

Tableau spun out VizQL technology out of Stanford which enables data visualizations with simple drag and drop functions, empowering line-of-business to benefit from sophisticated BI. MongoDB became the fourth most widely adopted database in the world in only seven years by simplifying database provisioning and management for developers. More recently, Slack has up-ended enterprise collaboration by creating a seamless, light-weight messaging experience where IRC and e-mail fell short.  

The bottom-line with 10x’ers is they represent a tangible and significant ROI benefit for customers relative to incumbent solutions.

*   *   *   *   *

The delineations between these classes of winners are far from absolute – a 10x’er could very well be riding a wave that can ultimately help crown them a Market Maker – and, in fact, the most successful companies will have several forces working in their favor.

Mongo flattened the learning curve for developers to get up and running with a database, but also benefited from the broader NoSQL boom. In doing so, Mongo has become the poster-child for non-relational databases. Docker’s adoption has been buoyed by a shift to distributed application architectures and the DevOps, and accompanying continuous deployment, wave. Similarly, VMware benefited from the general trend around IT consolidation.

The takeaway is that that great companies are not built in a vacuum. The tech stack is an ever-evolving, dynamic system where a small change in one part of the stack can send shockwaves through the entire ecosystem. Correspondingly, at a given moment in time there exists a set of conditions which creates opportunity. Having a set of mental models you can lean on as an investor allows you to spot and capitalize on those opportunities faster.

DockerCon tore through SF last week and the feeling is that we are at the apex of the hype cycle. Fear not, we at Redpoint are here to (attempt to) distill signal from noise. Here’s a recap of the top story-lines as we see them along with some thoughts… 

You down with OCP…?!

What happened: Docker and CoreOS got on stage, kissed and made up and announced the Open Container Project (‘OCP’). OCP is a non-profit governance structure, formed under the Linux Foundation, for the purpose of creating open industry standards around container formats and runtime. You may remember back in December ’14 CoreOS made headlines by announcing rkt, an implementation of appC, the company’s own container image format, runtime and discovery mechanism, which, in contrast to Docker’s libcontainer, was open, both technologically and in its development methodology. Then in May at CoreOS Fest, CoreOS’s inaugural conference, momentum for appC appeared to be gaining steam and image format fragmentation seemed inevitable. Instead, a mere seven weeks later, it appears Docker and CoreOS are willing to put aside differences to work together (and with the likes of Google, Amazon, Microsoft, Red Hat, and Intel) towards an open container spec.

Our take: The big winner is the broader container ecosystem. There are at least half dozen credible alternatives to Docker’s libcontainer emerging, and while competition is generally a good thing, the introduction of multiple different image formats creates ecosystem fragmentation which constrains customer adoption and broader momentum. Consolidation around the OCP spec will ensure interoperability while enabling vendors to continue innovating at runtime. More importantly, by agreeing on low-level standards, the community can move on to solve higher-order problems around namespaces, security, syscalls, storage and more. Finally, the loser in all this appears to be the media now that there’s, at very least, a ceasefire in the Docker-CoreOS war.

Docker Network and more dashed startup dreams

What happened: In early March of this year Docker acquired Socketplane to bolster its networking chops and the fruits of that acquisition were displayed in a new product release called Docker Network, a native, distributed multi-host networking solution. Developers will now be able to establish the topology of the network and connect discrete Dockerized services into a distributed application. Moreover, Docker has developed set of commands that enable devs to inspect, audit and change topology on the fly – pretty slick.

Our take: The oft-forgotten element to enabling application portability is the network – it doesn’t matter if your code can be executed in any compute substrate if services can’t communicate across disparate network infrastructures. Docker’s “Overlay Driver” brings a software-defined network directly onto the application itself and allows developers to preserve network configurations as containers are ported across and between datacenters. The broader industry implication here is that Docker is continuing to platform by filling in gaps in the container stack. The implication for startups? You will NOT build a large, durable business by simply wrapping the Docker API and plugging holes.  

Plug-ins and the UNIX-ification of Docker

What happened: Docker finally capitulated to industry demands and announced a swappable plug-in architecture and SDK which will allow developers to more easily integrate their code and 3^rd-party tools with Docker. The two main extension points featured were network plugins (allowing third-party container networking solutions to connect containers to container networks) and volume plug-ins (allowing third-party container data management solutions to provide data volumes for containers which operate on stateful applications) with several more expected soon.

Our take: For a year now there’s been an uneasy tension between Docker and the developer community as Docker became less a modular component for others to build on top of and more a platform for building applications in and of itself. The prevailing fear was that in Docker’s quest to platform, it would cannibalize much of the ecosystem, create lock-in and stifle innovation. Docker’s party line has always been that “batteries are included, but swappable,” implying you can use Docker tooling out of the box or swap in whatever networking overlay, orchestrator, scheduler, etc. that works best for you.  The plug-ins announcement is a step in that direction as it appears Docker is finally not only talking the UNIX philosophy talk, but walking the walk.

Container Management Mania

What happened: Whether it’s called “containers as a service,” “container platform,” “microservices platform” or plain old “PaaS”, it’s clear that this is the noisiest segment of the market. We counted no less than 10 vendors on the conference floor touting their flavor of management platform.

Our take: Everything old is new again. The evolution of container management is analogous to that of cloud management platforms (“CMPs”) when virtualization began invading the datacenter. There were dozens of CMPs founded between 2006 and 2010 the likes of Rightscale, Cloud.com, Makara, Nimbula, etc. Several have since been acquired for good, but far from great, outcomes, and the sea is still awash in CMP vendors competing feature for feature. Correspondingly as the compute abstraction layer moves from the server (hypervisor) to the OS (container engine), a new breed of management platform is emerging to provision, orchestrate and scale systems and applications. Will the exit environment this time around mirror the previous cycle?

*   *   *   *   *

Stepping out of the echo-chamber, the big question remains around adoption. There are some technological gating factors that will inhibit enterprise deployments in the short-term – namely persistence, security and management – but the overwhelming constraint holding back containers appears to be general lack of expertise and established best practices. The good news is that these are “when” not “if” issues that pertain to ecosystem maturity, and the steps taken by Docker last week will only help accelerate that process.

With the groundwork laid, we see an exciting year ahead for the container community.  The inevitability of container adoption only feels more inevitable now.  There are many hard problems to solve, but hopefully (fingers crossed) there is now more alignment within the community. Startups and enterprises alike can begin, in earnest, the real work required to drive broad adoption of this technology in datacenters.  Hopefully we will look back a year from now and feel like this was the year that the technology moved beyond the hype phase to real adoption.

A pause from our regularly scheduled programming to announce that I’m thrilled to have joined Redpoint Ventures as a Principal in their early stage group. The move is a homecoming for me – I was raised in the South Bay and went to college in Berkeley (Go Bears!) before shipping out east for a little over five years – and I can’t be more excited to be back!

When I began the conversation with the team at Redpoint, I was already familiar with the firm’s track record with them having backed multiple category-defining companies from A(rista) to Z(uora) with everything including Juniper Networks, Netflix, Pure Storage, Stripe, Twilio and many more in between. But track record in VC is derivative – it’s a byproduct of the people and culture of the firm – and the more I got to know the team and their inner-workings, I found a firm that, in everything it does, is wholly committed to the entrepreneur and helping them build next generation’s great companies. In that, Redpoint is a highly collaborative, tight-knit group that places an emphasis on openness, agility and intellectual honesty and curiosity. Finally, the same level of mentorship and commitment the firm devotes to its entrepreneurs extends to everyone around the table. Venture is an apprenticeship-based business that’s mastered over many years, so it speaks volumes that many of the firm’s Partners started as Associates. All in all, when you put everything together, it couldn’t be a better fit.

Prior to Redpoint, I spent the better part of five years – less a two year sabbatical to grab an MBA – cutting my teeth as an early stage investor with RRE Ventures in New York. At RRE, I was afforded the opportunity to help build the firm’s enterprise platform and in doing so was fortunate to back incredible companies like Datadog and WhipTail and work with some profoundly talented founders. I owe a huge debt of gratitude to the folks at RRE who challenged me to push my thinking and develop a strong perspective as a young VC, and I can’t say enough positive things about the team there as investors, and more importantly, people.

At Redpoint I’ll be working alongside Scott, Satish, John, Tim and Tomasz in the enterprise group, helping technical founders push the boundaries of IT in building the next wave of great cloud and data infrastructure, developer tools, SaaS and security companies. Put simply, the opportunity set in these sectors has never been more promising as there are fundamental changes taking place in, literally, every part of the stack: infrastructure is evolving to mirror an emerging application architecture which is distributed, elastic and highly available made necessary to support the scale of what will be billions of connected users and hundreds of billions of connected devices. With that said, you can find more detailed thoughts on these emerging trends on my blog, and follow me @lennypruss if you’re willing to put up with the occasional Sharks hockey rant. Looking forward to connecting with and getting to know you all – it should be a blast!

Last week I attended the inaugural CoreOS Fest. It was a fantastic event which brought together some of the best minds in distributed systems and celebrated the vibrant open source community CoreOS has fostered. Given this somewhat seminal moment, I thought it’d be a good opportunity to share a few observations from the conference and reflect on the state of industry, so here goes:

The pace of innovation in enterprise IT has never been faster. It’s been just over two years since the initial release of Docker and it’s amazing how quickly an ecosystem has coalesced around Linux containers and, more broadly, distributed systems infrastructure. By any metric – contributors and contributions to open source repos, companies founded and funded, support and partnerships from incumbent infrastructure vendors, etc. – there is a now a fully-formed, distributed computing stack and accompanying value chain. This rapid innovation cycle has compressed release cycles. VMware got the industry comfortable with a new vSphere release every year. Then the OpenStack Foundation promised releases every six months. With Docker, CoreOS and others we’re seeing releases every three months, if not faster. Customers barely have time to blink. There’s an even bigger implication for startups competing in this space: you will not succeed by plugging gaps in the stack – think bigger.

etcd is CoreOS’s crown jewel. While CoreOS itself and Rkt get a lot of the buzz, I’d argue etcd is the company’s most strategic project. A quick refresher: etcd is an open source, distributed key-value store that serves as the backbone and single source of truth of a cluster, coordinating communication and service discovery between nodes and managing cluster state. etcd is a critical building block in the distributed systems stack – CloudFoundry and Kubernetes, for instance, are built on top of etcd – with tentacles that extend down to physical/virtual infrastructure and up to the application; hence why it’s so strategic and was featured in so many session at the conference. For a great primer on etcd check out The New Stack’s write-up here.

We’re no closer to a standard container spec. CoreOS continues to bang the Rkt and Appc drum (“App Container Spec Technical Panel” was the first session after the Day 1 keynote), but it appears that, at least in the short-term, image format fragmentation is an inevitability. Another quick refresher: a container is comprised of an image format, a set of files which specifies all the facilities surrounding a container and includes the bits necessary to execute an application, and the container runtime which defines and manages processes, isolation and the environment in which containers are executed.

In December 2014, CoreOS announced Rkt and Appc as a more open – both technologically and in their development model – alternative to Docker. The issue however, is the introduction of multiple different image and package formats introduces ecosystem fragmentation which slows momentum. As the folks at Red Hat point out, we’re in the early midst of a massive shift from “the traditional model of a single-instance, monolithic, UNIX user space in favor of a multi-instance, multi-version environment using containers and aggregate packaging,” and there are still a lot of moving parts related to namespaces, security, syscalls, dependencies and more that need to be figured out. Given all this, it would be much better for the industry if Docker and CoreOS collaborated on a standardized common spec and image format. That, however, doesn’t seem to be coming soon.

A battle is unfolding over cluster management and orchestration. While a lot has been made of Docker vs. Rkt, the real competition is over who owns the cluster management and orchestration layer. You can see why this layer is so strategic in the following two slides from Google’s Kubernetes Lead Engineer Brendan Burns:

There is a handful of established physical/virtual hardware platforms (AWS, Google Compute, Microsoft Azure, VMware, OpenStack) which promise to be commoditized given the inherent (but still theoretical) portability of containers. The role of cluster managers and orchestrators is to take heterogeneous compute resources (potentially across different clouds) and present them as a homogenous, unified compute substrate. You can think of these tools as a datacenter hypervisor which aggregates all CPUs and then manages resources, schedules tasks and orchestrates application containers. What this implies is there is a platform opportunity at the cluster manager / orchestration layer. Today Mesos (Mesosphere), Kubernetes (Google and CoreOS), Swarm (Docker) and the rest of field are all playing nice; it’s been more co-opetition and true competition, particularly between Mesos and Kubernetes. But as these respective projects and companies mature, you can be certain that lines will be drawn.

But what about the adoption? It appears the rapid pace of development and lack of industry agreement on a standard container spec has come at the expense of the customer. Maybe it was coincidence, but a majority of folks I spoke with at the conference who deployed some CoreOS or container technology were just beginning to experiment. Most often, these tended to by devs and DevOps engineers at mid-stage startups using these tools in conjunction with a continuous deployment initiative or in test/QA environments. With that said, for as nascent as these technologies are, the interest from enterprise buyers is real, and I’m curious to see how CoreOS’s recently announced Tectonic offering does in market.

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:

(Source: Wikipedia) 

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.

Enter microservices…

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:

1.      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.

2.     Agility – Gilt’s platform is composed of 400+ independent services, implying the organization can release and respond to bugs and feature requests faster.

3.     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.

You may not have noticed, but we’re in the midst of another massive platform shift in enterprise computing. We can debate chicken or egg, but I believe this most recent transformation is being driven primarily by requirements placed on modern applications; requirements that are the result of the on-demand, always-on computing paradigm predicated by cloud and mobile. Simply, applications need to be scalable, available and performant enough to reach millions, if not billions, of connected devices and end-users. Infrastructure must mirror these specifications, in kind.

Historically, systems design has ebbed and flowed between periods of aggregation (centralized) and disaggregation (distributed) of compute resources. The most recent evolution, from client/server to virtualized, cloud infrastructure was driven largely by a desire to contain costs and consolidate IT around standards (x86 instruction set, Windows and Linux) form factors (first blade servers, then VMs) and physical locations (emergence of sprawling datacenters and giant cloud vendors). Now we’re seeing the pendulum swing back. Why?

A strong first principle is the notion that infrastructure is beholden to the application. Today, many applications are being built as large-scale distributed systems, composed of dozens (or even thousands) of services running across many physical and virtual machines and often across multiple datacenters. In this paradigm, virtualization – which really dealt with the problem of low physical server utilization – doesn’t make much sense. In a highly distributed, service-oriented world, VMs come with too much overhead (read more on this here). Instead of slicing and dicing compute, network and storage, the better solution becomes to aggregate all machines and present them to the application as a pool of programmable resources with hardware-agnostic software that manages isolation, resource allocation, scheduling, orchestration etc. In this world, the datacenter becomes one giant, warehouse computer controlled by a software brain.

However, the fact of the matter is that building, deploying and maintaining distributed applications is a highly technical feat. It requires a rethinking of the way applications treat and interact with other applications, databases, storage and network. Moreover, it requires a new toolkit that is central to solving the coordination and orchestration challenges of running systems that span across multiple machines, datacenters and time zones. To help understand what’s taking place, let’s deconstruct this new stack and, along the way, define some other key terms. Note that this is in no way a static, absolute taxonomy, but rather a simplified way to understand the layers that make up today’s application stack.

Layer 1: Physical Infrastructure – Actual servers, switches, routers and storage arrays that occupy the datacenter. This area was dominated by legacy OEMs (EMC, Cisco, HP, IBM, Dell) who are now giving way to low-cost ‘whitebox’ ODMs.

Vendors/Products:

Layer 2: Virtualized Infrastructure – Emulated physical compute, network and storage resources that are the basis for cloud-based architectures. The enabling technology here is the hypervisor which sits on top bare metal infrastructure and creates virtual clones of the server (or switch or storage array) each complete with a full OS, memory management, device drivers, daemons, etc.

Vendors/Products:

Layer 3: Operating System – Host or guest OS that sits atop a virtual or physical host. The rise of Linux has been a key catalyst for the commoditization the OS and physical infrastructure, decoupling applications from hardware. Microsoft with Windows Server is still a dominant player in traditional enterprise.

Vendors/Products:

Layer 4: Container Engine – This is where it starts to get interesting so let’s spend a little more time here. Linux containers offer a form of operating system-level virtualization, where the kernel of the OS allows for multiple user space instances. More simply, if hypervisor-based virtualization abstracted physical resources to create multiple server clones each with their own OS, memory, etc., the type of virtualization enabled by containers is a higher level abstraction of the OS. This begets the necessary degree of isolation and resource utilization to run multiple applications on a single kernel.

The beauty of containers lies in the idea of “code once, run anywhere.” A container holds the application logic and all of its dependencies, running as an isolated process. It ultimately doesn’t matter what’s inside the container (files, frameworks, dependences); it will still execute the same way in any environment – from laptop, to testing, to production across any cloud, at least theoretically. This enables application portability, which, in turn, commoditizes cloud infrastructure altogether.

Docker has become synonymous with containerization by making Linux Containers (LXC) user-friendly. The important thing to note is that container technology is made up of two fundamental components: the runtime and the container image format. The runtime is effectively a high-level API that runs processes and manages isolation. The image format is a specification for a standard composable unit for containers. In recent months we’ve seen several container runtimes and specs come to market which has caused a stir. I’m sure we’ll continue to see more.

Vendors/Products:

Layer 5: Scheduling & Service Discovery – Tools that solve and automate the coordination challenges related to breaking up and running applications across multiple nodes and datacenters. Schedulers interface with the resources of the cluster and are responsible for providing a consistent way to intelligently place tasks based on those resources. Service discovery tools manage how processes and services in a cluster can find and talk to one another. This area is largely greenfield but the ecosystem has coalesced around a few well known projects like Mesos, etcd and Zookeeper.

Vendors/Products:

Layer 6: Orchestration & Management – Tools that automate the deployment, scaling and management of applications and infrastructure.  This is what some refer to as the management plane. These tools enables devs, DevOps and sysadmins to maintain applications across clusters. This area is greenfield as new solutions are being adapted to support containers running across distributed environments. Those who win here will reap the greatest rewards. In addition to purpose-built products, there are a number of companies here who are creating application lifecycle management platforms optimized for containers including Deis, Flynn, Terminal, Tutum and many others.

Vendors/Products:

A few other helpful definitions:

Distributed System – A computing system consisting of a collection of autonomous nodes connected through a network and software/middleware which enables nodes to coordinate tasks and share resources of the entire system. The principle of distributed computing has been around for decades but only recently has it entered into mainstream IT as traditional software architecture has been pushed to its limits at Web scale. Perhaps the best known example is Apache Hadoop, an open-source data storage and processing framework where jobs are split and run across multiple commodity servers.

Microservices – Microservice architecture is a way of designing software applications as sets of modular, self-contained, deployable services. Whereas historically applications would be split into client-side, server-side/logic and database, the idea with microservices is to develop each application as a suite of smaller, modular services each running its own process with a minimal amount of centralized management. Microservices architecture is appealing because it enables greater agility (entire applications don’t need be taken down during change cycles), speed-to-market and code manageability.

        (Source: http://martinfowler.com)

The application stack is an ever-evolving, dynamic organism. Ultimately, whether it’s microservices, distributed systems, or containers, the changes we’re seeing at both the code and infrastructure level are about one thing: delivering better, more scalable software faster and cheaper. As a result, today we find ourselves at the outset of, what I’ll call, the warehouse computing era, defined by cheap, commodity infrastructure presented to the application as a pool of dynamically programmable resources with intelligent, hardware-agnostic software as the control plane operating at n-scale.

To me, though, this is still an incremental step. The world of IT I envision is one where code is written once and is executed anywhere, automatically at scale, irrespective of the underlying cloud, OS, container engine, orchestrator, scheduler, etc. In this world, ops ceases to be an IT function and becomes a product within, or even feature of, the underlying stack. This world is several years away, and before we get there I can promise the tech stack is going to get a lot more convoluted before it radically simplifies. Either way, it’ll be fun to watch.

In a world where applications are delivered via cloud and distributed across billions of Internet-connected end-points, we’ve seen barriers to entry, adoption and innovation compress byan order of magnitude or two, if not crushed altogether. Compound this by advances in application and data portability and the implication for technology vendors competing in this global, all-you-can-eat software buffet is that customers’ switching costs are rapidly approaching zero. In this environment it’s all about the best product, with the fastest time-to-value and near zero TCO. And it’s this second point – time-to-value (TtV) – that I want to dig in on a bit because it tends to be the one glossed over most often.

I’ll start with an anecdote …

A portfolio company of ours delivers a SaaS platform that competes with legacy, on-prem offerings from large infrastructure software vendors. In its early days the company had fallen into the enterprise sales trap: spending weeks, if not months, with individual customers doing bespoke integration and support work. About a year in when we finally decided to open up the beta to everyone, sign-ups shot up, but activity in new accounts was effectively nil. What was going on?

Simply, customers didn’t know what to do with the software once in their hands. Spending months with large accounts did inform some fundamental product choices, but at the cost of self-service. Our product was feature-bloated, on-boarding flow was clunky and the integration API was neglected and poorly documented.

In a move that, I believe, ultimately saved the company, we decided to create a dedicated on-boarding automation team within product. Sure enough, in the months that followed, usage spiked and the company was off to the races.

The takeaway is that highest priority should be given to building software that just works, and that means focusing relentlessly on reducing or eliminating altogether the time investment to fully deploy your solution in production. Ideally, you want customers to derive full value from your offering in mere minutes, if not seconds. To do so, treat on-boarding as a wholesale product within your offering and devote engineering resources to it. Find religion about optimizing TtV!

Below is by no means a complete list, but instead a few lessons that I’ve taken away from my experience with our portfolio that many SaaS companies should internalize in their product and go-to-market strategies to help optimize TtV:

Simplicity wins…be feature-complete, not feature-rich: This is a fairly obvious but subtle point that often evades even the most talented product teams: the defining characteristic of a simple (read: good) product is not the abundance of features but rather the relevance of those features to its users. This stands in stark contrast to the old paradigm of CIO-inspired products that were over-engineered and feature-bloated. The challenge in the new paradigm is what might be relevant to one customer may be entirely worthless to another. The solution is focus, either in product or in market.

The always-better option in my mind is to narrow your product focus. Do one thing incredibly well. Tackle the single, most acute – but universal – pain point and ingrain yourself in your customers’ workflow…then expand horizontally. Value needs to be delivered from day one, but features can be revealed over time. Ultimately, it’s about understanding your unique unit of value and exploiting that with your customers. Slack is the single best company embodiment of the focus/simplicity paradigm. Others take note.

Hack the onboarding flow: It doesn’t matter how beautiful or utilitarian your product is if no one ever gets around to using it. Developers are a fickle bunch with seemingly infinite alternatives to your offering of paid tools, open source projects and self-built hacks. You generally have one chance with them, and that chance lasts about 20 minutes (based on conversations with some of the least ADHD-ridden devs I know).

On-boarding should emphasize and reinforce the value prop that drove the user to your product in the first place. Sign-up should be frictionless and deployment should be self-service to the point where the customer is up and running in minutes and, most importantly, getting value from your product a few moments right after. Avoid the empty room problem at all costs – even if the data or insight you provide early on has less direct customer value, it’s better than a customer looking at a blank screen.

Suggestion: read New Relic’s early blog posts. The company was fanatical about delivering value to devs from their APM solution within 5 minutes of signing up.

Documentation, Documentation, Documentation: There’s nothing sexy or glamorous about documentation, but great docs can be a source of competitive differentiation. Look no further than Stripe, whose documentation is the stuff of legends (and a big reason why the company has grown as quickly as it has). Great documentation shows devs you care and it’s increasingly becoming table stakes, particularly if your product is technical or has an upfront integration burden. Given that, take the time to document from day 1 and don’t neglect those docs as your product offering expands.

An obvious corollary to the documentation point is around API cleanliness. Your API is a not adjunct to your product, it is an extension of the core; treat it as such.

Content, Content, Content: Embrace content – it’s your opportunity to connect with users. Content doesn’t just mean static blog posts, but includes webinars, tutorials, analyst publications and reference architectures. Leverage content to showcase the integrations, use cases and features of your product. Digital Ocean does this masterfully. Just go check out their blog.

Finally, make sure to quanitfy. Set a goal for TtV and benchmark against it. TtV’s vary widely across product segments and end-markets but study your comps and make sure you’re at least beating the pants off them.

An optimized TtV has positive ramifications throughout the organization ranging from freeing up support engineers to work on product to enabling a tightening of sales and marketing spend up and down the funnel. Ultimately, a short TtV drives all those other metrics folks seem to care so much about like MRR, LTV, CAC, Churn, etc.