There was this awesome session abstract that was submitted for this years VMworld by Will Huber (@huberw, VCDX #81) and Tim Gleed (@timgleed, my manager 🙂 ) titled “How to lose a cloud in 10 days”. I would’ve loved to hear from these 2 guys what they thought were critical mistakes for a cloud environment. But unfortunately it wasn’t the case, the session was not selected for VMworld. So here is my take on that session:
- Trying to pull all or nothing migration
Trying to pull an all or nothing migration when migrating to a cloud provider or to an internal hybrid cloud is primarily the top reason for a cloud project to fail. Think about it, while planning for migration, did you or anyone identify the applications and the data which would be suitable for cloud provisioning. If you’ve answered yes, then did you try a pilot of that application in cloud and run it for a group of users. If you’ve answered yes, then did the users require more performance, did they have any issues with the performance or availability of the application. See where I am going..
- Using Cloud to solve a business problem
As I’ve said before in my previous post, if you are looking for a technical solution or even worse a cloud based solution for a business problem, then the project is doomed from the start. One thing you definitely don’t want to do in a cloud environment is bring with you all the old grungy habits running IT as a Cost Centre. Any process or problem which exists in your non-cloud environment needs to be corrected before you bring that across to cloud environment.
- Treating Cloud project as Virtualisation + chargeback.
I recently spoke to a customer (not naming customers) who said “Isn’t cloud just virtualisation + chargeback”. Umm.. No. If your business want to adopt a cloud methodology then you have to fundamentally change the way you run your IT. Its no longer a cost centre, its a business unit. Exactly like the Investment Brokers, Retail Banking, etc. You pay money to this business unit and they provide you with a service. Not just any service, the service that you will have access to deploy yourself. Think of it like ordering a pizza. But what a lot of companies forget is, moving to a cloud methodology is basically a huge transformation project. One needs to educate and re-educate their users in the new way of doing things. Explain the consequences of not following certain pre-defined rules.
- Choosing Cloud Tech that your techie guys don’t get or understand.
This probably rates as the best way of getting everybody pissed off about cloud. If your tech guys don’t understand or know what cloud tech is running the environment, they can’t help if there is ever an issue. You don’t want to wait for the vendor to fix the issue all the time. When there is a problem, you need people who not only understand the technology but are actually well versed with the product suite to fix the issues. Granted not all of them will be fixed by your tech guys, but they still need to be able to fix minor issues. For example, deploying an Openstack cloud, when all your admins only know Microsoft is the wrong way to go. Go with Hyper-V based cloud in the said example, atleast your guys know something about Microsoft.
- Not monitoring or managing the underlying infrastructure
Do you look at your cars fuel gauge now and again? Do you calculate how many miles/kms more you can do before you most definitely have to fill up ? Yep thats the simplest form of monitoring and capacity planning I could think of. Your cloud is like your car, and what runs your car, yep the underlying physical infrastructure. The key point to note here is I am not talking about public cloud like AWS, vCloud Air, Azure etc. I am talking about your private cloud. If you don’t manage your physical infrastructure and don’t have adequate capacity planning. The whole cloud is going to grind to a halt. Cloud enables easier consumption of resources to the users, that doesn’t mean that the infrastructure is invisible to you. You know that your compute vendor takes 3 weeks for new kit to deliver and internal processes mean another week before you can get it ready, If you don’t have atleast 4 weeks worth of compute available at every single point in time. You are one step closer to failure.
- Believing in ” No such thing as Hypervisor ‘lock in’ “.
If your cloud vendor says there is no such thing as a Hypervisor lock in, they are lying. Of course there is Hypervisor lock in. VMware use ESXi, Microsoft use Hyper-V, Nutanix use KVM (Acropolis). They are all specific to each company. What shouldn’t be locked in by hypervisor if your application deployment model. If your application team is smart enough, they will ensure that they “containerize” the application so its less dependent on the OS, which is dependent on the Hypervisor. If you deploy an application to AWS, even they want it in a specific format using specific APIs. So there is such a thing as a lock in and it doesnt just stop at the Hypervisor layer.
- Not having proper resources to build a custom cloud.
OK, so you are a maverick, a risk taker, someone who says “F*** You” to all vendor cloud providers out there. You want to build it yourself using Openstack. Well good for you. The question you need to ask yourself is, “Do I have the people with the required skill set to develop something thats already been developed ?? “. And even if you do have the resources, wouldn’t it be better off to use those resources to build something more valuable to your company. Dont get me wrong, Openstack is great. Its more modular and extensible than any of the major cloud vendors out there, but its also that much more complex to get it right. So unless you are willing to bet your future on it, take an educated and risk aware decision.
- Believing that a traditional 3 tier app will scale like a cloud native app.
Unless your application has been custom built for cloud (so called 3rd gen applications), its not going to scale like Facebook or Google. Want to know why, because the applications that Facebook and Google use or rather you use, they have been developed and deployed “FOR CLOUD”. Your traditional 3 tier app might not scale so well in cloud if you haven’t designed or developed it correctly.
- Not Having a SDN strategy.
I am not picking sides here, but if I had to do it in my company, for a SDN strategy, I will definitely use NSX. I have my reasons behind it. So should you. If you don’t have a SDN strategy for your cloud environment, you are doing it wrong. Everything in cloud environment needs to scale with time. You know what doesnt like scaling .. networking. Because you’re physical bound to certain entities. So you need to de-couple your company from a physical networking place to a SW defined networking place. Imagine you deploy 100 VMs or containers or whatever in a matter of minutes and are waiting for the firewall rules to be created for each of them. Now imagine your CIO breathing down on your neck asking “why is it taking so long ???”. Thats why you need to have a SDN strategy.
- Ignoring DR or not thinking about DR because “its all in the cloud”.
Last but not the least, in fact probably one of the more important ones. Imagine you spend $5 million on your next gen cloud environment and the DC everything is being run from burns down. Do you have a backup ? Yes of your cloud environment, with all the application and user data as it was before it burnt down. Its hard to realise that you need DR despite everything being run inside “cloud”. The cloud still has to run somewhere, and no one hopes for it, but you should be prepared that eventually shit will happen.
With that I am done. Thanks for having the patience to read a long one.
Please feel free to comment on this and if you think I need to add more, feel free to do so and I will credit you in the post and update it.