Over a million developers have joined DZone.

OpenStack and Cloud Trends—Hypervisors, NFV, Orchestration and more thoughts from the Summit

· Cloud Zone

Build fast, scale big with MongoDB Atlas, a hosted service for the leading NoSQL database on AWS. Try it now! Brought to you in partnership with MongoDB.

OpenStack Vancouver Summit | OpenStack VMWare | NFV OpenStack | OpenStack Orchestration | NFV Orchestration | Cloud

The OpenStack Summits, which I have been attending twice a year for the past five years, continue to serve as the most formative and influential moments I have during the year - especially with everything related to the growth around OpenStack, which is especially notable from summit to summit. So right in the thick of OpenStack Vancouver, I’d like to take a moment and outline some of the important trends around where cloud will be going, and specifically around OpenStack in 2015.

Bring your OpenStack Orchestration to the next level with Cloudify.  Go

OpenStack & the Move Away from Hypervisors

When I think about cloud and OpenStack trends for 2015, the primary trend of note to me is the move away from hypervisors to a fusion between containers and bare metal. I’m basing this on the hard numbers from last OpenStack User Survey that was released following the OpenStack Summit in November in Paris, that to me, only represents the beginning of a growing movement.

Part of the reason this migration is becoming a popular option is because with containers it’s simpler to run dynamic workloads on bare metal while still ensuring isolation between one workload and another. This suddenly makes the option of running containers on bare metal an attractive option that comes with a lot of performance and utilization benefits, not to mention simplicity, especially in specific cases where a full-blown cloud may be overkill. For example, running a Hadoop cluster or managing dev/test environments. So I believe this is only the start of such a trend - especially with the addition of Ironic in the latest OpenStack Kilo release, which will simplify this even further, this coupled with the addition of Sahara in Juno with added features in Kilo for I/O intensive workloads.

The Convergence of NFV and Enterprise IT

The adoption of OpenStack as the private cloud of choice in both enterprises and telcos brings the two industries much closer together. If previously telco IT and infrastructure looked quite different than that run by enterprises, with OpenStack, we’re seeing that the solution, IT as well as the backend stacks for running the actual core services of telcos becoming very similar to that of enterprises. As a matter of fact, at the last OpenStack summit, which is traditionally driven by enterprises, we’ve seen a significant growth in and influence of telcos who are adopting OpenStack. This can be noted in the significance of NFV in the OpenStack Juno release, and it's having received even more emphasis in the OpenStack Kilo release, including such features as port security for OpenVSwitch, VLAN transparency and MTU API extensions. In the last OpenStack & Beyond podcast on NFV & SDN with Axel Clauberg, of Deutsche Telekom, who is leading one of the most ambitious NFV projects on OpenStack, he discussed the need to optimize your IT environments through NFV, and simplify the complexity through automation.

Another very important element in this respect is TOSCA (Topology Orchestration Specification for Cloud Applications) that has been gaining adoption. Since telcos are a very standard driven industry, we’re seeing the importance and adoption of a standard like TOSCA becoming an important criterion in the choice of orchestration. The direction I see things going in this space in the upcoming year are that the formerly disparate IT worlds of NFV and enterprises will begin to converge, and TOSCA will play a leading role in becoming the de facto standard for NFV orchestration for both these industries.

Orchestration is the Next Big Thing

On that note, the recent entrance by both Google and Amazon to add support for orchestration as an independent service layer of the stack, marks the move of orchestration to center stage, in addition to Docker’s recent release of tools of Machine, Swarm and Compose for orchestrating containers , and will become an official important component in all private and public cloud offerings. Therefore, it's not surprising to see Canonical/Juju, as well as, a growing list of orchestration tools adopting TOSCA as their official templating language joining a list of existing contributors such as IBM, Huawei, Cloudify, FastConnect, Alcatel-Lucent, among others, not to mention the progress being made in the OpenStack heat translator project. My talk at the OpenStack Vancouver summit will focus on this growing diversity of orchestration tools - and will dive into the difference and synergies. You can also read a sneak preview on this session from the recent interview by Jason Baker here.

The Future of Containers and Who’s in Control

It’s no news that containers are gaining huge momentum and popularity, and will continue to grow as this becomes a central piece in a modern cloud stack. I don’t think anyone put it better than Adrian Cockcroft (and I’m paraphrasing - as I heard him say this in one of his many talks) - “Docker is the technology that has gone the quickest from disruptive to legacy.” It’s almost easy to forget that Docker 1.0 was only launched in June last year.

Who is controlling the future of containers is now becoming a hot topic. As long as Docker was a small piece in the stack it was easy to swallow, but now as it's growing up the stack, it has started to compete with its own ecosystem. Therefore, it’s not surprising that we will start to see alternatives to Docker, one such example is the launch of Rocket earlier this year to keep up with Docker. Google just announced partnership with CoreOS and are, in essence, providing a full-stack alternative to the Docker-based approaches.

Personally i believe that for Docker to be successful it needs the industry support behind it and it wouldn’t be able to get this support if it wouldn’t open itself up through some sort of a foundation model that will give better chance for other companies to be part of the revolution and with that gain some level of control on their own destiny.

The OpenStack Distro War

Clearly the Mirantis $100M investment has put them in the spotlight as a rising star in the OpenStack distro world. As OpenStack is primarily positioned for private cloud and large enterprises, Red Hat has a promising position to continue and maintain its leadership position based on its current enterprise footprint, while Ubuntu, will have challenges gaining large marketshare within the enterprise world. And it also remains an open question whether the recent bold moves by HP who has finally gone all in on OpenStack is not too little too late. As mentioned in my previous post, on VMware/OpenStack, also joined the OpenStack distro war, with an aim to keep its existing customer base. This is potentially the main competition for Red Hat as they both compete in the same enterprise space, as Boris Renski noted in his post. I believe Mirantis will be a rising star in 2015, and expect to see more bold cat fights on the enterprise side by VMware/Red Hat and HP. The lack of a clear winner in this space will raise the demand for an independent/pure play app deployment and orchestration framework that can work with any kind of distribution.

Where OpenStack should be heading? - My personal thoughts..

My personal belief is that OpenStack will be much more successful if it will find a way in which more cloud providers will be able to add support for OpenStack, including those considered rivals to OpenStack such as AWS, Google, and Azure. Similarly, it will be more successful if it will find a way to encourage native support for OpenStack by other popular open source projects.

I think that so far there has been lots of focus on making OpenStack an alternative to Amazon. That strategy has led to spreading the OpenStack project too thin into many projects, in my opinion. I think that the VMware support for OpenStack is a good example for how a potentially rival infrastructure provider can become compatible with OpenStack. If we would make it easier for other infrastructure providers to add OpenStack compatibility to the OpenStack API we will gain much more than if we only focus on making OpenStack a viable competing alternative. Basically, I'd say inclusivity is of the essence, and not exclusivity: The open source way.

Final notes:

Overall, I think OpenStack will continue to demonstrate growth and be a serious business and investment driver across the cloud industry. It will continue to serve as a disruptive technology for many aspects that have previously been a black box in terms of “closed source” cloud. By opening the APIs to all - new and innovative forms of cloud automation capabilities are suddenly possible. I personally am looking forward to seeing how 2015 unfolds, and what the upcoming OpenStack summit in Tokyo, and the Liberty release, will hold in store.

For those who can’t make it out to Vancouver - we’ll be broadcasting live from the ground with an episode of OpenStack & Beyond, and you’re also welcome to join us for the OpenStack Israel

Now it's easier than ever to get started with MongoDB, the database that allows startups and enterprises alike to rapidly build planet-scale apps. Introducing MongoDB Atlas, the official hosted service for the database on AWS. Try it now! Brought to you in partnership with MongoDB.

cloud,orchestration,openstack,tosca,cloudify,juno,docker,nfv,hypervisors,openstack summit

Published at DZone with permission of Cloudify Community, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}