In more than 25 years of technology reporting rarely ran into such chaos as I did reporting a recent story for Computerworld on open source cloud frameworks. Just about everyone worth talking to claims to have a framework; just about everything valuable calls itself a framework; and just because you have (or are) a framework doesn’t mean you don’t need another framework to get anything done.
Let’s start simple: A framework is a collection (or, if you prefer, library) of software that helps you do something. In the case of cloud frameworks, the objective is to develop, deploy and/or manage a cloud-based application. The “library” of enabling software that makes up a framework might include development, management and test tools, middleware to link the application to other cloud components such as databases, or APIs to make it easier to move applications among clouds.
A Pain in the PaaS and the IaaS
Some frameworks are designed for use with private clouds (those within a customer’s own data center.) Others are for public clouds, such as those hosted in multitenant (multiple customer) environments such as Amazon. Others are designed for “hybrid” clouds (a mix of public and private) except, of course, if by “hybrid” we’re talking about a mix of physical and virtual servers, as some vendors do.
Then, of course, there are cloud frameworks built at various levels of the “stack” that leads from the base hardware to the applications user see. Infrastructure as a service (IaaS) clouds help customers deploy servers, storage and networks; platform as a service (PaaS) platforms have all the tools needed to deploy actual applications. Each level of framework provides a different combination of price, agility, control and security. A customer might need one framework (such as OpenStack) to provision virtual machines, and another (such as Opscode Chef) to describe how those servers will be configured.
Confused yet? Consider that not all frameworks have all the pieces customers need to not only deploy but manage very large, complex applications over time. Some, such as Eucalyptus and Deltacloud, are APIs (application programming interfaces) aimed at making it easier to move applications from one cloud to another. But customers have found that without the ability to also move underlying services, such as data storage, from cloud to cloud these APIs fall short. If your framework can provide that (or you need another to do this work) say so.
Some have even built their own frameworks after being unable to find one that handled enterprise-scale requirements. These requirements include updating hundreds of applications, providing the strict levels of authentication needed for financial applications and discovering and reusing services such as security and data warehousing. If you can provide these services, these are big draws for enterprise customers.
Open Source or Not?
Many large organizations now see open source software (where the source code is freely shared and open to improvement by customers and others) as a safer choice than proprietary code, as long as they can get enterprise-level support. But whether a framework is truly open source and not tied to one vendor can be another mystery.
Some frameworks have a true open-source feel (geeky Web pages with no major company logos.) Other frameworks are backed with financial and technical help from big-name software vendors. Cloud Foundry, for example, is backed by VMware, while Red Hat’s Open Shift is based on Red Hat Enterprise Linux.
That big-name backing is often a plus, not a minus, to customers. But it raises another question in customers’ minds about just how committed the vendor, or partnership of vendors, is to open-source versus their own in-house products. Providing details like the number of developers you’re committing to open source, what modules or code you are contributing to the effort, and how open you are to new members joining the “community” and pitching in. Those are all questions I hear customers asking when considering open source frameworks.
Guess What I Am. Go Ahead. Guess.
Kudos to those who clearly explain what type of framework they are (the level at which they operate, what functions they do and don’t provide, and exactly what role commercial vendors play vs. the volunteer “community.” But others confuse customers with cute product names and high-level benefits such as “agility,” “flexibility” and “portability” without explaining whether or how these hold up under the scalability, manageability and security requirements of the real world.
To avoid being swept away in a flood of look-alike offerings, use my tried and true “fill in the blanks” formula to make your framework pitch more understandable:
“(Product name) is a “(noun) that (verb, verb, verb.)
The product consists of (noun, noun, noun.)
It is better than competitive products (adjective, adjective, adjective) because it (specific claim, specific claim, specific claim.)”
And be sure to describe, clearly and up-front, how you meet the life cycle application demands of complex enterprise environments if you hope to serve that market.
Like this post? Subscribe to my RSS feed and get loads more!