Everything is cloud computing, Amazon AWS, etc. etc. these days. And yet for this website I kept it old school and purchased a Linux web server I had full root access to. Why was I such a Luddite? A couple of reasons really.
Curiosity killed the techie
Part of this is a learning experience. A hundred years ago I used to be a sys-admin. I still play with Linux periodically, on laptops, raspberry pi’s and virtual machines. But I wanted to build a thing from the ground up. To choose my webserver (apache or lighttpd), choose my blogging software, etc. I wanted a platform where I could do a little coding and be free to install what I wanted. And then to secure the whole platform correctly. In summary this website isn’t just a tool for me to share (or vent) my thoughts on a number of technology subjects. It’s also a learning exercise
But why so old school?
One of the supposed break-through’s that Amazon AWS provides is the ability to be charged for what you use. From a processor / memory perspective but also from a bandwidth perspective. Which for a small blog like this should be more cost effective. But what happens when my massive genius delivers the post that makes me famous. The popular web-based source code repository Github hosts their sites on Amazon’s AWS cloud platform. When they got DDoS ‘d earlier this year (supposedly by The Great Firewall of China), through no fault of their own and completely out of their control, Github started incurring a $30,000-a-day Amazon bill. Which is more than my little hobby can stand.
I’ve obviously picked an extreme example to make a point. But whilst paying for a dedicated virtual server is certainly not the cheapest website hosting option, it’s a known cost every month and something I can control.
The elephant in the cloud computing room
The pay per use / consumption model stands out to me as one of the major unspoken issues with cloud computing. The implication is that we have all bought far too many servers for what we really need. If we just moved to a usage model where we just pay for what we use then that’s bound to be so much cheaper. This concept is based on the assumption that IT (or non-IT people for that matter) have a really good idea on how specific applications are applying load to existing infrastructure. Or they have mature processes for projecting the infrastructure requirements for future applications currently in development.
Ahem
A consumption based solution like cloud has an associated requirement that product revenue is closely tied to infrastructure utilisation, i.e. if my hosting costs increase then that’s fine because that means my product is generating more revenue in line with the increased cost. But in reality how many people are re-architecting their applications this way. Sometimes that’s not even possible. Re-designing an application to tie it’s infrastructure utilisation to the revenue it will create is more than just a technology problem. It’s a business process and sales problem as well.
Summary
As a technology I’m a big fan of Infrastructure as a Service and Platform as a Service cloud technologies. I think the problem is when we are promoting them based on business reasons and not technology reasons. And often either the business isn’t engaged in that conversation, is just too far removed to understand the problem or even be in a position to make the required changes to adopt those benefits.
I’d share a picture of a Emperor but nobody needs to see that