View profile

Lock-in is usually a weird conversation - Coté's Commonplace Book - Issue #57

Lock-in is usually a weird conversation - Coté's Commonplace Book - Issue #57
By Coté • Issue #57 • View online
A little bit on lock-in, some app modernization links, and an online holiday party for you to chill out.

The Land of Cockaigne, Bruegel
The Land of Cockaigne, Bruegel
Lock-in
One of the most frequent objections/benefits/discussion points in software is the idea of “lock-in.” This usually means “if I pay someone for something, I’m using something only they have, and I’ll be locked into it.” With public cloud, it applies to cloud services as well. I’m never really bought into lock-in as a huge deal. I think there’s always lock-in, no matter what. When thinking about lock-in, the question isn’t so much avoiding it, as figuring out how much you want to take on for what benefits.
Here’s the more on this topic that I gave to a reporter about lock-in concerns with serverless vendors and services:
I work at a vendor, so it’s easy to use an ad hominem argument to dismiss anything I say here. Nonetheless!
Anytime you move your code from one environment to another, you’re doing to have to deal with portability. That’s what most people are worrying about with “lock-in.” This concern crosses open and closed source: if I use an open source UI framework here, and then I want to my my UI to another open source framework, I have to deal with portability - rewriting, re-configuring, maybe even re-architecting things.
Of course, you can try to follow standards to hide the unique FaaS stuff. You could do serverless with knative, for example. You write your own abstraction layer (in general, this is a terrible idea because you probably won’t maintain it over the years, when you want to move to a new type of infrastructure/cloud you’ll have to re-write parts of your own framework, and incorporate new ideas into it, staff will leave and then you’ll lose knowledge of how the system works). When considering “lock-in,” I would look at portability: how easy would it be to move this code - re-writing, etc. if needed - to something else? And then weigh that against any benefits you get from the thing you’re afraid of locking into. If there’s a standard to write to, then use that if you’re concerned with portability. 
Original content
☃️🎉It’s the Tanzu Talk Holiday Special!🥳❄️
I cover all the recent developments with the Tanzu Application Platform, VMware’s toolkit for making kubernetes easier and more secure for application developer use. It’s a watch party of some recent overviews of the betas along with lots of commentary and explanation from me about what’s going on. But, at first, in true holiday special tradition, a warm-up act from my daughter going over ten vital things to know about cats.
Tanzu Talk: ☃️🎉 🥳❄️ Tanzu Application Platform Holiday Special, or, DevX for kubernetes
Tanzu Talk: ☃️🎉 🥳❄️ Tanzu Application Platform Holiday Special, or, DevX for kubernetes
Relevant to your interests
Engage with my brand!
Did you enjoy this issue?
Coté
By Coté

¯\_(ツ)_/¯

In order to unsubscribe, click here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Powered by Revue
http://cote.io/newsletter/