11 October 2010

Cloud computing yet again

Last week I may have expressed quite a biased viewpoint about Cloud computing since it's design does seem to be about how to run a server farm without a team of admins. I can see there are both advantages and disadvantages. When I actually sat down and thought about it logically from an admin view though I can see this revolution in our work practices is long overdue however I don't beleive cloud is the answer right now.

Take developers for example. They love tools like Mamp, Wamp, Xammp because it removes the complexity and required knowledge of having to learn the intricacies of IIS or Apache. It's a tool which they run and straight away they have a localised environment which allows them to concentrate on developing their applications.

Cloud computing is doing the same for servers. What do you want? ok here it is in a ready configured software instance; but it still has all those complexities within it. One wrong configuration change and it could be game over. That's ok though because it's purely software and in the cloud, software is quick and easy to swap. The downside is the expense of doing this. So why is it necessary?

Well as server products mature they become more and more complex and none of my admin friends look forward to having to rebuild a server from scratch. Here then is the key to the problem. Why go on with this conventional method of running a server?

As an example, a few years ago I played with a firewall product called smoothwall. Smoothie was great. The software was all on CD and once it was configured, the configuration could be stored on a floppy disk (which could then be write protected). Sadly a typical server reuires more than a CD of system software but does it need more than a standard DVD? After all it's this system software that is a pain to reconfigure. Moving the data to another machine is as easy as swapping the drive over (or restoring a backup to another drive if it was the data drive that died).

So imagine if there was a project to install a few standard server configurations like this. You could download a disk with everything ready set-up in a standard configuration. all that would be needed is a few tweaks once the system was installed. Of course there would be security issues. If someone broke into it, every system would be affected. Then again there would be lots of people working on a solution at the same time. Add the fact that the server could be rebooted and would re-install from read-only media and it turns out that all you have to work on is the route that the intrusion uses to get into the system. It would also mean that configuration would be put together by experts using best practices.

The real advantage of this system would be in running it on your own local servers. No cloud tie-ins or expensive vendor changes. No hidden costs or data security concerns associated with your data being out there somewhere on another companies servers. I still think £2-3k for a new powerful server is a bargain compared to the price of consultants so this would be a real goer in my books. Now that I've thought of it, it's time to see if anyone is already doing it.

7 October 2010

Cloudbusting 101

I've been hearing a lot about this magical environment just lately. A place where applications are always available, can be seamlessly scaled and provide high availability. It's the greenest computing ever and all of your apps are belong to us.
Well I can now say at least I've investigated it and I wouldn't jump ship just yet. The price for all this is that you are likely to get stung by hefty development costs and you may end up tied into proprietry systems that could end up costing more than you expect.
Take for example Googles App Engine which I have thoroughly enjoyed playing with. To do anything useful with it I'm going to have to learn Python or Java. Since cron jobs are likely to be useful that choice is further limited to Python. While I have nothing against learning Python, it's important to remember that I've spent the past 10 years programming in PHP and it is apparently still the most popular Apache module. I know PHP well and I like it. Python, while not being quite as picky as Java has some unusual quirks about indenting sections of code. This means that not only am I restricted by choice of language, but further almost restricted to their choice of text editor until I understand this quirk. Not only that, but I am also faced with non-relational databases. Still at least Google lets developers have a go at all this for free, unlike their competition.
Oddly enough Microsoft Azure and Amazons EC have both set their price for a minimal system at $0.12 per hour. That sounds cheap when compared to the cost of a server and someone to look after it. The trouble is, you don't actually understand what you get for that $0.12 because looking at Azure pricing (here) suggests you will pay more for having a database, and then pay more for each GB of data you pass into or pull from this magic cloud. For this sum of $1051.2 ($0.12x24x365) you will get an amazing 1.6GHz driven VM with 1.75GB of memory and 225GB of internal storage. If you listen carefully you can just hear the server admin guy you just fired still laughing. Even louder as they hear the competition wants your credit card details before you get anywhere near uploading your precious applications.
Lets see how this compares with the server in the next room to me though. The equivalent of my dual processor xeon equipped server would be the large offering (4x1.6GHz processors, 1TB storage and 7GB memory - ok so the memory is more than our 4GB). How much would this system cost? Well it's $0.48 per hour or ($0.48x24x365)=$4204.80 per year. Add the fact that we have a database on it which is we'll guess slightly smaller than 5GB (that's an extra $49.95/month x 12) which costs us an extra $599.40. We typically backup our server every week as users like a bit of storage security and our data backups are typically 60GB. We'll be generous with knocking off the system files though and say that's 10GB which is not our data and wouldn't be transferred (we hope). So the transfer cost is 50GB per week for 52 weeks. Thats (50x0.15x52) or $390. This is just transferring data from their storage to ours though so we have to pay for their storage space too. If the data is 50GB backed up, it's likely to be around 80GB uncompressed. So for storage we also have to pay (80x$0.15x12=) $144. So far we're up to $5338.20 per year and that's before we've factored in any developer costs involved with migrating to cloud technology. Once we start adding in developers and consultants it could become really expensive, really quickly.
Oddly enough though, once you have everything online you're still going to need to give people access to it. How will they access your data? By this I mean the people in your company who utilise your data. In my workplace most people have a PC on their desk. Move all the server-side content over to the cloud and guess what - people still need a PC on their desk to access it. All you've done is released into the world a wild and grumpy admin who probably knows more about your business systems and data structures than you do. Not the wisest of moves to downgrade him to a desktop support role then. Also you have to look at how similar this is to outsourcing your helplines to foreign call centres. Yes you've saved some money for what started out as a great service, but how will it compare when more people jump on the bandwagon and the prices rise? What when your customers start complaining that the service they get is not what they expected?
The whole consultancy process alone is likely to wipe-out your IT budget at the moment as the consultant may only be there for 3-6 months (just long enough to really make a cobblers of it) but what are you paying them compared to your server admins? To really test out the new service, why not try calling the consultant at 2am with a critical problem and check out how they react. The developers likewise may be eager to get on-board but it's such a new concept that any worth their salt will be charging higher rates than conventional developers right now. Yeah you can buy a TV... or you can buy this new 3D TV and a limited amount of 3D ready films. See the comparison?
So I may already be a dinosaur but if my server dies I had the sense and good fortune to request a second for development (or spares). It may not be as quick to restore but since there are 365 days in a year, one lost half-day of service still gives an uptime of 99.86%. I can make that even higher if I use the second server to test out the backups. Of course I may return to this topic in 6 months time and completely change my oppinion on the subject. By that time I may be a fully-fledged cloud developer if I continue tinkering with this latest toy Google have given me access to.