Tag: Stack

When you come to think about it, people who work in the IT sector are all slightly nuts. We all work in an area that is notorious for trying to make itself not needed. When we find repetitive tasks, we try to automate them. When we have a feeling that we can improve something, we do just that. And by doing that, we try to remove ourselves from the equation where we possibly can. In a sense, we try to make ourselves invisible to the people working with our infrastructure, because a happy customer is one that doesn’t even notice that we are there or did something to allow him to work.

Traditional IT shops were loaded with departments that were responsible for storage, for networking, for operating systems and loads more. The one thing that each department has in common? They tried to make everything as easy and smooth as possible. Usually you will find loads of scripts that perform common tasks, automated installations and processes that intend to remove the effort from the admins.

In comes a new technology that allows me to automate even more, that removes the hassle of choosing the right hardware. That helps me reduce downtimes because of (un)planned maintenance. It also helps me reduce worrying about operating system drivers and stuff like that. It’s a new technology that people refer to as server virtualization. It’s wonderful and helps me automate yet another layer.

All of the people who are in to tech will now say “cool! This can help me make my life easier”, and your customer will thank you because it’s an additional service you can offer, and it helps your customer work. But the next question your customer is going to ask you is probably going to be something along the lines of “Why can’t I virtualize the rest?”, or perhaps even “Why can’t I virtualize my application?”. And you know what? Your customer is absolutely right. Companies like VMware are already sensing this, as can be read in an interview at GigaOM.

The real question your customer is asking is more along the lines of “Who cares about your hardware or operating system?!”. And as much as it pains me to say it (being a person who loves technology), it’s a valid question. When it comes to true virtualization, why should it bother me if am running on Windows, Unix, Mac or Linux? Who cares if there is an array in the background that uses “one point twenty-one jiggawatts” to transport my synchronously mirrored historic data back to the future?

In the long run, I as a customer don’t really care about either software or hardware. As a customer I only care about getting the job done, in a way that I expected to, and preferably as cheap as possible with the availability I need. In an ideal world, the people and the infrastructure in the back are invisible, because that means they did a good job, and I’m not stuck wondering what my application runs on.

This is the direction we are working towards in IT. It’s nothing new, and the concept of doing this in a centralized/decentralized fashion seem to change from decade to decade, but the only thing that remained a constant was that your customer only cared about getting the job done. So, it’s up to us. Let’s get the job done and try to automate the heck out of it. Lets remove ourselves from the equation, because time that your customer spends talking to you is time spent not using his application.

Like this:

Or so I’m told. Not just once or twice, but it’s something that is written down at least once each time a vendor introduces something new or when a revision of an existing product is rolled out.

Now, you could say that this is the pot calling the kettle black and I would agree with you. It’s a thing I mentioned in my UCS post, and also in my recent post on the stack wars. And today a tweet from @Zaxstor got me thinking about it some more. I asked the following on Twitter:

I hear this argument about vendor lock in all of the time. Open question: How do I avoid a vendor lock in? By going heterogeneous?

Because, when you think about it, we all are subject to vendor lock-in all of the time. As soon as I decide to purchase my new mobile phone, I am usually tied to either the phone manufacturer or the carrier that is use. Sometimes I am even tied to both, you just need to think about the iPhone as an example for this kind of lock-in.

The same goes for the car I drive. When I buy it from the dealer, I get an excellent package that is guaranteed to work. Until I take it to an inspection with a garage that is not part of the authorized network. My car will still drive, and will probably work great, but I no longer have a large part of the guarantees that came with it when I bought it, and would have been intact if I had taken it to an authorized dealer.

Now, I know my analogy is slightly flawed here since we are talking about things that work on a different scale and use entirely different technologies, but what I am trying to say is that we make decisions that lock us in with a certain vendor on an almost daily basis. Apparently the guys in and around the data center just like to talk about that problem a bit more.

One remark was made however by fellow blogger Dimitris Krekoukias and confirmed by several others:

“It’s not how you get in to the lock, but how you get out of it.”

And I do think that this is probably the key, but fortunately we have some help there from the competition. But it’s not all down to the others! All vendors are guilty with trying to sell something. It’s not their fault, it’s just something that “comes with the territory”. They will try to pitch you their product and make your head dizzy with what this new product can do. It’s all good, and it’s all grand according to them.

And yes, it is truly grand what this shiny new toy can do, but the question is if you really need it? Try to ask what kind of value a feature will offer in your specific setup. Try to judge if you really need this feature, and ask yourself the question what you are going to do if the feature proves to be less useful then expected.

Remember that not all is lost if you do lock yourself in with that vendor. Usually others will be quick to follow with new features and this is where the help from the competition comes in. Take the example with the mobile phone. Even if you will not receive any help from your current provider, you can bet that the provider that now also offers the same package will try to help you to become his customer. If NetApp is not providing you with an option to migrate out of that storage array, you can bet your pants that Hitachi will try and help you migrate to their arrays.

Now, I’m not saying that this is the best solution. Usually exchanging solutions is also accompanied with a loss of knowledge and investments that were made. But it’s all on you to factor that in before you take the plunge, and in the end that lock that you have with your current vendor might be hard and expensive to break, but usually it’s never a mission impossible.

P.S. Just as a side note, I’m not saying NetApp will not allow or help you to migrate out of an array, I’m just using these names as an example. Replace them with any vendor you like.

P.P.S. Being part of the discussion fellow blogger Storagebod posted something quite similar, be sure to read it here

Like this:

As some of you might have read, the stack wars have started. One of the bigger coalitions announced in November 2009 was that between VMware, Cisco and EMC, aptly named VCE. Hitachi Data Systems announced something similar and partnered up with Microsoft, but left everyone puzzled about the partner that will be providing the networking technology in it’s stack. Companies like IBM have been able to provide customers with a complete solution stack for some time now, and IBM will be sure to tell it’s customers that they did so and offered the management tools in form of anything branded Tivoli. To me, IBM’s main weakness is not so much the stack that they offer, as the sheer number of solutions and the lack of one tool to manage it all, let alone getting an overview of all possible combinations.

So, what is this thing called the stack?

Actually the stack is just that, a stack. A stack of what you say? A stack of solutions, bound together by one or more management tools, offered to you as a happy meal that allows you to run the desired workloads on this stack. Or to put things more simply and quote from the Gestalt IT stack wars post:

Standard hardware configurations are specified for ease of purchasing and support

The hardware stack includes blade servers, integrated I/O technology, Ethernet networking for connectivity, and SAN or NAS storage

Unifying software is included to manage the hardware components in one interface

A joint services organization is available to help in selection, architecture, and deployment

Higher-level software, from the virtualization hypervisor through application platforms, will be included as well

Until now, we have usually seen a standardized form of hardware, including storage and connectivity. Vendors mix that up with one or multiple management tools and tend to target some form of virtualization. Finally a service offering is included to allow the customer to get service and support from one source.

This strategy has it’s advantages.

Compatibility is one of my favorite ones. You no longer need to work trough compatibility guides that are 1400 pages long and will burn you for installing a firmware version that was just one digit off and is now no longer supported in combination with one of your favorite storage arrays. You no longer have to juggle different release notes from your business warehouse provider, your hardware provider, your storage and network provider, your operating system and tomorrow’s weather forecast. Trying to find the lowest common denominator through all of this is still something magical. It’s actually a form of dark magic that usually means working long hours to find out if your configuration is even supported by all the vendors you are dealing with.

This is no longer the case with these stacks. Usually they are purpose or workload built and you have one central source where you get your support from. This source will tell you that you need at least firmware version X.Y on these parts to be eligible for support and you are pretty much set after that. And because you are working with a federated solution and received management tools for the entire stack, your admins can pretty much manage everything from this one console or GUI and be done with it. Or, if you don’t want to that you can use the service offering and have it done for you.

So far so good, right?

Yes, but things get more complicated from here on. For one there is one major problem, and that is flexibility. One of the bigger concerns came up during the Gestalt IT tech field day vBlock session at Cisco. With the vBlock, I have a fixed configuration and it will run smoothly and within certain performance boundaries as long as I stick to the specifications. In the case of a vBlock this was a quite obvious example, where if I add more RAM to a server blade then is specified, I no longer have a vBlock and basically no longer have those advantages previously stated.

Solution stacks force me to think about the future. I might be a Oracle shop now as far as my database goes. And Oracle will run fine on newly purchased stack. But what if I want to switch to Microsoft SQL Server in 3 years, because Mr. Ellison decided that he needs a new yacht and I no longer want to use Oracle? Is my stack also certified to run a different SQL server or am I no longer within my stack boundaries and lost my single service source or the guaranteed workload it could hold?

What about updates for features that are important to me as a single customer? Or what about the fact that these solution stacks work great for new landscapes, or in a highly homogeneous environment? But what about those other Cisco switches that I would love to manage from the tools that are offered within my vBlock, but are outside of the vBlock scope, even if they are the same models?

What about something simple as a “stack lock-in”? I don’t really have a vendor lock-in since only very few companies have the option of offering everything first hand. Microsoft doesn’t make server blades, Cisco doesn’t make SAN storage and that list goes on and on. But with my choice of stack, I am now locked in to a set of vendors, and I certainly have some tools to migrate in to that stack, but migrating out is an entirely different story.

The trend is the stack, it’s as simple as that. But for how long?

We can see the trend clearly. Every vendor seems to be working on a stack offering. I’m still missing Fujitsu as a big hardware vendor in this area, but I am absolutely certain we will see something coming from them. Smaller companies will probably offer part of their portfolio under some sort of OEM license or perhaps features will just be re-branded. And if they are successful enough, they will most likely be swallowed by the bigger vendors at some point.

But as with all in the IT, this is just a trend. Anyone who has been in the business longer than me can probably confirm this. We’ve seen a start with centralized systems, then moving towards a de-centralized environment. Now we are on the move again, centralizing everything.

I’m actually much more interested to see how long this trend will continue. I’m am certain that we will be seeing some more companies offer a complete solution stack, or joining in coalitions to offer said stack. I still think that Oracle was one of the first that pointed in this direction, but they were not the first to offer the complete stack.

So, how do you think this is going to continue? Do you agree with us? What companies do you think are likely to be swallowed, or will we see more coalitions from smaller companies? What are your takes on the advantages and disadvantages?

I’m curious to hear your take on this so let me know. I’m looking forward to what you have to say!