8 ms·

It's not. If any of the big three entirely disappeared there wouldn't be a tear shed. It'd be an inconvenience at most and people would suddenly be reminded abo

by setq 10y ago

It's not. If any of the big three entirely disappeared there wouldn't be a tear shed. It'd be an inconvenience at most and people would suddenly be reminded about portability and lock in. At a microscopic level it's pretty stupid, dangerous and short sighted building your product to conform to any of these providers' services past the PaaS level. I see people with whole business on AWS who are a billing dispute away from weeks of downtime.

erpellan 10y ago
I presume every business who doesn't run all their services on their own servers inside their own building is also just a billing dispute away from downtime. And even then if you don't pay your bandwidth bill you'll still go dark.
- Retric 10y ago
  At a minimum using two hosting providers creates redundancy in both location, networks, and billing disputes.
  - setq 10y ago
    Exactly. Also it reduces portability risk. Consider if you implement SQS and SES using their native APIs then Amazon shaft you, where do you go? The answer is rewriting everything as AMQP and basic SMTP services, which until you're done, you're down.
- tobltobs 10y ago
  No, if you don't use AWS or GCloud specific services you usually can move your business from one bare metal provider to the next without problems.
  - jedberg 10y ago
    Oh boy. I take it you've never actually moved datacenters before? Last time I did it in 2007 it took weeks of planning, and the time before that in 1999 it was months of planning. You don't just get up and move. You still have a ton of data to worry about.
    - setq 10y ago
      Avoiding this is the best approach. Buy two cages in different DCs :)
      - godzillabrennus 10y ago
        Active / Active Failover between two facilities is something everyone wants until they realize how expensive it all is.
        setq 10y ago
        It is expensive. Unless your product makes a ton of cash.
        user5994461 10y ago
        Depends on the problem domain and if they thought about having active/active from the start. There are some rare stuff where active/active almost come out of the box.
    - camus2 10y ago
      > Oh boy. I take it you've never actually moved datacenters before? Last time I did it in 2007 it took weeks of planning, and the time before that in 1999 it was months of planning. That's nothing compared to a business that chooses to use a specific component that cannot be migrated from one host to another. If your architecture is truly distributed then migration is painless, because your system is designed around it.
      - la6470 10y ago
        Yeah try being distributed with your own D.Cs . Having two asynchronous replicated DR site is not a truly distributed architecture... it's something from 1998
      - la6470 10y ago
        Yeah try being distributed with your own D.Cs . Having two asynchronous replicated DR site is not a truly distributed architecture... it's something from 1998
discordianfish 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. 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.
PacketPaul 10y ago
Amazon is pretty good with billing disputes. They don't want the bad publicity of shutting someone down. Source: I work for a startup who does not pay their bills.
- setq 10y ago
  This is merely an example. There are numerous other things that can go wrong which are irrecoverable.
  - user5994461 10y ago
    All of these things can go wrong with not-AWS as well.
closeparen 10y ago
OK, but small and medium businesses with server racks in the closet are also one billing dispute with Comcast Business (or power outage lasting longer than their 5 minutes of battery UPS) away from downtime.
- setq 10y ago
  You are correct. Some of them are even swapping tapes daily blissfully unaware that the backup software failed 9 months ago and is just dumping an error in the event log, the UPS batteries are bulging about to burst, a squirrel has been working on nibbling the glass out of their fiber connection between two buildings and there is water dribbling into the main switch rack that caused a fire that is going to engulf the entire building. I've seen all these and it scares the shit out of me and should do with everyone. Hence why people must build a DR strategy, run scenarios, regularly test it. We're categorically just talking about one of the risk vectors here which is a pretty soft one but as destructive to a business as a large fire.

by setq 10y ago

erpellan 10y ago

I presume every business who doesn't run all their services on their own servers inside their own building is also just a billing dispute away from downtime. And even then if you don't pay your bandwidth bill you'll still go dark.

Retric 10y ago
At a minimum using two hosting providers creates redundancy in both location, networks, and billing disputes.
- setq 10y ago
  Exactly. Also it reduces portability risk. Consider if you implement SQS and SES using their native APIs then Amazon shaft you, where do you go? The answer is rewriting everything as AMQP and basic SMTP services, which until you're done, you're down.
tobltobs 10y ago
No, if you don't use AWS or GCloud specific services you usually can move your business from one bare metal provider to the next without problems.
- jedberg 10y ago
  Oh boy. I take it you've never actually moved datacenters before? Last time I did it in 2007 it took weeks of planning, and the time before that in 1999 it was months of planning. You don't just get up and move. You still have a ton of data to worry about.
  - setq 10y ago
    Avoiding this is the best approach. Buy two cages in different DCs :)
    - godzillabrennus 10y ago
      Active / Active Failover between two facilities is something everyone wants until they realize how expensive it all is.
      - setq 10y ago
        It is expensive. Unless your product makes a ton of cash.
      - user5994461 10y ago
        Depends on the problem domain and if they thought about having active/active from the start. There are some rare stuff where active/active almost come out of the box.
  - camus2 10y ago
    > Oh boy. I take it you've never actually moved datacenters before? Last time I did it in 2007 it took weeks of planning, and the time before that in 1999 it was months of planning. That's nothing compared to a business that chooses to use a specific component that cannot be migrated from one host to another. If your architecture is truly distributed then migration is painless, because your system is designed around it.
    - la6470 10y ago
      Yeah try being distributed with your own D.Cs . Having two asynchronous replicated DR site is not a truly distributed architecture... it's something from 1998
    - la6470 10y ago
      Yeah try being distributed with your own D.Cs . Having two asynchronous replicated DR site is not a truly distributed architecture... it's something from 1998

discordianfish 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. 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.

PacketPaul 10y ago

Amazon is pretty good with billing disputes. They don't want the bad publicity of shutting someone down. Source: I work for a startup who does not pay their bills.

setq 10y ago
This is merely an example. There are numerous other things that can go wrong which are irrecoverable.
- user5994461 10y ago
  All of these things can go wrong with not-AWS as well.

closeparen 10y ago

OK, but small and medium businesses with server racks in the closet are also one billing dispute with Comcast Business (or power outage lasting longer than their 5 minutes of battery UPS) away from downtime.

setq 10y ago
You are correct. Some of them are even swapping tapes daily blissfully unaware that the backup software failed 9 months ago and is just dumping an error in the event log, the UPS batteries are bulging about to burst, a squirrel has been working on nibbling the glass out of their fiber connection between two buildings and there is water dribbling into the main switch rack that caused a fire that is going to engulf the entire building. I've seen all these and it scares the shit out of me and should do with everyone. Hence why people must build a DR strategy, run scenarios, regularly test it. We're categorically just talking about one of the risk vectors here which is a pretty soft one but as destructive to a business as a large fire.