8 ms·

Ask HN: What are some examples of cloud lock-in?

• sparker72678 4y ago
  I find the biggest source of lock-in is that it's really hard to move a bunch of data. The longer you stay, the harder it is to leave, because the impact (downtime, slowness, resources allocated to moving data instead of building your business) on your product/service is likely to be bigger. As you research this, don't neglect the cost of attempting to remain vendor agnostic. Every level of abstraction adds new costs (for some people it's worth it, no doubt!). Sometimes it's more efficient to just go all-in with a vendor.
  • bombcar 4y ago
    Inertia is a huge lock-in. Almost willing to say if you’re not moving cloud every five years or maintaining two clouds at all time you will get so much inertia you’ll be stuck.
  • tech_tuna 4y ago
    This, of course, isn't new. I once worked at a company that was tasked with migrating data out of a CM system built by a company where I had also worked about 10 years earlier. I ended up pinging one of the founders at the old company and asked him how we'd go about extracting the data using the platform's data (we were wondering because we kept running into stability issues doing this). He basically told me what I suspected, there was no good way to do that. Because of the way the cache worked in the product, it would never stay up if every single data record were fetched via the API. We ended up pulling it all out of the database directly, which was a bit of a pain. tl;dr no vendor really wants to make it easy to pull ALL of your data out of their system.
    • tech_tuna 4y ago
      >extracting the data using the platform's data Meant to type (and can't edit apparently) "extracting the data using the platform's API"
  • __derek__ 4y ago
    Not just hard, but expensive. The Acquired podcast episode on AWS[1] highlighted a particularly ironic angle of this: > David: I can do you one better. Another example. Amazon.com used Oracle databases when it was started. Amazon.com did not finish their migration off of Oracle databases and onto AWS products until 2019. > Ben: Oh, my God. > David: Thirteen years after AWS launched. > Ben: That is insane. > David: It took that long for Amazon itself to migrate off of Oracle. [1]: https://www.acquired.fm/episodes/amazon-web-services https://www.acquired.fm/episodes/amazon-web-services
    • ajkjk 4y ago
      Anecdotally, from when I worked there in ~2015, there were a few good reasons: (a) a lot of Amazon's software was so old that it connected directly to the databases. We had to finish all of the SOA migrations that were long overdo -- all the misc random tools no one had gotten around to migrating -- before we could even contemplate moving off Oracle. (b) it wasn't done as a simple port; instead, the systems were re-architected in the process to no longer share backing databases as at all, which basically meant it needed a complete rewrite, which took a long time to get funded and then a long time to deliver.
      • ltbarcly3 4y ago
        These are just reasons, not good reasons.
        • ajkjk 4y ago
          True. I felt like they were good reasons at the time, or rather that they were basically the best you could do given that the can had been kicked down the road for far too long. As usual putting off solving tech debt ends up costing >10x in total.
        • scarmig 4y ago
          Is the implication here that it was a bad engineering choice to not start with a full SOA? It seems AWS made the right trade offs when it was starting, given its current position. The proof is in the pudding.
• LinuxBender 4y ago
  At a former company our development teams addressed this by making their own API gateways to talk to API's in AWS and Azure so that the same primary codebase could run in multiple clouds. I do not have specific details but this is absolutely a concern. I am not aware of a turn-key solution to address this. OpenShift would still need code to talk to all the API interfaces of each cloud vendor I have no idea if this is already baked in at this point. It is a bit of work up front but worth while in my opinion.
• _jplc 4y ago
  The most obvious one is exclusive products or features that only exist within a single cloud provider. Binding your scripts to a non-standard API will complicate any migrations outside of it and involve a lot of work. (example: Migrating away from Azure Resource Manager templates). AWS outbound data is expensive. That complicates any data migration outside of AWS or communication between machines inside and outside AWS (example: Cheaper machines on another infrastructure provider with a lot of data transfers with AWS machines).
• yellow_lead 4y ago
  Some OpenShift specific advice: There are OpenShift components that are not present in native k8s - i.e the OpenShift router. Also, OpenShift dashboard, and some management tools. All OpenShift commands use `oc` instead of `kubectl` as well. If you rely heavily on this stuff in build scripts, processes, or running applications, migrating at some later point could be a good amount of engineering work.
  • rkwz 4y ago
    We migrated from OCP to EKS, and IIRC, OpenShift router is Kubernetes Ingress? Also, Kubernetes Dashboard [1] is a similar tool to OpenShift dashboard. [1] https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/ https://kubernetes.io/docs/tasks/access-application-cluster/...
    • yellow_lead 4y ago
      You can replace it with K8s ingress but I think it's separate? https://github.com/openshift/router https://github.com/openshift/router Looks like you can run this on native k8s so maybe not a big deal anyways
  • robszumski 4y ago
    oc and kubectl are interchangable for create/apply/edit/delete type actions. It just also has commands for upgrading the cluster and stuff like that. You can absolutely use kubectl with an OpenShift cluster. (ex Red Hat)
    • yellow_lead 4y ago
      Yeah, I just meant more if your scripts do a lot of "oc" everywhere you'll have to change it (or symlink it somehow). Not a huge deal though
  • register 4y ago
    This doesn't seem so dramatic and doesn't seem such a strong lock-in. Any opinion on OpenShift Data Foundation?
• alphabettsy 4y ago
  Datasystems or services like DynamoDB on AWS, which are not compatible or available on other platforms. Things like Security Groups can be another one, they don’t necessarily translate directly to what you’ll find on other platforms. You don’t mention what clouds you’re evaluating, but avoiding services that aren’t available elsewhere or at least don’t have wire compatibility with those available elsewhere would be my recommendation. ex. AWS Kafka over SQS or Kinesis.
• zwkrt 4y ago
  Having worked at AWS and then a litany of other companies in Seattle that are mostly using AWS or Google cloud, here's my perspective on some lock-in that you might not have actively on your mind: * Larger companies generally have contracts with cloud providers to pay lower rates. Sometimes these contracts include obligations to use a technology for a certain period of time to get the reduced rate. * Any technology that isn't completely lift-and-shift from one cloud provider to another. It used to be that a JAR deployed to a 'real' host (say EC2) that accesses config through environment variables and communicates through HTTP was the gold standard here. Now docker broadens the possibilities a bit * All the cloud providers have annoyingly different queueing/streaming primitives (SQS, kinesis, kafka wrappers...). So if you are using those you might find it annoying to switch * Even for tried-and-true technologies like compute, MySql, K/V stores, cloud providers offer lots of "Embrace and Extend" features. * If you are wise then you will have back-ups of your data in cold storage. Getting these out can be expensive. Generally getting your data out of the cloud and into another cloud is expensive, depending on your scale. IMO the only way to truly avoid lock-in is to use bog-standard boring technologies deployed to compute instances, with very few interaction patterns other than TCP/HTTP communication, file storage, and DB access. For all but the largest companies and perverse scaling patterns, this will get you where you are going, and is probably cheaper than using all the fancy bells and whistles offered by which ever cloud provider you are using.
  • jerrygenser 4y ago
    One thing that I've seen work is that if you absolutely require the ability to deploy on-prem then using something like OpenShift/Kubernetes as a primitive can work per the parent. Even if you rely on streaming like PubSub or Kinesis, one thing teams I've worked on has done is to write interfaces in the application tier that allow for using an on-prem primitive like Kafka and not depending too much on the implementation of that abstraction. I've been on a platform team that built these primitives into the application layer, e.g. a blob storage interface to access any blob store whether it's on prem NFS, azure, etc. However I'm looking at newer projects like dapr [1] and have taken them for a spin in small projects. Such a project seems like a favorable way to add "platform services" to a non-trivial app while still maintaining a pubsub abstraction that allows for swapping out the physical backend. So agreeing with you but with the caveat that you can rely on platform service interfaces and then the service behind that interface could be a cloud vendor product or a boring technology provide you don't let that abstraction leak and call a very specific kinesis feature for example. [1] https://dapr.io/ https://dapr.io/
• hdjjhhvvhga 4y ago
  Just have a look at the list of AWS services and you'll find over a hundred of examples. But when you look deeper, it turns out people get locked in just because they want, not because they have to. A good example is ECR. You really don't have to use it to use Docker effectively on AWS, but it's slightly more convenient than spinning up an EC2 instance with a private Docker repo. Also it's well documented, many people use it and so on. So you get hooked up, you write scripts, and when finally you start thinking about switching you realize the sheer amount of work needed to modify all this is just scary. So you say, "I can't afford the downtime" and continue with AWS.
• tester756 4y ago
  I've heard that every year we're having less people with "traditional" admin skills, or not willing to work for non-devops salaries so it seems like in a few years that's gonna be the biggest vendor lock cuz admins (or actually their new name: devops) will only be able to operate on their abstractions.yaml provided by $cloud
• sokoloff 4y ago
  My 2¢ is "most companies should not avoid vendor lock-in, but rather should lean in and make maximum productive use of the tools and features that their chosen cloud vendor provides". Engineer time and attention is more expensive than most people give it credit for and designing for a future, seamless cross-cloud migration is building a gold-plated pyramid of YAGNI for most companies.
  • glutamate 4y ago
    Are you talking about large or small companies? If small, why not just use RoR/Django/whatever + PostgreSQL? If large, then cloud costs absolutely matter. It seems that there is very small intersection where you need cloud scale but engineer costs exceed infrastructure cost.
    • sokoloff 4y ago
      I think small and medium is well suited for cloud in areas where engineers are scarce or expensive. For me, cloud is more about pace, flexibility, and engineering efficiency than it is about scale. Even my little side projects I run on cloud. I don’t want to futz around learning how to configure, secure, and scale a DB server if I can order one up or use DynamoDB. I agree that very large and hyper scale companies are a worse fit for the cloud, largely in part because they can afford to dedicate centralized teams to running great ops. Tiny, small, and medium can’t.
  • jerrygenser 4y ago
    Agree mostly, however if you are a early-mid stage startup gaining traction and have enough of an engineering understanding to not become too coupled, then you can basically play the vendors against each other and get startup discounts or other types of discounts by swapping. I've heard of cases where vendor A gives a big discount to the tune of a the most recent year of annual billing from vendor B if you can prove that you most recent bill from vendor B is 0 due to completing the migration.
  • Terretta 4y ago
    Yes, and ... Pre-plan your offramps in case of necessary migration, architect and document those plans, and maintain those plans in the documentation of each service, so you keep those off ramps in mind as the service evolves.
• samtho 4y ago
  I’ve been consulting on contract exclusively for the last 2.5 years, and the biggest issue I’ve seen is the over reliance on AWS Lambda. People tend to go crazy because they are so easy to spin up, however, they quickly find themselves with a runaway AWS cost. This problem of infrastructure cost, as being significantly cheaper than development cost thought to be resolved by using hyper-scaling could providers, becomes salient once again. When your AWS spend, relative to your revenue, starts to impact your ability for additional headcount, something is really wrong. The problem with how teams I’ve worked with use Lambda is that they tend to use all the latest AWS specific features by rejecting the use of abstraction framework. This makes it hard to move shop to a cheaper provider and they instead opt to re-unite the functions into a single executable application and we’re back to an express app deployed on EC2.
• sam0x17 4y ago
  Monitoring and logging dashboards and stuff is almost entirely vendor specific unless you roll-your-own via structured logging and even then how you consume it can be a migration pain-point.
• ricksebak 4y ago
  Engineering staff, for sure. If my company decided all of a sudden to move from AWS to some other cloud (and nearly all of my experience as an engineer is with AWS), that’s a big headache for me and a lot of technology that I would have to re-learn. Or I could just go find another shop who is staying on AWS, and probably get a pay bump for myself too.
• starik36 4y ago
  Not necessarily programming related, though I used programming to get myself out of this pickle. Over the years I've created many Google Photos accounts for various trips and events (and to keep things free since 15GB is comes with the account). Now I wanted to consolidate everything into a single account. You would think it would be easy, but it's not. You can move photos from one account to another, but not painstakingly created albums and other customizations. I've had to use a combination of Google Takeout and Google Photos API (which, in itself, is such a half-ass implementation) to move everything intact to a new account.
  • kccqzy 4y ago
    In a similar vein, I am doing a migration from iCloud Photo Library from a completely self-hosted cloudless solution. Getting the photos out is easy enough, but there's no easy UI to export the albums and smart albums and tags etc. Was doing quite a bit of AppleScript programming before I discovered https://github.com/RhetTbull/osxphotos https://github.com/RhetTbull/osxphotos
    • rhettbull 4y ago
      I'm the author of osxphotos. Glad you found it useful!
• MarcoSanto 4y ago
  So I am contributing work to a product that is solving this exact problem. Would you mind giving it a look and see if it fits your requirements? www.nuvolaris.io
• jrudolph 4y ago
  Other commenters have covered the workload lock-in angle pretty well. Using Kubernetes as a target platform for your application already gives you a decent shot a workload portability. Keep in mind though that some K8s APIs are leaky abstractions. You pay with lock in into K8s of course. At the end of the day, lock-in is a matter of tradeoffs. An often overlooked angle is the "organizational lock-in" to the cloud. Adopting the cloud in any serious capacity with more than a handful of teams/applications means that you will eventually have to build up some basic organizational capabilities like setting up resource hierarchy (e.g. an AWS Organization with multiple accounts), an account provisioning process, federated authentication, chargeback... See https://cloudfoundation.org/maturity-model/ https://cloudfoundation.org/maturity-model/ for an overview of these topics. To be honest I have seen quite a few enterprise organizations that went through so much organizational pain integrating their first cloud provider that implementing a second provider is not really that exciting anymore. Now of course, if you plan on eventually leveraging multi-cloud anyway you can save yourself a lot of pain by setting things up with multi-cloud in mind from day one. A good read on the topic is "Cloud Strategy" from Gregor Hohpe https://architectelevator.com/book/cloudstrategy/ https://architectelevator.com/book/cloudstrategy/
• philip1209 4y ago
  Another one: IP addresses. If you offer custom domain functionality, it prohibitively hard to reach out to all of your customers to coordinate "Switch your A record from this IP to that one".
  • scarmig 4y ago
    I believe AWS, GCP, and Azure all have some form of BYOIP, though it's a bit of a process.
• Cullinet 4y ago
  The most vexing secondary effect lockup to Azure comes when you need Microsoft licensing that Microsoft discounts on Azure and offers palliative adjustments to smaller resellers of cloudy systems together with Microsoft licence agreements, which I could almost ignore using up my quota of enterprise licensing cynicism, except for the fact that margin extraction from competing cloudy resellers can't be ohbo for a probable effect on the level of hardware instances purchased for Microsoft customers who I believe are getting depressed specs as a consequence of this squeeze. Which inevitably has a compounding effect on platform renewal schedules and planned performance purchase points that can only push the package customers get downwards. I have been suspicious that whilst I am not convinced that the impact is so directly causal simply because of the relative small scale of independent clouds selling Microsoft contracts, nevertheless it could easily be this preferential self dealing the motor for slower upgrade cycles at lower budget defined configurations leading to increasing compression of the options available for Microsoft capacity and anecdotally I've found it increasingly difficult to find equivalent instances outside of Azure which if it isn't a anti competitive practice is most certainly a very harsh environment for resellers which has real effect on customer independence and I will surmise that Microsoft probably sees its position in ten years as being a much bigger and more attractive single source by default like Oracle. If being much more attractive than Oracle is attractive to you I would like to hear how. At least for Oracle, now that installs are nearly only hard mission critical F500 budget full metal jacket affairs, I can rationalise the Oracle position because Oracle at size is going to run on Oracle hardware. But the thought that Microsoft is lurching down the same tortuous path only redeemed by the fact that it's almost impossible for competition to follow after you, and taking the whole intensity of x86 competition off the table and with that a huge part of the value proposition Redmond ought to be nurturing far better than this in terms of passing on the difference between economy of scale plus advantage of platform innovation competition and that sum less some reasonable vig, simply is abhorrent not least because having a dominant swing volume customer gain insensitivity to innovation benefits is tremendously bad for the industry ecosystem entirely. This won't have to carry on for long before I will conclude that Microsoft is going to be a ARM vertical within the next ten years.
• VLM 4y ago
  I was involved in a long term project/service that moved from private bare metal to private vmware to private openstack to private vastly newer vmware to AWS. You'll probably laugh but the biggest problem we had was security, moving from one thing to another is possible but the "in between" needs to be as secure as normal operation so you write a LOT more security group style access lists than you'd think. If your process involves five middleware servers there are a large combination of partial moves possible which requires security review of each set of access lists. The second biggest problem we had with "always be moving" was latency. "Sure, we can move the mysql server today and the front end servers next month". Then insert a surprise 30 ms latency that nobody ever expected and suddenly round trips go from immeasurable and unimportant to being a pretty big idea while parts have been moved. Also funny watching front end people who did "SELECT *" and filter in their frontend because its a 10G connection find things are a little slower when the db is far away on the internet. The third biggest problem we had was documentation. "Hey its Tuesday so does anyone know where the 'ohio' database is today?" Anybody can move stuff, bigger question is can everyone find it, LOL? Whatever you use, a wiki or some more elaborate project planner, everyone needs to be able to find where "stuff" currently is. How many people need to know where things are and what's the labor cost of moving something? The forth biggest problem which has kind of gone away with Docker is the old fashioned version bump. "Well, we're moving it anyway, and it would take extra work to either upgrade the old xyz-server from 3.99 to 4.00 or install 3.99 on the new cloud, so what could possibly go wrong?" Turns out to be a lot, mostly performance tuning related although occasionally "ha ha we deprecated that feature two years ago so we removed it last week because nobody would notice". So try not to merge an upgrade process with a cloud conversion process if at all possible. The fifth biggest problem we had was budget. The bean counters liked how the electric bill was about constant and the bare metal servers were a fraction of HVAC and lighting although you'd have to replace a HDD every couple YEARS. Suddenly "operations" became bean-countable with the cloud and different clouds count different beans so suddenly someone else is driving "how we're going to save money" because overtime and weekend labor is "free" if its salaried but god help anyone provably "wasting" 25 cents on the AWS bill, and the best way to get a promotion is to force someone elses team to work saturday and sunday unpaid salaried to save fifty cents of AWS budget. The lock-in is your internal procedures will depend on some cloud providers crazy arbitrary billing ideas, they're not all on the same page. The endusers will never accept any explanation that's truthful along the lines of "sorry we can't change the font on that webpage because of AWS" which in enormous technical detail would be an entire page of tech and billing nonsense. I think really the meta-observation of cloud lockins is the front line salaried employees don't like putting in 30+ hours of unpaid maint window overtime just to lower the cloud bill by $5 so some manager can get a promotion. "Technically possible to move and reduce the bill" doesn't save money if employees quit or essentially rebel.
• heax 4y ago
  If you want the cloud to be a powerful tool you will use their higher level services. These are incompatible and cannot be reasonably abstracted away. The simple services like files which you could reasonably abstract away in your code you can also migrate when needed. If you don't want lock in you might be better of with a traditional hosting provider. The cloud is only really useful if you go in with a mindset to embrace what it offers.
• Sebb767 4y ago
  One thing I haven't seen mentioned yet: The infrastructure setup. If you're only running a VM or a container this won't be a problem, but if you have any setup that creates stacks on demand, needs dynamic DNS entries, does service discovery or similar - which you will most likely have in any medium to large setup -, you'll discover that switching cloud providers will involve a lot of friction in your application. This will be especially fun if some steps are synchronous (i.e. single API call) with cloud provider A, but callback-based with cloud provider B. Terraform can help a bit, but a lot of examples I've seen are very AWS-dependent and it won't be as simple as changing the API key to deploy it somewhere else (however, you'll still have somewhat of a documented infrastructure, so there's that). OpenShift and Kubernetes help a lot, but you'll be paying extra for using the non-native abstractions of your specific cloud and, at least in my experience, some quirks will still end up in your app - most likely somewhere in inbound routing and monitoring. That being said, vendor lock-in is a big topic, but depending on your situation, your really need to look at how much risk you are mitigating for your effort. None of the big clouds is likely to shut down unexpectedly (not even GCP) and no matter how much you prepare, moving a large infrastructure from cloud A to cloud B is always going to be both expensive and time-consuming; you will not do this for a minor reduction in the bill. If you really want to avoid lock-in, the actual way is to go multi-cloud, but this will be a lot of extra effort and I'd wager the expense is not worth it for most companies (except for backups).
• andrewstuart 4y ago
  It costs 9 cents per gigabyte to get data out of the big clouds …. AWS, Azure, Google. If you’ve got alot of data in there, it may never come out.
• adra 4y ago
  OpenShift is just k8s with batteries included so the batteries are in a real sense a lock-in to the OpenShift community so take that trade-off as you like. I wouldn't mind, but since your initial post was in the fear of lock-ins, this may be a start. Other examples: - full spec S3 (the basics are well copied at this point) - GraphDBs I've found are very different in many ways between cloud vendors - k8s load balancer bridges are different for each vendor though the big three have more or less feature parity with one another, just different impls Just as with OpenShift, you'll start to see trade-offs between vendor convenience, 'lock-in', and cost which you'll ultimately have to choose what's more important to your business in the end.
  • cmdlinecowboy 4y ago
    I use openshift at work, it’s way way more than k8s with batteries. It has downstream, secured, stable versions of open source projects built into one supported product. I see what you mean though.
• andrewstuart 4y ago
  Cloud is very expensive and very complex. Evaluate costs against self hosting.
• kkfx 4y ago
  Much depend on what you count as "real" lock-in: let's start with some dummy example: all cloud vendors offer some APIs there is no formal lock-in there, you can use them push and pull data as you wish BUT came back a minute: you USE THEM, witch means you craft something yours on top of certain third party APIs. If they change you have to change. If they do not work your service will not work (at least not normally) as well. You might say "hey, but almost ALL software use someone else code", yes, sure but cloud APIs means code you do not run, it's code that run on someone else iron. That's a TERRIBLE lock-in even if in formal terms data and logic on top is at your disposal. Habits is another form of soft but VERY HARD in practice lock-in. Let's say your employees already know on average, at least a bit, Zoom or Teams or Meet. There is no lock-in in choosing one of such platform, formally. In practice you get a certain UI for users, they get to know it, they are lost in case of change, MOST users at least. Oh, just try to see the sorry state of development of VoIP open tech, most sysadmins nowadays even HATE deskphones... There are many examples as such NORMALLY not called lock-in but in practice one of the hardest to break soft-lock-in. Oh, another form is: you decide to quit let's say Backblaze, ok. No lock-in formally... Just... Where you want your gazillion of Pb of crap ahem backups?
• l0b0 4y ago
  Having worked briefly with OpenStack and some years with AWS, I'd say OpenStack is great for what it does, but it does only a tiny fraction of AWS. For example, one of the more annoying findings was that security controls were utter garbage compared to AWS's policies. That said, if it does enough for you then avoiding lock-in is worth quite a lot in the long run.
• lee101 4y ago
  Micro example is that you can't scale rds/cloud db disk size downward easily, only upwards, so if you haven't sorted out go archiving before hand you may be stuck paying more for storage until you have both migrated data away and done the extra leg work to scale back down. Macro examples: cases where there are incentives to use for a period e.g. sustained use or yearly discounts Incentives to use proprietary technology such as S3 or dynamodb being cheap. Situations where migrations are hard (data), expensive (cold storage) or dangerous/slow to recover such as changing the DNS
• comprev 4y ago
  The cost of "lock-in" is often less than building a "cloud agnostic" product. Trying to work around cloud vendor specific nuances can increase the risk of that component/feature failing. The increased risk and longer development time might not be acceptable to management.
• khalidx 4y ago
  The two largest cloud lock-ins, hands down: - IAM (think Active Directory, AWS IAM, SSO) - Data Egress (how much does it cost to get all my GBs out again?? Answer: a lot)