7 ms·

You know, I'm totally cool with that. Given the ten-ish years I've been using AWS everything has gotten progressively cheaper and more feature rich. I see no s

You know, I'm totally cool with that. Given the ten-ish years I've been using AWS everything has gotten progressively cheaper and more feature rich. I see no signs of that stopping. I'll happily take on the risk of that theoretical future wherein for some reason I need to unwind from AWS, and in turn continue to save countless hours of my and my engineers' time not spent tackling solved problems, and focusing on our core business instead.

toomuchtodo 8y ago
I’m okay with you being cool with it because where there’s chaos, there’s money to be made. People will eventually move out of AWS (no lead lasts forever), as the cycle goes, and someone will get paid to orchestrate that. I encourage my competitors to marry themselves to a vendor’s proprietary stack. Source: 18 years in tech. Have done my share of unwinding from vendors
- CoolAndComposed 8y ago
  Perfection is the enemy of good. You have to have a product before improving it. Blah blah blah. God forbid you tie yourself to that git ecosystem. eyeroll
  - deleted 8y ago
    [deleted]
  - lccarrasco 8y ago
    You can't compare a FOSS like git to a complete stack of proprietary services over which you have zero control or knowledge of how it works under the hood.
    - scarface74 8y ago
      Right because if you trust FOSS you never have to worry about a 2 year old vulnerabilities in how they implemented SSL....
      - tarzip 8y ago
        You certainly should worry about the possibility of zero day attacks either when using FOSS or a proprietary solution. If the provider of a proprietary solution stops offering it you might have no easy path of migration where as hypothetically FOSS solutions are easier to self host or find a new hoster for (and thus reducing the cost of a potential migration)
        scarface74 8y ago
        If a FOSS solution is abandoned, it's doubtful that most companies are going to take on the maintenance themselves. They are going to start an initiative to migrate. But that goes back to the old saying "no one ever got fired for buying IBM." The same can be applied to Microsoft or AWS. Yes MS has put plenty of technologies in maintenance mode but you didn't have to rush to migrate. IBM still sells system that are compatible with what they sold in the 80s.
        tylerhou 8y ago
        On the other hand, if a FOSS solution is abandoned you typically have quite a long time to migrate since you can self-host. If AWS shuts down tomorrow and you rely on it heavily, you're basically fucked.
        scarface74 8y ago
        If AWS shuts down tomorrow. There are a lot of companies that are going to be in the same boat - including Amazon and Netflix. I would be more worried about my one colocated data center getting shut down or getting destroyed than the entire global AWS infrastructure that has data centers in 50+ availability zones. As far as software, most AWS services are just managed versions of available software. Even if you're using lambdas for API endpoints, if you treat your lambdas like Controller actions, it shouldn't be that much of a heavy lift to concert them into standard MVC APIs equivalent. For another perspective, listen to the podcast interview of Adrian Cockcroft, the guy who led the migration of Netflix's infrastructure from self hosted to AWS hosted. http://www.se-radio.net/2014/12/episode-216-adrian-cockcroft-on-the-modern-cloud-based-platform/ http://www.se-radio.net/2014/12/episode-216-adrian-cockcroft...
- anf 8y ago
  Seems like you can both be right in different circumstances. Humble Bundle got to a nice acquisition married to GCP. Snapchat has successfully unwound. I haven't looked into it in depth but it seems examples on both sides abound.
  - deleted 8y ago
    [deleted]
- scarface74 8y ago
  And eventually any product you use will need to be changed. When that time comes you make the necessary changes. But as far as being locked in to IBM as an analogy, that doesn't really support the argument. There are companies still running 30+ year old COBOL programs and IBM still sells compatible solutions.
- VectorLock 8y ago
  In my opinion you've got the right idea, but I think some of your competitors might encourage you to keep spending cycles on pre-optimizing for vendor lock-in while they're creating features and being competitive.
  - toomuchtodo 8y ago
    Off topic: Ideally, infrastructure resources optimize infrastructure and developers iterate on features with a robust CICD pipeline and a top notch local dev environment. That’s the folly of developers being expected to build infrastructure and develop, it slows devs down. People and time are your most expensive resources, do not slow your team down, shard responsibility as soon as you can afford to. Everyone cannot be an expert in all domains, and there are only so many working hours in a day.
    - scarface74 8y ago
      You don't have to be an "expert". It takes relatively little time to get "good enough" at AWS to spin up a VPC, and use Beanstalk to spin up a web server with load balancing and set up an RDS instance with the database of your choosing. On a more advanced level, using CloudFormation or Terraform is not rocket science and neither is setting up a CodePipeline. When you grow big enough to need someone to handle netops full time, you can hire an overpriced consulting company or find a developer who knows the ins and outs of AWS and dev ops. But for smaller companies, managing AWS is not worthy of being a full time job if you know your stuff around automation. I'm mostly either a "Senior Developer" or an "Architect" depending on how the wind is blowing, but from working with "AWS architects" and consulting companies, I know I can hold my own against most non-Netflix level AWS architects. But I'm glad we have a third party consulting company to handle the drudgery that I don't want to do even though I do have admin access to the console.
- gfodor 8y ago
  In the long run, we're all dead. How do you make an impact given finite time and resources? Vendor lock in is already far down the list of existential risks to tech ventures. Long term risk due to adoption of AWS specifically is even farther given their track record so far. What you're talking about here is survivorship bias -- yes, indeed you will find people paying big sums to migrate off of AWS for whatever reason. But they're still around! Unless of course you assume using AWS (or any vendor for that matter) provides no competitive advantage whatsoever, even in the short term. The specific category of risk you are talking about here are tech ventures that fail because of a specific sequence of events: - They choose AWS - They, miraculously, create a successful business on AWS - Some existential risk emerges due to their use of AWS - They either fail or cannot afford to move off of AWS - This singular decision causes their business to fail catastrophically - And, they would have been successful had they not chosen AWS in the first place This is a very specific path to failure and is highly unlikely relative to the more common cases of "they never found product-market fit" or "they had a toxic culture" or "they decided to build everything themselves and ran out of runway."
  - toomuchtodo 8y ago
    > In the long run, we're all dead. How do you make an impact given finite time and resources? Vendor lock in is already far down the list of existential risks to tech ventures. Long term risk due to adoption of AWS specifically is even farther given their track record so far. I work for a ~billion dollar organization in risk management. If developers can't certify to our team that you can pull your app off of $cloud_provider and have it running on prem or in another cloud provider in a few weeks, it doesn't go to a cloud provider. We'll assist with their IaaS/PaaS tooling selection, infrastructure orchestration, container lifecycle process, and other ancillary needs to ensure this requirement can be met. The issue isn't survivorship bias, it's risk management, business continuity, and cost management. It's entirely possible your organization doesn't place a high dollar value on these risks, but that's a business decision each organization needs to make for itself as a whole, and its products and services individually.
    - gfodor 8y ago
- jedberg 8y ago
  > People will eventually move out of AWS The most likely outcome has already played out. A lot of people aren't moving out of their datacenters, they're just putting new workloads in AWS. Sure, some big players actually moved, like Netflix, because the gains outweighed the cost of moving, but most enterprises don't have the budget or don't care. If something ever comes along that is significantly better, most people won't move out. They'll just put new workloads in the new thing.
  - toomuchtodo 8y ago
    Netflix workloads are a bit different than typical workloads (duck curve traffic right before the evening rush hits, bulk transcoding) and I’m confident Netflix doesn’t pay anywhere close to AWS retail prices. Also, Netflix has its own CDN for serving its video content using their OpenConnect appliances (you’re aware of that, but the audience might not be). Drew Houston, CEO of Dropbox, confirms my stance argued in this thread on Dropbox’s first earnings call: https://www.cnbc.com/2018/05/10/dropbox-earnings-q1-2018.html https://www.cnbc.com/2018/05/10/dropbox-earnings-q1-2018.htm...
    - jedberg 8y ago
      I think you may have missed my point (because everything you wrote supports it). Netflix moved out of their datacenter and into the cloud because their workload was different enough to warrant the investment. Most enterprises don't have enough of a different workload for that to make sense, so they don't move out of their datacenter. Dropbox didn't actually move out of AWS, they just started storing new data in their new datacenters. They did it because it was cheaper at their scale, it had nothing to do with lock-in. And for the same reasons, when the next big thing comes along, most companies won't move out of AWS. Unless there is a significant cost savings or significant new architecture, they won't move. They will just put new stuff in the new thing. Lock-in isn't an issue for most enterprises today, and won't be in the future. Inertia is the biggest thing that stops them from moving old workloads to AWS.
csomar 8y ago
What if they kick you out? (Or their AI fraud detection mistakes you for someone else)
jacobsenscott 8y ago
That's the life cycle of proprietary stacks - when there's a lot of demand for them they dump resources into adding more and more and cheaper features. Nobody believes the party will end. But it always does. AWS is certainly more than 50% through that life cycle of "hot new thing", "stable feature rich thing that will be around forever", "ash heap".
- scarface74 8y ago
  If you went by the mantra "No one ever got fired for buying IBM in 1983" and decided to build your product on DB2 and COBOL, you could still get support and new compatible systems 35 years later. If you decided to build your stack on top of MS SQL Server in 1990 you would have still had a relatively painless upgrade path over the years. We can also add products byy Oracle and Adobe.

toomuchtodo 8y ago

I’m okay with you being cool with it because where there’s chaos, there’s money to be made. People will eventually move out of AWS (no lead lasts forever), as the cycle goes, and someone will get paid to orchestrate that. I encourage my competitors to marry themselves to a vendor’s proprietary stack. Source: 18 years in tech. Have done my share of unwinding from vendors

CoolAndComposed 8y ago
Perfection is the enemy of good. You have to have a product before improving it. Blah blah blah. God forbid you tie yourself to that git ecosystem. eyeroll
- deleted 8y ago
  [deleted]
- lccarrasco 8y ago
  You can't compare a FOSS like git to a complete stack of proprietary services over which you have zero control or knowledge of how it works under the hood.
  - scarface74 8y ago
    Right because if you trust FOSS you never have to worry about a 2 year old vulnerabilities in how they implemented SSL....
    - tarzip 8y ago
      You certainly should worry about the possibility of zero day attacks either when using FOSS or a proprietary solution. If the provider of a proprietary solution stops offering it you might have no easy path of migration where as hypothetically FOSS solutions are easier to self host or find a new hoster for (and thus reducing the cost of a potential migration)
      - scarface74 8y ago
        If a FOSS solution is abandoned, it's doubtful that most companies are going to take on the maintenance themselves. They are going to start an initiative to migrate. But that goes back to the old saying "no one ever got fired for buying IBM." The same can be applied to Microsoft or AWS. Yes MS has put plenty of technologies in maintenance mode but you didn't have to rush to migrate. IBM still sells system that are compatible with what they sold in the 80s.
        tylerhou 8y ago
        On the other hand, if a FOSS solution is abandoned you typically have quite a long time to migrate since you can self-host. If AWS shuts down tomorrow and you rely on it heavily, you're basically fucked.
        scarface74 8y ago
        If AWS shuts down tomorrow. There are a lot of companies that are going to be in the same boat - including Amazon and Netflix. I would be more worried about my one colocated data center getting shut down or getting destroyed than the entire global AWS infrastructure that has data centers in 50+ availability zones. As far as software, most AWS services are just managed versions of available software. Even if you're using lambdas for API endpoints, if you treat your lambdas like Controller actions, it shouldn't be that much of a heavy lift to concert them into standard MVC APIs equivalent. For another perspective, listen to the podcast interview of Adrian Cockcroft, the guy who led the migration of Netflix's infrastructure from self hosted to AWS hosted. http://www.se-radio.net/2014/12/episode-216-adrian-cockcroft-on-the-modern-cloud-based-platform/ http://www.se-radio.net/2014/12/episode-216-adrian-cockcroft...
anf 8y ago
Seems like you can both be right in different circumstances. Humble Bundle got to a nice acquisition married to GCP. Snapchat has successfully unwound. I haven't looked into it in depth but it seems examples on both sides abound.
- deleted 8y ago
  [deleted]
scarface74 8y ago
And eventually any product you use will need to be changed. When that time comes you make the necessary changes. But as far as being locked in to IBM as an analogy, that doesn't really support the argument. There are companies still running 30+ year old COBOL programs and IBM still sells compatible solutions.
VectorLock 8y ago
In my opinion you've got the right idea, but I think some of your competitors might encourage you to keep spending cycles on pre-optimizing for vendor lock-in while they're creating features and being competitive.
- toomuchtodo 8y ago
  Off topic: Ideally, infrastructure resources optimize infrastructure and developers iterate on features with a robust CICD pipeline and a top notch local dev environment. That’s the folly of developers being expected to build infrastructure and develop, it slows devs down. People and time are your most expensive resources, do not slow your team down, shard responsibility as soon as you can afford to. Everyone cannot be an expert in all domains, and there are only so many working hours in a day.
  - scarface74 8y ago
    You don't have to be an "expert". It takes relatively little time to get "good enough" at AWS to spin up a VPC, and use Beanstalk to spin up a web server with load balancing and set up an RDS instance with the database of your choosing. On a more advanced level, using CloudFormation or Terraform is not rocket science and neither is setting up a CodePipeline. When you grow big enough to need someone to handle netops full time, you can hire an overpriced consulting company or find a developer who knows the ins and outs of AWS and dev ops. But for smaller companies, managing AWS is not worthy of being a full time job if you know your stuff around automation. I'm mostly either a "Senior Developer" or an "Architect" depending on how the wind is blowing, but from working with "AWS architects" and consulting companies, I know I can hold my own against most non-Netflix level AWS architects. But I'm glad we have a third party consulting company to handle the drudgery that I don't want to do even though I do have admin access to the console.
gfodor 8y ago
In the long run, we're all dead. How do you make an impact given finite time and resources? Vendor lock in is already far down the list of existential risks to tech ventures. Long term risk due to adoption of AWS specifically is even farther given their track record so far. What you're talking about here is survivorship bias -- yes, indeed you will find people paying big sums to migrate off of AWS for whatever reason. But they're still around! Unless of course you assume using AWS (or any vendor for that matter) provides no competitive advantage whatsoever, even in the short term. The specific category of risk you are talking about here are tech ventures that fail because of a specific sequence of events: - They choose AWS - They, miraculously, create a successful business on AWS - Some existential risk emerges due to their use of AWS - They either fail or cannot afford to move off of AWS - This singular decision causes their business to fail catastrophically - And, they would have been successful had they not chosen AWS in the first place This is a very specific path to failure and is highly unlikely relative to the more common cases of "they never found product-market fit" or "they had a toxic culture" or "they decided to build everything themselves and ran out of runway."
- toomuchtodo 8y ago
  > In the long run, we're all dead. How do you make an impact given finite time and resources? Vendor lock in is already far down the list of existential risks to tech ventures. Long term risk due to adoption of AWS specifically is even farther given their track record so far. I work for a ~billion dollar organization in risk management. If developers can't certify to our team that you can pull your app off of $cloud_provider and have it running on prem or in another cloud provider in a few weeks, it doesn't go to a cloud provider. We'll assist with their IaaS/PaaS tooling selection, infrastructure orchestration, container lifecycle process, and other ancillary needs to ensure this requirement can be met. The issue isn't survivorship bias, it's risk management, business continuity, and cost management. It's entirely possible your organization doesn't place a high dollar value on these risks, but that's a business decision each organization needs to make for itself as a whole, and its products and services individually.
  - gfodor 8y ago
jedberg 8y ago
> People will eventually move out of AWS The most likely outcome has already played out. A lot of people aren't moving out of their datacenters, they're just putting new workloads in AWS. Sure, some big players actually moved, like Netflix, because the gains outweighed the cost of moving, but most enterprises don't have the budget or don't care. If something ever comes along that is significantly better, most people won't move out. They'll just put new workloads in the new thing.
- toomuchtodo 8y ago
  Netflix workloads are a bit different than typical workloads (duck curve traffic right before the evening rush hits, bulk transcoding) and I’m confident Netflix doesn’t pay anywhere close to AWS retail prices. Also, Netflix has its own CDN for serving its video content using their OpenConnect appliances (you’re aware of that, but the audience might not be). Drew Houston, CEO of Dropbox, confirms my stance argued in this thread on Dropbox’s first earnings call: https://www.cnbc.com/2018/05/10/dropbox-earnings-q1-2018.html https://www.cnbc.com/2018/05/10/dropbox-earnings-q1-2018.htm...
  - jedberg 8y ago
    I think you may have missed my point (because everything you wrote supports it). Netflix moved out of their datacenter and into the cloud because their workload was different enough to warrant the investment. Most enterprises don't have enough of a different workload for that to make sense, so they don't move out of their datacenter. Dropbox didn't actually move out of AWS, they just started storing new data in their new datacenters. They did it because it was cheaper at their scale, it had nothing to do with lock-in. And for the same reasons, when the next big thing comes along, most companies won't move out of AWS. Unless there is a significant cost savings or significant new architecture, they won't move. They will just put new stuff in the new thing. Lock-in isn't an issue for most enterprises today, and won't be in the future. Inertia is the biggest thing that stops them from moving old workloads to AWS.

csomar 8y ago

What if they kick you out? (Or their AI fraud detection mistakes you for someone else)

jacobsenscott 8y ago

That's the life cycle of proprietary stacks - when there's a lot of demand for them they dump resources into adding more and more and cheaper features. Nobody believes the party will end. But it always does. AWS is certainly more than 50% through that life cycle of "hot new thing", "stable feature rich thing that will be around forever", "ash heap".

scarface74 8y ago
If you went by the mantra "No one ever got fired for buying IBM in 1983" and decided to build your product on DB2 and COBOL, you could still get support and new compatible systems 35 years later. If you decided to build your stack on top of MS SQL Server in 1990 you would have still had a relatively painless upgrade path over the years. We can also add products byy Oracle and Adobe.