Wednesday, 24 October 2012

Changing Ways... RFP'ing for services rather than technology silos

So… you run a big infrastructure group, you deal with servers, storage, networks, a bunch of different infrastructure software (database, monitoring, cap planning, message bus etc)…. The chances are that when you evaluate different technologies, for functionality or maybe based on a price that you want to chase after –  you will do it by the typical silos / disciplines… (i.e. the fore-mentioned technology silos).

Maybe there is a different approach to this… OK –  so you will never get rid of the core disciplines entirely, but if you were to take a service centric view rather than silo'd view –  you may take a slightly different approach….. Maybe you would look at the various services that you offer within an infrastructure team and decide that there are some that are more mature than others and could benefit from a service RFP (as an example) rather than break it down by its component approaches… Or maybe –  there are some engineering aspects that are just too hard –  and you would rather get someone to take this work-item and do it for you, or maybe there is an appliance based product that could fulfill the service requirement for you….

OK –  so read my previous blogs, and especially the ones based on appliance type technologies –  i think its fair to say that at this point in time, i have a pretty jaded view of functionality –  that is because either (a) the integration job that has been done by the vendor is pretty rubbish and you end up polishing a turd or (b) there is only the core infrastructure that has offered (i.e. x86 h/w, hypervisor, storage) and no inclusion of the software layer that is required to offer service –  but hey, im probably talking about vendors that manufacture and not those that offer integration services…. Its also worthy of note that you may get a consortium of vendors bidding for a given piece of work (as an example and not me backing anyone –  HP ,EMC, Microsoft may bid for a SQL service stack)

Pretty quickly you get to the point of discussing which services could you offer out, where you know clear requirements and you would be happy to say “Hey vendors, respond to an RFP for a given service stack that i may engineer and support… and give me some price and options

Next step – what are these service stacks we could articulate (and we have a mature enough handling of these services and can articulate clear requirements) and get vendors responding too.. so lets break them down to core services rather than technology silos…. here is my starter for ten…

  • WEB services
  • File Transfer services
  • Database Services
  • Message bus services
  • Mainframe services
  • Network services

these are some of the service items that believe are mature enough to take this approach at this point of time –  you will notice i have left out items such as directory services, name services etc –  this is based on the fact that there are elements of security and business logic / layout that might just make it too hard…

So once you get to a place where you decide which services you may look into –  you are then into deciding which of the sub-categories you may chase after… For this example –  I'm going to pick on database…. lets go for a Microsoft SQL stack (one that is pretty mature)…. Its well known, predictable, its a mature tech, there is lots of expertise and its a service offering that you can well define.. We know the stack, Hardware, Storage, Operating system (windows), high availability and then the MS SQL product layered… Metrics and service definitions are relatively easy to formulate –  Why wouldn't you work at this level?

Anyhow –  its a different view of taking technology requirements to market, and i am also sure its been done by a bunch of people already…. times a'changing…

Final thoughts –  if you are going to use this approach –  think about the *measuring sticks* you would use to judge responses and ensure that you are defining services appropriately. Don't go for panacea options, work with “good enough is good enough…” –  you might just end up saving some more cash along the way and delivering real business benefit at the right price (lts face it –  the business would much rather make money than keep us techie nerds in work!)

Night all!

A link to a great article from @storagebod - Big Data

Just read a superb article that @storagebod wrote –  which talks about bigdata –  and how it doesn't necessarily need to be big, it just happens to be *different* and the way that you may use a data set for analytics may be different. Please take a read –  its really quite interesting (Martin –  please start calling it football rather than soccer!!)  please follow this link –   http://storagebod.typepad.com/storagebods_blog/2011/02/big-data-little-information.html 

SSD's save the world... or maybe they dont...

So… what is all the fuss about… really??? every man and his dog has a story about SSD's, how fast they are… How they are gonna rock my world and also how cheap they are on a $/IOPS basis…. hmmmmmm… no one talks about combined cost of $/GB and $/IOPS as a combined metric –  slightly different story methinks…

And another thing –  yes your drives go really really fast  and they are great and i can aggregate large amounts of IO onto them but some how i need all of my compute services to take advantage of them and connect to this nice shiny SSD array…. Pointless putting them onto my already oversubscribed FC fabrics –  as the average (of most of the worlds FC fabrics) i guess is somewhere around the 4 gig mark..

ok – so i get the use case of SSD within enterprise arrays and promotion of hotspots –  but really am over the hype of large scale SSD only arrays (altho i do see some small niche cases of SSD arrays for very point solutions).

Another point to note –  SLC / MLC drives –  my guess is they will not be long of this world –  so big investment of arrays that utilise this tech may also not be a grand idea –  watch this space for new funky tech coming along!!

Finally –  i guess “one to watch” –  EMC's acquisition was (IMHO) a legend purchase –  and of all the tech i have seen / read about –  is really the one to watch –  could this finally be the emergence of a large scale solid state array that really can deliver the promise, give the price point of $/IOPS and $/GB that is needed to make the thing cost effective and be building a good connectivity story!

That is all!

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!

Cheers!


- Posted using BlogPress from my iPad

Location:Somewhere between Victoria & Wallington