5 ms·

Your assumption that you'll build a unicorn or be able to untangle from vendor lock in at a time of your choosing with money you have no better use for is fairl

Your assumption that you'll build a unicorn or be able to untangle from vendor lock in at a time of your choosing with money you have no better use for is fairly optimistic. The reality is you'll need to do it when you are tight on resources and you're stuck rebuilding what has become a very complex infrastructure (because you spent the last 5 years hooking into every proprietary bell and whistle) from scratch - with no internal expertise because you didn't start early when it was still a tractable problem. I'm not saying you need to choose between AWS or running on your own physical hardware. But I am saying you don't want to lock in to the proprietary parts of AWS, which do tend to add lots of complexity to your infrastructure because they make that complexity easy to use. Spinning up some ubuntu ec2 servers is fine - you can move those anywhere easily.

scarface74 8y ago
Have you seen the code that people write? When it comes to complexity, AWS is the least of their worries. If I happen to luck up and be part of unicorn that grows so large that AWS can't handle it - something larger than Netflix - I think I'll have the resources needed. I've worked for a company that had two issues - badly written software and a badly architected AWS environment. Guess which one was easier to fix? All of the companies that tied their fate to Webforms, Ruby (Twitter), or some other deprecated tech have far bigger problems than someone who tied themselves to AWS. As far as AWS what complexity is that? Databases - all of their databases are compatible with standard databases except for DynamoDB. DynamoDB sucks anyway. If I wanted a managed NoSQL database, I would go with one from Mongo. Messaging - You usually end up sending and reviewing messages from one central place in your code, changing your messages system out is pretty simple. Caching - ElastiCache exposes either a Memcached or RedisCache client. Load balancing - the only thing special you do as far as software is have a health check endpoint. I used the same endpoint that I used on prem with Consul+Fabio. ElasticSearch -same as using your own. Autoscaling - I've got nothing. I've never tried doing autoscaling on prem. Codepipeline/CodeBuild/Code Deploy - the triggering event is nothing more than a standard Web hook from your git repo of choice, Code Build is a preconfigured Docker Container that executes commands based on a yml file. I use a Python Lambda function for deployment, but I could run that in anything. Even Lambda if written correctly - your handler should be skinny and treated like a Controller - shouldn't be that hard to port over. Fargate/ECS - orchestration for standard Docker containers. Parameter Store - yeah I could (and have) set up a cluster of Consul/Vault servers but why would I instead of using a service that ties in security roles and encryption with everything else? Load Balancing - I've also set up my own Consul+Fabio clients on web servers/app servers for load balancing and service discovery. Not trying to do that anymore either when I can configure an ALB and an autoscaling group. The software wouldn't be the hard part to move over. Even if we ran everything in EC2 instances, the hard part would be duplicating multiple geographically redundant VPCs in multiple locations in the US and an environment in Asia that was close to the outsourced developers. Netflix went all in on AWS and much of their tooling is tied tightly into AWS. If Netflix can trust its entire business to AWS, I think anyone can.
- toomuchtodo 8y ago
  > If Netflix can trust its entire business to AWS, I think anyone can. This is a terrible argument. Netflix is simply a media streaming company, with very little importance compared to other businesses. Most of its data is served from its own CDN!
  - scarface74 8y ago
    So how many businesses are actually important? Check out a few of Netflix's blog posts, AWS re-invent presentations (available on YouTube), the podcast interview, I posted earlier, and thier open source project. Netflix uses a lot of AWS services.
  - Zombieball 8y ago
    I don’t think you have an understanding of the complexity behind Netflix. Their tech blog is a great resource that provides insight into some of their engineering challenges. I’d highly recommend. Edit: just realized I duplicated scarface74’s comment. My bad!
    - toomuchtodo 8y ago
      I’m very familiar with Netflix’s tooling and orchestration stack, and have had discussions with several of their engineers.

scarface74 8y ago

Have you seen the code that people write? When it comes to complexity, AWS is the least of their worries. If I happen to luck up and be part of unicorn that grows so large that AWS can't handle it - something larger than Netflix - I think I'll have the resources needed. I've worked for a company that had two issues - badly written software and a badly architected AWS environment. Guess which one was easier to fix? All of the companies that tied their fate to Webforms, Ruby (Twitter), or some other deprecated tech have far bigger problems than someone who tied themselves to AWS. As far as AWS what complexity is that? Databases - all of their databases are compatible with standard databases except for DynamoDB. DynamoDB sucks anyway. If I wanted a managed NoSQL database, I would go with one from Mongo. Messaging - You usually end up sending and reviewing messages from one central place in your code, changing your messages system out is pretty simple. Caching - ElastiCache exposes either a Memcached or RedisCache client. Load balancing - the only thing special you do as far as software is have a health check endpoint. I used the same endpoint that I used on prem with Consul+Fabio. ElasticSearch -same as using your own. Autoscaling - I've got nothing. I've never tried doing autoscaling on prem. Codepipeline/CodeBuild/Code Deploy - the triggering event is nothing more than a standard Web hook from your git repo of choice, Code Build is a preconfigured Docker Container that executes commands based on a yml file. I use a Python Lambda function for deployment, but I could run that in anything. Even Lambda if written correctly - your handler should be skinny and treated like a Controller - shouldn't be that hard to port over. Fargate/ECS - orchestration for standard Docker containers. Parameter Store - yeah I could (and have) set up a cluster of Consul/Vault servers but why would I instead of using a service that ties in security roles and encryption with everything else? Load Balancing - I've also set up my own Consul+Fabio clients on web servers/app servers for load balancing and service discovery. Not trying to do that anymore either when I can configure an ALB and an autoscaling group. The software wouldn't be the hard part to move over. Even if we ran everything in EC2 instances, the hard part would be duplicating multiple geographically redundant VPCs in multiple locations in the US and an environment in Asia that was close to the outsourced developers. Netflix went all in on AWS and much of their tooling is tied tightly into AWS. If Netflix can trust its entire business to AWS, I think anyone can.

toomuchtodo 8y ago
> If Netflix can trust its entire business to AWS, I think anyone can. This is a terrible argument. Netflix is simply a media streaming company, with very little importance compared to other businesses. Most of its data is served from its own CDN!
- scarface74 8y ago
  So how many businesses are actually important? Check out a few of Netflix's blog posts, AWS re-invent presentations (available on YouTube), the podcast interview, I posted earlier, and thier open source project. Netflix uses a lot of AWS services.
- Zombieball 8y ago
  I don’t think you have an understanding of the complexity behind Netflix. Their tech blog is a great resource that provides insight into some of their engineering challenges. I’d highly recommend. Edit: just realized I duplicated scarface74’s comment. My bad!
  - toomuchtodo 8y ago
    I’m very familiar with Netflix’s tooling and orchestration stack, and have had discussions with several of their engineers.