This article is written in kind of a controversial way but it seems like the throughline of the argument is something like "use heroku until you have 100k users".
This seems very reasonable to me. I thought it was going to be a pitch for on prem, which is also fine for certain scales.
I think generally the scaling steps from startup to megacorp go:
Heroku/Dokku > Public Cloud >Dedicated servers in someone else's DC > Custom Hardware in custom built data centers.
Each makes sense at each scale. I find it to be more of a right tool for the job consideration than one being better than the other.
With modern cloud tooling your infra can also look more or less logically the same once you grow past the heroku level.
I really agree with you, what's weird though is how many mega-corps are going away from Custom Hardware in Custom Built DC towards Cloud.
There's also something to be said for buying a VPS or a Colo machine, making sure it's backed up and dealing with the 9's that you get from that machine on it's own. I am routinely surprised by how far a single node machine will get you.
As a software engineer who doesn't really like devops and has been in this position multiple times, I'm a huge fan of buying à la carte services from different providers that specialize in managing a specific type of service (often since they are the developer/maintainer of said service). As long as you make sure they are all in the same datacenter, you still get great performance. And typically minimal configuration woes.
For example:
datacenter - aws: us-east-2
Dockerized Webservers/task servers:
Render or Engineyard
Postgres & Kafka:
aiven or 84codes
Redis:
Redis labs
Unified logging
Elastic or Grafana
I still end up using some underlying AWS services like S3 and lambda, but it's a lot less work than managing an entire AWS ecosystem with security groups/VPC/networking etc.
Thing is that for most/many startups 100k users is not a lot. Rejiggling your basic infra just as your growth is starting to accelerate is a non-trivial task, a risk, and something that doesn't fundamentally move the needle.
I don't think this is a good advice in general and I haven't seen many companies to do it practice. The initial decisions which a company makes most of the time are hard to change. Moving a successful business with clients from one platform to another 3 or 4 times is very difficult to do or hardly impossible.
It may work for a simple website, but for any more complicated project with web clients, mobile clients third party integrations, migrating from Heroku to cloud provider to on prem means refactoring big parts of the project.
What is even bigger problem a migration like this is hard to do incrementally.
I don't see the point of public cloud. In practice, it still requires a sysadmin (now called "DevOps engineers") so it's not any better than rented bare-metal in terms of maintenance overhead, while still being extremely expensive.
Use a managed PaaS to begin with (you pay more but it does genuinely save you time as there is no management overhead), then when you're ready to do things yourself go straight to hosted bare-metal, and only use public cloud services for their managed services that you can't replicate yourself (think Redshift/Athena/Aurora/etc).
I would recommend starting with DigitalOcean. It may have little overhead but a much more cost effective and you can stay on it for longer before migrating.
> If you're an indie hacker, a boostrapper, a startup, an agency or a consultancy, or just a small team building a product, chances are you are not going to need the cost and complexity that comes with modern cloud platforms.
Hard disagree.
- On cost: there is almost nothing better for the indie hacker, bootstrapper, or startup than cloud services.
I run apps on all three platforms (Google, AWS, and Azure) and my monthly spend is less than $2.00 < month using a mix of free tier services and consumption based services (Google Cloud Run, Google Firestore, AWS CloudFront, AWS S3, Azure Functions, Azure CosmosDB).
- On complexity: if you've used Google Cloud Run or Azure Container Apps, you know how easy it is to run workloads in the cloud. Exceedingly easy. I can go from code on my machine to running API in the cloud that can scale from 0 - 1000 instances in under 5 minutes just by slapping in a Dockerfile _with no special architecture or consideration, no knowledge of platform specific CLIs, no knowledge of Terraform/Pulumi/etc._
The current generation of container-based serverless runtimes (Google Cloud Run, Azure Container Apps) is pretty much AMAZING for indie hackers; use whatever framework you want, use middleware, use whatever language you want. As long as you can copy/paste an app runtime specific Dockerfile (e.g. Node.js, dotnet, Go, Python, etc.) in there, you can run it in the cloud, and run it virtually for free until you actually get traffic.
If any of the projects take off, then pay to scale. If they don't take off, you've spent pennies. Some months I can't even believe they charge my CC for $0.02.
The AWS free tier lets you do a lot, and if you use it well, it lets you avoid up to about $50/month of digitalocean bills.
If you're never planning on scaling past a hobby project, the free tier is a great place to stay. If your hobby project "goes viral," though, it might cost you a few thousand dollars, but hopefully that helps you get a lot more money to turn your hobby into a business.
If you have commercial intent, however, $50/month goes from an expensive hobby (3 streaming services) to a very cheap business. At that point, the fact that you don't have to pay for scale on DO VMs and other platforms actually makes a lot more sense. You can sleep at night knowing that you will still have a business even under a load spike, and $50 of digital Ocean buys you roughly the compute power of $1000+ of AWS managed services.
Yeah I can’t agree with you at all. Without setting up your own NAT Gateway on EC2 on a t2.micro instance (or something cheap like that), it runs you about $30. This isn’t even accounting for database costs, usage costs, development costs, etc.
So right away that “I can’t believe they even charge my CC for $0.02” is real suspect. Do you have a completely empty AWS account?
Agree, we bootstrapped a business from cents a month to $4 or $5 now, there's no maintenance, and I know if we get mentioned on Oprah - we'll be able to cope with a blip thousands of signups a second. I know how I'd run the system on our own hardware but can put off that decision to when (or if) we need it.
if you're spending less than 2$ per month how much traffic -> how much money can you make?
Sure, I also have plenty of static websites hosted for free by vercel / netlify / heroku / yourpick and even free functions.
As soon as you start hitting traffic, functions start to cost a lot vs your own vps.
My ideal setup right now is free static hosting from the marketing budget of friendly saas, free cloudflare on top and then APIs hosted on small vps (I have plenty of stuff on digitalocean but if I were to start from scratch I'd go fully with hetzner).
I avoid the big 3 as much as I can and I laugh for hours when I see the bills of clients using them.
> - Terraform to create the API gateway, database, lambdas, queues, Route 53 records: 1 week
- Terraform to create the IAM policies: 4 weeks
Perhaps it's because I am very familiar with the aforementioned tool and cloud but 5 weeks for writing those resources gives me the impresion of:
1. Lack of experience on AWS.
2. Lack of experience with Terraform.
3. Both.
I don't want to sound arrogant by any means but a Terraform project for something like that, documented, with its CI and applying changes via CD, would take me 4 days being generous.
I got handed a Terraform project for a GCP-based service. Simple dev, staging, prod environment. Secrets managed by secret manager, SQL Run without a public IP address for prod (but accessible via SSH for admins).
I more or less gave up after a month of beating my head on the brick wall. We hired an expert. Took him another month to get it all more or less sorted. There were still aspects that we wanted that we could not get Terraform/GCP to do.
In the end, we dropped Terraform and went back to modifying the GCP manually.
Five weeks sounds about right based on my experience coming up to speed with Terraform. It's flexible enough to solve everybody's problems so it solves nobody's problems. Not until you inundate yourself enough with it to build the intermediary layer between what it does and what you want to do.
Same, I do it routinely and maybe the first time I ever did it, it took me a week but after that it was fast. But I may be being generous.
The only thing that could make that tough is if you put the Lambdas in a VPC. That can get tricky because you have to plan out subnets and whatnot but still not a week.
The AWS documentation is also extremely good with regards to what properties are on each resource. I can't speak for Terraform since I usually use CloudFormation / SAM directly. Maybe it's a Terraform problem?
I know those tools too. It’s kind of my job to know them seeing I work at AWS in ProServe.
But if someone gave me the same use case as the author. I wouldn’t suggest any of those tools. What’s the business case for introducing the complexity of AWS for someone who is just trying to get an MVP out the door who doesn’t know cloud?
I’ve been in the industry for 25+ years and only first logged into the AWS console in mid 2018. I had a job at AWS two years later. That gives me a completely different perspective
It's a joke. Or at least I've interpreted it as such. Still true that you always spend more time terraforming the little things compared to what you expected.
Four days sounds fair if you're experienced. If you're new to TF/AWS I could easily see it taking significantly longer. If you assume IAM is the devil and refuse to learn it, it will absolutely take a while to get correct
Agreed here. There is no reason setting up IAM policies through Terraform takes four weeks. Anecdotally, on my own personal projects it took me maybe three hours, or more, to set up IAM policies for AWS Lambda, ECS and RDS.
ITT: people who spent many hours learning proprietary (often unnecessarily complex) cloud platforms trying to convince others (and themselves) that it was the best use of their limited time alive.
Stockholm syndrome à la Big Cloud.
It's okay to be interested in elaborate cloud architecture things and learn them because of that, but don't sell it as one-size-fits-all thing that every little company needs.
Most companies don't need that complexity, but of course, Big Cloud with their billions needs to convince you otherwise.
Exactly. Of course GCP/Azure/AWS have great development kits, of course they make it easy to get a Docker application running for the first time within 1 minute. That is the sales model.
However, to be cost effective, you need to adapt your application to be more cloud native using their propietary SDKs. Azure Functions/Lambdna, CosmosDB, Blob Storage/S3, etc. The application gets cheaper, but you've now also bought yourself into the ecosystem and you're never migrating anywhere else.
And now the pricing increases. Or the cloud provider decides you shouldn't be a client anymore. Too bad. No easy way back.
There is still not much wrong with a webapp on a VM. You still need sysops, except classic sysops instead of cloud certified sysops.
At small scale, you can lower your complexity using cloud. You don't need k8s for a small operation, just spin a couple of VMs and set them up via a few lines of Ansible.
OTOH you can pick a managed datsbase: you just get a connection string to a Postgres with failover and backup already taken care of. Same with queue services, email services, etc. They have really simple APIs.
You only need platform-specific knowledge when you start operating at a larger scale. By that time, you likely can afford to hire a dedicated SRE.
I don't know. Maybe I'm in a bubble, but it seems to me that knowing the basics of AWS (or some cloud provider) has become part of the standard developer's toolkit. With AWS specifically, there's so much documentation out there about getting started that I think you can have something up in a day or two on something like ECS or lambda (using something like the Serverless framework). And then when you need the more complex functionality, you are already in the AWS ecosystem.
If you are a startup trying to get a product to market, AWS is typically going to be a very small cost unless you are doing something very compute intensive (in which case something like Heroku, which the author recommends, certainly won't be cheaper anyway). The high bills only come later, if ever, after you've decided to create 20 databases and 50 apps for your 70 person startup.
This is just another way of saying “you shouldn’t use AWS if you don’t know how to use it”
Yes, there’s a steep learning curve. But once you’re passed that (or if you gained that knowledge in a prior role) AWS can easily hands down be the easiest, cheapest, and fastest infrastructure platform to use.
…if you know what you’re doing.
If you don’t know the ins and outs of AWS, then yes, you probably shouldn’t use it for your next MVP or startup idea.
Lol. This may be true but if kind of pointless as an api on localist isn’t very useful unless you’re automating your home. Of course it’s easier to hack something out on localhost than to design for actual users.
I think it makes more sense to build incrementally with the end in mind. So writing those terraform scripts will take less time if you initially write them to deploy to localhost for testing.
I've been able to get a lot done with API Gateway, Lambda, S3, RDS, SQS, Lex, and ElasticSearch. I work for a Fortune 200 company who's risk averse and views "the cloud" with suspicion. My team's ability to get so much done is starting to change that perception.
Sure, if you're in a startup and you're doing most of the infrastructure and operational work yourself then working on-premise is often advantageous. If, like me, you're working for a Fortune 200 company and it takes multiple ServiceNow tickets to get on-prem hardware, a lead time of several months to get it through procurement and subsequently racked and stacked, and working with infrastructure solution engineers throughout the process - trust me, AWS is a much better choice and will enable your team to get stuff done.
If you are working for a startup then beware, as you grow avoid the temptation to build a data center - go to the public cloud. I would argue since that's where you're going to be hosted anyway - assuming your successful growth - then you should really consider just starting out there in the first place.
I use AWS all the time and for startups I 100% agree with this. Sure, I could get a cool stack up and running in AWS much faster than this article, but the infrastructure by its self delivers ZERO value even if it’s shiny and fun to work on. We must remember this.
Start on Heroku, maybe with your own RDS. This removes so many decisions and ongoing overhead and lets you focus on building the thing that actually delivers value.
Two points (worked at AWS for 5 years and then left to start a company, which runs on AWS)
- Yes, if you don’t have AWS, Azure or GCP experience it can be hard. Harder than it should be. But this is why I try to make things simple. Run node / express in lambda. Use managed services. Use CDK so the IaC abstraction is easier. Definitely not 4 weeks for the IAM policies.
- You get tons of credits as a VC backed startup (in all providers) so cost is not that much of an initial issue
- Yes you need to pay attention on the expenses, setup budgets and budget alarms, and run cost optimizers often
The author's not wrong. Cost comes with lack of accountability in my experience. In turn, my devsecops dept (~20 people) has kept costs down by holding monthly AWS accountability meetings. "Who owns this and why does it exist?" is the leading question.
> The all-you-can-eat buffet problem
Valid point. But I've gotten far in my career by specializing in AWS. It's not going anywhere soon. It's the one cloud provider I would say you should go all-in on. Azure maybe next. GCP? Come on. Conversely, I just got an email from Heroku saying they're retiring one of my free-tier databases that I still use.
> Culture of simplicity eats strategy of complexity for breakfast
Orgs, please retire this saying. I hear this everywhere. It's lost a lot of meaning. Just spell out what your org does better than the rest of the pack.
Don't use AWS, GCP or Azure. Use Digital Ocean and the likes. Cheap VM compute, managed databases. And for the most effective setup, just get an affordable VM and chuck https://dokku.com/ onto it. Boom you have your self hosted Heroku. Cheap bandwidth, opportunity to scale.
AWS is a fools errand at the startup level unless you need some of their specialised services. Stick to "tier 2" cloud providers like Digital Ocean or Linode. If all you need is servers, database and storage, then don't waste your money on the major cloud providers. They are the wrong choice for basic compute.
In Netflix more than 10 years ago, it's more like this: a single engineer builds a deployment/management tool: 1 - 2 months. Every other engineer creates a new and fully configured cluster: minutes.
Seriously, can we please get over the fetish of using anything this DSL that YAML or whatever "specification language"? Such tools are powerful, flexible, but should not have a place for engineers who just want to provision resources. The tools violate almost every UX principles, in particular the following:
- Discoverability. Very little. One has to read tons of docs and SO posts to figure out what needs to be done. You want to pass in some environment variables? A typical answer from those who use Nomad/TFE: easy, just pass in this 200 lines of Jinja template. Really? Really? You call this ease of freaking use?
- Affordance. None.
- Constraints. If you call the errors only after you submit your 1000-line yaml scripts.
- Consistency. Maybe, but still, embedding a Jinja template to pass in variable is an insult to UX.
It's a unrepentable sin to ask me to learn your shit.
As an solopreneur running a SaaS and various apps/addons on other SaaSes on AWS for 7 years now, I'm inclined to agree.
In fact, I've already migrated a fair chunk of my workload off AWS Lambda onto constantly running fly.io VMs.
It's significantly cheaper than serverless (when you're past the free tier), the servers just restart if they crash (as opposed to running up a six figure AWS bill), and it's less complicated operationally (it's just a VM, less need to pipe messages with SQS, figure out IAM, etc)
I work for AWS and I get paid decent money to work with companies and help them become “cloud native”. My specialty is “application modernization” and I avoid “lift and shift” projects like the plague. Even though I realize that doing lift and shifts first is the right answer sometimes. I think I can confidently state that I know AWS pretty well.
That being said, in my personal life if someone ever came to me and said that they were starting a project from scratch or even if I were starting a hobby project from scratch where I saw Lambda + DynamoDB wasn’t the right answer, I would just use Lightsail and simple monolithic application using whatever frameworks are appropriate that I already knew.
AWS Lightsail is a simple fixed priced VPS. I’m not advocating using Lightsail over another VPS provider. It would just be my preference because I know how to transition to full fledged AWS later.
>Let's face it, choosing AWS is the cloud computing version of "nobody ever got fired for buying IBM". There is perceived safety in choosing a popular offering — it's what everybody else does.
This is the only line that actually matters. Are there better and cheaper options for your organization? Almost certainly, but no one ever got fired for picking AWS.
Article doesn’t really present an argument. Pretty much starts with ‘you don’t want the cost and complexity’ and then goes on from that point as a given.
A more useful article would actually walk through the cost/complexity trade
One thing I have been wrong about for about 2 years is predicting companies would pull back from using the cloud. What I see in corporate AWS accounts is a lot of waste. I thought once companies started tightening spending they would look at their cloud spending and shut a bunch of it down. When an EC2 instance only costs $30 a month to leave running, it's easy to forget about it. You get enough of those across a corporate enterprise and you are talking about serious money.
[+] [-] f0e4c2f7|3 years ago|reply
This seems very reasonable to me. I thought it was going to be a pitch for on prem, which is also fine for certain scales.
I think generally the scaling steps from startup to megacorp go:
Heroku/Dokku > Public Cloud >Dedicated servers in someone else's DC > Custom Hardware in custom built data centers.
Each makes sense at each scale. I find it to be more of a right tool for the job consideration than one being better than the other.
With modern cloud tooling your infra can also look more or less logically the same once you grow past the heroku level.
[+] [-] sakisv|3 years ago|reply
I think stackoverflow and its siblings proved that having a handful of servers can go a very long way, even making cloud ops redundant.
Of course this is function of what you're optimizing for, and whether you want to go down the "boring monolithic app" route.
[+] [-] dijit|3 years ago|reply
There's also something to be said for buying a VPS or a Colo machine, making sure it's backed up and dealing with the 9's that you get from that machine on it's own. I am routinely surprised by how far a single node machine will get you.
[+] [-] buffalobuffalo|3 years ago|reply
For example:
datacenter - aws: us-east-2
Dockerized Webservers/task servers: Render or Engineyard
Postgres & Kafka: aiven or 84codes
Redis: Redis labs
Unified logging Elastic or Grafana
I still end up using some underlying AWS services like S3 and lambda, but it's a lot less work than managing an entire AWS ecosystem with security groups/VPC/networking etc.
[+] [-] buzzdenver|3 years ago|reply
Thing is that for most/many startups 100k users is not a lot. Rejiggling your basic infra just as your growth is starting to accelerate is a non-trivial task, a risk, and something that doesn't fundamentally move the needle.
[+] [-] cultofmetatron|3 years ago|reply
nowadays, i'd say use fly.io or render till you have 200k users.
[+] [-] avrionov|3 years ago|reply
It may work for a simple website, but for any more complicated project with web clients, mobile clients third party integrations, migrating from Heroku to cloud provider to on prem means refactoring big parts of the project.
What is even bigger problem a migration like this is hard to do incrementally.
[+] [-] Nextgrid|3 years ago|reply
Use a managed PaaS to begin with (you pay more but it does genuinely save you time as there is no management overhead), then when you're ready to do things yourself go straight to hosted bare-metal, and only use public cloud services for their managed services that you can't replicate yourself (think Redshift/Athena/Aurora/etc).
[+] [-] blackoil|3 years ago|reply
[+] [-] osigurdson|3 years ago|reply
[+] [-] CharlieDigital|3 years ago|reply
Hard disagree.
- On cost: there is almost nothing better for the indie hacker, bootstrapper, or startup than cloud services.
I run apps on all three platforms (Google, AWS, and Azure) and my monthly spend is less than $2.00 < month using a mix of free tier services and consumption based services (Google Cloud Run, Google Firestore, AWS CloudFront, AWS S3, Azure Functions, Azure CosmosDB).
- On complexity: if you've used Google Cloud Run or Azure Container Apps, you know how easy it is to run workloads in the cloud. Exceedingly easy. I can go from code on my machine to running API in the cloud that can scale from 0 - 1000 instances in under 5 minutes just by slapping in a Dockerfile _with no special architecture or consideration, no knowledge of platform specific CLIs, no knowledge of Terraform/Pulumi/etc._
The current generation of container-based serverless runtimes (Google Cloud Run, Azure Container Apps) is pretty much AMAZING for indie hackers; use whatever framework you want, use middleware, use whatever language you want. As long as you can copy/paste an app runtime specific Dockerfile (e.g. Node.js, dotnet, Go, Python, etc.) in there, you can run it in the cloud, and run it virtually for free until you actually get traffic.
If any of the projects take off, then pay to scale. If they don't take off, you've spent pennies. Some months I can't even believe they charge my CC for $0.02.
[+] [-] pclmulqdq|3 years ago|reply
If you're never planning on scaling past a hobby project, the free tier is a great place to stay. If your hobby project "goes viral," though, it might cost you a few thousand dollars, but hopefully that helps you get a lot more money to turn your hobby into a business.
If you have commercial intent, however, $50/month goes from an expensive hobby (3 streaming services) to a very cheap business. At that point, the fact that you don't have to pay for scale on DO VMs and other platforms actually makes a lot more sense. You can sleep at night knowing that you will still have a business even under a load spike, and $50 of digital Ocean buys you roughly the compute power of $1000+ of AWS managed services.
[+] [-] dimgl|3 years ago|reply
So right away that “I can’t believe they even charge my CC for $0.02” is real suspect. Do you have a completely empty AWS account?
We haven’t even spoken about dev experience yet.
[+] [-] helsinkiandrew|3 years ago|reply
[+] [-] yrgulation|3 years ago|reply
heroku, a vps or a dedicated server are all in the cloud, not sure what you mean by this.
[+] [-] jokethrowaway|3 years ago|reply
Sure, I also have plenty of static websites hosted for free by vercel / netlify / heroku / yourpick and even free functions.
As soon as you start hitting traffic, functions start to cost a lot vs your own vps.
My ideal setup right now is free static hosting from the marketing budget of friendly saas, free cloudflare on top and then APIs hosted on small vps (I have plenty of stuff on digitalocean but if I were to start from scratch I'd go fully with hetzner).
I avoid the big 3 as much as I can and I laugh for hours when I see the bills of clients using them.
[+] [-] perryizgr8|3 years ago|reply
[+] [-] Octabrain|3 years ago|reply
- Terraform to create the IAM policies: 4 weeks
Perhaps it's because I am very familiar with the aforementioned tool and cloud but 5 weeks for writing those resources gives me the impresion of:
1. Lack of experience on AWS.
2. Lack of experience with Terraform.
3. Both.
I don't want to sound arrogant by any means but a Terraform project for something like that, documented, with its CI and applying changes via CD, would take me 4 days being generous.
[+] [-] marcus_holmes|3 years ago|reply
I more or less gave up after a month of beating my head on the brick wall. We hired an expert. Took him another month to get it all more or less sorted. There were still aspects that we wanted that we could not get Terraform/GCP to do.
In the end, we dropped Terraform and went back to modifying the GCP manually.
[+] [-] shadowgovt|3 years ago|reply
[+] [-] throwaway2016a|3 years ago|reply
The only thing that could make that tough is if you put the Lambdas in a VPC. That can get tricky because you have to plan out subnets and whatnot but still not a week.
The AWS documentation is also extremely good with regards to what properties are on each resource. I can't speak for Terraform since I usually use CloudFormation / SAM directly. Maybe it's a Terraform problem?
[+] [-] scarface74|3 years ago|reply
But if someone gave me the same use case as the author. I wouldn’t suggest any of those tools. What’s the business case for introducing the complexity of AWS for someone who is just trying to get an MVP out the door who doesn’t know cloud?
I’ve been in the industry for 25+ years and only first logged into the AWS console in mid 2018. I had a job at AWS two years later. That gives me a completely different perspective
[+] [-] lorenzotenti|3 years ago|reply
[+] [-] ianbutler|3 years ago|reply
[+] [-] icedchai|3 years ago|reply
[+] [-] nijave|3 years ago|reply
[+] [-] holografix|3 years ago|reply
TF is not Infra as Code it’s infra as configuration files and it’s a mess.
I haven’t used Pulumi but that’s kind of what I really want. Give me Python and better abstractions to gcloud cli.
[+] [-] dimgl|3 years ago|reply
[+] [-] acedTrex|3 years ago|reply
[+] [-] 727564797069706|3 years ago|reply
Stockholm syndrome à la Big Cloud.
It's okay to be interested in elaborate cloud architecture things and learn them because of that, but don't sell it as one-size-fits-all thing that every little company needs.
Most companies don't need that complexity, but of course, Big Cloud with their billions needs to convince you otherwise.
[+] [-] sebazzz|3 years ago|reply
However, to be cost effective, you need to adapt your application to be more cloud native using their propietary SDKs. Azure Functions/Lambdna, CosmosDB, Blob Storage/S3, etc. The application gets cheaper, but you've now also bought yourself into the ecosystem and you're never migrating anywhere else.
And now the pricing increases. Or the cloud provider decides you shouldn't be a client anymore. Too bad. No easy way back.
There is still not much wrong with a webapp on a VM. You still need sysops, except classic sysops instead of cloud certified sysops.
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] nine_k|3 years ago|reply
OTOH you can pick a managed datsbase: you just get a connection string to a Postgres with failover and backup already taken care of. Same with queue services, email services, etc. They have really simple APIs.
You only need platform-specific knowledge when you start operating at a larger scale. By that time, you likely can afford to hire a dedicated SRE.
[+] [-] chadash|3 years ago|reply
If you are a startup trying to get a product to market, AWS is typically going to be a very small cost unless you are doing something very compute intensive (in which case something like Heroku, which the author recommends, certainly won't be cheaper anyway). The high bills only come later, if ever, after you've decided to create 20 databases and 50 apps for your 70 person startup.
[+] [-] Aeolun|3 years ago|reply
[+] [-] cj|3 years ago|reply
Yes, there’s a steep learning curve. But once you’re passed that (or if you gained that knowledge in a prior role) AWS can easily hands down be the easiest, cheapest, and fastest infrastructure platform to use.
…if you know what you’re doing.
If you don’t know the ins and outs of AWS, then yes, you probably shouldn’t use it for your next MVP or startup idea.
[+] [-] prepend|3 years ago|reply
Lol. This may be true but if kind of pointless as an api on localist isn’t very useful unless you’re automating your home. Of course it’s easier to hack something out on localhost than to design for actual users.
I think it makes more sense to build incrementally with the end in mind. So writing those terraform scripts will take less time if you initially write them to deploy to localhost for testing.
[+] [-] taylodl|3 years ago|reply
Sure, if you're in a startup and you're doing most of the infrastructure and operational work yourself then working on-premise is often advantageous. If, like me, you're working for a Fortune 200 company and it takes multiple ServiceNow tickets to get on-prem hardware, a lead time of several months to get it through procurement and subsequently racked and stacked, and working with infrastructure solution engineers throughout the process - trust me, AWS is a much better choice and will enable your team to get stuff done.
If you are working for a startup then beware, as you grow avoid the temptation to build a data center - go to the public cloud. I would argue since that's where you're going to be hosted anyway - assuming your successful growth - then you should really consider just starting out there in the first place.
[+] [-] xcskier56|3 years ago|reply
Start on Heroku, maybe with your own RDS. This removes so many decisions and ongoing overhead and lets you focus on building the thing that actually delivers value.
[+] [-] eranation|3 years ago|reply
- Yes, if you don’t have AWS, Azure or GCP experience it can be hard. Harder than it should be. But this is why I try to make things simple. Run node / express in lambda. Use managed services. Use CDK so the IaC abstraction is easier. Definitely not 4 weeks for the IAM policies.
- You get tons of credits as a VC backed startup (in all providers) so cost is not that much of an initial issue
- Yes you need to pay attention on the expenses, setup budgets and budget alarms, and run cost optimizers often
[+] [-] ABraidotti|3 years ago|reply
The author's not wrong. Cost comes with lack of accountability in my experience. In turn, my devsecops dept (~20 people) has kept costs down by holding monthly AWS accountability meetings. "Who owns this and why does it exist?" is the leading question.
> The all-you-can-eat buffet problem
Valid point. But I've gotten far in my career by specializing in AWS. It's not going anywhere soon. It's the one cloud provider I would say you should go all-in on. Azure maybe next. GCP? Come on. Conversely, I just got an email from Heroku saying they're retiring one of my free-tier databases that I still use.
> Culture of simplicity eats strategy of complexity for breakfast
Orgs, please retire this saying. I hear this everywhere. It's lost a lot of meaning. Just spell out what your org does better than the rest of the pack.
[+] [-] monlockandkey|3 years ago|reply
AWS is a fools errand at the startup level unless you need some of their specialised services. Stick to "tier 2" cloud providers like Digital Ocean or Linode. If all you need is servers, database and storage, then don't waste your money on the major cloud providers. They are the wrong choice for basic compute.
[+] [-] g9yuayon|3 years ago|reply
In Netflix more than 10 years ago, it's more like this: a single engineer builds a deployment/management tool: 1 - 2 months. Every other engineer creates a new and fully configured cluster: minutes.
Seriously, can we please get over the fetish of using anything this DSL that YAML or whatever "specification language"? Such tools are powerful, flexible, but should not have a place for engineers who just want to provision resources. The tools violate almost every UX principles, in particular the following:
- Discoverability. Very little. One has to read tons of docs and SO posts to figure out what needs to be done. You want to pass in some environment variables? A typical answer from those who use Nomad/TFE: easy, just pass in this 200 lines of Jinja template. Really? Really? You call this ease of freaking use?
- Affordance. None.
- Constraints. If you call the errors only after you submit your 1000-line yaml scripts.
- Consistency. Maybe, but still, embedding a Jinja template to pass in variable is an insult to UX.
It's a unrepentable sin to ask me to learn your shit.
[+] [-] rozenmd|3 years ago|reply
In fact, I've already migrated a fair chunk of my workload off AWS Lambda onto constantly running fly.io VMs.
It's significantly cheaper than serverless (when you're past the free tier), the servers just restart if they crash (as opposed to running up a six figure AWS bill), and it's less complicated operationally (it's just a VM, less need to pipe messages with SQS, figure out IAM, etc)
[+] [-] scarface74|3 years ago|reply
That being said, in my personal life if someone ever came to me and said that they were starting a project from scratch or even if I were starting a hobby project from scratch where I saw Lambda + DynamoDB wasn’t the right answer, I would just use Lightsail and simple monolithic application using whatever frameworks are appropriate that I already knew.
AWS Lightsail is a simple fixed priced VPS. I’m not advocating using Lightsail over another VPS provider. It would just be my preference because I know how to transition to full fledged AWS later.
[+] [-] Entinel|3 years ago|reply
This is the only line that actually matters. Are there better and cheaper options for your organization? Almost certainly, but no one ever got fired for picking AWS.
[+] [-] apalmer|3 years ago|reply
A more useful article would actually walk through the cost/complexity trade
[+] [-] fredsted|3 years ago|reply
[+] [-] sputknick|3 years ago|reply
[+] [-] atemerev|3 years ago|reply
If that's starting to be not enough, then consider yourself lucky, and start scaling.
"Premature scaling is a root of all evil" (and a good source of profit for Amazon, but I am repeating myself).