It is Not All About Changing Your World.

A funny thing has happened in the technology world, the hype cycle has become far more than a cycle that you watch and smile at. It has become a sales frenzy, while people try to make a name and/or sell you stuff before the idea or product category has even solidified. You can see it all around you, and as has been going on for years, the trend seems to be worsening.

I call it a funny thing because the truly revolutionary technologies – like server virtualization – really didn’t need a full-on hype cycle at all. Virtualization just kept growing year after year. People would declare “the year of virtualization!” and the year would pass, with more servers virtualized but no mass shift from one paradigm to the other.

I think it may just be time to consider that as long as the hype cycle is revving for a product or technology, it is not ready for prime time. My reasoning is pretty simple… As long as the hype cycle is in full swing, you will hear a lot of talk and not much implementation. Or a lot of talk that ignores the weaknesses that all technologies have.

The problem that drove me to this conclusion is that nothing is “A great solution for X” any more. They are all going to change your world! And I can’t speak for all of you, but for me that is problematic and counter-productive.

If you tell a CIO that DevOps really isn’t automation and standardization, but rather a redefinition of his role, his organization, and his employee’s roles, he sees risk. The same is true with the old “public cloud will change everything”. The problem is that “everything” is a big word, and it helps no one to hear it. I still recall laughing at the pundit that claimed there was no need for datacenters anymore because public cloud was here… But in all honesty, laughter was the wrong response. He scared a lot of people off, for fear that options would be taken away from IT. It took a couple of years for some to come back around to “right tool for the job” thinking.

To get an idea of the difference I’m talking about from the open source perspective, look at git versus OpenStack. People say “We use git.” on one side and “OpenStack will change the face of computing forever!” on the other. In fairness, OpenStack has made steady progress and is actually having average enterprises saying “we use OpenStack” these days, but from its earliest days, the hacks have been out there selling it as The Next Big Thing, whether it was ready or not. Git, on the other hand, has achieved astounding uptake precisely because it does one thing – manage code and similar files – and does it very well.

Truth be told, I suggest clients use VMware as much as OpenStack. Why? For a variety of reasons. Some because they have licenses, some because they have the skills, some because they do not have the skills for OpenStack. But when it comes down to it, both are just a way to better serve the business, and changing the world is not on most business users’ list of priorities.

Historically, corporate IT has been pretty good about sorting out the hype from the usable information, but this seems increasingly problematic. More orgs hopped on the “cloud everything” bandwagon than I expected (most only until they saw the TCO growth curve), and more seem to be biting on the “SDN changes everything” current hype.

Keep a cool head, look at what you can use and how it benefits, not what pundits claim the cool kids are doing. There is a ton of cool stuff going on, no need to grab the “this will change the world” thing unless (a) your world needs changing, and (b) you’re willing to invest a lot to change it.

High tech, though pundits hate it when people like me point it out, is like any other market. There will not be a world-changing shift of the seas, the world changing will happen slowly and visibly, as good products/solutions are recognized and implemented, word spreading about their utility and knowledge spreading about how to overcome their inevitable weaknesses.

And finally, remember that there is rarely One Ring To Rule Them All in real life. That’s why it’s a line from a fantasy book. Choose the right tool for your environment, your employees, and the direction you want to move your company, not the One Ring that some pundit is selling.

After all, if you’re like me, you’re using half a dozen technologies on pretty much a daily basis that were at one time going to change everything. And now they’re more reasonably positioned as tools to achieve results.

Continuous Integration or Continuous Improvement?

One funny thing about DevOps is that it is often touted that constant, on-the-fly changes are the way of the future in operations, and DevOps enables those changes. While this sounds really good, and some organizations are actually doing this type of DevOps, I think it is time that, for the enterprise, we strongly question that premise.


While it is really very cool to think about moving an entire web server from a farm to the cloud with just a script, upgrading a system while it’s hot, or spinning up more instances of a server without having to configure anything, I propose that, for the average enterprise, it is simply not necessary.

I’m working on a test automation project that is being implemented for a generally available library. In this case, test automation gives standardized testing with standardized reports for those who are going to use the library to review before implementing or upgrading. This makes perfect sense, but the need for this level of effort and maintenance (remember that nearly all test systems are code too) for a library you’ve developed internally for use amongst your applications becomes much less clear. While testing should be mandatory for such a library, the question becomes what the coverage needs to be. If 80% of your applications utilize 10% of the library, I think I have an automated test coverage plan for you that will balance the cost of implementation with the benefits of having the tests run as part of the build effort.

The same is true with moving web servers around. Let’s face it, in day-to-day operations most enterprises just don’t do this. Really don’t. So having automation scripts to move a web server because you did it once may not be the best use of your time. If you are one of the organizations that perpetually moves things around, then yes, this is a solid solution for you. But if hardware replacement cycles are the most likely determinant for when you will next need to spin up a whole new copy of this app, or move your server from one host to another, then it is highly likely that automating this process is not the best use of your time.

The thing is, DevOps is not a black and white endeavor. Little in IT is. Think about the organizations you’ve known (and we’ve all known them) that tried to standardize on a single language or a single database. It rarely works out, not because the decision to make such a move wasn’t serious, but because the needs of the business trump the desires of IT management to focus skill sets. DevOps is trying to simplify a complex environment with a high rate of change. That’s hard enough, don’t shoot for automating everything that moves.

Think of each automation you write as a liability. I know that sounds weird and counter to the current DevOps thinking, but each script, like it or not, will be dependent upon the (changing) environment it runs in. Unless you are in one or two organizations that I’ve worked with who have abstracted their entire infrastructure (with a huge man-hour investment, I might add), each change in your architecture is reflected in maintenance costs for existing automation. Most of the time, this cost is worth it, but ignoring this fact will drag your IT operations down, even while you are improving things. The best you can hope for by automating little-used processes is reduced ROI from your efforts. The worst could be a nightmare of perpetually out of date scripts that have to be modified just about every time they’re used.

Tools are coming that will ease this pain – a lot – that are more focused than what’s available today. The thing is, until they’re ready and your staff has time to learn them, they won’t help. And like any new market, it could take a while for this one to shake out. So for the near term, just weigh the cost/benefit equation for each process you want to automate. If it saves operator man-hours, is used frequently, and is not too terribly complex, that’s probably where you want to start.

Yes, we’re still talking “low-hanging fruit”. That is always the best place to start, and it gives you the biggest return on your man-hours.

After all, isn’t the point of this whole exercise to get more time at the beach?

Product Roadmaps – from vendor to CIO tool

Thought I’d take a moment to drop a bit of an idea out there for making the most of vendor relationships.

You see, product roadmaps in the tech space are simply a sales and marketing tool. They are designed so that whomever you are talking to can point at them and say “those fifteen must have items? Look! They are coming!”


How most of us really view roadmaps… 

But there is wealth in products roadmaps. We all view them with skepticism because we all know plenty of cases where the roadmap and reality didn’t mesh.

So the other day when I was telling a friend how to get more out of them than the vendor, I decided I’d share this tidbit with you all also. It’s really pretty simple.

When a vendor shows you the roadmap, ask for a copy. If this is the first time you’ve gotten a copy, ask for a road map from 12-18 months ago also (though they’ll claim they don’t have one, ask anyway). Create a location somewhere in your org – intranet, NAS, cloud storage, where ever – to store roadmaps, and drop what you have into a directory bearing the vendors’ name.

Then, you have an actual example to judge a vendors’ ability to deliver what’s presented in the roadmap. It won’t be perfect, there are a lot of things that impact product/feature development, but it’s far more than what you have now, which is skepticism. Comparing last years’ (or any old) roadmap to the product literature should give you an idea of how well they delivered. If it’s not in the feature list on the website, it’s worth asking if they have the feature.

Now you have turned the tables of the roadmap. Instead of a potential smoke-and-mirrors list of promises, you are using it to evaluate vendors’ willingness/ability to deliver. It gives you the edge in choosing solutions that are best for your organization, by comparing past performance.

Whenever a vendor meeting is scheduled, go out and look briefly at the roadmap, compare it to the literature on the website, go in forearmed with knowledge of what they said was going to happen and what did happen in the past.

I did this in the storage space while writing for Network Computing, and you find relatively quickly that size does not matter so much on delivery as other factors. And having the roadmap helps you understand which vendors – be they huge multi-nationals with decades of experience or tiny startups with just a couple of people – are more likely to deliver what they promise.

Of course, many vendors will be resistant to this intelligent use of their roadmaps. In fact, I didn’t tell them I was doing it when I was, because I worried they’d stop providing me this valuable tool. It is of course up to you how your org wants to handle getting and keeping copies of roadmaps, but it I heartily recommend doing so. Use the tools available, and avoid “we can’t do that yet” failures in your IT endeavors.

All-consuming, all-confusing.

Ask two politically opposed people in any given country about the causes of the country’s problems, and guess what? Each will give you an answer filtered through their world-view. Through what they know, and what they believe. That is not to say one is right and one is wrong, both simply see things in the manner their background and experiences tell them is right.


We definitely live in interesting times. Server virtualization has just about reached saturation, application development is going through a wide range of changes from the return of automated testing to continuous integration and the other facets of DevOps, SDN is the next wonder of the world, once we agree what exactly it is capable of and where it fits best, cloud didn’t conquer the world, and people are still building physical datacenters, yet cloud offers solutions to some problems. And all of this is changing while IT staff has increased security concerns, projects are still rolling in, and every new solution or system takes even more man-hours to implement.

If you ask a networking person – and I’ve had quite a bit of talking with networking people over the last few years – about DevOps, they’ll talk about automating network provisioning processes, SDN is either the greatest idea ever (software vendors), or the dumbest idea ever (hardware vendors). Ask them about cloud, and it’s all about the network functions – all of cloud’s woes are from utilizing a primarily (or singularly) software network, and the bright future of cloud is only possible if the network is completely redone to mirror historical networks.

Ask a systems administrator the same questions, and you will get completely different answers. SDN frees them from the network, cloud offers a good solutions to some problems, but isn’t likely to replace the datacenter any time soon, and DevOps is an opportunity to actually schedule time to automate things they’ve been meaning to automate for a long time.

And the list goes on. Process people think all of the above are about changing the culture. Security folks are getting involved in DevOps even though they’re pretty certain changes to things like firewall rules aren’t going to get changed without a human saying “yes, do that”, because more than jobs are on the line.

And do you know what? They’re all right, to some extent. The problem is that conflicting messages while IT is trying to figure out what all these things really are, and how a given technology can help them out can cause more confusion than the information imparted warrants.

So I’m going to spend a good long while here at my new blog home talking about all of the above. Not from the developer, or network admin, or systems admin, or process specialist perspective, though I have experience in all of those areas. I’m going to help you figure out what these technologies are, and how your organization can utilize them.

And I’ll definitely point out where they are unlikely to be of assistance to you. After all, that is one of the services we offer here at Ingrained Technology, and thus far, our clients have clearly told us “this needs to be talked about”.

And that’s enough for me.

Oh, and welcome to my new blog!

Looking for more? Try these links:

SDN Central

Cloud Computing Magazine

Test Driven