Have a good one!
- Posted using BlogPress from my iPad
Location:Costa Coffee, Cheam....
Location:Costa Coffee, Cheam....
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…
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!)
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!