I’ll say from the outset that this post is not an attack against Amazon EC2, nor against IaaS in general. It is merely a consideration of use cases, and end games. Specifically, the Enterprise use case for EC2. I personally use EC2, and for my use case it’s bloody great. For startups, it must be a god send. Same for more mature businesses who are built around 1 or 2 internally developed applications, especially if they are web related. It must be a massive boon for students. But for the Enterprise? No.
Let’s start by looking at some application level requirements to get the most from EC2. First, your application needs to be designed for failure – that means scaling out rather than up, loose coupling of components, and statelessness of the endpoint. Second, you don’t want to run an EBS backed instance (and cop all the IO charges), you want to run the operating system on an S3 backed AMI – again that means statelessness within the OS, and complete automation on this layer from instance creation to destruction. Third, you want management and control over the base image itself to ensure your instances come up pre-patched, secure and ready for action.
The problem is very few Enterprise applications are built this way, operating systems as deployed in the Enterprise certainly are not. Why? Are all Enterprise IT employees stupid? All too often the blame for this is misdirected – it’s not the fault of the application owners, the in-house developers, nor the IT infrastructure people. Ladies and Gentlemen, I introduce you to… the accountants!
Read More »
A new version (1.3) of the HP ESXi Offline Bundle has been released for ESXi 4.0 Update 1. Now I don’t normally tend to post about patch releases because… well, I just don’t really see the value in posting that a patch was released and leaving it at that. But this is a little different.
Because you _still_ cannot apply this patch via Update Manager.
So once again I’ll ask the question of VMware – what is the point of having an automated patch tool if it can’t actually apply patches like these? Clearly the HP patches are packaged in accordance with VMware requirements, because they can be installed via the vSphere CLI. Yet there is still not an easy way to add patches like this to the VUM repository. Cisco patches seem to be available via a VMware provided online repository, but I’m not asking for that – there needs to be a way to manually add patches to local VUM servers, without pointing the VUM server at a website.
Update Manager does on the other hand continue to offer somewhat useless and redundant guest patching functionality, and even more useless application level remediation for things like BizTalk server. But it still cannot handle patching a host that happens to be running a vCenter VM (yet I can manually VMotion said VM around). And there’s still the unscalable 1:1 relationship between vCenter and Update Manager. I’m not sure what the Update Manager team are working on, but they really should forget about the guests and concentrate on the host patching capabilities, which are far from ideal currently.
This post is part of a series based on a presentation I did to the London VMware User Group on February 25th, 2010 about the reality of Enterprise scale internal cloud platforms. To find other posts in the series, just look for the tag “Bringing the Cloud Down to Earth”.
We’re finally at the end – this is the last of my observations on the life of an Enterprise Cloud project. And again, it’s not something that we really anticipated at the beginning, and has the potential to create very unwelcome interruptions to development. But on the positive side, it’s massively important – not just to get feedback from the stakeholders that you are on the right track, but to stop yourself from getting so hung up on what you’re _not_ developing that you actually forget about the good stuff you _are_ delivering.
Read More »
This post is part of a series based on a presentation I did to the London VMware User Group on February 25th, 2010 about the reality of Enterprise scale internal cloud platforms. To find other posts in the series, just look for the tag “Bringing the Cloud Down to Earth”.
Agility is another buzzword that goes hand in hand with Cloud, but what I’m referring to here is more aligned with Agile as a philosophy or methodology rather than the conventional interpretation (although of the course the 2 are closely linked). Agile is most often used for software projects, so you may initially think it’s a bit strange to use for something that is as much infrastructure as it is software but trust me, it works exceptionally well.
Read More »
This post is part of a series based on a presentation I did to the London VMware User Group on February 25th, 2010 about the reality of Enterprise scale internal cloud platforms. To find other posts in the series, just look for the tag “Bringing the Cloud Down to Earth”.
It’s time to get back to the reason for doing all this in the first place – it’s about the business, and the applications.Which is why you need to think outside the infrastructure when it comes to Cloud more than you need to think about the actual infrastructure itself. By that I mean the Cloud is more about logical concepts like service levels / tiers and features rather than HP or Cisco, EMC or NetApp.
Read More »
This post is part of a series based on a presentation I did to the London VMware User Group on February 25th, 2010 about the reality of Enterprise scale internal cloud platforms. To find other posts in the series, just look for the tag “Bringing the Cloud Down to Earth”.
Following on from the previous topic of “API First” is another very important principle – that of discrete components (not to be confused with discreet components 
). We see it time and time again, applications or systems that are built in a monolithic style – with every piece of functionality imaginable crammed in and inseparable from the rest. But it is an easy trap to fall into, and indeed I am speaking from experience. Not everyone is as forward thinking as you or I, there is no shortage of people who subscribe to the “when all you have is hammer, everything looks like a nail” view of the world. My advice is to let them hold that view of _their_ world, but do not let that spill into _your_ world. The points in this slide are fairly self explanatory, so this will be brief.
Read More »
This post is part of a series based on a presentation I did to the London VMware User Group on February 25th, 2010 about the reality of Enterprise scale internal cloud platforms. To find other posts in the series, just look for the tag “Bringing the Cloud Down to Earth”.
I cannot stress how important this point is, and at the same time I can’t convey how difficult it is to do. The difficulty doesn’t lie in the technical part (although that is far from easy) – it’s linked to one of the other points which I called “The Importance of Showing Others”. The sad reality of life in the Enterprise, and even in the outside world to a certain extent, is that non-technical people generally need to see a UI in order to get a sense of what something does – as I once heard a sales guy say, “it’s very difficult to sell an API”. And even sadder, the better the UI, the better that thing is perceived to be. But although this is an unfortunate state of affairs (IMHO), you can work it to your advantage. There’s a saying which goes something like “you can’t polish a turd”… well actually, yes you can. You could have absolute rubbish under the hood, but dress it up in a nice UI and 99% of non-technical people will be sold. Case in point, the Windows operating system (heheh, that was a cheap shot). Now I’ll admit, I don’t know the solution to this problem – in my experience, I have failed to convince others of the importance of developing the API first and they have only come to realise it later (but thankfully not when it was too late). Given that, I’m going to talk about what I mean by ‘API’ rather than how to do it first.
Read More »
