Some key takeaways from the "Cloud is more efficient than your own DC" debate.
During the PLNOG conference, my team member participated in an “Oxford debate” called “Cloud is more efficient than your own DC”. Even though he’s joined the opposition (DC enthusiasts) he and the rest of the participants turned their attention to some key factors, which I’d like to sum up:
First of all, no matter what size your company is or how many specialists you’ve already got, regarding on-premise technologies, moving to the cloud is a never-ending, continuous improvement and knowledge gathering process. Choose external, experienced companies or do it by yourself, however, be curious and open for changes.
Cloud is definitely not, do not believe in any bull***t, an out-of-the-box magic button which you press and it’s being launched and integrated. It solves many issues by its ready to provision services, which of course are feasible to develop and implement by your team, but honestly guys time is money and ask yourself what your business team cares the most about. Don’t get me wrong, I believe that humans are able to create tremendous things, you can even create your own, better cloud, but literally is it your goal, because you don’t believe anyone can do that better? Or, maybe you want to develop your brilliant ideas which are your app or new business.
All these stories about tools, which some of them I consider as really great, are nothing more than abstractions onto the cloud.
Every day you see a new bunch of tools around our old friend JSON which cloud’s API is ready to serve and believe or not but devs from all over the world love that because API is like their best buddy from the team. They know each other very well and it’s their natural way of communication. That’s why clouds becoming a natural environment for your developers’ teams.
Anyway focusing just on the tools will make a pain if we don’t explain what the tools do and why. Do not ever try to think about a tool then match a problem, but my suggestion is, always to define a problem and search for the proper tool. Same as do not use the cloud because someone has told you, rather perceive it as a remedy for your problems.
Vendor lock-in is something that exists for ages and I’ve spent more than 8 years watching how, those former admins, now more fancy “DevOps” from on-premise would die for their vendors who promised them new features, discounts, etc. Everyone is telling the same story, it depends on what your goals are. If you want to be independent, go on, run your environment in 3 different clouds, of course, if you’re lucky enough to have specialists ready to be on time and develop your products. You can always start with one and change it or add another but it’s the same story like well-known migrations between different on-premise vendors. Of course with got Terraform and all those wrappers, frameworks, but come on, it’s always a process, someone’s responsibility for making a decision about change/migration. There’s nothing wrong with being related to one vendor, provided your intentions are based on technological choices. Actually, it was the cause that turned me into the cloud solutions. I’m lucky enough to have my own company fully focused on technology I believe in, which in our case is AWS, and it’s not the point to only love AWS or even cloud, but to choose wisely and solve problems fast.
It can be Google, Azure or any other. Anyway, I’ve never seen (correct me if I am wrong) that AWS has raised the prices of its services. I can only say about AWS because it’s the only cloud provider we’re working with, but answer yourself about others.
One point of the discussion was about the time needed to deliver and install new servers, which as I understood was kind of example of the expansion of your current fleet. Spending time inside the on-premise world taught me one thing — there is no such thing as instant order. It was mentioned during the debate that implementation of a new server in your fleet takes several hours, let’s take 2 — you’re pro. Hmm, someone has forgotten about the time of delivery/shipping, the time needed for order acknowledgment, time for pre-provisioning or on-site provisioning and all of that stuff that people, whoever ordered anything from well-known networking vendors, know well. I think I might have missed some points but I think you’ve got the clue. Contrary to this scenario you’ve got an out-of-the-box service like EC2 (AWS) which allows you to launch an instance (VM) with attached volumes and networking configuration by just choosing several options and clicking “launch” button. Simple, yes it is and the cloud is all about that — make service delivery simpler. It’s always about someone’s time needs to be spent — decide how much you’ve got.
Another topic that was mentioned is using self-managed services offered by cloud as a replacement of laborious maintaining complex solutions which does not bring much more value.
This cost is always very hard to predict and calculate in case of maintenance work of our solutions we build. But it is very clear that creating their own solutions from scratch (load balancers, DNS, firewalls, etc) is always connected with this whole baggage of maintenance responsibility. Those ones which measure their success only until implementation time will be surprised and faced with reality very quickly. Work smart, not hard and have time for improvements rather than fixes and operations. And first of all, calculate and find a balance between value and cost your business required.
Do not believe in words that migration to the cloud is going to prevent your environment from failures, but also do not listen to those who believe that their DC won’t ever fall down. Below are some examples:
I believe in the thesis I’ve heard from CTO of Amazon “everything fails” so you can neither think about your “own” data center as 100% reliable ones nor about clouds. AWS, Azure, Google, I mean all of those heroes fail sometimes (whole regions, availability zones, data centers) even though they are experts in provisioning their services.
I found a quote from the book The Psychology of Science, “if all you have is a hammer, everything looks like a nail”. Companies tend to follow other’s standards. You won’t use PHP because Facebook did and do not follow a DevOps or cloud approach because someone else did. Always think about what the best interest for your success is. Of course, you have to learn from others’ successes and explore new ways of innovation. Don’t implement DevOps to conforming to the norm rather define the norm that leads you to success.
We'd love to answer your questions and help you thrive in the cloud.
