6 ms·
Well, sure, if you hate your devops team and you want to make sure they can’t use any of the proprietary functionality of either provider. At which point, if yo
by BurritoAlPastor 7y ago
Well, sure, if you hate your devops team and you want to make sure they can’t use any of the proprietary functionality of either provider. At which point, if you want to be managing a fleet of vanilla Linux boxes yourself, why use a cloud provider at all?
- stingraycharles 7y agoThis seems overly negative. There are lots of ways to do hybrid clouds, especially if you’re doing it for only the more critical parts of your application.
- mathattack 7y agoStaying on current versions, and the ability to scale usage up and down?
- fkdo 7y agoWhy would you want to lock into a cloud provider? You're losing a lot of operational flexibility for less devops and sysaadmin work. You are really limiting your tech stack by using standardized things like Jenkins, Docker, K8, mqtt, kafka.
- StreamBright 7y agoFor the same reason you want "to lock in" (meaning use) any solution. You do not want to build or operate it yourself. Why don't you take this further? Why to use a water utility if you can just drill your own wells? Most businesses are better of on cloud because their core business is not to build and operate datacenters but provide services to their customers (on the top of datacenters running their apps).
- bradstewart 7y agoIt's not really that I "want to lock into a cloud provider". Sometimes I simply don't have the human bandwidth available to handle devops and sysadmin work while building the actual product. "Outsourcing" those functions to cloud services can be big win for a small team. Like all engineering, it's a trade off.
- toomuchtodo 7y ago* You should not be locking yourself into proprietary functionality of a cloud provider unless you are deeply interested in what happened to Oracle customers getting raked over the coals happening to you. * DevOps teams can be multi-cloud relatively easy when using infrastructure as code tooling (Terraform, Packer, etc) and traditional DevOps practices * Why manage a fleet of vanilla boxes when you can use vanilla boxes with Kubernetes and not get gouged by cloud providers in the first place? You don't need to jump off the hype train if you never got on in the first place.
- opportune 7y agoProprietary managed services can save a lot of dev/setup/SRE time though. Many businesses have more pressing things to work on than spending dev time to prevent vendor lock-in.
- toomuchtodo 7y agoEveryone spends their runway differently. Once you’re off the ground, derisk.
- jjeaff 7y agoMost companies don't have a "runway", they are just bootstrapped and have to actually justify their expenses and lock-in every day.
- tomcam 7y agoif I voluntarily choose a provider at a price that’s acceptable to me am I being gouged?
- tjr225 7y agoNot yet, but it seems obvious to me that the GP was referring to a situation where the price changes and then you are getting gouged. That's exactly what the negative connotations of lock-in refer to.
- 7y ago
- the8472 7y agoIt's not quite that black and white. You can use common/open APIs and cross-provider tooling whenever available and provider-flavored ones where necessary. It's more effort, but still less than hand-rolling everything. Of course that only works as long as you're swapping out largely replaceable parts. If you built everything around some proprietary service then yeah, you've tied yourself to that anchor.
- peterwwillis 7y ago> why use a cloud provider at all? Cost+speed of scalability, and managed services. If you rarely need to scale, your workloads are all predictable, and you don't need managed services/support, you should just buy some VPSes or dedicated boxes.