Passionate about filling the gap between technology and business. Explaining complexity in plain English is my thing. Thriving on #cloud, #bigdata and #microservices applications. Based in Europe. Photographer wannabe. Heavy metal guitarist.

Meta

Tag Archives: private cloud

Following the news today regarding the acquisition of Inktank by Red Hat, lots of people – me included – started to wonder how would this potentially conflict with the Gluster acquisition completed by Red Hat itself nearly two years ago. Twitter has been hot all through the day on this topic and, as one would imagine, the two companies tried to give specific explanations on how Ceph and GlusterFS are actually complementary. I’m not a GlusterFS expert but I did attend recently an exciting Ceph training course and I have some doubts on what has been said. As I see lots of overlaps between the two, the truth could simply be the failure of GlusterFS to gain traction in cloud infrastructures implementations.

First off, I’d like to congratulate all the folks at Inktank for this awesome result. And not only because they’re partnering with Flexiant, the company I work for, or because some of them are former colleagues of mine, but because they’ve successfully managed to demonstrate how innovation can be still delivered in areas like IT infrastructures, that are typically considered as heavily commoditised.

A blog by Jeff Darcy (@Obdurodon) published today went just through the comparison of the architectures, the approaches and how that the two projects could actually borrow stuff from each other. But what was stated more clearly on Twitter on their positioning is the following:

Ok then Red Hat is gonna promote GlusterFS for POSIX-compliant distributed file systems and Ceph for distributed object and block store? Really? What if a company wants a combination of the three? Are they going to roll out two separate physical infrastructures with incompatible architectures? How about the famous TCO optimisation?

If you think about it, a file system, a block store or an object store are simply three different interfaces to consume the same type of resource: data storage. For this reason, I believe that Ceph’s approach of a unified layer underneath (RADOS) and the different interface gateways (FS, block and S3-compatible object store) is the exact right approach to providing a truly scalable, resilient storage system that can be consumed through different APIs. Now it’s also true that CephFS is not a mature technology at all but if I had to pick one to concentrate my storage development investments in the future, I’d pick Ceph.

When Red Hat acquired Gluster two years ago, the company was still betting its entire cloud orchestration strategy on CloudForms (based on Deltacloud) but then OpenStack became so popular that Red Hat, leader in anything open-source, had to commit to that. Today OpenStack counts quite a few installations with Ceph as storage backend, probably more than those with GlusterFS, and I believe this is the real reason behind the acquisition.

That said, I find this an extremely smart move, given that Red Hat now has to compete against all those hundreds of companies providing OpenStack support and consulting services. Owning the technology behind one of the most popular storage implementations could be a real way to differentiate from the competition. However, I still wonder if this is enough in order to stand out from the OpenStack consulting crowd. Of course Red Hat is a rock solid company with a brand, a history and reputation that scares off most competitors, but that’s nothing if not coupled with a high pace in delivering technology innovation.

Enterprise private clouds are failing. As I’ve also written on a Quora answer to “What is the future of private cloud?”, no matter what marketing and vendors are saying, efficient, large scale production enterprise private clouds don’t exist as of today. In my opinion, cloud is an extremely new model in delivering IT infrastructure that the culture of its utilization won’t be able to reach the enterprise with a bottom-up approach (evolving from their current infrastructure) but only taking a top-down direction (deploying into public clouds and then migrating back in-house). A revolution as opposed to an evolution.

Enterprise private clouds are failing due to the wrong approach taken by the IT department. Treating the cloud just like an infrastructure stack instead of a service, because “you are building the private cloud without engaging the buyers who will consume this cloud”, Staten says.

And of course, I wasn’t the only one recognizing “the truth” in James Staten’s words. His opinion on failing private clouds echoed throughout the web, generating a large consensus among cloud experts and visionaries such as James Urquhart (@jamesurquhart):

@Staten7 This is a post I wish I had written. Phenomenally clear articulation of the problem IT has with an infra-first focus on cloud.

The two cloud models

Much has been already written about different approaches to the cloud and big brains have concluded that all of them can be summarized in two different cloud models. They have been given various names according to the author, but I shall refer to the nomenclature of the OpenNebula blog post.

Datacenter Virtualization model: cloud as an extension of virtualization in the datacenter. Some more automation, service catagloue, etc. VMware vCloud-like approach.

With reference to the above models, James Staten is basically saying that the Datacenter Virtualization cloud model is wrong. That is not the right approach to implementing a private cloud. Because “a Porsche is [not] just a Volkswagen with better engine, tires, suspension and seats.”

Awesome. I’ve been convinced about that for some time. If you read my very first post on “Cloud Computing is not the evolution of virtualization”, as the title says, I’ve been always considering exclusively the Infrastructure Provision model as the only possible cloud implementation, completely excluding the Datacenter Virtualization to be even called cloud.

And I don’t think this was an extremist approach. As I said many times, cloud is a tremendous opportunity for the enterprise to start thinking differently. In my opinion, cloud will be able to reach the enterprise IT departments only using a top-down approach: from a public cloud implementation to back in-house. Enterprise cloud consumers will try (and love) the public cloud and eventually drive the implementation of something similar within the enterprise itself. But trying to transform the current virtualized infrastructure into a private cloud will simply fail. Fail to deliver a real elastic and service-oriented cloud infrastructure to the real cloud consumers.

Vendors didn’t get it

So what? All enterprise IT departments simply didn’t get it? What’s their problem? It’s a vendor problem. Enterprise software vendors didn’t get it. Every one of them started to think of the cloud as an opportunity (that’s good, as a matter of principle) and they all just tried to profit from the hype. For virtualization technology vendors, that was an easy path: adding a new product to their portfolio to “cloudify” the existing virtualization products, that would have been a natural extension to existing implementations within the enterprise. The perfect scenario for IT departments. Pity that it doesn’t work to deliver what cloud consumers are looking for.

But recently we heard something new from virtualization vendors. They actively started perceiving public clouds, and AWS in particular, as a threat to the workload which is (was?) currently running on their virtualization technology and that’s failing to migrate to private clouds for the above reasons. Despite their very rich cloud products portfolio, workload is still moving from the enterprises to commodity public clouds. Why?

Many of you may probably think that after the success of virtualization technology they had to invent something appealing to keep pushing sales and they called it Cloud Computing. And the same people would think that cloud computing is just an extra layer on top of your virtualization management platform for better and coordinated resource management, that provides things like billing, machine catalogues, self-provisioning, etc.

Cloud Computing actually has a much wider meaning (that sometimes makes it simply look like a marketing trend) so today I will narrow it down and focus on cloud infrastructures. The questions I will try to answer are: what is a cloud infrastructure, and when can you say you’re really running your business in the cloud?

To provide the right answers, you have to think of the applications that you want to run on your IT infrastructure. Many of you have probably gone through the server consolidation process that made VMware a billion dollar company: you had lots unused hardware resources but you still wanted to separate operating environments so, no problem, hardware virtualization could solve that for you, without the need to change anything in your application code or architecture. The same application you were running before on the bare-metal would run exactly in the same way inside a virtual machine.

After server consolidation practices became common, somehow the evolution of hardware virtualization went much faster than the evolution of applications. Hypervisor vendors started to provide more and more features to make the underlying hardware always available for running applications, so they could endlessly run without even caring about potential hardware failures.

What people tend to forget when buying powerful hardware platforms is that application failures are much more the primary reason of outages than hardware failures. For this reason, sooner or later you realize that and you have to build up an application-level redundancy in order to implement a real highly available system. But with application-level redundancy, do you still need to have underlying expensive hardware? Why not to run your application on commodity servers?

This question will lead to the real concept of cloud computing. Let’s now try to give a definition: a cloud infrastructure can be called so if it:

And what is the purpose of all of the above? If you think carefully, you’ll realize that it’s all aimed at commoditizing the infrastructure itself. Companies shouldn’t spend anymore time to build up their IT foundations but they should concentrate on their actual business workflows, supported by really innovative applications. Infrastructure is something they want to take for granted.

In this scenario, a cloud platform should have another important characteristic: it has to be cheap.

So can you achieve all of that with a traditional hardware virtualization-powered infrastructure? No.

Scalability will be an issue if you’re using centralized resources (that can’t grow big forever) that are usually necessary for providing hardware-level HA.

You will feel safe thanks to all those automatic live machine migration features but don’t forget that they protect you only from hardware failures. If the application fails there is not much they can do for you. You should protect yourself from application failures by building a redundant application architecture but, if you do so, do you still need expensive hardware-level HA? No, you don’t.

And one more thing, cost. Hardware virtualization infrastructures require complex high-end hardware that won’t get the point of being cheap in order to turn the IT infrastructure into a commodity.

In the end, do you want to run your old legacy application in the cloud? Forget it. Just keep it on your powerful expensive virtualization platform. That will work just fine. But if you’re a visionary who believes in a future that requires performant, scalable, elastic and cheap commodity IT infrastructures, then choose your next applications to be cloud aware. That will take you much further, much faster.