Earlier today, Chris Kleisath wrote an excellent post entitled Behind Every "Cloud" There are Real People. In that post he noted:
The challenge vendors face when trying to market and sell something for "the cloud" is that the definition of "the cloud" is so broad and varied.
I would add that I think this broad and varied definition is the fault of those same vendor's marketing departments. It is an unfortunate reality that you can count on all vendor's marketing teams to seize the technical buzzword de jour and co-opt it to fit whatever they are selling.
Disclosure: I am a member of the Sybase marketing team. :smile:
As a result, the word "cloud" conjures up connotations of cost savings, opportunity, risk, loss of control, flexibility, and general anxiety all at the same time. I think this is what motivated Chris’ assertion:
Ultimately, behind every "cloud", there are real people managing real machines. What is marketed as a "cloud" is really a rack of machines, with a very real person who has to keep them running. To that person; the administrator, the "cloud" isn’t "in the cloud", it’s in his own data center! The administrator must put together a set of machines, software and administrative tools that enable everything to be viewed in a completely hands-off way by the users, so that they think of it as a "cloud".
It wasn’t until I read this post that I realized that the broadening of the term "cloud" has conflated two related, but distinct concepts. Specifically, "Cloud" and "cloud computing" are not the same thing. "Cloud" refers to the place things are running. "Cloud Computing" is a set of technical characteristics.
I believe Chris’ post is dealing with the first concept, where the "cloud" is, and the fact that at the end of every cloud metaphor is, "a rack of machines, with a very real person who has to keep them running." However, that doesn’t say whether or not that real person with the rack of machines is utilizing cloud computing concepts to help them get the most out of those machines.
Recently, we launched the "Fuji" Beta program for our new product, SQL Anywhere OnDemand Edition . Like most marketing departments have been doing with their new products, we have been claiming that Fuji is a "cloud" solution.
This then begs the question, is Fuji really a cloud solution? Or rather, does Fuji exhibit the characteristics of cloud computing? After all, if Fuji were nothing more than co-location of databases on a rack of servers, then there would not really be anything "cloudy" about it. This topic came up very directly when we launched Fuji in September. During analyst briefings, I was asked to defend how Fuji could be considered a cloud, and not just co-located hosting. In essence, we were being asked to defend that we were not guilty of the buzzword hijacking previously described.
Fuji is a cloud, and I aim to prove this by showing that it exhibits all of the characteristics of cloud computing. As we have already established, it is hard to get a good definition of cloud. As a result, I am going to rely on the wisdom of the crowd, and use the characteristics listed on the Wikipedia article for Cloud Computing . For each characteristic, I will explain how Fuji achieves it:
1. Agility improves with users' ability to re-provision technological infrastructure resources. Fuji provides this agility in two forms. The first is that you can dynamically add and remove computing resources to handle variable workloads. The second is that you are able to flexibly move databases amongst the computing resources to help achieve better throughput, and prepare for bursty workloads.
2. Application programming interface (API) accessibility to software that enables machines to interact with cloud software in the same way the user interface facilitates interaction between humans and computers. Cloud computing systems typically use REST-based APIs. Communication in Fuji works in this manner. Fuji uses a OData , a RESTful-like interface for communication between machines. This API is currently exposed through the Cloud Command Utility which allows actions in the cloud to be scripted.
3. Cost is claimed to be reduced and in a public cloud delivery model capital expenditure is converted to operational expenditure. This is purported to lower barriers to entry, as infrastructure is typically provided by a third-party and does not need to be purchased for one-time or infrequent intensive computing tasks. Pricing on a utility computing basis is fine-grained with usage-based options and fewer IT skills are required for implementation (in-house). Although pricing has not yet been announced for SQL Anywhere OnDemand Edition, it would be a candidate for utility pricing as described here.
4. Device and location independence enable users to access systems using a web browser regardless of their location or what device they are using (e.g., PC, mobile phone). As infrastructure is off-site (typically provided by a third-party) and accessed via the Internet, users can connect from anywhere. The databases that run inside of Fuji can be accessed from a large number of platforms, architectures, and devices. These can range from desktop clients, to mobile web browsers. Furthermore, the Fuji infrastructure can be accessed and managed from any Flash-enabled browser.
- *Multi-tenancy enables sharing of resources and costs across a large pool of users thus allowing for:
- Centralization of infrastructure in locations with lower costs (such as real estate, electricity, etc.)
- Peak-load capacity increases (users need not engineer for highest possible load-levels)
- Utilization and efficiency improvements for systems that are often only 10–20% utilized.
* I consider this one to be the most important characteristic, and Fuji exhibits it. The whole goal of Fuji is to allow multi-tenancy. By using the agility characteristics described above, Fuji delivers on centralization of infrastructure, peak load capacity, and utilization and efficiency improvements.
5. Reliability is improved if multiple redundant sites are used, which makes well-designed cloud computing suitable for business continuity and disaster recovery. Fuji allows your computing resources to be spread across any computing resources that have internet connectivity to each other. This can even include running across multiple IaaS providers. Fuji allows databases to set up with multiple copies in a high-availability setup that can act to achieve business continuity and disaster recovery.
6. Scalability and Elasticity via dynamic ("on-demand") provisioning of resources on a fine-grained, self-service basis near real-time, without users having to engineer for peak loads. Fuji scales with the number of databases that it is running. It is a trivial task to dynamically add and remove databases. As mentioned under the "agility" section, additional computing resources can also be added dynamically to help achive this scaling. a
7. Performance is monitored, and consistent and loosely coupled architectures are constructed using web services as the system interface. All of the computing resources that make up Fuji are constantly monitoring their own performance, and using web services to communicate that to all the other computing resources. With this aggregate knowledge, Fuji is able to better achieve on the peak-load capacity and utilization and efficiency improvements mentioned above.
8. Security could improve due to centralization of data, increased security-focused resources, etc., but concerns can persist about loss of control over certain sensitive data, and the lack of security for stored kernels. Security is often as good as or better than under traditional systems, in part because providers are able to devote resources to solving security issues that many customers cannot afford.However, the complexity of security is greatly increased when data is distributed over a wider area or greater number of devices and in multi-tenant systems that are being shared by unrelated users. In addition, user access to security audit logs may be difficult or impossible. Private cloud installations are in part motivated by users' desire to retain control over the infrastructure and avoid losing control of information security. In my opinion, this is the biggest win for Fuji. By keeping each tenant’s data totally isolated from each other, Fuji provides a very strong security model. Furthermore, the ability to host Fuji yourself on a rack of machines within in your sole control can add an extra level of security. This is partially what Chris’ post was addressing (the “where” part of the cloud).
9. Maintenance of cloud computing applications is easier, because they do not need to be installed on each user's computer.
Maintenance of the cloud is accomplished though a centralized, web-based console. There is no need to visit each machine, and nothing (apart from a Flash-enabled browser) needs to be installed on a machine to administer from it.
Fuji is a cloud in the sense that it exhibits all of the characteristics of cloud computing. This does not mean you have to run Fuji in the cloud, nor do you have to think of it as a cloud. If you would prefer think of it as a data management tool for your private rack of servers, it will not disappoint you. If you would rather think of it as a data cloud layer over your raw computing resources, it will measure up.
