Despite the fact that every vendor, editor, and reporter likely thinks that media attention to a concept should be sufficient to drive hockey-stick deployment, in the real world a bit more is needed. One of the major challenges that all of our current technology revolutions—the cloud, SDN, and NFV—all have is that of operations cost creep. Savings in capital costs, which are the primary focus of these technology changes, are all too easily consumed by increases in operations costs caused by growing complexity or simple unfamiliarity. That can poison a business case to the point where the status quo is the only possibility.
Yesterday, a startup called Platform9 came out of stealth with a SaaS cloud-based offering that manages “private clouds” using principles broadly inherited from Amazon’s public cloud. I use the term “private cloud” in quotes here to suggest that you should also be able to apply the Platform9 tools to virtualized data centers, which are inherently technology ancestors to most private cloud deployments. The primary target for the company, in fact, seems to be businesses who have adopted virtualization and want to take the next step. There also seem to be other potential enhancements the company could make that further exploit the flexibility of the term “private cloud”, which I’ll get to presently.
At a high level, the Platform9 is a management overlay on top of hypervisor resources and builds on OpenStack, but is designed to be an operationally more effective and complete way of viewing resources/infrastructure, applications, and users. Details of the virtualization framework—ranging from containers to VMware, are harmonized through the tools so that users get the same management interface regardless of infrastructure. That’s helpful to large companies in particular because many have evolved into virtualization in a disconnected way and now have multiple incompatible frameworks to deal with.
The Platform9 services provide for resource registration through a set of infrastructure views, and this is what an IT type would use to build up the private cloud from various virtualization pools. Application or Enterprise Architects or even end users could then use a self-service portal to obtain compute and storage resources for the stuff they need to run. The IT side (or anyone else, for that matter) can use panels to get the status of resources and instances allocated.
I’m not totally clear on where Platform9 fits with respect to DevOps tools. Logically they should be a part of the “inside” processes at the IT level, and the assertion that the APIs are OpenStack compatible suggests that as well. Presumably higher-level application deployment automation could exercise the user self-service interface, which might provide a second-level orchestration option that I think is the right answer for complex application and service deployment.
The goal here, obviously, is to make it possible for enterprise IT to deploy virtualized resources as private cloud services that have the same convenience as public cloud services would. Certainly the Platform9 mechanism is likely to be considerably easier than gluing OpenStack onto current virtualized resource pools, and that could facilitate adoption of a true private cloud framework. I think you could even assume that Platform9 would reduce the operations cost of virtualization, at least where there was a significant level of dynamism in terms of how machine images were assigned to resources. After all, the boundary between virtualized data centers and private clouds is a bit arbitrary.
There are APIs and developer programs to support third-party extension of the platform and obviously Platform9 intends to add functionality. Some of the features I’ve cited here (container and VMware, particularly) are future enhancements not available in the current beta release, and I’m sure the company expects to have to enhance the platform over time. They’ll need to because there’s likely to be a lot of other approaches to the same problem.
As I noted earlier, I think the company should look at further generalization of that “private cloud” term to broaden the range of IT environments it can accommodate. To offer IT on a self-service basis, it’s probably not optimal to think that all of it is deployed on a private cloud. Obviously some is likely deployed on a public cloud or would be cloudburst there or failed over. Equally obviously, some IT operations are neither based on virtualization nor on cloud computing; they’re the old business-as-usual multi-tasking server apps. The point is that it is very unlikely that everyone will be all private cloud in the strict, explicit, sense and so the benefits of Platform9 would be limited unless it extends itself to cover the range of hosting options actually used. This kind of expansion could let Platform9 provision PaaS and SaaS cloud services, hybrid cloud, and pretty much cover the opportunity space.
Another area I’d like to see the company address is that of operationalizing the infrastructure itself. Cloud adoption is a combination of deployment and lifecycle management. Some of the cost of private cloud is associated with the registration of the available resources and the commitment of those resources, but some is also associated with sustaining those resources using automated tools. I suspect that Platform9 believes that third parties can enhance its offerings with automated lifecycle management, and if that’s the case I’d prefer they be explicit about that goal and also talk a bit about the APIs and the progress they’re making in having partners use them for this important task. The company may also have some plans of its own in this area; it lists SLA management as a future.
I think that the Platform9 approach is interesting (obviously or I’d not have blogged about it). It demonstrates that there’s more to the cloud than capex reduction, and that in fact operational issues can be profound problems for cloud adoption. It demonstrates that there’s value to abstraction of “the cloud” so that users are more insulated from the technical details of cloud software. If the company evolves their offering correctly, they have the potential to be successful.
This also demonstrates that the whole opex thing is perhaps one of those in-for-a-penny issues. Ideally, private cloud deployment shouldn’t be exclusively private, or exclusively cloud, or even exclusively deployment. It should be cradle-to-grave application lifecycle management, both in the traditional sense of ALM and in the more cloud-specific sense of managing the application’s resources to fulfill the expectations of the users. We’ve had a tendency in our industry to talk about “opex” in a sort-of-two-faced way. On the one hand, we say that it’s likely a larger cost than capex, which is true if we count the totality of operations lifecycle management. On the other, we tend to grab only a piece of that large problem set. Platform9’s real value will be known only when we know just how far they intend to go.
The timing of this is interesting. We have clearly plucked most of the low-hanging fruit, in terms of cloud opportunity. Absent an almost suicidal downward spiraling of costs driven by competition among providers, the IaaS cloud has to draw more on operations efficiency or it will stall. We will likely see enhancements to cloud stack software to accommodate this, improved management/orchestration coming out of the NFV space, and additional commercial offerings. All that is good because we need to optimize the benefit case for the cloud or face disappointment down the line.