If you deploy OpenStack on your own, you are doomed to FAIL !

We are glad to bring you a no-holds barred conversation with one of the founders of EnCloudEn. The company has been making a lot of noise recently by claiming to have solved the OpenStack conundrum on the ideal mode of deployment. As such, we thought it would be best to hear straight from the horse’s mouth.

(Sharun, who has had years of experience in the communication industry is in conversation with Abinash Saikia, Founder & Director, EnCloudEn)

Sharun: Let me start straight away by addressing the elephant in the room. EnCloudEn has been quite vociferous in the industry these days with its claim that if companies are deploying OpenStack on their own, they are doomed to fail. Don’t you think that’s a strong statement given how it’s been more than 7 years now that OpenStack originated. And we have seen wide scale adoption across the world, a lot of them in-house.

Abinash: Let me ask you in return what do you think that the intent and purpose of most organizations who want to go the OpenStack route are?

Sharun: Well I would think that given that it is an open source alternative to the likes of VMware, it would be a much more affordable entry to building one’s private cloud.

Abinash: Exactly! Affordable, convenient are the terms that would come to your mind once you decide to embark on the OpenStack journey. But that’s exactly what it’s not. You have this whole notion that your in-house DevOps team can read up what OpenStack constitutes and start deploying it. They start with either a Dev stack or Pack stack, which are equivalent to most college second year projects, and that early success leads them to think that they can move up to a proper production deployment. Well, let me be frank. No company in the world has successfully deployed OpenStack in production with a budget of less than a Million Dollars. More likely, several million.

Sharun: That seems like it’s defeating the purpose of moving out of another equivalent proprietary software if that much money is required.

Abinash: And that’s just the tip of it. What we are saying is nothing new. A simple google search on the costs of deploying and maintaining OpenStack will reveal lots of interesting comparisons with other solutions. But that’s just the beginning. Each of these successful OpenStack deployments have been built by huge teams of engineers, who are certified in OpenStack. Forget about the costs of such personnel, but the fact that you have now moved from being dependent on the software to being dependent on exclusive personnel has its own ramifications. The number of great OpenStack certified engineers are still not that many now, they still aren’t available at a moment’s notice and also each deployment can be unique in itself. Thereby increasing the human dependency even more.

Sharun: But isn’t that the case with most software deployments? Otherwise why would you have an in-house IT team, isn’t that the human resource that most companies are building?

Abinash: Well that’s the difference between a proprietary software and an open source one. Don’t get me wrong, we love open source ourselves, they are some of the building blocks of our solutions as well. But, whereas the onus of maintaining a proprietary deployment is on the Vendor who has built the software, in an open source world the onus lies on the company itself. Now for most open source solutions, it’s pretty doable. But OpenStack is a behemoth. The sheer complexity of it is truly unimaginable. That’s why you have the likes of Red Hat and Mirantis flourishing with their OpenStack services business. So, what starts as an innocent attempt at building your own private cloud, pretty soon sees more and more money getting funneled into the project. Inevitably, the dollars spent get to such a level that you were better off having bought VMware at the start. But then, you have already made your investments and now you are stuck trying to prove that you were right as a decision maker in moving to OpenStack.

Sharun: So how is EnCloudEn trying to right this ‘wrong’, if I may call it that.

Abinash: Indeed that is what it is. We are here to help companies avoid making that mistake and sinking deeper into the quagmire with each passing day. What we believe is that there is a fundamental difference in how OpenStack is to be used. What you need is a stack that has been developed and packaged as ready for consumption. Each free OpenStack distribution pretty soon runs into its own set of problems that are too hot to handle for the in-house DevOps teams. That’s why we believe that the only sustainable way forward (unless you want to burn a million dollars on the project) is to use the EnCloudEn Productized OpenStack Distribution.

Sharun: So you mean like pure plug-n-play.

Abinash: Exactly, you took the words right out of my mouth.

Sharun: Well, thanks. But isn’t that what some OpenStack vendors were providing a few years ago? How is EnCloudEn different?

Abinash: Let’s just say that at EnCloudEn, we have the late mover’s advantage. Till now, if you were to source outside help for your OpenStack deployment, there was one of two paths that you could take. One, buy a rigid OpenStack distribution that also had a deployment engine inbuilt into it or two, take the distribution that is close to the open-source one and buy the services from one of the OpenStack companies. While the first choice would give you an easy to deploy option but sacrifice all the flexibility of OpenStack, the second would have you reaching out for help for every little thing.

That’s the gap that EnCloudEn helps bridge. In an ideal world, you want to enjoy the benefits that OpenStack brings but enjoy a complete hassle-free production experience. EnCloudEn’s POD (Productized OpenStack Distribution) brings you this ideal solution.

Sharun: Would you care to elaborate a little more on that please.

Abinash: Sure. When we designed the POD, we looked at 3 different parameters – what were the most stable and central components and services in OpenStack, which components of OpenStack had to rewritten or a substitute built and what were the other architectures/products that OpenStack generally works with to build a complete private cloud. So the POD combines all 3 of these qualities and also delivers them in the most optimum fashion.

I’ll give you some examples on these. So, when you deploy a plug-n-play OpenStack distribution, you are generally worried on the upgrade path. To counter this, the POD is built on the most stable of OpenStack components for its base. These have hardly seen any change over the years. In this fashion, the POD is able to resist the need for constant upgradation on existing deployments and also at the same time offer all new deployments with the latest version compatibility of OpenStack.

For components which needed replacement, you can easily look at the default orchestration and monitoring components of OpenStack. The monitoring is slow and the architecture doesn’t scale well at all. We completely revamped this and built our own monitoring ground up. It is now based on a distributed data store, scales with each new node addition and guarantees sub-second queries irrespective of the size of the deployment. For the orchestration, the OpenStack service is just restricted to the launching and provisioning of VMs. The other orchestrations are either non-existent or not mature enough.

Today, the POD doesn’t come only with VM orchestration. It sets up the entire cloud in a Highly Available production grade architecture with addition & removal of nodes all automatic. But the best part of it is that the EnCloudEn orchestrator goes well beyond this and also gives the POD capabilities of application and process orchestration to give you full control over what’s happening inside of your VMs.

Sharun: That definitely sounds intriguing. The other day I was in conversation with a CIO and he was mentioning on how he wished for application control to be inbuilt within their cloud. You were also discussing something on comprehensiveness outside what OpenStack provides.

Abinash: Yeah, that’s the other ground that the POD covers. The traditional 3 tier architecture has more or less become niche and HCI is what everyone desires by default today. So, we looked at how we can base our POD on this as well. And voila, our engineers came up with the perfect solution. Today the POD comes with its own HCI, a native platform that is vertically integrated with the entire OpenStack Cloud. And because of being tightly integrated and not any generic HCI solution, the POD today generally just requires between 8-12% of system resources to run any average size cloud. Those are industry leading numbers.

Not to mention, the same POD node can run as a Controller, Compute, Storage, Network, Monitoring and Granular Orchestrator all together if required and still deliver around the same numbers. In just 3 nodes, you have a fully featured Hyper-converged, Highly Available OpenStack Cloud. I doubt anyone else in the Industry can match up to that.

Sharun: Well, that seems like the perfect note to end this conversation. Thank you so much for taking time out from your busy schedule to take us through the entire though process. We hope that we can have another chat soon to discuss all the new innovation happening at EnCloudEn.

Abinash: Thanks for having me. It’s been a pleasure to be a part of this discussion.

Leave a Reply

Your email address will not be published. Required fields are marked *