content top

Debunking Cloud IaaS Mobility Myths

Many things in life appear great on the surface, but wisdom has taught us to never trust a book by its cover or believe in silver bullets. The latest story I frequently hear being pitched in IT circles is that of cloud IaaS Utopia. In this universe, workloads can simply move anywhere (between disparate providers and private data centers, for example) without consequence. Typically you’ll hear a few data points to justify the story, including: We use OpenStack, therefore your workloads can be run anywhere We use an open source hypervisor, so you can run your workloads anywhere We support Open Virtualization Format (OVF) import and export, so you won’t have any portability concerns We have a VM import and export tool, so you can easily add and remove VMs The last three points are mainly VM-centric, so let’s begin there. When it comes to workload mobility, the VM has always been the easy part. Don’t get me wrong, VM import tools do a great job of dynamically removing the right device drivers and associated software, and properly preparing a VM disk for a new hypervisor; however, that is rarely a challenge today. OVF takes VM import and export beyond a simple vendor or provider tool and OVF’s extensibility allows a VM or an aggregate of multiple VMs to specify its management, security, compliance, and licensing requirements to the provider or management platform. Moving Beyond the Checkboxes So far, the openness story sounds legit, but holes often quickly emerge when you try to operationalize any new workload in a new environment. Operational issues such as orchestration, backup, disaster recovery (DR), security, identity and several requisite management tasks (such as performance, capacity and configuration management) ultimately impede true workload mobility. Here is a list of considerations: Third party integration: It’s critical to understand how a third party solution is supported rather than just the fact that it is supported. Integration can occur at various parts of the stack (such as at the hypervisor management layer APIs instead of at a higher orchestration layer), meaning that moving to a new hypervisor could require product replacement or additional integration work and QA. It’s also important to understand how features are exposed through a platform’s API set (such as open source vs. proprietary APIs). Multiple API integrations may be required to operate the workload in a hybrid cloud. Third party software licensing: Can software that manages or runs in the VM have its licenses follow the VM to new infrastructure, or is a new procurement cycle required? Vendor ecosystem: Are all of your preferred vendors supported and provide rich integrations for the hybrid cloud environment? How easy is it to find details on third party...

Read More

What IT Operations Can (and Should) Learn from the Electronics Industry

  The state of New Jersey is home to some of the most significant electronics inventions in our history, including countless inventions by Thomas Edison and what became the modern transistor. Bell Labs ushered in a sustained period of innovation and along with it a robust and growing workforce. My own technology career also had started in the electronics industry, where as a young US Marine I did component level repair (such as troubleshooting and repairing transistors and integrated circuits on electronic circuit boards). While such specializations were important at the time, today they are mostly irrelevant. In New Jersey I continually run into folks who used to have solid careers as electronics technicians and most of them are no longer doing any work related to technology. The reason – their skill is no longer important, or the number of skilled professionals is far greater than the available jobs. That happened because lower costs and agility requirements (such as faster repairs and high uptime requirements) made their specializations no longer practical. We’re seeing those same requirements drive public, private and hybrid cloud computing initiatives today. If you’re wondering what any of this has to do with IT operations, consider the role of the typical IT ops professional. He or she often must deploy, optimize, troubleshoot, and remediate a variety of infrastructure-related services. At the same time, agility demands are mandating substantial investments in automation. As I’ve said before, the key to automating systems economically is to remove as many variables as possible. To the IT ops professional, that will ultimately shrink the demand for high degrees of customization. We’re moving to a world where IT will be consumed as a series of modular components and integrated systems. IT value will increasingly be determined by cost, agility, and availability; successful IT professionals will worry less about minutia operational details and simply leave that up to vendors and trusted partners. You could go to Radio Shack, buy a bunch of pieces and parts, and build a radio, but why would you? You can go to a department store and buy one for a lower price that will likely last for years. The notion of building a radio from scratch (outside of a learning exercise) is laughable. Ultimately I foresee the same fate for IT infrastructure systems. Building highly automated infrastructure systems from scratch will be viewed as an academic exercise.  Value will shift from building integrated systems to integrating systems with key business processes. In the end, there will be plenty of work for all of us, but we must evolve as IT professionals or risk being left behind. To do that, we need to lose the...

Read More
content top