Starting small and getting quick wins with PoCs
Technology is vast and moves at light speed. For any given problem there’s usually multiple open source and commercial solutions in the wild. How do you find the right one? Is it the one with the most Github stars? The least open Github issues? The lowest price? The best tasting lunch provided by the sales representative?
Startups have long learned to focus on a Minimal Viable Product (MVP). Get your product out to an audience to collect feedback, be it good or bad. Many of the same concepts and lessons can be used by your IT organization.
There are many questions that come to mind when choosing the next solution that will power your infrastructure platforms for the next 3+ years, in no particular order:
· Does it scale?
· How well does it perform?
· Is it secure?
· How much will it cost?
· How will we update/manage/maintain it?
Maybe the most important question you’ll have is: Will anyone actually use it? Probably the hardest question to answer is: What’s missing?
So how do you get answers to any of these questions? We could read hundreds of white papers, bring in vendors for demos, set up comparison matrices to learn which products have/lack particular features, and on and on.
Or we can just do it live!
What has worked for us is deploying proof of concept (PoC) environments. To say they are initially rough around the edges would be an understatement. There are no bells and whistles, and there’s minimal automation. They are just isolated environments that won’t affect others, used by an audience who is eager to get some hands-on use of that new technology that they’ve only read about so far.
We recently went through this exercise for a deployment of OpenShift Virtualization, a recent feature added to Red Hat OpenShift based on the open source KubeVirt project. We deployed a basic proof of concept (PoC) environment. For a real deployment, we would create workflows, onboarding, write custom operators to ease adoption, and create custom front ends to improve user experience — the PoC included none of that. It was just a simple deployment of OpenShift, with virtualization, some basic instructions on how to get started, and an invitation to come try this with us.
It didn’t take long for technologists to do what technologists do. Teams jumped onboard, asked questions, found flaws/missing features, and broke things. We definitely didn’t have all the answers and we all learned together. We found bugs, lacking features, and even security concerns. The result was that the product itself grew and improved as we provided feedback back to Red Hat. Though many use cases were exactly what we anticipated, a number were things that we didn’t know existed (e.g., ephemeral root disk virtual machines ended up becoming a core component of our offering).
While teams tested, we worked to improve our integration and built out operators, documentation, workflows and base image templates. The journey is far from over, and though we still have plenty of questions as we approach general availability, we already have a number teams ready to jump in. The great news is that this approach has allowed much of the feedback during the PoC to be addressed very quickly (evaluating viability as well), ultimately allowing us a path to making this generally available to our consumers. We can now provide a helpful solution to allow migration to our new hybrid cloud platform for applications that cannot easily be containerized. For us (and many other companies exploring hybrid cloud solutions), that’s a HUGE win.
Yuri Gelfand is a Digital Business Architect for CIO Hybrid Cloud Platforms at IBM based in Southbury, CT. The above article is personal and does not necessarily represent IBM’s positions, strategies or opinions.
