Virtualization and Cloud executives share their predictions for 2017.  Read them in this 9th annual VMblog.com series exclusive.

Contributed by JJ Asghar, Sr. Partner Engineer at Chef

Compute isn't as important as flexible workloads

The cloud industry sphere changes rapidly. This is a given and something that we not only take for granted, but consider a truth. You can be using one technology one day, then within only a month or two you could be using something completely different. 2016 has demonstrated this many times over. For example, at the beginning of the year there were still major pushes for OpenStack in your own datacenters, and now, at the end of this year, serverless is the new paradigm. From the forces that I see moving, 2017 will be the year of creating and solidifying the mechanisms for common cloud workflows. I acknowledge the previous statement is a mouthful, but it's the perfect "middle ground" of the progresses we've been making.

The Big Three Clouds

In 2017, we will see the three major cloud players solidify their places in the industry. It can be argued that Amazon, Azure, and Google Cloud have become household names, but at year's end we are still seeing other large vendors trying to break into the space. Companies including, but not limited to, the likes of Cisco, Oracle, or Alibaba, all believe there is enough demand in our economy for more hosted clouds. I vehemently disagree with this. The versions I've listed here that aren't part of the big three clouds have no reason to be in this space. They simply don't have the years of disruptive engineering that allow for radical changes in design and development required to be successful. 2017 will be the year these companies learn the hard way that there are only three big clouds now, and they are the only ones who can afford to sit at the table. Any attempts to build competing, bespoke cloud platforms will be an exercise of not only loss of cash, but futility. In 2016, the flash in the pan of VMware's vCloud Air is a perfect example of this microcosm. VMware comes in hard, tries to get adoption, but quickly notices that there is no viable market for this, and then lets it die on the vine.

k8/Mesos/Nomad/docker swarm

Turning to distributed work flows and disruption in traditional IT compute design, 2017 will see trench warfare between Kubernetes (k8), Mesos/Mesosphere, Nomad, and Docker (with Docker Swarm). This is a space that emerged in 2016 pushing a "new" way to deploy microservices, with the promise of teaching old tanker size corporations to become more agile. 2017 will be the year that we see k8 take off. Yes, Mesos/Mesosphere is backed by Azure, and Microsoft has, and will continue to invest in it, but k8 is clearly superior technology. (In the process of writing this article, Microsoft now supports k8 on Azure too, so as you can see even Microsoft isn't 100% sure what horse to back here).

I equate it to something like the betamax verse vhs tapes of the late 80s and early 90s. Even though most believed that betamax was a superior technology, the adoption was challenged by narrow focus and specialization, instead of a broad coverage. k8, on the other hand is the basis of all of Google's infrastructure, which allows for not only association with the Google brand, but long-term investment from Google itself.

Not to discount Nomad from Hashicorp, or Docker Swarm from Docker, but in some unscientific polling of people in my industry, I asked:

"If I say Nomad, in the context of our business, what do you think?"

And then followed that up with, "What do you think of Docker Swarm?"

The answers I received mostly fell in the camp of:

"Nomad? You mean a road warrior? Like a Sales person?"

"I set up Docker Swarm on a couple desktops, it was easy but it felt very non-production."

I should mention that after these types of answers, I gave more context and people quickly started asking about k8. k8 has a complexity issue, which ironically makes it feel more "production" like in this context. If you have to invest those many human hours to make it work, you feel more invested. Unlike Swarm, for instance which is literally 2 commands to get a working cluster node.

The New Cloud Workflow

Microservices

With the big three cloud players pushing shared workflows, they will have to also evangelize redesigning applications from monolithic stacks to microservices. If traditional enterprises buy into this evangelism in 2017, we'll undoubtedly see a lot of failed legacy application conversion projects. As pessimistic as that sounds, I believe it will become reality. The traditional way companies have been developing and building applications is just too ingrained in not only their corporate policies and culture, but in the actual silos within which they create applications. Microservices, and the agility required to actually build them, will put traditional IT organizations on their head and, ultimately, fail. Microservices will eventually disrupt legacy IT, and if successful, change IT itself, but unfortunately this transformation will take more time than anyone thinks. It's a huge, and risky, bet for any large business on. There will be a land grab of talent that can handle these types of environments, the places in flux, between the legacy monolithic stack, and the process to break it out. This talent will start earning their stripes in 2017 because with the push and promise of three major clouds, many companies will try. Because most companies won't advertise their failure, over the course of 2017 we'll see an influx of engineers with skills like "Java 10 years, .NET 5 years, and Go 1 year". Only a couple years ago you would have thought that one of these isn't like the other.

The Opportunity of Choice

There will be a lot of cross-pollination among the three big clouds, but the one that wins will allow fluidity/elasticity between each and offers the easiest route to doing so. This will require the "big three" to give up at least some of their ability to "keep things in the walled garden". Interestly, giving up some control will actually be to their advantage. The ability to allow customers to leverage another cloud for rudimentary background tasks will open up their premium level resources for more mission-critical work, allowing for higher premium pricing. There is this romantic idea I have where your mission-critical applications run on AWS, with your AD and business applications on Azure, and your "number crunching" happens on Google Cloud. From what I'm seeing in the industry, this doesn't seem too far fetched. I'm not going to go as far as predicting this Utopia will become the norm in 2017, but I genuinely believe we'll see this pattern emerge. Leveraging containers, the ability to "ship" these applications from any to all of these clouds - where they aren't tied to just one technology stack - will not only empower the developer, but finance will enjoy this, too! The opportunity to be charged for the exact resources you need to run, instead of massive Capex expenses, will make any CFO smile.

##

About the Author

JJ is a Sr. Partner Engineer at Chef, he was also the PTL for the Openstack-Chef project, and helped bootstrap the OSOps project in OpenStack. He lives in Austin, Texas and still is itching for Google Fiber. He enjoys a good strong stout, hoppy IPA, and some Dwarf Fortress or Factorio. He's a member of the Church of Emacs, and usually chooses Ubuntu over CentOS. He's a father and husband, if he's not trying to automate his job away he's trying to convince his daughters to "be button makers not button pushers."