Saturday, 17 November 2012

A thought for the day.... Same People Same Results

It always confuses me... a bunch of people work on a bunch of stuff - and that bunch of stuff goes wrong.... why on earth would you get the same people to put it right / expect to get a different outcome next time round after they got it wrong the first time round... Same people, same mistakes, same screw ups, same result... Enough said!!!

Have a good one!

- Posted using BlogPress from my iPad

Location:Costa Coffee, Cheam....

Monday, 5 November 2012

The Internet Super Highway

I like how it was a superhighway before it became a cloud. I hope it's an aquarium next, with dolphins and squid –  because why the hell not!!!! :-)

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 – 

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!


- Posted using BlogPress from my iPad

Location:Somewhere between Victoria & Wallington

Wednesday, 8 February 2012

Vendor Infrastructure Stacks - do they deliver on their promise??

So another blog article on the topic of vertical stacks / engineered systems - however this time I would be interested in what the general views are out there... Of course I would never write anything without stating my views / opinions etc. ;-)

All these stacks / engineered systems / appliances are emerging at a fast rate - but I have to ask - really how useable are they and where is the real market place / market sector that they have real benefit.

Working in a number of large enterprises over the years - some of the big technology departments understand all of the pitfalls of putting stuff together wrong, ensuring that inter-op matrices need to be considered and also it doesn't just stop at the infrastructure layer - it also has to take into account the layered applications that sit on top (database, middleware, message buses, java runtime engines etc...). Why do we need to get this right, well (a) to ensure stuff works properly (b) ensure that we are using a supported configuration and finally (c) as a cover ass to ensure when something does go wrong - we get the support from any given vendor when we need to pick up the pieces and make it all work again!

So what is the promise of these so called engineered stacks, well my view is it should be some of the following:
   Ready to rock and roll
   Integration tested
   Ready to “just use”
   All that time making stuff works is taken away from a business (they can concentrate on making money rather than making technology work
   One throat to choke for support / outage issues
   Ease of upgrade between generations of stacks
   Simplicity of support
   Can consume shared services within a given organization to ensure that security, monitoring, authentication etc. capabilities can be available
   No need to engineer based on components – just validate functionality and you are I business

Of course - if you take a look at these stacks, they are also not made equal. Technologies such as VCE vBlock really deliver the core infrastructure layer where as vendors such as oracle provide the complete stack from infrastructure right up to an application layer (i.e. database / middleware etc.)

I also accept that different sizes of organizations may require different stories & capabilities for a stack… For the larger enterprise they may have comprehensive IT functions and staffing that allow full integration testing and validation (lets call it engineering capability) and others smaller enterprises may just want to consume technology without large I.T. functions… I also buy that the business wants to concentrate on just that (i.e. the business that they are in / making money rather than technology work for technology sake).

So back to the promise of these pre-engineered systems that we wish to consume for the above reasons – it really requires that the stacks are of a mature enough state that they can just slot into a business and be used… and here is where my problem really lies…. My personal view is that the level of maturity is still not there, and if you are not careful you can take on some of these technologies and turn it into a massive professional services gig (which is fine as long as you get efficiencies at the end) and potentially some increase in technical complexity (really should be a reduction!)

Some of the traits that I have read about / noted / observed would be:

·      Masses of professional services to implement a solution
·    Varying degrees of integration completed
·      Never quite the finished article
·      Management integration is poor
·      Internal engineering / technology departments still required to ensure that integration and take on activities can be handled
·      No consideration for organization that will be taking on infrastructure
·      The vendor offering stacks has a less clear view of how to do this integration than some of the technology depts. within enterprises (as those technology departments have probably been doing it longer)
·      A patch regime that was worse than before
·      Slide ware promises the world, actual product is left wanting (i.e. senior management go for the dream / vision but in reality product doesn't match slide ware)
·      Vendor Lock-in
·      Escalating costs
·      Lack of control
·      Destruction of the world
·      Wars that encompass the length and breadth of the universe

OK – maybe the last two are not quite fair – and I having a giggle – however I still believe there are maturity issues…

Enough of my ramblings and ranting’s… over to the reader!!!

So – I guess this is really where I want to put a question out there – which of you have used vendor supplied holistic stacks, how have you found them and to be explicit I would be interested to read / hear about some of the following points (snail mail / email / twitter etc. is fine)

·      What is the relative size of your org
·      Which vendor stacks have you looked at
·      Which vendor stacks have you chosen
·      What was the level of success
·      What perceived benefit have you found (and how did you measure it)
·      How much integration did you end up doing as the stack vendor had not completed all aspects
·      Would you do it again
·      What didn't work and why

I would love feedback in anyway I can get it and am happy to be challenged – so please feel free to use my blog page to respond – or all other forms of communication


Monday, 2 January 2012

Just to say...

Hope you all had a great new years eve, the hangover wasnt to bad (Mine was!) and all the best for 2012... Lets make it a good one!!!

Hope to see some of you at storage beers in Jan!