When I became an infrastructure architect at a large, privately owned consumer-goods store, I was so excited to be on the technology leading edge, a thought leader, and a trendsetter. I imagined all of the cool, new things I’d get to use, build, design, and possibly deploy. It was like playing with Legos or Lincoln Logs, except this was the real world and people were going to consume solutions that I designed so I knew they had better be good.
But it wasn’t long after I started the job that I realized getting to architect cool solutions also meant I would have to do some very—and I mean very—mundane tasks that it turns out every architect has to do. By mundane, I mean boring, crappy, and a whole bunch of other closely related adjectives. I was looking at BIOS version, HBA firmware compatibility, VMware ESXi patch level, VMware ESX compatibility with newer versions of VMware vCenter, and so much more.
Reality Hit Hard
Let me explain. There was a point when I wanted to upgrade to the latest and greatest version of ESXi that I could on one of my lab test servers—so I wanted to even upgrade the hardware. I installed new XEON processors in my server and it wouldn’t boot. Why? Well, the BIOS wouldn’t support the newest CPUs, so I had to upgrade it. No problem. I wondered to myself how long it had been since I’d gone through that process on a bare-metal machine with no OS. It really wasn’t that bad. Just getting everything sorted and ready was a little bit of a task, but I got it done. It powered up fine and I installed ESXi. I was excited until I realized ESXi couldn’t see my converged network adaptor (CNA). Hmmm. I wanted to upgrade the driver, but how? I only had connectivity via [useless] CNAs. I actually had to run a cable across the data center floor to the regular on-board gig ports so I could update the driver. I was all set then, until I realized that this simple CPU upgrade and OS install had turned into an all-day affair of frustration.
I was optimistic about most things like that until I got into them. I would tell the team, “Sure, let’s upgrade vCenter Server to 5.5. Oh wait, we have some old ESX hosts, so we can’t. And by old, I mean really old, like 3.5 old. And that meant vCenter was pretty old, too.” Now you’re probably wondering how that happened. It turns out there were some apps that we couldn’t take offline to upgrade or migrate to newer ESXi hosts. In fact, I had a pretty long list of servers classified as Tier 0 that couldn’t afford any downtime. They were definitely roadblocks to some of the cool new things that I had planned to build. I thought this was the worst of it, but oh no…
Then Reality Hit Harder
While the ESX host issue was going on, my SAN team started retiring an entire frame—that’s right the entire thing! So I instantly became responsible for figuring out how to plan an upgrade of my old 3.5 hosts around a full migration away from aging EMC technology. At this point, I was starting to wonder when architects got to do the fun stuff. It seemed like instead of designing, I was dealing with a continual flow of expiring certificates in vCenter, VMware Update Manager, VMware vCenter Site Recovery Manager, and hundreds of hosts. I swear the cycle never ended for those things! Every week, I had a certificate to replace and you’d think there might have been an easier way to handle them, but at the time, there wasn’t.
Not only was the work frustrating, but I also had to attend several boring weekly meetings with all of the different platform teams—hearing about networking and storage updates, new hardware, and even technology roadmaps. Weekly solution planning meetings weren’t any better with development teams proposing architectural designs that didn’t make any sense. When our weekly architectural review board met, it seemed better suited to check email than to explain technical best practices and differences between platforms. Meetings were probably the most mundane part of my job. I felt like they were wasting time that I could be spending on more useful projects like streamlining our provisioning process!
What I Learned from My Experience
By now you’re probably asking, “Where is he going with this?” I look at most things like these as learning experiences—experiences that I have learned never do again. I’m ranting about the boring tasks that every architect has to do—that I had to do—for good reason. No one has to go through what I’ve gone through or any of the other terrible things that you have probably experienced beyond what I’ve mentioned
As an architect, you no longer have to keep up with what ESXi versions are in your environment. You don’t have to worry about whether the firmware version of your HBA is compatible with the latest driver. You don’t have to set up the proper usages or SANs for your certificates, or keep hoping your security team will give you longer-aged certificates. Why? Because you can let a service provider worry about it for you.
All of those headaches go away when you use Rackspace Server Virtualization powered by VMware®. Rackspace does the mundane so you can concentrate on what really matters which is delivering the best, value-added solutions to your company. You finally get time to play with all of the cool technology as you plan and design applications. You get to work closely with other teams in your organization as a proactive contributor instead of a reactive one.
With Server Virtualization powered by VMware, Rackspace manages vCenter Server. Rackspace manages ESXi and the hardware. All you have to do is tell Rackspace what you need. A service provider also makes the product roadmap stress that you’d regularly have to deal with non-existent.
Architects have a tough enough job already without having to support upgrades. I had nightmares at my last job about entering the wrong info on my CSRs for Site Recovery Manager. We can all sleep better with Rackspace.