As the enterprise world moves to the cloud, a variety of options for doing so without vendor lock-in have been proposed, with open source alternatives like OpenStack and CloudFoundry on offer to help enterprises buy into the cloud without getting locked into any particular cloud. All of this makes for great theory, but in practice, as Expedia vice president of technology Subbu Allamaraju argued, “anything that needs to be procured or downloaded, built, run, operated and maintained is up for lock-in,” with a future built on just a few public clouds that want your data, infrastructure, and everything else.

As much as we’d like to eschew this era of ultimate lock-in, the reality is that there’s far too much value in the innovations bred within large public cloud providers like AWS and Microsoft Azure to avoid. We can therefore agree with former MongoDB executive Kelly Stirman, who told me: “λ [Lambda] is for “lock-in,” yet still clamor for more.

Depressed? Don’t be. As Allamaraju went on to argue, we needn’t fear public clouds, but rather use them to initiate a culture of what he calls “change agility.” In sum, the very clouds that lock us in can set us free.

A right way and a wrong way

Allamaraju isn’t talking about the kind of low-code IT agility preached by Francois Dunoyer, the public sector vice president for Appian who argued that “open source is not the answer to the agility challenge. The reason why is right there in the name of the site and the policy: code.” In Dunoyer’s worldview, government IT (and, really, all enterprise IT) needs a “no code” future driven by “declarative tooling that supports visual drag-and-drop composition rather than specialized coding.”

It’s a bold declaration, given a “software-is-eating-the-world” trend that has every business heavily investing in developers (and for good reason). Unfortunately, it’s wrong.

No enterprise is going to be competitive with a drag-and-drop approach to software. However, many will find success with serverless computing models like AWS Lambda, which, as AWS product chief Matt Wood told me in an interview, allows “AWS customers…to think about building applications with services, not servers. With S3, DynamoDB, and Lambda, you can build apps without thinking about the underlying infrastructure.”

SEE: Why AWS Lambda could be the worst thing to happen to open source

Developers, in short, get to minimize the amount of infrastructure code they write, instead focusing on calling APIs that provide such essential infrastructure services. They get to spend more time writing their applications while the associated infrastructure “just happens” and “just works.”

Lock-in, thy name is cloud (or not)

To get such innovative services, however, you’re going to have to pay with lock-in. As Allamaraju declared: “You can’t take advantage of all the new capabilities to innovate for your business while staying agnostic to the platform.” Developers are going to flock to things like AWS Lambda (Expedia, by Allamaraju’s count, does over 2.3 billion Lambda calls per month…and they’re just getting started), or similar offerings from Microsoft and Google, and in the process they’ll burrow deeper and deeper into those clouds.

Part of the reason is that the big cloud vendors have incorporated the best open source components into their platforms and make them super convenient to consume, much more so than cobbling it all together by any particular enterprise.

SEE: Lock-in is what people love, not open source

But, an even bigger part goes back to Allamaraju’s argument that the most innovative software is being built by the public cloud vendors for use, not sale. Developers, consumed with increasing productivity, are jumping in.

So, how can an enterprise embrace the cloud without becoming consumed by it?

As mentioned, Allamaraju’s argument is for “practicing change agility.” Traditional IT practices, he says, contributed to a culture of resistance to change, which drives more lock-in than any particular code license ever could:

During the last fifteen years, most enterprises reacted to lock-in concerns by over-investing in abstractions, whether it be programing frameworks, parsers, databases, communication protocols, application servers, cloud providers, you name it. At the end of it all, what’s left was past regrets and large difficult to change monoliths. Those abstractions, in effect, did nothing other than contributing to a culture of change resistance.

Instead, he said, enterprises should “embrace[] techniques like service orientation, asynchronous and decoupled communication patterns, micro-architectures, experimentation, failing fast, tolerance for mistakes, chaos engineering, constant feedback and continuous learning.” Such things may involve proprietary platforms and code, but they aren’t rooted in them. They allow an enterprise, for example, to embrace containers today but perhaps switch new applications to a Lambda approach tomorrow.

Change is a constant in such an approach. Indeed, elastic infrastructure and services from AWS or others are critical to enabling this shift, as I’ve argued before. The lock-in only endures so long as an enterprise refuses to change. In short, it’s a question of culture, not code.