Storagebod Rotating Header Image

BFI

BFI is an acronym which gets thrown around a bit and could stand for many things

Brute Force and Ignorance is one…but I've come up with a hopefully a new one which goes along with it, Big F**king Infrastructure. And this is my problem with Cloud at present; there seems to be a trend around at the moment that the point of Cloud is to build Big F**king Infrastructure. 

Now as an infrastructure bod, I can appreciate this and indeed, the part of me which likes looking at big tanks, fighter jets, aircraft carriers etc; finds BFI cool! Who wouldn't want to build the biggest, baddest data centre in the world? 

But is it really the point of Cloud? And this is what concerns me! Cloud should not just be about building infrastructures, it certainly should not be about turning data centres into Building Blocks. Cloud needs to be more than that.

It needs to be about something more; it needs to be about changing development methodologies and tools. If we just use it to simply replicate at scale what we do today, I think that we have failed. It certainly needs to be more than packaging and provisioning. It needs to be about elegance and innovation. 

I really don't want Cloud to turn into something like Java; what do I mean? Don't get me wrong, Java is great (and the JVM is greater) but how much Java written is simply C written in Java? Lots, believe me! I don't believe that Java has changed development paradigms nearly as much as some people like to believe. A large amount of C++ code is also simply C written using some of the features of C++ but not the fundamental structural changes brought by C++. And so it goes on.

Cloud brings elasticity to infrastructure, applications need to be designed with this elasticity in mind. A database needs to be able to scale up on demand and then gracefully shrink back down again; perhaps it needs to be able to start additional instances of itself on different machines to meet a peak and then when the load falls away, it should remove those instances whilst maintaining transactional consistency and integrity. 

Developers need to be able to design applications which wax and wane with demand. Yes we can fix a lot of these sort of issues at an infrastructure level but is that actually the right place to do it? We can fix a huge amount of problems with BFI but are we bringing sledgehammers to bear? 

So Cloud needs to be more than BFI! And that is why I was glad to see this story here about VMware and Redis; like Zilla writes, I also know >.< NoSQL apart from a couple of presentations at Cloud Camp and what I've read on the Net. After sitting in presentations by VMWare employees where they seemed to be equating Virtualisation with Cloud; it is great to see that they are looking beyond that. Let's hope it continues.


5 Comments

  1. Daniel Eason says:

    Interesting point and one I share…questions i’ve asked are;
    1. Do we have enough power/space and any other resource known to man that CAN allow us to scale within the “cloud”?
    2. Will cost visability make developers who are used to lazy scaling change this way of thinking? See my thoughts on this at http://vmlover.blogspot.com/2010/02/application-efficiency-in-cloud.html

  2. Martin G says:

    That’s a good point…if developers were faced with the stark reality of what inefficient code costs, I wonder if we would see behavioural changes. And before someone leaps in and says
    ‘Forget about the cost, consider the business benefit…’
    Inefficient code can often dilute business benefit; code which becomes unresponsive under load because of inefficient architecture can be fixed by throwing infrastructure….sometimes! It’s not just about building efficient infrastructure, it’s about building efficient IT…the I stands Information, not Infrastructure.

  3. Chuck Hollis says:

    Martin
    I definitely understand your point, but sometimes it gets into a question of end-to-end economics. Smart programmers who know how to write efficient code seem to be an extremely rare resource ; by comparison, all this plumbing seems to be on a downward price spiral.
    There’s also the time-to-market aspect — getting something up fast is sometimes more valuable than making it efficient — at least at the outset.
    No good answers that I have, though …
    — Chuck

  4. Martin G says:

    The problem is that often getting something up fast which was supposed to be a temporary solution is five years later still running and running the infrastructure team ragged.
    And yes, good developers are becoming rarer but I sometimes if it is resource abundance which has produced a generation of programmers which expect an infinitely expansible infrastructure.
    I have been involved in projects which assume that the infrastructure will be powerful enough when the code is delivered.
    There are no good answers at present but if no-one asks the question; there will never be an answer!
    I am certainly not blaming the infrastructure companies for pushing on a open door.
    But look what a mess we’re getting ourselves into by treating the world as an inexhaustible resource…what was cheap to do yesterday may now have an unacceptable cost tomorrow. All resources are finite.

  5. It’s always good to do things smarter, but if you try to force it the customers may just walk away. Look at EC2 1.0 or App Engine; some people called them “mushroom cloud” computing because of their scorched-earth disregard for compatibility with existing standards. The result was near-zero enterprise uptake.
    We need an incremental path to the cloud, and maybe BFI is an appropriate first step on that path. I agree with Daniel Eason’s comment that once people have used the cloud to convert their capex to opex, hopefully they will be motivated to optimize.

Leave a Reply to Martin G Cancel reply

Your email address will not be published. Required fields are marked *