John Burke — Principal Research Analyst with Nemetes Research
John advises key enterprise and vendor clients, conducts and analyzes primary research, and writes thought-leadership pieces across a wide variety of topics. John leads research on private and public cloud; private cloud infrastructure; private and hybrid cloud management and security; network, server and storage virtualization; and software-defined networking (SDN), SD-WAN, and network functions virtualization (NFV).
Your company is probably using a lot of cloud. Nearly everyone uses SaaS, and the more successful companies get 21 percent of their enterprise IT services that way on average (in Nemertes’ 2017-18 Cloud and Networking Research Study). Nearly 60 percent of companies will host at least some of their production workloads out in IaaS and PaaS platforms by the end of this year.
Folks love cloud for many reasons, including the low cost of entry, and the immediacy: have a need, meet a need, don’t break the bank to try something out. These are the traits, along with easy scalability and the pay-as-you-go model, that have made the cloud developers’ best friend. Even your developers.
But your company may not be ready to entrust its most vital intellectual property— the apps you develop for yourselves, whether for customers or staff, or the data those apps manage—to the public cloud yet. Even though the big cloud providers can probably boast decisively better potential for secure deployment than you can with your own data center, staff, and operational practices. Because, it is all too easy to misconfigure (or fail to deploy) the measures that will give you the security you need in the public cloud. The environment can only warn you that clicking “yes” will expose the virtual machine or storage volume or data base to the Internet—it can’t keep you from thinking “no” but clicking “yes.”
That doesn’t mean your developers don’t want a cloud to develop in, of course. Some will still want a PaaS platform to develop to, something that will abstract away some of the architectural and operational details of managing distributed resources and providing continuity of services. Others will want to use APIs to control directly how their systems’ components spin up and down, pro-grammatically managing compute, storage, and networks. Basically, the standard for good design in the cloud era is to design for cloud: distributed, horizontally scaling, and based on a microservices architecture and container technology. The easiest way to do that is to actually work in a cloud, of course, but it doesn’t have to be the public cloud.
To best support the developers while still respecting the risk tolerance of leadership, give everyone what they want. Give developers a cloud that is flexible and responsive…and inside your own data centers.
To do that, IT needs to adopt a cloud mindset: get past managing individual devices and VMs, and use powerful management tools to abstract away the low-level details of physical resources as much as possible. Building a fully automated private cloud is nontrivial; it involves having a cloud management platform, a staff that can think and manage in cloud terms, cloud technology strategies and roadmaps, and cloud- style resourcing practices. It also requires an IT organization ready to support true cloud operations, from the portal or API used to spin a service up on demand, all the way through to the by-the-drink billing.