Ben and Krish have taken a bold step, and we at Cloudscaling are happy to help them. They’ve launched a one-day event focused on perturbing the steady-state system of cloud thought leadership by going beyond vendor stories and cloudwashed application profiles to think about questions that matter to cloud buyers going forward.

Their event, Cloud 2020 Summit, is a small, invitation-only gathering of about 75 buyers, vendors and pundits. (apply here)

Check out the agenda, and apply to attend. If you’re coming to Las Vegas for Interop, it’ll be easy enough to join in, and it should be well worth your time.

The OpenStack cloud computing software platform is the fastest-growing project in the history of open source. OpenStack Grizzly, the seventh major milestone release of OpenStack in less than three years, has become generally available after six months of active development, delivering powerful new features and some 7,620 patches contributed by 517 contributors globally.

Grizzly, incorporates the three major components for building a cloud: compute, storage and network and is about making OpenStack scale and integrate with existing systems more easily. Users can now manage multiple OpenStack clouds through a single console; there are new drivers that ensure it is compatible with a wide range of products commonplace in the enterprise market, from vendors such as HP, IBM, VMware, NetApp and Red Hat, among others.

The OpenStack platform has matured to a point where enterprises can start to reliably use it to power next-generation computing workloads on their own private clouds. Real-world deployment stories are a central theme at this week’s OpenStack Summit. Stories from industry leading companies such as EVault, IBS DataFort, Ubisoft and LivingSocial will put Cloudscaling at the center of the conversation.

Despite the momentum behind OpenStack and early customer success, there is still more work to be done to make it truly enterprise-ready.

Delivering industry-leading OpenStack-powered solutions requires an ecosystem

Today, Cloudscaling and Juniper Networks announced a partnership that will integrate Juniper’s virtual network control technology – developed by Contrail – into Cloudscaling’s Open Cloud System (OCS). Juniper chose Cloudscaling for several reasons:

1. Cloudscaling engineers understand network engineering and cloud deployments at scale.
2. Cloudscaling has the technical chops and experience to deliver to the most demanding enterprise customers.
3. Cloudscaling uses 100% community OpenStack code. We do not fork OpenStack, and our customers take delivery of the source code.

Additionally, Juniper and Cloudscaling share a vision of the modern data center as well as an understanding of how the elastic cloud model and dynamic applications are revolutionizing the way IT services are delivered.

Customers expect highly agile, production-ready solutions, and the partnership with Juniper reflects that. As early leaders in SDN and the OpenStack community, respectively, Juniper and Cloudscaling understand the key disruptions driving cloud convergence and are uniquely qualified to deliver robust solutions that scale IP (internet protocol) service delivery and new application deployment. Alternative market solutions have failed to address the needs of enterprise and service provider customers who require a turnkey, open architecture, elastic cloud infrastructure solution that interoperates with existing data center and elastic public cloud environments.

Contrail’s virtual network control technology does more than simply emulate a Layer-2 network. It solves many of the problems inherent in other designs that compromise the dynamic scaling capabilities that app developers expect of a Layer-3 network – IP reachability and network services including advanced security, horizontal scaling, and fault tolerance. With the Contrail controller and Open Cloud System, customers get what they expect: architectural and behavioral compatibility between Layer-2 and Layer-3 topologies that simplifies automation and supports today’s enterprise apps and tomorrow’s hybrid deployments.

How the Juniper partnership transforms OCS and Cloudscaling

The deal is the first phase of an ongoing partnership in which the two companies will work together to leverage Cloudscaling’s leadership in OpenStack-based elastic cloud infrastructure and Juniper’s leadership in network innovation for enterprise data center customers.

In this first phase, the two companies are integrating Juniper VNC technology into Open Cloud System to enable the modernization of the traditional data center networking towards open, any-to-any fabrics where Layer-3 network services are moved closer to cloud-enabled application workloads. This approach emulates the cloud infrastructure (Virtual Private Cloud) architectures pioneered by hyper-scale web and cloud computing pioneers such as Amazon Web Services (AWS) and Google.

The new software-defined networking capabilities are implemented via OpenStack Quantum. Following validation with early access customers, general availability is slated for later this summer. The VPC capability will be delivered as an advanced feature module in Open Cloud System 2.5, which was announced today at the OpenStack Summit in Portland.

While the first step of the collaboration is integration of the Contrail controller into Open Cloud System to provide a new VPC capability, there are more announcements on the horizon. And, as our early access customers begin implementing the VPC product, you’ll hear more about how they’re using it and the results they’re achieving.

(Read more on the Juniper Networks blog.)

• OCS Virtual Private Cloud (VPC)
• OCS Block Storage snapshots plus production-ready enhancements
• OpenStack Grizzly support, and
• New certified hardware options from Juniper, Dell and Cisco

OCS Virtual Private Cloud (VPC)

OCS Virtual Private Cloud (VPC) provides fine-grained networking control for customers deploying applications into elastic clouds. It supports provisioning of logically isolated, virtual networks with complete control and customization of the IP network constructs (address range, subnets, gateways, etc), delivers enhanced security via security groups and network ACLs, and enables traffic load balancing across groups of instances. OCS VPC supports the familiar network constructs and controls found in a typical enterprise network, but without sacrificing elastic cloud functionality such as tenant security groups and elastic IPs.

With OCS VPC, deploying cloud-ready dynamic and enterprise apps has never been easier or more secure. The additional control and flexibility simplifies application deployment as tenants have full control of the network and security access. It opens up a variety of application deployment options that simultaneously provide access to public resources while protecting private ones.

For example, a tenant can set up both a public subnet and a private subnet within a VPC. Instances launched within a public subnet will have both outbound and inbound connectivity but private subnets will not have internet connectivity by default. This separation allow tenants to simply place all public facing servers (such as web servers and search servers) in the public subnet while keeping private servers (such as database servers, cache nodes and application servers) in the private subnet. This is one of the many application deployment scenarios that are made possible by OCS VPC.

We are very excited to be working with the great team at Juniper to deliver OCS VPC. Our CTO, Randy Bias, got an early glimpse into what the Contrail team was developing in late 2012 and he was very bullish by what he saw. Our customers expect production-ready solutions and now they will have a choice of deploying OCS Elastic Networking – VPC or Standard – depending on their cloud infrastructure networking needs.

OCS Block Storage Product-Ready Enhancements

We announced OCS Block Storage as part of OCS 2.5. With 2.5, we’re enhancing the Block Storage service by allowing tenants to initiate snapshots of their volumes and store these snapshots in OCS Object Storage. In addition to providing cost-effective backups, volume snapshots provide an easy way to rapidly launch new instances when a dynamic app needs to auto-scale. The ability to capture block volume snapshots to object storage leverages the strength of each storage type – the performance and persistence of block storage and the low cost and scalability of object storage.

With 2.5, we have also focused on additional production-ready enhancements that simplify deployments and improve SLAs. We’ve automated the installation and deployment of OCS Block Storage blocks plus built redundant services and interconnects to protect against infrastructure failure. Finally, we’ve expanded the hardware choices available from Quanta and Dell that can be used to deploy OCS Block Storage.

Grizzly Support

I called OpenStack Folsom “awesome” and I am sure in due time I’ll find more descriptive adjectives to describe OpenStack Grizzly (OpenStack 2013.1 release). More than 550 people contributed code, documentation, or infrastructure configurations plus resolving 1,900 development tickets within the various OpenStack projects. Our approach to building the best OpenStack-powered system starts with curating which components of OpenStack get enabled in OCS. With the Grizzly release, OCS 2.5 adds support for Quantum in addition to the already-supported Nova, Swift, Cinder, Glance and Keystone components.

Certified hardware from Juniper, Dell and Cisco

Finally, our hardware team has been busy certifying hardware from Juniper, Dell and Cisco. Our CloudBlocks architecture already supports servers from Quanta and high-speed, 10GE top-of-rack switches from Arista. Based on customer feedback and our expanding technology ecosystem, we will support the Dell R420, R620 and R720xd rack mount servers. We have also significantly added 10GE network switches with new choices including the Juniper QFX 3500, Quanta LY-2 and Cisco Nexus 3000. Our expanding certified hardware list enables a broader range of OCS configuration options and price points, and it allows our customers to leverage established relationships with existing, trusted infrastructure partners.

OCS 2.5 is accelerating down the Turnkey, Production-grade System Path

Before pivoting to a pure product company in late 2011, Cloudscaling started as a cloud consultancy and developed extensive experience deploying most of the open source cloud software options out there. We’re well aware of the development, operational and maintenance challenges presented by customized cloud infrastructure. OCS 2.5 represents the third major release of our packaged cloud system designed to stand up cloud infrastructure quickly and reliably to support your production workloads. We look forward to continuing the investment as we continue to ramp up customers on the Open Cloud System.

Cloudscaling will be there in force, with six presentations (well, five plus one panel), and customers of Open Cloud System on hand to talk about building clouds with OpenStack and Open Cloud System.

We’ll even have some news to announce.

Frequent readers of this blog know that Cloudscaling was among the first commercial entities to publicly support OpenStack, and that our OpenStack-based Open Cloud System is in production environments for multiple customers.

What you might not know is that Cloudscaling was the first company to deploy a Nova compute public cloud, and we were the first to deploy a Swift storage public cloud outside of Rackspace. We’re a founding member of the OpenStack Foundation and a charter Gold Corporate Sponsor. Co-founder and CTO Randy Bias has served on the Foundation board since its inception, and Cloudscaling is a top-ten code contributor to the project, including ZeroMQ messaging, RPC abstraction layer, APIs for Google Compute Engine and security improvements. The second version of our OpenStack-based product, OCS, is in GA.

In other words, we’re all-in on OpenStack. And the presentations our engineering team will give in Portland reflect that.

Review the session descriptions below, and come check out those sessions that address the questions you have about deploying OpenStack. Here’s the full schedule. There’s plenty to choose from.

PANEL: Vendor discussion about RAs -> battle for a winner — Randy Bias

April 16, 1:50 pm

Operations Summit: Design summit-style technical working sessions to discuss and refine best practices for deploying and operating OpenStack installations.

State of the Stack — Randy Bias

April 17, 11:00 am

OpenStack is the fastest growing open source movement in history, but its marketing momentum has largely outrun its technology growth. Why are organizations so eager to embrace OpenStack? Some components – like Swift – are ready for prime time. But others – like Horizon and Quantum – are still evolving. What needs the most attention: networking, storage, compute, or something else? Where are the reference architectures and real world deployments? How are different product and service companies implementing OpenStack in production today? We’ll go beyond the hype and dig deep on OpenStack, exploring all that is great and all that needs serious work. Attendees will leave with a firsthand account of the State of the Stack, ready to help their organizations embrace OpenStack armed with practical knowledge.

Scale-out Block Storage: There’s a Reason AWS EBS Looks the Way it Does — Randy Bias and Eric Windisch

April 18, 9:30 am

Existing approaches to delivering persistent block storage in OpenStack focus on integrating existing SAN/NAS hardware solutions, using Distributed File Systems (DFS), or using simple Direct Attached Storage (DAS) with Cinder. There is another alternative: scale-out block storage nodes with intelligent scheduling. This is the same approach that Amazon Web Services (AWS) uses for Elastic Block Storage (EBS) and it’s worth taking a close look at the pros and cons. This presentation will explore the differences between SAN, NAS, DFS, DAS, and EBS. We will look at the implicit and explicit contracts that users and operators get from the different approaches and look at a variety of failure conditions. EBS may not be right for some clouds, but for many it’s an important and viable alternative to the existing approaches.

Folsom Security in Review — Matt Joyce

April 18, 3:20 pm

This talk is a breakdown of security concerns relating to the OpenStack Folsom Release. The purpose of this talk is to look at past vulnerabilities in Folsom, existing security models, and emerging technologies that will impact those models. The presentation will follow the flow of describing several deployment models in terms of their security attributes. The next phase will be the discussion of specific protocols in use and their individual security characteristics. I will present statistics on where past vulnerabilities have been found and reported allowing us to consider how we can better address security in our continuous integration processes. The goal of this talk is to present a map of where we are today, and expose some of the issues we have yet to face.

Networking is NOT Free: Lessons in Network Design — Dan Sneddon

April 18, 4:10 pm

This presentation will be an in-depth critique of the existing OpenStack networking approach, with a focus on how the Nova network controller is more of a hindrance than a help. We will also discuss the gap in Quantum’s functionality required to close the gap, and alternative solutions. How can we make networking in OpenStack robust, high performance, and fault tolerant? What do typical large scale networks look like and what lessons can we learn from them? Is there an approach to networking we can take that is the same with a handful of servers as it is with hundreds of racks?

Securing OpenStack’s Underside: True Computing — Eric Windisch

April 18, 5:00 pm

There have been a number of premature attempts to provide a trusted computing platform for IaaS software. However, all have met with failure and a lack of mass market adoption. What would be required to solve this problem for real and deliver “true” computing? True computing requires the ability to have a trusted chain of events related to the provisioning and deployment of hardware and software. It requires integration to the supply chain with installation of initial keys at the hardware vendor’s site, secure PXE booting, system attestation, and robust key management. None of this is easy or free, but what would it look like if OpenStack could become the first truly trusted cloud system? How would it integrate with the current ‘trusted-messaging’ blueprint? Would it make CloudAudit’s API more relevant?

OpenStack Product Landscape — Option #1: DIY

Option #1: DIY OpenStack: At first glance, the least expensive path to consuming OpenStack is via the Do It Yourself (DIY) route.  Adventurous DIY-ers can go to Github, download the OpenStack bits and crank through the installation. There are some basic guidelines and documentation available in the public domain to keep you on the well travelled path. If you don’t have available technical expertise on staff, you can outsource the work and let an OpenStack integrator do the work for you. There are benefits to using this product option – you learn a ton about OpenStack on the journey and you get your own custom OpenStack cloud running on the infrastructure you specify.

Straightforward right?  Well, not quite.  It’s not the typical path people pursue to stand up a production ready OpenStack cloud, especially given the pre-packaged OpenStack options available on the market.  You (or your OpenStack integrator of choice) are ultimately creating your own fork of OpenStack that you’ll have to maintain in perpetuity – this cost/benefit trade off should not be underestimated.

Cost is the most important consideration for the DIY option – outside of free open source software, this choice can quickly lead to cost overruns if not well managed.   First, there’s the fixed cost of employing a very capable OpenStack team to develop, maintain and operate your custom cloud.  Additionally, there is significant cost in reduced reliability of your infrastructure, lack of support options and higher operational effort of having your own OpenStack “island”.

Option #2: OpenStack Distribution 

What you get in this product category is a packaged and supported OpenStack software distribution.  The software is commonly delivered via a convenient downloadable ISO with documentation to assist the installation.  Most of the packaged OpenStack distributions in the market are made available by purveyors of Linux distributions – so some people will likely align with their Linux vendor’s OpenStack solution.  It’s a great way to get acquainted with OpenStack, but it may not be the best path forward to actually running a production OpenStack cloud. Why is that?

The scope for most OpenStack distributions is to provide a “try and buy” option for people interested in using OpenStack.  This allows prospects to deploy a handful of servers in a test environment where single points of failure and an inability to scale linearly over time are acceptable compromises.  However, these shortcomings are not acceptable for a production cloud.

Many OpenStack distributions are only in preview mode today – which means you can’t buy support even if you wanted to.  When there is support available for the OpenStack distribution, it isn’t comprehensive.  Frequently, support is via the web only with no upgrade option for phone support.  Finally, the OpenStack distribution vendors will support only OpenStack software but not the running system (such as the hypervisor, hardware infrastructure and network elements).

Option #3: Turnkey System 

 This option pushes the effort of developing, maintaining and upgrading OpenStack to the ISV, thus freeing the customer to focus on technology areas that are more beneficial for their business.  The reality is if you want to build a production ready OpenStack cloud, you must curate, test, validate and support the whole stack – this is the approach Cloudscaling took.  What you get with an OpenStack system is 

• A production ready OpenStack distribution
• A reference architecture optimized to the type of cloud being built
• A range of certified hardware components
• Additional software components that streamline deployment and management

Choosing to deploy an OpenStack system eliminates the guesswork present in the OpenStack DIY and distribution product options, resulting in rapid deployment with reduced costs, higher infrastructure reliability and lower operational effort.  An OpenStack system is production ready on Day 1 because it is architected  to eliminate single points of failure and scale linearly over time.

Customers choose OpenStack because of the project’s feature velocity, so seamless upgrades of the entire stack is a key value proposition.  Upgrades for an OpenStack system such as Cloudscaling OCS are predictable since the entire “stack” – OpenStack distribution, underlying hardware components and reference architecture – is treated as an atomic unit.  

Finally, support for OpenStack systems cover the entire “stack”.  Cloudscaling extends support beyond just the OpenStack software to include key areas such as the hypervisor, hardware infrastructure and network elements.   This comprehensive approach to support is unique in the OpenStack product landscape.

— Summary of options for deploying OpenStack-based clouds. —

Examples of areas we want to talk about:

• Nova networking, network architectures, hypervisor networking, & software-defined networking (Quantum, SDN)
• OpenStack internals, open source software that works well with OpenStack
• Approaches to managing hardware and organizing cloud infrastructure
• Infrastructure security issues, security in OpenStack, hypervisor-related security challenges, and how “distributed software” impacts security generally
• Scale-out storage approaches, measuring and managing IOPS, and comparison of storage technologies generally
• Deep dive explanations of how Open Cloud System (OCS) solves some of these areas

Our slogan in engineering at Cloudscaling is “simplicity scales,” which inspired the name of the new engineering blog.

Come on over and check it out.

“We want to own corporate workload,” said Pat Gelsinger, VMware’s CEO. “We all lose if they end up in these commodity public clouds.”

James Staten, who has lately been on an incredible roll in terms of his vision and foresight in recent research on cloud computing (paid research), nailed it in a cogent response on his blog.

I want to fill in some of the gaps.

Background
At various times since pretty close to the inception of cloud computing, I have engaged with the leadership at VMware and explained what is required to help them maintain dominance.  Unfortunately, on all these occasions I was rebuffed.  VMW’s hubris is to believe that their lead in enterprise virtualization will translate into success in the public cloud space.  Other voices have since joined mine in making this point, yet Gelsinger’s recent admittal at the partner conference is nothing less than a public statement of VMware’s impotence in this regard.

Simply put, VMware does not understand what is required to win in the public cloud space nor are they willing to listen to those who do.

The Emperor Has No Clothes
VMware’s failure to ‘get it’ stems, classically, from The Innovator’s Dilemma, as Staten so righteously points out in his blog post.  In this case, their value chain of partners and technology has simply kept them from being effective in managing the transition in what is clearly a disruptive upheaval to their business.

At Cloudscaling, I coined the phrase: “the two cloud model” which is at the heart of the disconnect.  Our product manager, Azmir Mohamed, put this into words and graphics in this blog posting.

Put more plainly, there is the way that cloud pioneers like Amazon and Google built their clouds and there is the way that VMware asks people to build clouds.  These are not the same in any manner.  The datacenter design, hardware, hardware architectures, network, networking architectures, software, software architectures, and applications, are all fundamentally different.

Enterprise Virtualization is the ASP Business Model Redux
In 1999 there were two competing business models: Application Service Providers (ASP) and Software-as-a-Service (SaaS).  The ASP model lost and SaaS won.  Why is that?

A quick glance at a representative 1999 press release from Oracle and Qwest at the time will tell you everything you need to know.  The ASP business model essentially said: “We’re going to use the same hardware, same software, and same labor pool as you.  We’re going to add a margin, own all of the hardware and software, and keep the entire bundle in our datacenter.  You’ll have your own isolated Sun server running Oracle software that you can access over the network.”

It was in truth, a pure outsourcing play.  This model, of course, lost horribly to the likes of Salesforce.com (SFDC), the canonical SaaS company, who defined the category.  SFDC won because they rethought the entire stack: hardware, software, datacenters, labor pool, and business delivery model (signup with a credit card).

Does that sound familiar?  That’s because it’s the exact same playbook as Amazon Web Services (AWS).

Enterprise public clouds built to look like enterprise datacenters are operating at a significant competitive disadvantage to AWS.  They aren’t elastic clouds, but something else.  These enterprise public clouds are pure outsourcing plays that can’t ever be successful as long as they are designed, built and delivered the way they are today.

So it’s a complete loss, right?  AWS has won?  Not so fast…

The Elastic Cloud Model for Enterprises
The advice I gave to VMW on many an occasion was to build like Amazon.  The reality of the situation is that unlike Salesforce.com (SFDC), much of what Amazon has built is easily reproducible and difficult to protect.  Certainly, higher level services such as DynamoDB would be hard or even impossible to duplicate, but the reality of the situation is that 90%+ of Amazon’s revenues come from just a handful of lower level services:

• Elastic Cloud Computing (EC2)
• Elastic Block Storage (EBS)
• Simple Storage Service (S3)
• Virtual Private Cloud (VPC)

This list of capabilities is easily reproduced unlike the difficulties with reproducing something proprietary like the SFDC CRM application.  In fact, three of the four are available in Open Cloud System today, faithfully reproduced using OpenStack as a core technology.

More importantly, enterprises can get these capabilities both outside and inside the firewall, which was not true for SFDC’s application.  This means that true hybrid cloud solutions are possible using the elastic cloud model.

VMware’s Missed Opportunity & How to Fix It
Why then, is VMware concerned about the flight of enterprise workloads to Amazon?  The concern is because they can see that enterprise virtualization clouds are like the ASP model and have a very short shelf life.  Enterprises need a different kind of cloud.  An elastic cloud.  Unfortunately, VMware’s key technologies don’t allow you to build an elastic cloud based on VMware.

Why not?

There are four key areas of de facto or explicit restriction:

1. VMware best practices, hardware compatibility lists, and reference architectures all focus on legacy scale-up, gold-plated approaches that needlessly increase costs.
2. The VMW end-user license agreement (EULA) disallows the use of any other technology for managing their hypervisor (ESX/ESXi), particularly for hosting providers. You must deploy vCenter, vSphere, and vCloud, and the like.
3. VMW’s current business model and revenue stream is dependent on selling the more expensive enterprise licenses that focus on technology irrelevant to an elastic cloud such as DRS, HA, and similar.
4. The vCloud API is too focused on enterprise virtualization use cases (e.g. the whole vApp mess).

As Massimo Re Ferre’ of the VMware vCloud team has said before (apologies, I can’t find the exact article), it is possible to build a less expensive VMware-based cloud.  The cost of the hypervisor licensing itself is not the problem.  The problem is that a less expensive VMware cloud has none of the advanced capabilities desired by enterprise customers looking to outsource.  It also has none of the capabilities of an elastic cloud and does not look like AWS.  More importantly, VMW best practices and reference architectures will drive you towards hardware that is not as performant and storage and networking architectures that make no sense in an elastic cloud model.

VMW can’t unlock the ability to build elastic clouds on ESX until it stops insisting that its own management stack is in use to manage ESX/ESXi.  Period.  Full stop.

Bringing it Home
Dear VMware, here’s what to do, although it may be too late:

• Remove the EULA restrictions
• Work with nimble startups that understand elastic cloud, like Cloudscaling
• Focus on OpenStack as the next generation management technology
• Aim for the elastic cloud model sans vCenter, vSphere, and vCloud director

If you do this, you will bridge the gap, cross the chasm, etc.  If you do not, we’ll be looking at a followup to this posting in 2014-2015 when Amazon’s incredible growth rate will begin to significantly impact your bottom line.

Right now it’s looking like it’s going to be 3-0 Amazon.