5 ms·

Why is it stupid, dangerous and short sighted? People say those things about cloud vendor locking like it's a obvious truth. I really annoyed by this arrogance

Why is it stupid, dangerous and short sighted? People say those things about cloud vendor locking like it's a obvious truth. I really annoyed by this arrogance among my systems minded peer group. I get where this comes from, but it's too simplistic. Even if your build close around the AWS primitives, why is it harder to migrate away from this when necessary than building the alternative yourself from before you can proof your business or build any MVP. I'd say use whatever service you helps to get your product out there fast and allows you to iterate quickly. This will also free time to consider your long term options. The primitives and constraints imposed by a cloud provider often make your life easier even if you migrate to bare metal or another cloud. I'd even go so far to argue the other way around: You get away with way shittier, less future proof design when running on bare metal and have a ops team taking care of your pets. Not being able to move that to a cloud, private or public, would concern me most.

camus2 10y ago
> Why is it stupid, dangerous and short sighted? People say those things about cloud vendor locking like it's a obvious truth It depends on the relationship you have with these cloud vendors. If it is a custom contract , with penalties if the host screws up , then by all means, lock yourself in as much as you like. But most clients aren't in any position to negotiate with Amazon. Worse, a well known vendors doesn't hesitate to shut down paid accounts without notice. Imagine your business depends on a specific component of that vendor's stack ... you are screwed. > The primitives and constraints imposed by a cloud provider often make your life easier even if you migrate to bare metal or another cloud. Provided you can "migrate" to something else at first place. Look at all these sorry folks building their "serverless architecture" on Amazon. They depend entirely on Amazon services and SDK. There is no migration path to something else.
setq 10y ago
I've build a couple of startups and sold out, worked for a couple of well known ones as early employees and now reside in an architecture position. This magical free time never appears, particularly when your business is suddenly return focused after your capital comes in. The low capital cost of the services your are integrating typically is used as a justification to utilise them more. Then a client comes along dangling a few million quid/dollars etc who wants it somewhere else for regulatory compliance or wants to self host it and you have to turn them away. It's not about making your life easier in the short term, it's about building a solid business foundation and continuation plan and a good DR strategy. A lot of people don't consider this and crash and burn and it's not pretty. Edit: your approach is known among my circles as the "Ferengi badass" approach.
- discordianfish 10y ago
  > This magical free time never appears, particularly when your business is suddenly return focused after your capital comes in. The low capital cost of the services your are integrating typically is used as a justification to utilise them more. Never talked about magical free time, I'm talking of not having to dedicate an ops team to maintain your bare metal infrastructure. > Then a client comes along dangling a few million quid/dollars etc who wants it somewhere else for regulatory compliance or wants to self host it and you have to turn them away. How do you imaging this being easier with a bare metal infrastructure than one on AWS? It really depends on the specifics: If you're using managed services and the customer wants a on-site solution, you need to find replacement for those. If your customer needs something geographically close, deploying to another region is trivial compared to building our a DC suite. > It's not about making your life easier in the short term, it's about building a solid business foundation and continuation plan and a good DR strategy. A lot of people don't consider this and crash and burn and it's not pretty. Indeed, and depending on the specifics it might be much more reasonable to run in the cloud.
  - setq 10y ago
    I explicitly mean IaaS not bare metal as the target. IaaS is portable. PaaS is not. I wouldn't have an ops team.
  - halomru 10y ago
    >I'm talking of not having to dedicate an ops team to maintain your bare metal infrastructure. You can still build an architecture that works on any of the large feature rich cloud providers with minimal retooling, and that can be deployed on bare metal if needed (minus automatic scaling, load balancing etc.) In the end the trick is to build infrastructure agnostic apps that work on AWS as well as on IBMs cloud
    - setq 10y ago
      This. OpenStack seems to fit that role well.
jerf 10y ago
"Why is it stupid, dangerous and short sighted? People say those things about cloud vendor locking like it's a obvious truth. I really annoyed by this arrogance among my systems minded peer group." It's not arrogance. It's decades of experience in this industry, and simple business reality. If you let yourself get "locked in the trunk", you've made yourself vulnerable to whoever owns the trunk. If an entire industry gets locked in the same trunk, the only sensible decision for the owner of that trunk is to raise the rent. What are the people in it going to do? Most recently the industry was here with Microsoft Windows. Our whole industry was so beholden to Microsoft that we basically danced to their tune. Computer manufacturers didn't sell "computers", they sold "Windows machines". Microsoft could move in and take over entire sub-industries with impunity, like the spreadsheet industry and office suites in general, networking software industry, the browser industry, pretty much anything that was software and they decided they wanted. Yes, there are entities that are too small to be worried about this. If you're a five-person startup, you've got bigger problems than whether or not your cloud vendor is going to become a monopoly in five years and jack the prices through the roof for your services. But larger entities need to be more careful. There's other cases too; you can end up over-exposed to Oracle databases, for instance. Some small-medium companies end up designing custom hardware for some purpose and end up overexposed to the only people willing to make that hardware at a price you can profit from it. It's not a good idea to be stuck to one entity like that, and even if you judge the benefits to outweigh the costs, that doesn't mean the costs don't exist and you can just forget about them. It's something you need to constantly reevaluate.
- discordianfish 10y ago
  I agree that those are all valid problem. My point is more that it's not such hard lock as people assume who never built a "cloud native" infrastructure. I wish we would discuss more specifics. So what are we talking about? Snapchat running on app engine is probably one of the more extrem examples. Let say they aren't happy with that anymore. So far they deployed easily by using the google apps api and since want to keep a similar workflow. They could setup kubernetes for that. Same for managed data stores. Maybe there is no 1:1 open source equivalent, but most likely there is one similar in design which won't require much change in your code. Of course all this takes time and live migrating your site isn't trivial. But so does building on bare metal from the start. Sure, you don't all the fancy self-service features right away, but you want them eventually. So even if you realize that moving to the cloud, or a specific cloud was a huge mistake, it's not like being locked in a trunk.

camus2 10y ago

> Why is it stupid, dangerous and short sighted? People say those things about cloud vendor locking like it's a obvious truth It depends on the relationship you have with these cloud vendors. If it is a custom contract , with penalties if the host screws up , then by all means, lock yourself in as much as you like. But most clients aren't in any position to negotiate with Amazon. Worse, a well known vendors doesn't hesitate to shut down paid accounts without notice. Imagine your business depends on a specific component of that vendor's stack ... you are screwed. > The primitives and constraints imposed by a cloud provider often make your life easier even if you migrate to bare metal or another cloud. Provided you can "migrate" to something else at first place. Look at all these sorry folks building their "serverless architecture" on Amazon. They depend entirely on Amazon services and SDK. There is no migration path to something else.

setq 10y ago

I've build a couple of startups and sold out, worked for a couple of well known ones as early employees and now reside in an architecture position. This magical free time never appears, particularly when your business is suddenly return focused after your capital comes in. The low capital cost of the services your are integrating typically is used as a justification to utilise them more. Then a client comes along dangling a few million quid/dollars etc who wants it somewhere else for regulatory compliance or wants to self host it and you have to turn them away. It's not about making your life easier in the short term, it's about building a solid business foundation and continuation plan and a good DR strategy. A lot of people don't consider this and crash and burn and it's not pretty. Edit: your approach is known among my circles as the "Ferengi badass" approach.

discordianfish 10y ago
> This magical free time never appears, particularly when your business is suddenly return focused after your capital comes in. The low capital cost of the services your are integrating typically is used as a justification to utilise them more. Never talked about magical free time, I'm talking of not having to dedicate an ops team to maintain your bare metal infrastructure. > Then a client comes along dangling a few million quid/dollars etc who wants it somewhere else for regulatory compliance or wants to self host it and you have to turn them away. How do you imaging this being easier with a bare metal infrastructure than one on AWS? It really depends on the specifics: If you're using managed services and the customer wants a on-site solution, you need to find replacement for those. If your customer needs something geographically close, deploying to another region is trivial compared to building our a DC suite. > It's not about making your life easier in the short term, it's about building a solid business foundation and continuation plan and a good DR strategy. A lot of people don't consider this and crash and burn and it's not pretty. Indeed, and depending on the specifics it might be much more reasonable to run in the cloud.
- setq 10y ago
  I explicitly mean IaaS not bare metal as the target. IaaS is portable. PaaS is not. I wouldn't have an ops team.
- halomru 10y ago
  >I'm talking of not having to dedicate an ops team to maintain your bare metal infrastructure. You can still build an architecture that works on any of the large feature rich cloud providers with minimal retooling, and that can be deployed on bare metal if needed (minus automatic scaling, load balancing etc.) In the end the trick is to build infrastructure agnostic apps that work on AWS as well as on IBMs cloud
  - setq 10y ago
    This. OpenStack seems to fit that role well.

jerf 10y ago

"Why is it stupid, dangerous and short sighted? People say those things about cloud vendor locking like it's a obvious truth. I really annoyed by this arrogance among my systems minded peer group." It's not arrogance. It's decades of experience in this industry, and simple business reality. If you let yourself get "locked in the trunk", you've made yourself vulnerable to whoever owns the trunk. If an entire industry gets locked in the same trunk, the only sensible decision for the owner of that trunk is to raise the rent. What are the people in it going to do? Most recently the industry was here with Microsoft Windows. Our whole industry was so beholden to Microsoft that we basically danced to their tune. Computer manufacturers didn't sell "computers", they sold "Windows machines". Microsoft could move in and take over entire sub-industries with impunity, like the spreadsheet industry and office suites in general, networking software industry, the browser industry, pretty much anything that was software and they decided they wanted. Yes, there are entities that are too small to be worried about this. If you're a five-person startup, you've got bigger problems than whether or not your cloud vendor is going to become a monopoly in five years and jack the prices through the roof for your services. But larger entities need to be more careful. There's other cases too; you can end up over-exposed to Oracle databases, for instance. Some small-medium companies end up designing custom hardware for some purpose and end up overexposed to the only people willing to make that hardware at a price you can profit from it. It's not a good idea to be stuck to one entity like that, and even if you judge the benefits to outweigh the costs, that doesn't mean the costs don't exist and you can just forget about them. It's something you need to constantly reevaluate.

discordianfish 10y ago
I agree that those are all valid problem. My point is more that it's not such hard lock as people assume who never built a "cloud native" infrastructure. I wish we would discuss more specifics. So what are we talking about? Snapchat running on app engine is probably one of the more extrem examples. Let say they aren't happy with that anymore. So far they deployed easily by using the google apps api and since want to keep a similar workflow. They could setup kubernetes for that. Same for managed data stores. Maybe there is no 1:1 open source equivalent, but most likely there is one similar in design which won't require much change in your code. Of course all this takes time and live migrating your site isn't trivial. But so does building on bare metal from the start. Sure, you don't all the fancy self-service features right away, but you want them eventually. So even if you realize that moving to the cloud, or a specific cloud was a huge mistake, it's not like being locked in a trunk.