Posts Tagged ‘Bringing the Cloud Down to Earth’

The Importance of Showing Others

April 15, 2010

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.
(more…)

Advertisements

Be Agile

April 14, 2010

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.
(more…)

Think Outside the Infrastructure

April 11, 2010

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.
(more…)

Discrete Components

April 6, 2010

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 :D). 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.
(more…)

API First

April 5, 2010

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.
(more…)

Start Simple

March 15, 2010

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”.

With all the hype surrounding Cloud, it’s easy to lose your head when planning what your first release is going to offer. Well maybe not you, but other people around you who aren’t as grounded will almost certainly lose theirs. “ZOMG we’ll have vMotion to Amazon and single click clone-to-new-VM for production workloads BOOM! HEADSHOT!!!”. Calm down, Doug. You should always remember Gall’s Law, which in a nutshell says any complex system that works is bound to have evolved from a simple system that worked. Amen to that. It’s also worth remembering that simple does not necessarily mean easy, of course as Einstein said “It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience.” (ie make it as simple as possible, but no simpler).
(more…)

The Atomic Unit of Compute

March 8, 2010

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”.

Bonus content When I first started putting together my VMUG presentation, it was actually solely focused on this particular topic. I’ll link to the original presentation at the end, as I think it’s better if you read the post first.

Another of the challenges you’ll face along the way of Cloud is that of how to measure exactly what it is you are offering. But having a look at what the industry is doing won’t give you much help… as with so many things in IT, there is no standard. Amazon have their EC2 unit, and state that it is roughly the equivalent of 1.0-1.2GHz of a 2007 Opteron or Xeon CPU. With Azure, Microsoft haven’t gone down the same path – their indicative pricing/sizing shows a base compute unit of 1.6GHz with no indication as to what is underneath. Rackspace flip the whole thing on it’s head by deciding that memory is the primary resource constraint, therefore they’ll just charge for that and presumably give you as much CPU as you want (but with no indication as to the characteristics of the underlying CPU). Which way should you go? IMHO, none of the above.
(more…)

Engage Support Early

March 4, 2010

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”.

Last post I talked about challenging convention, but you can go too far in doing so. Depending on the depth of your operational knowledge of the environment you work in, it’s easy to do just that and if you don’t consult with the ops teams until the last minute you could be in for a nasty surprise. And so the best thing to do, even if you think you know how things run, is to get operational representation onboard early. Like day one of the project early.
(more…)

Challenge Convention

March 4, 2010

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”.

In the previous post, I talked about some of the things that you should think about before going ahead with an internal Cloud project. And I ended saying you should challenge the way things are done currently if they are impossible or very difficult to automate. But there are other things you should also challenge that aren’t directly related to automation, and I’ll cover some of those now.
(more…)

Garbage In / Garbage Out

March 3, 2010

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”.

The notion of GIGO is of course much older than I am, but it’s one of those concepts that is timeless. In relation to Cloud, it’s more pertinent than ever. The marketing hype would have you believe that Cloud is a panacea, and many people hawking their wares artfully dodge the subject of your existing tools and processes. But ignore these at your own peril. The COO of the company I work for has a great quote, which goes something like “God made the earth in 6 days, because he started with a clean slate.”. The same is true of internal Cloud (or whatever you want to call it – I’m going to call it that for the sake of convenience) – you could probably nail down the platform code and functionality that you want to launch with in a few weeks, but making the requisite changes to existing processes and integrating with existing tools in your environment is what will take the lion’s share of time to address.
(more…)