vZen: Real world principles to ‘Virtualization Zen’ designs

Note: This is a post written by Pancil. Pancil normally sits quietly in a dark corner of the blog sanity/spell checking my posts. He is also a Sr. Virtualizaiton Engineer at Rackspace, where he and I work side by side, making the "Private Cloud" Awesome.

So, while reading another blog Cody suggested that the ideas fit virtualization (and my evil ideas) quite well. I took this as an opportunity to extend on my primary focus at work, ‘Virtualization Zen’, and give everyone an idea to the theories that we employ day to day. Mostly they’re principles that we (Cody and I) hold in our design and architecture group, (I spend most of my time thinking about stuff, and convincing Cody it’s a good idea) so here goes:

1. Agile Systems Design
2. KISS – Keep It Simple Stupid
3. Whiteboard IT
   
4. Focus on ‘process’, not progress (at least for a while)
5. Proactive is the destination
6. Aim for small changes
7. Increase your view
8. Count on things you can control
9. Know your subject
10. It’s OK to give up control
    

Each of these principles has a baring on the way we do things, and each has a reason. I’ll try explain each one, and feel free to ask questions in the comments section. Sorry about the length of the post in advance, but it’s just how we roll 🙂 – I’ll try keep it short.

1. Agile Systems Design

This is the fundamental principle when designing a solution with virtualization. It’s very easy to get locked into a single design, or technology (especially when you consider the price of some of the networking and storage gear). As the technology has so much scope, and there are so many options (even without spending additional money – LACP Bundles, Data Deduplication, VLAN Tagging, etc…), you have to be mindful that there really shouldn’t ever be a ‘final design’ it should be a evolution of design to design, with simple points between. We’ve taken to giving our milestones a version and sub version – 3.0 is our current infrastructure. Think of the version as a point to work to 🙂

2. KISS – Keep It Simple Stupid

Every design, no matter how big, no matter how complex, can be simplified, yes really… A lot of complex designs have been created because of simply no more than age, and the never ending – ‘that’s how we used to do it’ (or line of DOOM as I call it). With age comes change, and a lot of these changes are done to simply achieve a single requirement (Accounting needed another network? Sound familiar…). Very few people look back at an infrastructure and look at where they can redesign and improve either a section of, or the entire infrastructure.

Mostly this choice is made due to the standard day to day bustle that keeps us away from what we could be doing. Remember that every small complexity you remove allows you to better manage, and support your infrastructure. KISS should be a driving force in your daily design thoughts. A good idea is to set either a quarterly, or yearly target to review your infrastructure (a good time could be shortly before your budget needs to be defined)

3. Whiteboard IT

If you can’t draw it, you shouldn’t do it. If your whiteboard is a real whiteboard, that’s great (we love them, we have entire walls that are painted with this magical paint that lets you write on it, and then wipe it off – You can get some here : Marquee Dry-Erase Paint). If it’s Microsoft Visio, or even a notepad and some writing tool, that’s great too! What ever you use, get a friend, or friends, draw it, explain it… The more you talk about it, the better you’ll understand it, and you’ll find yourself changing things each and every time… always for the better 🙂

Don’t be afraid to change it when you get a new idea, that’s what this is all about 🙂

4. Focus on ‘process’, not progress (at least for a while)

No matter how amazing, how awesome, or how fantastical your design is. You need processes (if you knew me 5 years ago, you’d be amazed, if not flabbergasted, that I’m saying this), you need a way for things to keep going. Be they processes on documentation, or processes on change management, or anything else for that matter, you need them to ensure that you’re able to do your job in the long run. By keeping everything in line, you’re able to then focus on progress, it’ll come with time, be patient 🙂

* Beware of rigid processes that cannot be changed *

A common misconception is that when you create a process, it’s a rule. A great example of this is the internet RFC’s that you see talked about often. RFC stands for ‘request for comment’, however in many cases these great processes are treated as rules. You need rules, and you need processes, they don’t have to be the same thing.

5. Proactive is the destination

You’re going to spend the majority of your time putting fires out if you don’t aim for ‘Proactive Nirvana’. Spend your time focused on changes that will make it easier to spot the future fires, the less fires you have to put out, the more time you have for doing your job – Making things better. Some of these changes may come in the form of monitoring, or simple scripts to check over things on a periodic basis. No matter how small the fix (like checking for disk space) may save you HOURS in the future.

6. Aim for small changes

You will never win, if all you have is the big picture. Don’t get me wrong, the ‘Big Picture’ is where you want to head to (or agile milestones), but the small changes get the job done, it revolves around ‘Agile Systems Design’ once more. You’ll know you’re getting closer to the big picture, when you have less small changes to make.

If you’re anything like me (or Cody for that matter), you need to see progress or you get frustrated. The easiest way to show progress is to make the small changes and keep track of what’s left to do, and what you’ve done. Another side effect of keeping the changes small is that you are able to do things in parallel in a lot of cases. If one task stalls, move to another.

7. Increase your view

You’re probably thinking that we’re talking about monitoring, or something similar, however as an IT person, it’s easy to forget that you have more to look at than just systems. You have people (yes, really) you need to service, tasks you need to have completed for those people. The more you see, the better you can do your job… Take some time out to sit with the people that want tasks or systems from you, you’ll learn more about what your design needs to include.

8. Count on things you can control

You cannot control everything. It’s very simple, you may want to force a team or group to work between certain hours, you may want to force a choice, but you can’t, it doesn’t work. You need to focus on things you can control, and things you can affect. You’d be surprised as to how the other things fit in when you stop fighting the process 🙂

9. Know your subject

Never EVER implement a first design and when you see a need, fill that need. List some problems that you need to have resolved in your infrastructure, make them broad problems, and work out how to solve the problem. Using this method you’ll learn more about your subject and come closer to being a great architect.

10. It’s OK to give up control

You may work with other teams, we definitely do, and it’s something we’ve run into a few times (if not every day actually). Giving up control, and working with another group doesn’t have to be a punishment. How much time do you spend doing something in your ‘silo’ that you could ask another group or person to do for you. That time can be better spent, and when the time comes that things fail YOU are not the only person who can help solve a problem. Hippie drum circles of IT love save the day. This is probably the hardest of the 10 to do, and probably one of the easiest too.

Let me know what you think of our principles, we’re always happy to hear from you. Have an awesome vZen day 😉

– Patrick

Photo by quinet