4 ms·

All valid concerns. I expected such a response, and hence I qualified my reasoning as a personal preference :-) > If you are starting a business, the least of

All valid concerns. I expected such a response, and hence I qualified my reasoning as a personal preference :-) > If you are starting a business, the least of your business risks is lock in to AWS. True and I agree, for the largest part. > Every cloud vendor has a hand-me-your-code-in-a-zip-file-and-I-setup-everything-for-you service. This is where I'd disagree (perhaps because of my infrastructure management background). The magical abstraction of "give me your code and don't worry about what happens underneath" IMO is not a good engineering practice. It may be for some. But, you're spending time anyway reading through documentation of some AWS service setting up your business only to walk away from it all as soon as you need to scale. I'd rather spend the same time reading the docs of the FOSS software that the AWS service in question is built on. Why? - Now you know what runs your code, and how. There is an inflection point to this idea. I'm not advocating for running your own DNS, DHCP, personal firewall etc. Just the core of what your business depends on. In my example - nginx and Postgresql. Again, if you have an idea which you want to see if it works - perhaps setting up nginx and PostgreSQL by yourself just to see feasibility is silly. But, if you are starting up a real business and expect it run seriously, it'd be a good idea understanding what runs your business. > You're talking about adding more servers (and no redundancy) to save a few pennies. I would avoid any company managed like that like the plague. I intended to bring up cost only as a tangential benefit for a startup in its 0th phase of life. I did not mean to suggest that a company should make infrastructure reliability decision based on saving a few pennies. By the time you need the complexity of dependable infrastructure redundancy, failover handling, and auto scaling, your company is big enough to hire infrastructure engineers whose job it is to do those and not have developers half-assing them under stress. My point is - for a young enough startup, avoid the need for complexity in the first place. > I actually have walked away from offers where the company was "on AWS" but all they were doing was running a bunch of EC2 instances and hosting everything themselves and expected their developers to be on call for infrastructure failures. If a company expects their developers to do infrastructure operations as "extra load", and be on call for some $AWS_SERVICE/$INFRASTRUCTURE, then I'd avoid them like plague as well. They are setting themselves up for failure by skimping on hiring SRE and infrastructure engineers. By the time you need on call service for infrastructure, you're simply not in the nginx+PostgreSQL realm that I was talking about anymore.

scarface74 8y ago
This is where I'd disagree (perhaps because of my infrastructure management background). The magical abstraction of "give me your code and don't worry about what happens underneath" IMO is not a good engineering practice. The context of the discussion is not needing “complex” infrastructure starting out. If you are trying to ramp up quickly, there is a way with a click of a few buttons you can have a scalable, fault tolerant solution with Blue/Green or rolling deployments etc. It may be for some. But, you're spending time anyway reading through documentation of some AWS service setting up your business only to walk away from it all as soon as you need to scale. Scaling your web servers with EB is just going into the console and increasing the maximum number of servers in your web farm. I'd rather spend the same time reading the docs of the FOSS software that the AWS service in question is built on. Why? - Now you know what runs your code, and how. Developers don’t develop on AWS. They still need to know how to set up their local machine to run their software during development. There is an inflection point to this idea. I'm not advocating for running your own DNS, DHCP, personal firewall etc. Just the core of what your business depends on. In my example - nginx and Postgresql. They would set up Nginx on their computer as part of their development cycle. They would need to know that anyway. Again, if you have an idea which you want to see if it works - perhaps setting up nginx and PostgreSQL by yourself just to see feasibility is silly. But, if you are starting up a real business and expect it run seriously, it'd be a good idea understanding what runs your business. Is setting up Postgres on my computer locally going to help me understand how Aurora/Postgres stores data redundantly across multiple availability zones with Multi-AZ redundancy, automatic failover, read replicas, automated backups, point in time recovery etc? By the time you need the complexity of dependable infrastructure redundancy, failover handling, and auto scaling, your company is big enough to hire infrastructure engineers whose job it is to do those and not have developers half-assing them under stress. My point is - for a young enough startup, avoid the need for complexity in the first place. Why do you assume that reliability and scalability isn’t a requirement from day one? Both small companies I’ve worked for were B2B companies that had a few large “whales” as clients. They wouldn’t have been able to keep their first client if they weren’t reliable on scalable. If a company expects their developers to do infrastructure operations as "extra load", and be on call for some $AWS_SERVICE/$INFRASTRUCTURE, then I'd avoid them like plague as well. They are setting themselves up for failure by skimping on hiring SRE and infrastructure engineers. By the time you need on call service for infrastructure, you're simply not in the nginx+PostgreSQL realm that I was talking about anymore. If an AWS infrastructure service goes down, there is really nothing an infrastructure engineer can do at that time. It’s dead simple to build out on AWS in a fault tolerant, scalable manner between autoscaling groups of EC2 instances, Aurora (MySQL/Postgres) with read replicas and multi AZ deployments, lambda, etc. But you still don’t need to hire a full time infrastructure person. You can farm that stuff out to a managed service provider cheaper. Don’t get me wrong, I personally hate Elastic Beanstalk. If I want to spin something up fast, I’ll use another service that AWS has called Codestar. It creates a code template in your chosen language, your CI/CD pipeline, an EC2 instance (or lambda pipeline for serverless) and your buildspec/appspec files (containing a bunch of shell commands) and your CloudFormation template. But to make the skeleton usable, you still have to know how everything on AWS works. But the whole point of the submission is that you shouldn’t have to know all that from day one. At the end of the day, you still have a standard Windows or Linux based VM with EB using the same stack you would use anywhere else.

scarface74 8y ago

This is where I'd disagree (perhaps because of my infrastructure management background). The magical abstraction of "give me your code and don't worry about what happens underneath" IMO is not a good engineering practice. The context of the discussion is not needing “complex” infrastructure starting out. If you are trying to ramp up quickly, there is a way with a click of a few buttons you can have a scalable, fault tolerant solution with Blue/Green or rolling deployments etc. It may be for some. But, you're spending time anyway reading through documentation of some AWS service setting up your business only to walk away from it all as soon as you need to scale. Scaling your web servers with EB is just going into the console and increasing the maximum number of servers in your web farm. I'd rather spend the same time reading the docs of the FOSS software that the AWS service in question is built on. Why? - Now you know what runs your code, and how. Developers don’t develop on AWS. They still need to know how to set up their local machine to run their software during development. There is an inflection point to this idea. I'm not advocating for running your own DNS, DHCP, personal firewall etc. Just the core of what your business depends on. In my example - nginx and Postgresql. They would set up Nginx on their computer as part of their development cycle. They would need to know that anyway. Again, if you have an idea which you want to see if it works - perhaps setting up nginx and PostgreSQL by yourself just to see feasibility is silly. But, if you are starting up a real business and expect it run seriously, it'd be a good idea understanding what runs your business. Is setting up Postgres on my computer locally going to help me understand how Aurora/Postgres stores data redundantly across multiple availability zones with Multi-AZ redundancy, automatic failover, read replicas, automated backups, point in time recovery etc? By the time you need the complexity of dependable infrastructure redundancy, failover handling, and auto scaling, your company is big enough to hire infrastructure engineers whose job it is to do those and not have developers half-assing them under stress. My point is - for a young enough startup, avoid the need for complexity in the first place. Why do you assume that reliability and scalability isn’t a requirement from day one? Both small companies I’ve worked for were B2B companies that had a few large “whales” as clients. They wouldn’t have been able to keep their first client if they weren’t reliable on scalable. If a company expects their developers to do infrastructure operations as "extra load", and be on call for some $AWS_SERVICE/$INFRASTRUCTURE, then I'd avoid them like plague as well. They are setting themselves up for failure by skimping on hiring SRE and infrastructure engineers. By the time you need on call service for infrastructure, you're simply not in the nginx+PostgreSQL realm that I was talking about anymore. If an AWS infrastructure service goes down, there is really nothing an infrastructure engineer can do at that time. It’s dead simple to build out on AWS in a fault tolerant, scalable manner between autoscaling groups of EC2 instances, Aurora (MySQL/Postgres) with read replicas and multi AZ deployments, lambda, etc. But you still don’t need to hire a full time infrastructure person. You can farm that stuff out to a managed service provider cheaper. Don’t get me wrong, I personally hate Elastic Beanstalk. If I want to spin something up fast, I’ll use another service that AWS has called Codestar. It creates a code template in your chosen language, your CI/CD pipeline, an EC2 instance (or lambda pipeline for serverless) and your buildspec/appspec files (containing a bunch of shell commands) and your CloudFormation template. But to make the skeleton usable, you still have to know how everything on AWS works. But the whole point of the submission is that you shouldn’t have to know all that from day one. At the end of the day, you still have a standard Windows or Linux based VM with EB using the same stack you would use anywhere else.