Thursday, 18 October 2012

Stacks, Appliances & Turkeys Voting for Christmas

So, for those of you that know me - you understand that i have been working in infrastructure engineering for some time. My job (well, actually not me but the really smart dudes that do the hard graft) is to take products that vendors churn out at a high rate and make them consumable by our end users, providing applications that add business value.... So - its fair to say that we know a bit about sticking lego bricks together.....

What does a typical lego brick model look like (or Stack), well an example might be items as follows:
- Compute Hardware
- I/O Subsystem (Network, HBA's etc)
- Storage
- An abstraction layer may be included (such as a hypervisor)
- Operating System
- Infrastructure applications layer (Database, JVM etc)
- Management tooling
- Monitoring, capacity planning agents and all of that jazz
- Integration into the various ecosystems (i.e. DNS, AD, Network etc)

Thats a fair whack of stuff to glue together, takes a whole lot of skilled people to do it, lots and lots of validation to ensure we have all the support statements / interoperability statements and a hell of a lot of operational acceptance (by service owners) to validate its fit for purpose...

Onto the the turkey voting for christmas.... Enter the engineered stack / appliance view (there is a whole heap of vendors that profess to have these) - the promise is fantastic - don't spend your businesses hard earned cash on expensive IT folk that glue this stuff together - go buy a widget that you can wheel into your data centre (or in fact consume from a service provider) and it will just work - no expensive staff, no expensive integration processes roll it in, switch it on and start using... Fantastic dream - and one that i see as an end state that we should all be chasing (it will do me out of my current job - but hey - thats technical advance for you...) - OK so it may cost a little more to buy this "it just works kit" - im gonna save a shed load - so not a problem!!!

There is a but coming here.... and its a big but(t).....

Numerous iterations of these stacks exist - and a number of my peers have tried to implement these "easy use" appliances - but guess what - for some strange reason they don't just plug in and work, in fact the general observations have been:
- They take longer to integrate into the org
- Typically and organizational model needs to change
- loads of technical work still needs to be done to make them workable
- Rarely do these appliances meet the security requirements / deployment standards that are required by the large enterprise
- "Standard" deployment patterns are open to mis-interpretation

The net result of the above detail is not only do my nicely packaged appliances cost more to acquire, but i still need to invest the same amount of technical effort (if not more) than i did with my previous "own built stack", integration is typically harder, time to market takes longer and frankly it doesn't quite add up.

Its not like i don't believe in the appliance model - i really do, and also totally believe that this is where the market place will go - but for me (as the turkey) to vote for christmas - i need the following to be true:

- Appliance is reasonably priced
- Limited customization is required
- It just works...
- My requirement are clearly understood before proceeding with an implementation
- Deployment patterns are clear, precise and not open to own-judgement or interpretation (tell me exactly how to deploy)
- Ensure that you (as the vendor) have adequate skilled professionals wrapped around deployment to make it work
- I don't want to have to maintain technical staff to manage / engineer the product
- I don't want to end up polishing a furry turd

So as an offer - I am more than happy to talk to any vendor that has or is thinking of bringing an appliance to market and tell them what my job is, considerations around building a stack, what i expect from a finished article, how i engineer today - and what i expect them to take off my plate.

thats enough from me - and here's to some cranberry sauce and stuffing!


- Posted using BlogPress from my iPad

Location:Somewhere between Victoria & Wallington

1 comment:

  1. Interesting. To take things further - utility computing/cloud.

    If the cloud takes off - then it will be a utility used by businesses. As such should a cloud provider fail or be seen to be struggling then this will invoke a run on the cloud provider - as a result businesses may not be able to move their data to another provider, cascading failures. Follow the dots and like all utilities the provision either needs to be nationalised or regulated to prevent a swathe of businesses freezing up due to one failed corporate entity (too big to fail, a bit like banks).

    So private clouds/appliances may be the future, and public clouds at best a regulated industry - but what is the economic argument? If the argument is that the stack is pre-integrated and tested we are likely talking about a hardware software comibination: but not necessarily an end-to-end application.

    Perhaps when the industry has standardised on an ISA (x86+fudge - apologies hypervisor), a converged network (Ethernet - something with not as much trust as FC), and an OS (it'll need to be open source to avoid the single entity failure): lets say an open stack - then add a standard way to communicate (SOAP etc) - we have the building block upon which appliances can be plugged into.

    But I don't have to authenticate with my toaster, and when my washing machine goes in the bin the most sensitive information it can contain is my undies (and depending on where in the cycle a furry turd)......

    Ultimately IT is about data - if you need to be able to access your data, do you want a single point of failure: your third party supplier of the appliance.

    The next commodity is the on-disk format.....the appliance should be able to present the on-disk format in a way that enables me to access the data the way I want - but should that supplier fail I can use a different appliance to access the same data (then I don't need the skilled staff who can get the appliance to work....perhaps XML is the answer we just need all data access systems (databases, word processors, ..) to work with an XML backend.

    Why do we have standards for data in transit but not at rest.....why are some technologies/providers more sticky than others.

    Until appliances can injest data in the same format and give the 'correct' output (a clean pair of duds) then they are a shortcut to an implementation, or friction against progressing to a different implementation......