Over the past month I spent much of my time at two Australian conferences: one in Melbourne, called ConNect 2015 and another one in Sydney with a more recognizable name, CeBIT Australia. In both cases, I was there to present and talk to customers about IBM Cloud. However some of the most interesting, cloud-themed conversations were from a series of roundtables that I was asked to host for IBM.

This post is about the highlights of these roundtable discussions along with my observations. The audience at both conferences was more business than tech oriented; many of the participants were in IT leadership with over 50 individuals joining the events in total. There was also a broad spectrum of industries represented at the discussions, including banking, shipping, insurance, and tech. Governments were represented at municipal and state levels. Given the audience, the discussions were less about specific technologies and more about the whys and the hows of adopting cloud.

Risk aversion

The roundtable participants who came from outside of the tech industry were clearly averse to taking risks with cloud, obviously around data privacy and regulatory compliance but also around the decisions on picking the right cloud platform and the right provider. The idea of workload portability resonated with these participants as much as the idea of freedom to switch to a different vendor or a provider of the cloud services. For IT leadership this was about flexibility and adaptability to changing circumstances.

Given this risk averse mindset it is not surprising that the principles of an open and hybrid cloud resonated with the roundtable participants. Open source and open standards help solve the vendor lock-in problem and also help ensure workload portability. Hybrid cloud is an inevitable consequence of mature IT policies that require some of the company’s applications and data (its secret sauce) to reside on company’s premises and behind its firewall.

Naturally, Docker came up as a solution to application portability. Given the amount of hype around Docker (much of it justified) it is not surprising that some IT leaders have overinflated expections about the promise of the techology. However, today, the Docker ecosystem does not provide a full featured and open platform as a service. Unlike Cloud Foundry, Docker does not define an approach for binding and sharing service integration metadata (unlike Cloud Foundry’s VCAP_SERVICES) and the Docker community is yet to settle on a common container scheduling and orchestration engine. Also production grade workloads shouldn’t blindly trust the default security settings of publicly available Dockerfiles. My message to the roundtable on Docker was to continue monitoring and experimenting with the technology but to hold off on using it as part of production PaaS deployments.

Commitment to Cloud

I’ll be the first to admit that cloud computing isn’t for everyone. With that said it was interesting to observe that all of over 50 participants at the roundtables said that once they have moved a workload into cloud they have never reverted back to the pre-cloud architecture (e.g. client-server) for the workload. In my mind this is a testament to the value of IT delivered as a service and coupled with consumptive metering and/or billing.

At the sametime, given that most IT organizations are risk averse when moving to cloud (see above), they are also deliberate in picking the appropriate workloads and investing the effort to migrate from existing infrastructure to the cloud. At the roundtables, it was clear that many organizations took the “cloud enabled” route to migration. In many cases they completed virtualization of internal infrastructure first and then selectively started to migrate some of the virtual machines to cloud.

Hybrid clouds are especially relevant to companies taking this route of cloud adoption. Fewer than 10 participants of the roundtables said that they standardized on a single type of a hypervisor like VMWare and its associated virtual infrastructure. Most have heterogeneous environments with a variety of hypervisors. The general sentiment at our discussion was that the outsourcing of a workload to an external vendor was a complex exercise in itself and change of the hypervisors during this migration should be avoided.

Cloud and “Core Technology” Companies

In everything I covered so far, the ideas of hybrid and open clouds made sense to participants. However, some of the most intriguing questions were from engineers with what I would describe as “core technology” companies, those involved in using computers (often in an embedded form factor) to build a “core technology” that drives their business. For example, one of the companies sold a media appliance that played movies in hotels from an encrypted hard disk. The appliances were intentionally running on isolated networks without any internet access to minimize security risks. Bandwidth costs made it cheaper to distribute media on hard drives rather than through downloads. Another company sold rugged computers preloaded with navigation and seismology related software designed to operate in remote conditions where only expensive satellite phones can connect to the internet. Although we didn’t have any such companies at the roundtables but I would place semiconductor and other high tech equipment manufacturers into this category. Most modern equipment, such as the equipment for etching chips on wafers, uses a built-in server that enables graphical user interfaces, application programming interfaces, and equipment management.

As everyone else in IT, these companies were struggling to figure out what cloud computing means to them. For them the challenge was admitting that their “core technology” workloads did not need a full featured cloud computing environment. Some of these companies could have benefited from virtualized infrastructure or from cloud based dev/test environments but they also had to recognize that factors like absense of network connectivity or complex real time requirements, or impact of network costs on their business plans meant that cloud did not play a role in the deployment of their core technology.