Clouds Evolve: Dealing with Infrastructure Complexity

As expected, at least by me, Amazon EC2 is evolving in a more “concrete” platform good for web hosting; in fact, some time ago I received a mail from AWS announcing two new features: Elastic IP Addresses and Availability Zones (you read for sure the news also on Slashdot: Amazon EC2 Now More Ready for Application Hosting, isn’t it?)

After my last post (which has got an update since then), I discussed the technology with a couple of colleagues in the system administration field and the general opinion is that there not sufficient trust right now for using these services for production and/or large projects: in the best case they are seen as not yet reliable as real hardware, in the worst as something still too “academic” to be used today.

I’m sure that this is about to change not only because real hardware is way too expensive to manage directly, but instead because the complexity of application setups which continues to grow more and more, with a lot of details regarding every included element to be taken into account only by humans: so what’s the difference in moving the management of this complexity from hardware level to virtual hardware/cloud level?

In my opinion the main difference is that virtual hardware management can be automated through software itself: think about a day when, inside your application installation script, you’ll have also an environment deployment script in which you’ll have a description of the environment required by the application and anyone will be able to run in on any cloud computing service through a cloud service console (yes, someday there will be a standard that will define the API to access all cloud services… maybe someone wants to start to talk now about that?): load balancers, web and database servers (with their operating systems and applications), firewalls, IP’s, everything will be instanced with a click on a button.

At the real hardware level will remain the simplest of system administration duties: take bought hardware, find a space somewhere or order new racks and network hubs, plug in power and network cables, turn on the switch, maybe insert a CD or better count on network boot, throw away old/broken hardware and… stop, no complexity at all (this is not entirely true, as every system administration professional can tell, but let’s assume it here for simplicity’s sake).

All the experience at application setup level will be transferred to the cloud management software, letting sysadmins specialize in it and not in all applications that will run on it, passing from a fragmented knowledge to a specialized one: this means less problems solved in less time, the creation of clear roles, more satisfied sysadmins, more satisfied developers, and so happier customers.

2 thoughts on “Clouds Evolve: Dealing with Infrastructure Complexity”

  1. Why I’m against cloud?

    There was a time when people was drive to buy hosting solution, and the one that had few money got ‘shared hosting’ solutions. To have a ‘shared hosting’ was something bad, poor performance, unknown infrastructure details, high dependency on hosting provider commercial and technical policies to guarantee the level of services. But one day some marketing guy had a very smart idea. He took the ‘shared hosting’ solution and start to refer to it as ‘cloud services’, and it become a cool solution 🙂 … amazing the power of marketing tools!

    Beside this joke (not really a joke honestly): cloud (let’s call it as it has to be called: shared hosting) is a good solution if your application is not critical.From a system engineer point of view to administer a could (as for every virtualized\consolidated environment) is a mess. It does reduce costs in terms of hardware but it mean incomparable complexity in terms of monitoring, maintenance and analysis (expecially for performance). Took this together with the commercial aspect (the same 100 G of disk space sold to 20 different customers because they will never use it completely, but when this happen? and you know that this will happen at a certain point in time). First thing that happen when you have a virtualized\consolidated environment is that you start to experience random slowness, this is usually linked to latency and conflict on I\O resources (network and more frequently disks). When your service is hosted in a cloud you will never been able to discover where the bottleneck is and you will keep your random slowness after month and month of code review to try to identify the issue internally to the application.

    Shared hosting is good for non critical application (my personal web site is proudly on a shared hosting but I really do not care if it remains unavailable even for days and performance is really far far to be a concern for it) but critical application do require dedicated services, where it is possible to control the resource available and used (and for the same reason in most cases also a dedicated virtual platform is not enough but physical machines are required).



  2. Thank you very much for your comment, well done! I’ll take the time to respond to it with a full post because it helps me understand better what is a cloud and in which ways can be helpful and better than bare hardware/virtualization/shared hosting.
    Here I want to say only that cloud computing *is* different from shared hosting, like a programming language is different from assembly or an operating system is different from hardware, because it helps humans deal better with complexity.

Comments are closed.