A lot of new technologies and techniques were invented and developed to enable large cloud businesses. Enterprise IT organizations are now looking at these innovations with an eye toward realizing business benefits from doing the same thing. Techniques like continuous integration (CI) and continuous delivery (CD) are helping cloud companies. Enterprises are looking for the same agility. Both Google and Netflix have been using containers for years, and many enterprises are adopting them now. Most of these businesses are nowhere near the size of Google, or even Netflix, yet they want to use the same techniques. The challenge is that businesses of different scales have different needs. What works at an enormous scale isn’t always right for companies that are merely huge or simply large.

How large is large? I live in New Zealand, and our government has a cloud-first IT policy. It set up a panel of local cloud providers to help government departments get their IT into the cloud. The people responsible for this panel went to AWS and asked for a group deal for bringing all of New Zealand’s government departments to AWS. Naturally, AWS said, “We don’t discount.” What it didn’t say is that New Zealand’s entire population is less than a medium-sized metropolitan city in the US. What looks huge to a New Zealand–based person is the same population as metro Phoenix, Arizona. Similarly, a business that has ten thousand customers ordering products every week feels large. It certainly doesn’t want website outages. Yet compared to the Amazon Web Store, it is a tiny minnow. Scale is a matter of perspective.

If the majority of enterprises are tiny compared to these vast web businesses, does that mean they cannot use the same technologies? Of course not, but they probably need to use them in very different ways. A commercial customer might need a few hundred instances of a container for an application. Google might need a million container instances for one part of an application. The problems you need to solve for a million container instances are significantly different from a thousand instances. Both businesses can benefit from containers but need quite different techniques. One of the big differences is the capabilities of the teams that run the infrastructure. Enterprise organizations use operations teams; cloud-scale companies use developers. Google has several teams of developers, and some of them are dedicated to creating and enhancing the platforms that run these applications. For Google, the infrastructure platform is a key part of its business. It is so central the business that it provides this infrastructure to customers. You can rent access to this infrastructure as the Google Compute Platform. Google’s infrastructure is its product, so dedicating developer resources to this infrastructure is good business sense. A massive global company, like Apple, needs a lot of infrastructure to keep its business running. Apple has recently decided that more of this platform needs to be developed in-house. It, too, has a team of developers making its infrastructure work exactly as Apple needs.

Most enterprise organizations have developers as well. Few of them have these developers building software to run their infrastructure. This is where the model of using cloud-native tools falls down for enterprise customers. Enterprise customers expect infrastructure to run on packaged software: install the software, then choose a few dozen configuration options, and the infrastructure is ready. This is a long way from how massive companies deploy infrastructure. Cloud companies expect to customize the software to their needs. I suspect this is where a lot of OpenStack projects go wrong in enterprises. Deployment is complicated and requires coding skills that enterprise operations teams may not have. This custom design philosophy is everywhere in cloud businesses. Amazon builds everything customized to its own specifications, from the physical server racks, to the power supply and networking, to the servers and software that runs in them. Enterprise customers rely on hardware manufacturers and order from a catalog. What enterprise customers need is a catalog of software that cloud businesses use. Enterprise-ready versions of OpenStack, Mesos, or Docker are what they need. To be enterprise-ready, the platforms need to have graphical installers. They need hardware compatibility lists that identify models and hardware configurations.

Different scales of the same problems require some different solutions. Parts of the solutions will be the same, but other parts will necessarily be different. There is a huge business opportunity in turning tools used by cloud-scale companies into packaged software that can be deployed by enterprise customers.