3 ms·
I mean, you could still avoid vendor lockin by having proper build scripts and deploying directly to EC2 instances and their equivalent. The lockin happens whe
by VHRanger 3y ago
I mean, you could still avoid vendor lockin by having proper build scripts and deploying directly to EC2 instances and their equivalent.
The lockin happens when DevOps gets lazy and start using a bunch of cloudy functions.
- scarface_74 3y agoAnd now you’re going to spend more money on cloud just to treat it like an overpriced collocation center without any of the benefits of moving to it. Have you ever done a large migration at scale? I have - even moving over a lot of VM hosted services involves your project management organization, regression testing, networking, firewall, training, security, working with outside vendors, and the list goes on. The average enterprise uses 254 SaaS services. I have never in 5 years heard any CTO of any company of any size worry about “lock in” when considering their cloud choices. Source: 2 years as an architect responsible for integrating acquired companies before a private equity owned company went public, two years leading the “application modernization” effort at a startup that exited 10x revenue, 3 years working at AWS in the Professional Services department and now working at a smaller consulting shop. And I got Amazoned a couple of months ago. I have no particular loyalty toward Amazon
- secondcoming 3y agoMaybe they don't worry about it because they don't think there's anything to worry about it. The most expensive part of switching cloud providers is data transfer. That's where the lock-in is, Kubernetes vs VMs isn't that big a deal at all; annoying sure. For the record, my employer uses both Kubernetes and VM. The deployment is pretty much the same.
- scarface_74 3y agoThe most expensive part is the staff and man hours. Everyone here is completely ignoring the organization complexities.
- icedchai 3y agoTotally. Migrating anything is a PITA, even if it's simple. If it's complex and involves tons of code changes to eliminate "lock in", or more likely, move from one flavor of lock-in to another, you better think seriously whether it's even worth bothering. Developer time is very, very expensive, and any time you spend "migrating" is time not spent building features that add value. Except in rare cases, the end customer probably doesn't care if your stuff runs on AWS, GCP, or Azure.
- diarrhea 3y agoI guess the point is then: once you’re migrated over, you live happily. For a while. The next migration will come. It’s only a question of when. What then? You’re now so far removed from simple Unix-like principles, tools and platforms that migration will be harder by an order of magnitude (and you noted how much work it is!).
- scarface_74 3y agoAnd what about the 250 other SaaS services that your company uses? Are you going to suggest that your medical software doesn’t integrate with third party EMH/EMR systems? That your call center and sales team doesn’t integrate with Salesforce? What about your dependency on Workday? ServiceNow? Your project management software? All of the Microsoft software? Yes even VMWare. There is a reason that AWS has a VMWare offering.
- garganzol 3y ago> You’re now so far removed from simple Unix-like principles, tools and platforms that migration will be harder by an order of magnitude Exactly my experience. Some services I manage are still entrenched in Big Co. Cloud, and it's a hell. This lock-in costs us additional money (thousands per year), but that amount is less than it would cost us to migrate those apps immediately. Unix is cool not because it's a Unix, but because it's simple, aka Unix Philosophy.
- scarface_74 3y ago“Thousands of dollars a year” is probably a rounding error in your organization
- noirscape 3y agoIt does depend on the managed services you're using. Most SaaS companies do offer the "conventional" services managed; if all you need is a database, a cache and some sort of place to dump a docker container for your backend/frontend and not deal with the wires of manually setting up, connecting and securing all of it against the outside world, their offer makes sense. (And like... this describes the majority of internet tech stacks). The hairy stuff is when you get into the highly specific offerings for each SaaS platform. They all offer a ton of them and they can certainly be attractive for some cases (ie. Filehosting) or useless in others (there's a lot of stuff that amounts to "our version of cache/database" and little else) but that's where the lock-in issues tend to play up. GCP is uniquely terrible though from what I've heard in terms of support lifespan and utter unhelpfulness in terms of communicating to their customers when some SaaS offering of theirs are on the chopping block.
- hobs 3y ago> I have never in 5 years heard any CTO of any company of any size worry about “lock in” when considering their cloud choices. The company I got laid off just decided they are going multi-cloud and that anything on their original cloud offering which is vendor specific is verboten in the middle of multiple in flight projects which now probably will never complete because they basically just did it by fiat in an unfunded mandate; no new deadlines, no new thought around how.
- scarface_74 3y agoAnd how is that adding any business value? Are they constantly testing for cloud portability like Uber does? Is it giving your former company a competitive advantage?
- hobs 3y agoNo, its stupid and wrongheaded, but that doesn't mean people don't do it, just giving an example of my most recent experience but I have seen it multiple times. They believe they will be able to sell their SaaS product in different clouds using existing budget companies have invested in said clouds. People are loss averse to decisions that they made about things that are completely unrealized, it makes no sense.