“But what about lock-in? If we use your stack to escape the last stack we bought, won’t we just be trying to escape that stack five years from now?”
That’s a common question I get when giving an overview of Pivotal Cloud Foundry. There’s also some good competitor rock throwing, as always, around the notion of being overly loyal and, thus, “trapped” in a stack. (Spoiler alert: surprisingly, any given vendor’s competitors seem to always be harboring the old boogie person of lock-in, according to the vendor at least.)
I wrote a perspective on how to think about and deal with “lock-in” at the platform level for InfoQ recently. Now, the idea of “lock-in” is a slippery notion. When developing and running software, at some point, you have to choose a technology to rely on: a programming language, a front-end framework, an operating system or runtime, and so forth. In theory, you could write these things on your own, which may seem like a way to avoid “lock-in,” but once the staff who built that left, you’ll experience a type of lock-in unique to your organization: the lock-in of having no idea how something works and being deathly afraid to change it, often known as “legacy.”
With that view, I’ve always liked the notion of the freedom to leave as a reframing of lock-in. If you wanted to be all formal and concise, you could call it “portability.” Just as with lock-in, portability is more a series of shades of ease rather than a binary situation. We learned this in the Java world which espoused endless portability…well, if you wrote your code to be portable and didn’t rely on any particular JVM or app server. Oh, and that was also the era before DevOps where we thought of the production runtime environment as part of the application, and thus, something that should be “portable” as well. Or there’s the “portability” across versions of an operating system or family of operating systems, like Linux: each version just slightly different enough to feel a slight prickling of fear down the back of your neck when it’s time to move applications around.
The point is: how you plan for and manage “lock-in” is a lot more complicated than it first appears. Portability is a bit better, but it still needs a mindful approach.
Our philosophy of lock-in management at Pivotal revolves around the ability to move between different types of infrastructure. We call it “multi-cloud.” The idea is that you should be able to run your stack on as many types of infrastructure as possible: from private and public cloud; running in OpenStack or VMware; on AWS, GCE or Azure; and several more options. We think of all this infrastructure as below “the value line,” things that while useful and valuable for the function they provide are not the source of business value for most organizations.
In addition to automating much of the operational concerns below the value line in the above diagram, this focus on running an application layer on-top of a standardized infrastructure layer adds a meaningful degree of portability to your applications: you can now run on all of the supported cloud infrastructures (IaaS’es, mostly), whether as public and private clouds.
Intuitively, this type of portability makes sense. Who wouldn’t want portability? But do you really need it? Well, most of the large organizations I talk with use many different pools of infrastructure, or “clouds,” not only for simple things like separating development from production, but also for availability and endless regulatory concerns—from geographic ones to industry compliance requirements. And, of course, for better or worse, most organization’s either inherited lots of clouds, or seem to like having lots of them—cloud pets, perhaps.
About the Author