Storagebod Rotating Header Image

Web/Tech

Bambi-based Computing

I found this article in the Register very interesting but not as interesting as the paper it links to.

The concept of building balanced systems to improve efficiency and reducing TCO is one which is elegant and pleasing; I wonder if at times that we in the storage world could do better in this? The paper also points out one of the things that we are very aware of in storage; spinning rust has just not kept pace with the development of CPUs.

It also has a fact in that I was not aware of consciously, 2x2Gb DIMMs draw as much power as a 1 Terabyte disk. So simply chucking huge amount of memory in the form of cache will not solve all problems. I like the new measure that they come up with for measuring efficiency, Queries per Joule. Perhaps we could have a new SPC/TPC measure based on power efficiency.

Conversations and comments

I had a few interesting conversations at IP Expo last week and I'd like to talk about a couple of them as they really highlight what is going on in a lot of IT Departments.

First was a conversation I had with a Senior Sys Admin who was very anti the moves we are seeing in the industry towards simplification; he really didn't want to see his job simplified and de-mystified as he could see that he would no longer have a job or not as well paid job. And all this automation and simplification didn't work anyway; all mouth, no trousers.

Secondly was a conversation with a vendor who acknowledged that in the past that their GUI had not been great and we should look forward to a much simpler UI with ease of use at the fore.

So we have an industry move towards simplification at a time of recession; an easy sell to the CIO but not such an easy sell to the people on the shop floor. I wonder how many of these initiatives are going to fail because of these attitudes; unfortunately, I suspect quite a lot but often broken promises, imperfect products and shoddy delivery has allowed these excuses to stand.

I think that lot of people in IT like the idea that what they do is somehow mystical and complicated; they get a thrill from getting called at 3 am in the morning, they bitch and moan like hell about it but deep down they love it. I've certainly seen this in my day to day work; heroes in IT are all over the place, working silly hours to keep systems up but if you suggest that there might be a better way, there is a look of horror.

I wonder what we can do to change this attitude? Ideas? Obviously, we need to ensure that the tools that are supposed to make lives easier, actually do make lives easier; often not the case.

All the functionality that is provided at the CLI needs to be in the GUI; this means there are less excuses to revert to the CLI. CLIs themselves need to be simplified and made consistent; as functionality has got bolted onto systems, the CLIs have got covered in cruft and are no longer syntactically consistent. 

We need to ensure that the simplification is actually simple; too often the automation breaks and means that we end up doing things manually anyway. It must deliver on its promises not deliver more promises.

Economic Truth

Steve Duplessie posts on Cloud Economics and especially the economics of Cloud Storage, 20 TBs of storage from Amazon's S3 cloud will cost you $36,000 a year and that doesn't necessarily compare especially well with purchasing your own array. So do the economics of the Cloud storage scale, especially when we start talking about the 100s of terabytes of storage which many enterprises consume?

The problem is we don't really know how much it costs us per terabyte in total! There are no good published TCO models for storage; this is why the initiative started by Nick Pearce and Ian are so important. Go and read their blogs here and here on building a TCO model for storage; let's get this thing crowd-sourced and perhaps we can make the TCO costs of storage a little less cloudy.

And then we can start on the model for Cloud TCO…public vs private etc!!

Many Solutions, Many Problems…

Instead of focusing on product, more and more of us are concentrating on solutions; products don't solve business problems, solutions do; I like this entry on Eigenmagic which looks at the differences between products and solutions.

But concentrating on solutions can be dangerous because next thing you know you have a data centre full of point solutions and a support nightmare. Many vendors like to try and package their solutions as black-box type solutions which require their own OS builds, own hardware, do not support virtualisation, do not co-exist well with others. 

Software appliances which run on industry-standard hardware may well be the answer but even these often have stringent requirements. I have come across software appliances which specify that they only support certain types of server underneath; we need to move away from this and to very high-level requirements i.e how much memory, how much CPU and how I/O is required to support the application; not it requires a specific HP server. 

Solutions are great as long as they are not used as a way to sell me expensive OEMed hardware which I can buy off the shelf from half the cost. And you may claim that the TCO will be lower; let me tell you, often the TCO goes up because I still have to manage the security patching, multiple support contracts, non-standard form-factors etc, etc.

You Gotta Love Larry

You really have to love Larry Ellison of Oracle; if there is one thing that you cannot acuse him of and that is being a shy retiring violet. But his latest pronouncements on becoming the new IBM; not the IBM we have today but the monopolistic (although very successful) monster of Thomas Watson Jr's day.

The IBM which manipulated the market, the big arrogant beast? Do we really want this to happen? Does anyone really want the IBM of the past back? I don't, do you? Perhaps he thinks that today's crop of ITers don't remember that IBM gouged the market with their prices for years. Is this the message that he is really sending out!

However to be honest, I don't think he stands a hope in hell of becoming the behemoth; there is too much competition out there and that in my mind is good.

Live Forever

No not my favourite Oasis track, no it's something which I've been thinking about and a subject I've touched on a few times; once you've deployed a technology, how do you get out of it? Do you get out of it? And what impact does virtualisation have on this.

How many of us are running or are aware of business critical applications running on hardware which is no longer supported by the vendor? And the reasons? Often the reasons are that the application only runs on a particular operating system which is no longer supported and will not run on current generations on hardware.

Virtualisation may well allow you to refresh the hardware; for example if you insist in running applications under DOS; pretty much any of the x86 hypervisors will run DOS. This will allow you to run that business critical application on DOS for the forseeable future and will allow you to continually refresh the hardware underneath it.

Well, it will until the Hypervisor vendor calls time and decides that they no longer want to certify the hypervisor with DOS x.xx; oh well, what do you do? Obviously you shrug your shoulders and now run a back-level hypervisor with an unsupported Operating System which is running an application which by now, no-one has a clue on how it works!

Oh, you've migrated the application into a Public Cloud? Well, it didn't need much in the way of the resources and suited the Cloud perfectly. And now your Cloud provider has said that they are no-longer supporting or even allowing DOS instances to run; oh heck and now you can't get the hardware/software to run your application locally. 

So although virtualisation will allow you to get away with running legacy apps for a long time; don't assume that this means that they can 'Live Forever'! Virtualisation is not an excuse for not carrying out essential maintenance and keeping your estate up-to-date.

*that's 'Bring It On Down', just in case you were interested!

The Cry of the Grump!!

A slightly plaintiff and frustrated tweet from grumpystorage aka @ianhf inspired this blog as did replies from various of the storage twitteratti.

Ian cries the lonely cry of the infrastructure architect

'Application
architects – please know & understand your infrastructure
requirements. Infrastructure isn't magic or telepathic!'

And of course, IaaS and PaaS are then held up as potential solutions to the problem. I've got bad news; they're not! Cloud Architectures are neither magic or telepathic, they still rely on application developers and architects understanding their infrastructure requirements.

Now we, in the infrastructure world can help them by educating in the questions that they both need to ask and also need to answer. Questions like, what availability does your application require? What is it's throughput? Have you designed an application which scales either horizontally or vertically?  Infrastructure Architects have always had to work in a consultative manner and drag the requirements from the Application teams.

All providers of infrastructure need to understand the importance of this; nothing will destroy the credibility of Cloud Architectures quicker than the inappropriate and unplanned deployment of applications into the Cloud.

I think there is a temptation that we represent the Cloud as Magic Smoke where things happen but just look at the backlash when Gmail goes down? Fortunately for Google; people have become so reliant on Gmail, beyond a bit of moaning, few people will really change but a Corporate taking their first steps into the Cloud who loses a key application or a key application under performs may well be more unforgiving. 

Push button deployment without the consultative input of the Infrastructure Architects guiding could end up in a world of pain and it won't be the application at fault, it will be the Infrastructure.

It’s all a case of History repeating…

If we look at the PC revolution of the 1980s, we can start to see some remarkable parallels with what might happen with Cloud computing. The PC revolution took a number of the existing big vendors by surprise; in fact most of the big vendors were so taken taken aback that they are no longer here.

The PC revolution allowed department heads to go and do their own thing; it decentralised the control of the Information Technology budget and allowed users to bypass their slow moving IT departments. Whilst IT departments were debating whether PCs etc were good things and the existing vendors were fighting rear-guard actions trying to maintain their historically high margins; new vendors and paradigms came to the market and people moved on.

Arguably, in the mid-90s and with the Internet revolution; IT departments finally got hold of things again and began to hold the whip-hand again. Larger Unix servers, big networks and an ever growing demand for storage and centralised information allowed IT to do things better and for the last decade, centralised IT functions have probably had control.

But the revolution which allowed 'us' to gain control has evolved and changed into something which could lead to us loosing control again. The growth of the Public Cloud allows department heads to yet again bypass centralised IT functions and to take control back again; yet again we see the inevitable debates by internal IT functions, the dismissal of the Cloud, similar objection with regards to Security, Availability, Control, Scalability etc all raise their heads as they did during the PC revolution.

Have we learned nothing? The customer is king and we need to maintain the focus on the customer; telling the customer that they are wrong will not work, it didn't then and it won't now. Internal IT departments need to ask why their customers are looking at the Public Cloud and try to replicate those services internally.

IT Suppliers need to embrace Cloud and look to how their products can play but also to understand what they need to change. Things are changing again and continuing to carry on as you have in the past is not going to work.

But what I see at the moment both in corporate IT departments and in IT vendors is a scarey amount of lip-service to the notion of Cloud; or sometimes an arrogance belief that this will all go away. It won't but it's not all doom and gloom, I'll suggest reasons why in a subsequent post!

Post Your Favourite FUD!!

Okay, let's get all the FUD out of our systems! What piece of FUD are you either

  • Most proud of! What scurrilous piece of FUD have you manufactured to smear another vendor?
  • Most amused by? What patently stupid thing has a vendor said to smear another vendor?
  • Most shocked by?
  • What piece of FUD actually turned out to be true?

This doesn't have to be storage specific but obviously I would prefer it to be so!

Failure is an Option…

I really like this comment by Ian on his blog as part of his questions/response to Val; this displays a different approach to engineering a service architecture and instead of focusing on the components; you focus on the service and how you make the service available.

"I see nothing relating to technology more aligned to a 'recovery
orientated architecture' where 'tin/software' failure is expected, and
as such component availability as a requirement is reduced in priority
(in favour of price point) and the architecture of the service deals
automatically with the regular failure of components."

Perhaps part of the Cloud is like routing for services and we simply design services that route round failure. I'm not sure exactly where this takes us but it's an interesting and powerful idea.