Saturday, 15 May 2010

Are Oracle about to eat a well deserved portion of humble pie??

Hey there - Howzit, hope all is good out there!

So it is with some interest that i have watched the recent announcements
of takeovers / mergers and acquisitions... Some notable ones being
gemstone being purchased by springsource (VMWare) for their caching
laying, Adaptec going to PMC-Sierra and of course the most notable,
Sybase being acquired by SAP for a rumored cool $6.1B

So the last of those, for obvious reasons has really caught my
attention... Major reasons in the press for this purchase is based
around mobility - and some of the cool tech that Sybase acquired a while
ago, however you have got to ask if this is going to cause Oracle some
more hurt...

I mean - lets face it, Oracle have been trying to dictate tech that
end-users will buy. Over the last year or so (after the Sun acquisition)
- you only need to mention some of the recent attempts of change of
product support for Solaris x86 to technology owners and can watch blood
boil, tears start, ranting begins and general mumblings like "if i had
my way it would be ripped out" to start... Enterprises have had a really
rough run with Oracle in the last few months...

If it hadnt been for the recent hold on the database market that Oracle
have and Sybase doing a really pants job of getting price point right it
may be a very different landscape now, with Sybase (before this
purchase) starting to make big inroads back into enterprises again.

There is a huge opportunity here for SAP to take a look at its portfolio
of product, look at synergies within the organisation (ie back office
costs) and use their selling power to get Sybase back on track and put
some real competitive scenarios in place between themselves and Oracle
and getting Sybase DB products back as the premier preferred product in
the enterprise and Oracle out..

Of course the other purchase that is of interest (and concern to
Oracle?) is that of VMWare's purchase of Gemstone (who make data caching
products) - This is a direct competitor of Coherence, and whilst they
(Gemstone) are not in as many accounts and as big as Coherence, arguably
this was due to size of company - now they have a monster of a firm
backing them up, a hugely viable company (VMWare) and a Storage Company
(EMC) who know a thing or two about storage...

Is it time that Oracle ate some humble pie, realise that customer choice
is once again going to decide and dictatorships may be over..



Saturday, 1 May 2010

Confused.....Object storage, Bycast (Bygone?), NetApp, Atmos and NotOnTap

Howzit then??
So as of well, erm "some time ago" NetApp were well on their way to
putting together their object storage roadmap and was due for release in
the near-time... All fully integrated into NOnTap etc etc... Its all
going great..
Of course, NetApp have also been in acquisition mode for another product
with the bidding war that emerged on Data Domain, that clearly didn't
happen - but hey we knew something was on the cards..
What was announced last week - well, NetApp acquired Bycast (Bygone?) -
which is a great solution that does some funky stuff with "cloud
storage" and all this object based stuff that we need for cloud type
Hold on... Object storage... Didn't i say that NetApp had it on their
roadmap some time ago... Oh yeah - i did... Right at the top... So what
is the deal here, were our NOnTap friends really on their way to
creating an object based storage solution - or were there a few porky
pies / being a little over optimistic with deliverables
Ok - anyways, so maybe we have two object based solutions / cloud type
storage or one - as long as we have something - then its all good... But
i have another worry here.... I am sure that all of us out there that
use and enjoy NOntap functionality remember NetApp purchasing a company
called Spinnaker, and some 5 years or so later, do we enjoy all of the
integrated functionality - maybe not... we are talking about clusters
possibly running in 7 or 8 mode... I think the date for NOnTap 8.1 is
still pretty fluid...
What is my faith in NetApp being able to integrate Bycast into NOnTap in
a timely manner - its pretty low to say the least... Would really love
to see some statements from NetApp around both roadmap (from a "we are
doing it already / object storage perspective) and also details on
integration timelines, along with release dates etc.
Whilst we are on the topic - EMC Atmos - so whats the deal here then???
Is it a globally dispersed CIFS / NFS presentation layer? Is it an
object store that can be global in nature, is it bird? Is it a plane? Is
it SOOPERSTORAGE??? Is it Cloud Storage??? In fact - i would love the
sales team that market it to give me a clear and concise view at to what
it is, what it is trying to achieve and what the roadmap plans are for
the product set.... Don't get me wrong - i think that this product has
its place.. (and i think i have found a use for it) - but i am not sure
i get the whole deal and how the product set is really gonna hang
together and
I guess what I am really trying to say is what is the vendor community
up to here, and other than calling this bunch of stuff cloud storage -
where is the coherent story that is dragging this lot together????
would love the various vendors to take us through this "journey" we need
to take and understand what fits where and does what, which cloud it is
and which product is playing in which space. - i am sort of guessing at
the moment!

What sort of things would I like to see included in storage array federation??

Hi there all, so there have been a good few discussions going on between
a bunch of us, namely: @storageanarchy @3parfarley @ianhf @storagebod
@stuiesav (myself) and numerous others (apologies if i have missed
anyone) around the subject of storage federation...

Firstly - a big "Get fixed soon" to Marc Farley - Take a nose at his
Blog - really quite humbling to see what technology is capable of...
forget about all this storage and infrastructure malarkey - Keeping
people healthy - that is where it is at... Take a nose:

Now - back to business - Just a little rant... honestly just a little
baby one.....I truly truly think it would be of great help to both the
industry (vendors and customers) if some firm definition of terms were
made, and in this example - why federation does not equal virtualisation
and virtualisation does not equal federation (I'm still struggling with
it whilst writing this article - please don't flame me ;-) I really
believe that the governance and standards bodies could really help here
by writing a dictionary of terms etc.

Right - back to the topic in hand - As well as twitter traffic there
have been a couple of good blog postings, one from @3parfarley which can
be found here:
another from @ianhf which can be found here:
and finally some of my own thoughts on some of the hype etc that is
surrounding this topic which can be found here:

Views and thoughts have been shared and its been a good discussion. I
thought i might just add a few more views in terms of the type of
functions / behaviors that i would expect from a federated storage

This really is not a hard spec of items, but really some rough
scribblings that i thought peeps may be interested... so here goes for a
bit of "rough":

Day 1 functions that i would like to see (again rough...):

* Allows non-intrusive life-cycle in and out of arrays
* Allows a re-balance of data across arrays
* Load balances (guess this couples with the above point)
* Scales (isn't limited by lun counts, array counts etc) as an
example, i dont want a federated layer becoming a bottleneck
* Storage array agnostic and can federate data spread across arrays
of disparate type
* Understands performance characteristics of arrays that are being
federated (look and listen approach)
* Ability not just to tier on disk within array but accross arrays
based on holistic performance of arrays and can place data into
different locations
* Is not tied to geometries / lun boundaries / like for like
configs, can move and translate
* Ability to off replication (not sure this is a federation function
- but rep between dislike arrays is attractive)
* Can spoof previous geometries of configurations to allow easier
migrations between host types / arrays etc
* Has a policy engine that can define what should be where, when
data needs to be evacuated / drained (in the event of system
lifecycle) and define where data should be right-placed.
* Any host able to map to any component within the federated array
configuration without the pain of additional lun masking, zoning
etc etc etc (i.e. help me with the provision nightmare that is
involved with moving data around)
* Federate over short distances where possible (i.e. arrays within
a DC complex or upto 80km spread)
* Move the smarts normally associated with the array (such as
snapshot, replication etc) upto the federation layer

I would like to put in day-1, the ability to federate to differernt
types of storage, i.e. file system, block, object stores, links into
various API's etc - but i guess this could be asking just a little too

Day-2 functions (even more rough....)

* Ability to link into an Infrastructure federation layer that works
/ behaves at a global enterprise level
* Offer the concept of connectors between federation layer,
application, OS and array so that data can truely be moved to an
appropriate tier based on API, Application definition and policy -
a big ask, but as we move to these cloud based services - its
gonna need to be tackled - maybe there is a federation that needs
to happen between cloud services??
* Start offering concept of de-dupe (or maybe i mean
single-instance) across federated infrastructure - learn whats out
there and stop writing the same thing everywhere - I am guessing
the amount of metadata required to do this is huge - but it may be
less than the data set itself ;-) (hey - i never said this was
gonna be easy!)
* Global federation - based on centralised federation layer, tie in
with application definitions and location information - if an
application gets deployed in one region or many - the ability to
handle that, and right-place provision is key. This could play
such a huge part in time-to-market discussions - and the fact you
can just tell an infrastructure cloud to provision ready to accept
app would just rock!
* Ability to federate from a storage service that may be in house,
and movement / lifecycle out to a cloud service and vice versa...
This coupled with a policy engine would rock... (hmmm never used
that term before - whats that all about)

Right - that is where I am up to now... Will add to this over time -
However, I am on a train whizzing to Nottingham for a friends bulls
party (maybe might even have a beer or two)...

I am aware that i may be dipping out of storage federation and bumping
into infrastructure federation but hey.... there ya go!

Would be really great to hear other peoples views / add to list / tell
me i am mad as a box of frogs etc..

Have a great one!!