A note from the Editor:
This guest post was written by Steve Pantol, a colleague who works as a senior level data center engineer at Ahead where he spends a lot of time understanding, designing, and implementing data center level solutions. You can find him on twitter @StevePantol.
I hate wasting time. On the surface, this is often mistaken for laziness, but no–I love get things done, but only the things that matter.
There’s a certain pattern that seems to crop up again and again. It’s called the Pareto Principle, after an Italian gardener, but it’s known more informally as the 80/20 rule, or sometimes “the vital few and the useful many.” It states that 80 percent of effects tend to come from 20 percent of causes.
There are a couple of ways you can look at that. You might say, great, I can work a fifth as hard and still get by with a solid B. This works for some. Let’s assume, though, that you like your job. From that perspective, this means you’re spending 80 percent of your time creating that last 20 percent of value.
A common claim is that 80% of IT spending and effort is on support and maintenance–“keeping the lights on”–leaving only 20% left for new projects, new value. If that’s true, that new project time is precious. You need to think smarter about working harder. The Pereto Principle gives you an interesting framework for looking at IT projects.
When you find yourself in analysis paralysis on a project, you should ask what you’re really working on. Is it Easy Eighty stuff, or the Valuable Twenty?
Look at the process of bringing a new datacenter online. You have some set of applications and services you need to deliver, and a green field in which to build.
The way I see it, you have four ways you can approach that sort of thing:
- I’m-a-beautiful-and-unique-snowflake. This is the where you get lost in the weeds, with endless research, RFPs, POCs, and bake-offs, until you’ve proven to yourself that you have the prettiest pony at the show. Focusing on the journey, not the destination.
- Reference Architectures. Vendor-driven strawman designs for combinations of products that ought to work together if you do exactly what they did.
- Converged Reference Architectures. These are your FlexPods and VSPEXeses. Reference Architectures with a safety net–you have a partner driving the customization and integration efforts. And that partner has hundreds and hundreds of pages of documentation and scripts to help.
- Productized Converged Architectures. Vblock. We’ll talk more about that in a bit.
Infrastructure, I’d argue, ought to be that Easy Eighty, leaving you to focus the bulk of your time and effort on the actual value the project is delivering–the applications and services that run your business. It should be about satisficing, not optimizing. Figure out the level of performance, availability, capacity, and support you need, then get it on the floor as quickly as possible so you can do something with it.
So, if you’re results-focused, Option 1 is right out. There’s always going to be something better coming down the pike, and at some point you’ll need to stop over-engineering and actually do something.
Options 2 and 3 are common ways to break that cycle. But they’re not perfect. They’re point-in-time blueprints of solutions that are guarenteed to work only as prescribed, and they leave the details of implementation and integration as an exercise for the customer, or the customer and the integration partner. They’re a parts list of components from assorted vendors, all of which will arrive on their own schedules making implementation times that much more difficult to predict. They’re the Easy Eighty of the Easy Eighty, still leaving you to do the heavy lifting before you can move on to activities that really add value.
A better option is to trade some flexibility for predictability. Option 4, Vblock, is a great way to do this. You have a relatively narrow set of options to choose from, but once you lock in your selections, things get done in a predictable, efficient manner, with minimal impact on your team’s time. You’ll spend maybe a day working with VCE on the Logical Configuration Summary, a spreadsheet detailing the nuts and bolts–IPs, names, VLANs, storage layout, blade placement, and vSphere configuration. You’ll do a walk-through for a site survey, to make sure you have the floor space, cooling, and power the Vblock needs. Then they go and build it. When it’s done, they ship it to you in pre-racked, pre-cabled cabinets and dispatch a small team to hook them together, get them uplinked to your core, and run through some validation testing before turning it over to your team ready for production workloads. PO to production in 30-45 days.
You can’t come close to that speed with a build-your-own approach, even one built from a reference shopping list.
Infrastructure ought to be boring. Pick it out, put it in, and move on to the things that matter.
