15 ms·

Cloud services like AWS or Google Cloud Platform may be the wrong choice

196 points by karls 4y ago

apalmer 4y ago
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
somecommit 4y ago
Whateversimple cloud service you use, it's likely using AWS underneath anyway. Like Netlify for example, I think it's all based on AWS.
- solardev 4y ago
  I really like Vercel's approach of mixing cloud providers behind the scenes. They deliver features (like edge functions) using one cloud, basic hosting using another one, etc. It's all invisible to you as the customer and painlessly abstracted.
bpodgursky 4y ago
If you either use or don't use AWS based on a HN blog post, you deserve whatever happens to you.
- dotxlem 4y ago
  This is the correct answer
stytchwhy 4y ago
this "thought leadership" in our industry is a disease
- prepend 4y ago
  There’s been an seo template since slashdot ages of find a prevailing wisdom, write a naive clickbaity post, profit. Sometimes I think authors are earnestly wrong, sometimes I think they are just fake. Sadly, it’s still profitable. I thought that one day I’d interview someone who wrote a post like that and figure out for real. But I’ve been waiting decades so it probably won’t happen. “Everything you know is wrong.” Yadda yadda yadda
  - sseagull 4y ago
    It's probably been a lot, lot longer than that. This is an evolution of "think again!" articles from long ago. I wouldn't be surprised if in some cave somewhere there's a message on the wall like "Think Oogie is best stone tool maker? Think again!"
- halfmatthalfcat 4y ago
  The pretentiousness is suffocating sometimes, especially from those who don't actually build things but pontificate like they do.
irate2942 4y ago
Strange, tried to access this page with my clients vpn on, but got FortiGuard blocked because site is classified as 'phishing'.
- karls 4y ago
  That's strange indeed. It's hosted by ghost.org and uses Fathom Analytics, that's about it. Unsure why it would be reported as phishing.
cj 4y ago
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.
- TheNewsIsHere 4y ago
  Different strokes for different folks. (Or at least, use cases.) We’ve found at work that if you already have the talent, the hyper scale cloud platforms are amongst the most expensive ways to manage infrastructure if you go all in. For example $0.40/secret/mo is _expensive_ compared to the cost of an HA vault (not necessarily Hashicorp) setup. If you have 1,000 secrets but you only need to access any given secret once a day, that’s a lot of expense against just setting up your own. And then you can take it with you. Beyond that, we’ve had a LOT more reliable performance from our current VPS provider than we ever got from EC2. That’s not to say AWS is exactly without competition. We use S3 extensively because nothing compares for our usage.
  - benmmurphy 4y ago
    If you don’t need secret manager features like region replication and rotation you can use system manager parameters and the secret type. It’s effectively free. We use secret manager but weren’t aware of the price difference.
  - scarface74 4y ago
    You probably don’t need secrets manager. Just use SSM Parameter Store secret string type. It’s free.
fredsted 4y ago
I don't understand. Then I won't be able to put Kubernetes, Microservices and AWS on my CV.
prepend 4y ago
> API that works on localhost: 4 days 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.
- throwaway2016a 4y ago
  API gateway is simply how you expose Lambdas to an HTTP interface in AWS. It was the easiest way until they recently unveiled a way to expose the Lambda directly. You can also use ALBs (Application Load Balancers) and CloudFront to expose Lambdas to HTTP. Either way, Lambdas are hard to debug locally, often I just deploy them to test (since deploying is easy). Or I write my code such that it bootstraps differently when launched locally vs Lambda. Either way, unless it is a very complex app that has lots of external dependencies, 4 days is a bit much.
  - Aeolun 4y ago
    But don’t try to create a REST API Gateway with more than 200 resources, or CloudFormation will randomly start failing. Or try to add more than 100 rules to your ALB, because it’ll be impossible. My biggest issue with AWS is that the limits are so arbitrary, and seem to solely exist due to terrible design decisions. If my local express server, or nginx can deal with 100 endpoints, how is it possible for this multi billion dollar infinitely scalable service to not do the same…
    - throwaway2016a 4y ago
      Interesting, I haven't had the experience with CloudFormation. At that scale, however, I tend to group my Lambdas as microservices not per endpoint. It helps with cold start time as well. So for example, if I have a page" resource, I don't make that 5+ endpoints, I make it a wildcard / prefix match and do the routing inside of the service lambda. Maybe you legitimately have 100+ different microservices, in which case, I don't doubt that is a problem, I just haven't experienced it.
chadash 4y ago
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.
- Aeolun 4y ago
  The problem with even lambda or ECS though is that it’s all much more complex than a simple rsync to your desired server.
  - sofixa 4y ago
    With Fargate or Google Cloud Run, it really isn't. Assuming zero knowledge it's probably easier to learn how to build a docker container and call a binary to send it to the service than it is to setup ssh and rsync and a server to host your website.
    - Aeolun 4y ago
      I don’t think you can build a docker container without already understanding concepts that you need to run rsync. So it seems like an extra step?
  - coredog64 4y ago
    https://aws.github.io/copilot-cli/ https://aws.github.io/copilot-cli/ That takes a Dockerfile, manages networking, secrets and CI/CD deployment. I have a few quibbles with what it does, but it generally works and is being maintained/updated.
willsmith72 4y ago
I actually totally disagree. With the various development frameworks/CLIs, AWS has the ecosystem benefits that can make hosting on it a breeze, and leave more time to focus on delivering value to the customer.
cuuupid 4y ago
C’mon guys, this week it was my turn to post the AWS bad article
shrubble 4y ago
Small companies and startups can get pretty far with 1 dedicated server and good backups...
Octabrain 4y ago
> - 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.
- ianbutler 4y ago
  You have to concede that that's most of the industry right? The state of implementing IaC is new and foreign for the majority of teams.
- shadowgovt 4y ago
  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.
- throwaway2016a 4y ago
  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?
  - acdha 4y ago
    > 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. Yeah, it’s about 20 minutes if you use the VPC and Lambda modules from https://github.com/terraform-aws-modules https://github.com/terraform-aws-modules. I could see a week if you had to learn all of this first with little prior experience but that’s true of everything. A newbie running a Linux colo server isn’t going to get all of the security & reliability issues right in less time, either.
valenterry 4y ago
So what, the suggestion is to go with Heroku instead? I think fargate + docker is super easy to setup, run and maintain. Maybe Heroku makes it a little bit easier, but that's about it. Once you leave the Heroku ecosystem you'll have lost all the time you saved. I'm not convinced.
- arcbyte 4y ago
  I spent a few evenings going the ECS route and the complexity and cost of just a single api available to the internet and a database kept ballooning to way more than what I wanted to pay for and deal with. Fargate, image repo, NAT gateway, I don't even remember all the nonsense at this point but it was ridiculous. I took a look at a few alternatives and DigitalOcean's App service was night and day easier, faster, and cheaper to deal with.
  - valenterry 4y ago
    Interesting, have never tried out DigitalOcean. Maybe I should.
raydiatian 4y ago
Gross, this article mentioned terraform. Never use terraform, it is a silly thing.
f0e4c2f7 4y ago
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.
- dijit 4y ago
  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.
  - mwcampbell 4y ago
    > how far a single node machine will get you. This. I took the wrong lesson from the DDoS attacks on Linode in late 2015 (particularly the one on Christmas Day), and the intermittent issues I encountered with DigitalOcean and Vultr in 2016 while both providers were still fairly young. A single dedicated server from a mature provider (ideally not during its hyper-growth phase) is pretty reliable.
  - sofixa 4y ago
    > what's weird though is how many mega-corps are going away from Custom Hardware in Custom Built DC towards Cloud It costs a lot of money to run your own datacenters, and very very few companies are capable of doing it as good as AWS or even Scaleway/OVH can. By that I mean, waiting weeks/months to get through tickets, approvals, multiple different teams just to get a server deployed. Then waiting a few more weeks for monitoring/backups. Allowing developers and related to have hardware/software at a whim is a massive advantage.
ABraidotti 4y ago
> It costs how much?! 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.
- auggierose 4y ago
  > GCP? Come on. What's wrong with GCP?
  - shmoogy 4y ago
    Trust issues
  - smolder 4y ago
    The G. Products from Google are often transient, support is often non-existent. It doesn't create confidence for people who might be investing big into proprietary cloud features.
  - Gigachad 4y ago
    Lots of people have had their servers randomly deleted one day because a google script thought they were a bot. And then of course, there is no one to call at google to have it resolved.
deleted 4y ago
[deleted]
scarface74 4y ago
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.
- pkos98 4y ago
  Hey, coincidentally I am about to start a role in "Application Modernization" as Cloud Solution Architect at MSFT (though I only have experience with AWS). Do you mind if I ask u some further questions via the email in your profile?
  - scarface74 4y ago
    I’m not even sure if I have access to that email. My username is the same on Reddit as it is here. DM me there. I come from a .Net background , so feel free to reach out.
- nicoburns 4y ago
  What advantage do you see companies getting from using AWS's proprietary products over standard open source equivalents?8
  - scarface74 4y ago
    I’m not the sales guy. I’m not here to do sales talking points. I’m going to speak from an on the ground hands on keyboard implementation person. AWS offers plenty of hosted versions of open source solutions and API compatible services like DocumentDB with Mongo compatibility. If I’m working with a customer that prefers the open source solution and there is an equivalent on AWS, I’m going to suggest that. My goal is never to introduce too much new technology to an organization unless there is a compelling need. I’ve recommended everything from a straight lift and shift, to hybrid, to full on all in on AWS depending on the use case. I’m not dogmatic and I’ve never been told “get the customer all in on our services so we can lock them in”. I’ve implemented pure AWS CI/CD solutions, integrated with Azure DevOps, done lift and shifts with Jenkins, etc. I’m judged completely by outcomes and whether the customer is satisfied. But I’ve been railing against worrying about “lock-in” wat before coming to AWS. I’ve been part of numerous large scale migrations and implementations. If you’re at any scale, you’re always both technically and organizationally “locked in” to your infrastructure choices and migrating involves, dealing with CxOs, PMO, retraining, security, regressions, etc. It’s usually much easier to just have a conversation with your account manager.
daniel-cussen 4y ago
sputknick 4y ago
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.
- dalyons 4y ago
  Why would they pull back from the cloud, instead of just implementing some basic infra ownership and cost auditing processes?
  - sputknick 4y ago
    Good point, I explained that poorly (sorry, was half paying attention to a conference call). I meant "pull back" as in reduce their number of instances, which would reduce their monthly spend.
CharlieDigital 4y ago
> 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.
- pclmulqdq 4y ago
  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.
Entinel 4y ago
>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.
- Aeolun 4y ago
  > no one ever got fired for picking AWS It’s also nowhere near as bad as Concur/Oracle/IBM. Though that’s a fairly low bar.
atemerev 4y ago
To start working, you need a VPS instance, a Postgres, and a backup scheme. 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).
eranation 4y ago
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
philliphaydon 4y ago
This might be true if you’ve never used AWS before. But if you know AWS it doesn’t take anywhere near that long. I’m building a PBBG and have it on AWS. Built the site in .NET with SignalR, MartenDB/PostgreSQL. Needed to host it. 2 evenings to write a cloudformation script which builds a VPC. Public and private subnets. RDS. A tiny instance to act as a nat gateway (for servers in private subnet). A small server with HAProxy for load balancer. A tiny server for redis. 2 web servers. Plus some sh scripts to build the project. Zip. Ssh jump to the server and deploy. Total cost is like $42/m. Used a tiny instance for nat gateway cos aws nat gateway costs $32+ingress. Used tiny instance for redis as it’s only used for signalr connections across servers and services. Tiny instance for HAProxy cos aws application load balancer is $15/m. I could consolidate 3 of the servers into 1 but I choose not to. You can build flexible things on AWS. The problem with AWS is it’s very easy to just spin up random stuff and not care about cost and blow out a budget quickly.
- jarym 4y ago
  > Used a tiny instance for nat gateway cos aws nat gateway costs $32+ingress AWS NAT gateway is certainly pricey. And doesn't even support NAT traversal which means P2P/STUN stuff is out (this is in contrast to GCP which does support it). C'mon AWS you can do better!
TekMol 4y ago
AWS is many things. Their CloudFront service is pretty awesome. You just put it between your server and your users and BOOM all your static content gets delivered lightning fast via Amazons world wide CDN. And it costs like $10 per month millions of requests.
Cloudef 4y ago
AWS is very good and cheap once you know how to use it and what parts. The alternatives most likely run on top of AWS anyhow. I use terranix https://terranix.org/ https://terranix.org/ instead of straight terraform. I can compile, package, deploy everything just with nix.
xcskier56 4y ago
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.
revolutukr 4y ago
These shock jock articles are boring. Step 1: Write an incendiary title Step 2: Make definitive statements meant to be applied broadly but actually targeted at a specific situation that the author is experiencing, or comes from the author's own problems with something. Step 3: Make sure to cast doubt and insecurity, making somebody else feel like they made the wrong choice, even when everything is working perfectly Step 4: Street cred improved!
marcus_holmes 4y ago
Couple with "you should not be using Kubernetes, probably" and "you should be writing a monolith, probably".
clncy 4y ago
> And often it is so alluring that actual requirements and costs fly out the window. Need to scale... infintely? Just use Lambda Functions. I don’t know why the author singles out Lambda. For many use cases their ongoing maintenance is close to zero.
tpict 4y ago
I can see how this makes sense for a startup etc that has passed some threshold of operational complexity. As an “indie hacker” there is no way I’d be able to move out of the cloud without my costs going up by an order of magnitude.
ctvo 4y ago
- Time it took to learn the skills to write a scalable service that can handle 100K events per second: 3 years - Time it took to write that API on localhost: 4 days - Time it took to learn Terraform and some AWS services, to create the API gateway, database, lambdas, queues, Route 53 records: 1 week - Time it took to learn AWS IAM policies to create the IAM policies in Terraform: 4 weeks Author conveniently left out a few bits of information. Once you learn IAM and Terraform, I'm doubtful it takes you another 4 weeks to setup the policies for a new project.
- JackFr 4y ago
  In my experience Terraform was a horrible pain point, and yet I'd happily suffer it again. We can spin up and spin down transient UAT environments which are pristine and match PROD exactly in a matter of seconds and we can robustly test infrastructure changes. The improvement in developer productivity that entailed was worth the cost.
727564797069706 4y ago
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.
- deleted 4y ago
  [deleted]
- nine_k 4y ago
  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.
  - Nextgrid 4y ago
    > 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. You can replace "couple VMs" with a dedicated Hetzner/OVH/Kimsufi server, it'll be the same except you won't get ripped off on egress bandwidth and performance.
    - nine_k 4y ago
      I agree that AWS egress bandwidth is a rip-off, but cloud != AWS only. Many cloud providers, from DO to Vultr, offer sane egress prices. The cheapest dedicated server at Hetzner (an excellent provier indeed) is €44.39 / mo, while their cheapest VM option is €4.51 / mo, literally an order of magnitude less. If you don't need the power of a dedicated server for your small project (and even 10 small projects), you don't need to buy it. You can't have a free dedicated server, but many small projects can run either entirely within free tiers of some cloud providers, or for pennies a month based on usage. OTOH you of course can run such small projects from your desktop at home, or maybe even from your NAS or router if they are beefy enough, entirely under your control, and for free! The key value prop of the cloud for me is elasticity. Say, our project spins up more nodes in anticipation of daily waves of traffic, and then spins them down to save cost when the load goes way down. This won't work so well with long-term dedicated servers.
syrusakbary 4y ago
This article has so many gems... > Using the shiniest new technologies is rarely the cause for success, it's usually the result > Culture of simplicity eats strategy of complexity for breakfast
osigurdson 4y ago
I think AWS is shooting themselves in the foot with their ridiculous EKS offering. The fact that it is necessary to first download a 3rd party tool (eksctl) to get anything working is insane. Then, getting basic things working like connecting a load balancer involves importing all kinds of random policies and configuration (which does who knows what) from random github repositories is perhaps even more ridiculous. The same thing in GCP takes nearly zero effort. I can understand why AWS would try to steer people away from Kubernetes since it has a commoditizing effect. However, it could end up steering people away from AWS entirely.
cliftonk 4y ago
I generally agree that no one that isnt a professional devops person (or has spent months tuning IAM and route53 policies) should be using AWS. That said, GCP is so much easier to use and easily usable by a novice because it has a lot of good defaults. Compute and egress costs can be prohibitive at scale, but features like storage + bigquery (OLAP SQL db where u only pay for queries) are basically free for low-to-moderate volume workloads.
solatic 4y ago
> It costs how much?! Less than $5/month. Yes, on AWS. Serverless (the genuine kind, which scales to zero with pay-per-request) is pretty much free until you have actual users, and once you have actual users, you have actual revenue to pay your cloud bills. Unless your ($revenue / $hosting_costs) is less than 1.0, in which case, you don't have a business. > "(LISP) programmers know the value of everything and the cost of nothing". A specific technology product never exists in a vaccuum — it has to communicate and co-exist with other components in the system. There are costs associated with every choice, often hidden costs. An odd choice of quote, considering the author is promoting choices that costs orders of magnitude more money in the earliest stages, and inevitably provoke high migration costs when it comes time to move off those platforms. > Cultivate a culture of ruthlessly fighting complexity Again, an odd claim. Stacks like AWS Lambda and DynamoDB let me forget about scaling concerns* (asterisk because this is true in the early stages, slightly less true later, but still mostly true compared to traditional architecture). Those concerns absolutely rear their head when handing off to a site like Render that refuses to publish public pricing for their largest database instances, or talk about very common usecases like read replicas for analytics workloads. > the harsh truth is that neither Lambda Functions, nor Kubernetes, nor Kafka on their own will magically make your app work correctly, be performant and deliver value. But Redis, PostgreSQL, and PaaS-style service deployment magically will? You mean, early startup CTOs need to actually think about the architecture they propose to build to satisfy business needs? gasp > "Why do we think this choice will provide the most value for users compared to the alternatives?" Because serverless means not needing to hire DevOps. Because most companies running Kubernetes do not get anywhere near the ~38+% efficiency (last time I ran the numbers, and that's for production environments, not even including staging/testing/development environments) they need to make Kubernetes more cost-efficient than AWS Lambda, because developers just don't have time to figure out why the hell their services need a guaranteed vCPU, won't perform with less, and in the meantime their services are using less than 20% of the resources they requested - and they particularly don't have time to figure it out when Customer Support is happy, Product is happy, and Finance will cough up whatever budget is needed so long as Engineering says that it's "necessary". Because founders who actually think about optimizing for value, will optimize for what is scarce, and what is actually scarce is not money (plenty of money out there looking for the right investment opportunities that check all the right boxes), it is people. Serverless means hiring fewer people because you hand off undifferentiated heavy lifting.
Kon-Peki 4y ago
These kind of blog posts treat this as a technical problem instead of a business problem. Until you get some unicorn that says "we are profitable at price $X and all of our competitors are losing money at $X + $Y, and it's because of our software architecture and infrastructure choices", nobody is going to be convinced.
vcryan 4y ago
I disagree. As a small company, having all the various AWS services available is a major competitive advantage.
jabart 4y ago
If you are a starting out, you don't have to use terraform, use the console. Nothing stops you from using the managed services in a heroku box either. Need a queue for your API Heroku->SQS. Need storage, Heroku->S3. The industry always talks about best practices but rarely mentions maturity models which this article gets close to brining up but stops short.
Thristle 4y ago
> Unless you hire a good (read: expensive) devops person to look after your infrastructure, clickops-ing your way through the AWS console will likely leave behind a pile of unused instances and components that will eat into your budget. While this is true-ish (finding lost resources or just not creating them in the first place is not that complex), when the day comes that you will need/want to move to one of the cloud providers you will need a good devops to handle that hybrid cloud environment and making the transfer as painless as possible. cross cloud routing, DB migrations and not to mention setting up secure access for all of it is less complex in my POV then cost managing your cloud account
gbro3n 4y ago
There is a middle way, just set your boundaries on which AWS services you want to use. 1 x EC2 server + 1 x application load balancer and a few S3 buckets works well for my hobby projects (ALB is just for multiple domain SSL and reverse proxy). You can run docker on the EC2 and deploy containers. Yes there is a small amount of setting things up in the AWS UI and some bash scripting for deployment, but then you'd have to configure your DNS and firewall somewhere with a VPS anyway.
fareesh 4y ago
I am currently in the middle of setting up AWS and that decision graph made me chuckle because it resonates quite deeply. I need to do GPU inference but I don't want to run the machine 24x7. I may use it for about 4 hours per day at best. Lambda doesn't offer GPUs and neither does ECS+Fargate. It seems like I could setup an endpoint using Sagemaker and then destroy it when no longer needed, and automate all of this but it feels quite messy. The other route is perhaps I can launch an instance every day with ECS and then get rid of it. All these routes seem quite inefficient. There seems to be something called Elastic inference where I can provision the right amount of GPU resources - but it seems like I'll need a spare EC2 instance to do that if I'm not mistaken, which is not ideal either. I guess all this stems from the fact that there is no straightforward virtualization for GPU workloads and so they have to provision them 1:1 which currently they are not equipped to do. Has anyone run into a similar problem and found a more elegant solution? All of the above are very messy. Is there some obvious choice I am missing?
- mwcampbell 4y ago
  If your GPU inference can run on an Intel integrated GPU, you could rent a dedicated server from OVH for ~$130 a month and use the integrated GPU on that. I don't know about affordable dedicated servers from mature providers with Nvidia GPUs.
  - MacsHeadroom 4y ago
    I pay a tiny fraction of that for a dedicated served from Hetzner with a modern iGPU transcoding and streaming video 24/7.
- Moissanite 4y ago
  Depends on what "4 hours per day" really means. If you want an interactive endpoint, putting in the work to set up an ECS task you can start and stop feels like the best approach. If you have longer-running inference tasks and just want to pick up results asynchronously, Batch (which is a layer on top of ECS) seems like the way to go. SageMaker might have an abstraction which is a closer fit for your particular use-case, but I'd be wary of potential cost excesses; running on raw EC2 and automating the lifetime somehow is inevitably going to be the cheapest route.
rozenmd 4y ago
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)
rkangel 4y ago
Disclaimer: not a backend or web engineer, I mostly write embedded software, but inevitably need to implement services from time to time (and had a startup at one point) My response is "yes but what about databases". There are any number of ways of hosting my application - "put it on a VM" is a perfectly reasonable approach, particularly as my preferred platform is Elixir which is pretty monolithic anyway. That's fine for the app, but what about the DB? I think I know just enough to know that hosting Postgres properly (i.e. reliably and performantly with appropriate backups) is not that easy, and I'd like someone else to do it for me. For my startup I used App Engine (Flexible Environment) and Cloud SQL. That worked well in that I had the "two instances behind a load balancer" that you want for seamless upgrade, and managed SQL without having to delve into all the many Google Cloud services for networking etc. etc. Everything else was just 'more elixir' which is easy to test locally.
mwcampbell 4y ago
Always remember, HN itself runs on a single dedicated server from a fairly small provider (m5hosting.com). IIUC, they have a backup server. But still, if it's good enough for HN, it's good enough for lots of us.
deleted 4y ago
[deleted]
0xbadcafebee 4y ago
Holy oversimplification, Batman. If you hire people who don't know how the cloud works, then of course their time will be sucked up by learning how it works. If you hire people who know how the cloud works, it is a productivity multiplier. Use the tools that you know. BUT. If you have to build a giant wooden sailing ship, and all you know how to use is a Swiss army knife... and you want to get that ship done this century..... you need to learn new tools.
nkotov 4y ago
A whole lot of nothing being said. Use the right tool for the right job. If you're familiar with AWS, use it and get running and focus on delivering product instead of fine-tuning all the settings and worrying about the perfect cloud environment. My honest opinion, using some third party tools/services on top of AWS only creates tech debt. Over the last two years, AWS has improved a lot of their tools to be incredibly easy that any developer can use it. Developers should be able to understand how their applications run in the cloud provider as well.
mattferderer 4y ago
TLDR - Author seems to value simplicity & focusing on value for users. Doesn't like AWS/Google/etc. because they have to many advanced features. Suggests using Heroku instead. The first part I think most anyone would agree with. The 2nd part doesn't make sense. AWS/Google etc all have simple ways to setup a web app & database without messing with containers, microservices, event architecture etc. As for cost, they all offer generous free tiers for learning & hobby projects. If you want to make a business out of it, check out their also very generous programs for startups with over $100,000 of free services. Azure is over $150k. https://aws.amazon.com/activate/ https://aws.amazon.com/activate/ https://www.microsoft.com/en-us/startups?rtc=1 https://www.microsoft.com/en-us/startups?rtc=1 https://inthecloud.withgoogle.com/startup/dl-cd.html https://inthecloud.withgoogle.com/startup/dl-cd.html Digital Ocean, Cloudflare and many others also offer great incentives to get you to build on their platform for cheap or free in hopes that you succeed & stay with them.
effnorwood 4y ago
monlockandkey 4y ago
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/ 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.
taylodl 4y ago
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.
- scarface74 4y ago
  > if like me, you're working for a Fortune 200 company and it takes multiple ServiceNow tickets to get on-prem hardware “I didn’t get into the cloud to avoid administering servers . I wanted to avoid server administrators”
- ericbarrett 4y ago
  > If, like me, you're working for a Fortune 200 company and it takes multiple ServiceNow tickets to get on-prem hardware What's stopping them, after they "embrace the Cloud," from making it take multiple ServiceNow tickets and several months to change an IAM policy? This has been my experience in very large corps that do use AWS. Typically it's also made a violation of policy to use a team-specific cloud account. P.S. After having helped a mid-sized company migrate some core functions from DC to cloud, I agree with your startup advice.
  - taylodl 4y ago
    You are correct, nothing stops us from taking our terrible on-prem practice and applying them to the cloud except for one thing - it will be more obvious that we screwed the pooch because they let some renegades in before they were able to nail everything down. Now they can't hide behind their gobbledygook BS when they try to apply their existing practices to the cloud. My team is respected so much that we're able to push back on their nonsense in public meetings with the suits. Simply put, I'm enjoying First Mover advantage. Also, doesn't hurt that before joining this team I was on the Enterprise Architecture team and I literally wrote our Cloud Policy! I think that was well-played, even if I say so myself! :)
remram 4y ago
Why do you need IAM policies at all to run a service that works on localhost on AWS? I would expect that you need IAM policies if your app integrates with the AWS platform, which it definitely wasn't doing on localhost, or if you are running multiple services in the same account and want to lock them down (e.g. not have services access each other's S3 buckets and such).
g9yuayon 4y ago
> Terraform to create the IAM policies: 4 weeks 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.

196 points by karls 4y ago

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

somecommit 4y ago

Whateversimple cloud service you use, it's likely using AWS underneath anyway. Like Netlify for example, I think it's all based on AWS.

solardev 4y ago
I really like Vercel's approach of mixing cloud providers behind the scenes. They deliver features (like edge functions) using one cloud, basic hosting using another one, etc. It's all invisible to you as the customer and painlessly abstracted.

bpodgursky 4y ago

If you either use or don't use AWS based on a HN blog post, you deserve whatever happens to you.

dotxlem 4y ago
This is the correct answer

stytchwhy 4y ago

this "thought leadership" in our industry is a disease

prepend 4y ago
There’s been an seo template since slashdot ages of find a prevailing wisdom, write a naive clickbaity post, profit. Sometimes I think authors are earnestly wrong, sometimes I think they are just fake. Sadly, it’s still profitable. I thought that one day I’d interview someone who wrote a post like that and figure out for real. But I’ve been waiting decades so it probably won’t happen. “Everything you know is wrong.” Yadda yadda yadda
- sseagull 4y ago
  It's probably been a lot, lot longer than that. This is an evolution of "think again!" articles from long ago. I wouldn't be surprised if in some cave somewhere there's a message on the wall like "Think Oogie is best stone tool maker? Think again!"
halfmatthalfcat 4y ago
The pretentiousness is suffocating sometimes, especially from those who don't actually build things but pontificate like they do.

irate2942 4y ago

Strange, tried to access this page with my clients vpn on, but got FortiGuard blocked because site is classified as 'phishing'.

karls 4y ago
That's strange indeed. It's hosted by ghost.org and uses Fathom Analytics, that's about it. Unsure why it would be reported as phishing.

cj 4y ago

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.

TheNewsIsHere 4y ago
Different strokes for different folks. (Or at least, use cases.) We’ve found at work that if you already have the talent, the hyper scale cloud platforms are amongst the most expensive ways to manage infrastructure if you go all in. For example $0.40/secret/mo is _expensive_ compared to the cost of an HA vault (not necessarily Hashicorp) setup. If you have 1,000 secrets but you only need to access any given secret once a day, that’s a lot of expense against just setting up your own. And then you can take it with you. Beyond that, we’ve had a LOT more reliable performance from our current VPS provider than we ever got from EC2. That’s not to say AWS is exactly without competition. We use S3 extensively because nothing compares for our usage.
- benmmurphy 4y ago
  If you don’t need secret manager features like region replication and rotation you can use system manager parameters and the secret type. It’s effectively free. We use secret manager but weren’t aware of the price difference.
- scarface74 4y ago
  You probably don’t need secrets manager. Just use SSM Parameter Store secret string type. It’s free.

fredsted 4y ago

I don't understand. Then I won't be able to put Kubernetes, Microservices and AWS on my CV.

prepend 4y ago

> API that works on localhost: 4 days 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.

throwaway2016a 4y ago
API gateway is simply how you expose Lambdas to an HTTP interface in AWS. It was the easiest way until they recently unveiled a way to expose the Lambda directly. You can also use ALBs (Application Load Balancers) and CloudFront to expose Lambdas to HTTP. Either way, Lambdas are hard to debug locally, often I just deploy them to test (since deploying is easy). Or I write my code such that it bootstraps differently when launched locally vs Lambda. Either way, unless it is a very complex app that has lots of external dependencies, 4 days is a bit much.
- Aeolun 4y ago
  But don’t try to create a REST API Gateway with more than 200 resources, or CloudFormation will randomly start failing. Or try to add more than 100 rules to your ALB, because it’ll be impossible. My biggest issue with AWS is that the limits are so arbitrary, and seem to solely exist due to terrible design decisions. If my local express server, or nginx can deal with 100 endpoints, how is it possible for this multi billion dollar infinitely scalable service to not do the same…
  - throwaway2016a 4y ago
    Interesting, I haven't had the experience with CloudFormation. At that scale, however, I tend to group my Lambdas as microservices not per endpoint. It helps with cold start time as well. So for example, if I have a page" resource, I don't make that 5+ endpoints, I make it a wildcard / prefix match and do the routing inside of the service lambda. Maybe you legitimately have 100+ different microservices, in which case, I don't doubt that is a problem, I just haven't experienced it.

chadash 4y ago

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.

Aeolun 4y ago
The problem with even lambda or ECS though is that it’s all much more complex than a simple rsync to your desired server.
- sofixa 4y ago
  With Fargate or Google Cloud Run, it really isn't. Assuming zero knowledge it's probably easier to learn how to build a docker container and call a binary to send it to the service than it is to setup ssh and rsync and a server to host your website.
  - Aeolun 4y ago
    I don’t think you can build a docker container without already understanding concepts that you need to run rsync. So it seems like an extra step?
- coredog64 4y ago
  https://aws.github.io/copilot-cli/ https://aws.github.io/copilot-cli/ That takes a Dockerfile, manages networking, secrets and CI/CD deployment. I have a few quibbles with what it does, but it generally works and is being maintained/updated.

willsmith72 4y ago

I actually totally disagree. With the various development frameworks/CLIs, AWS has the ecosystem benefits that can make hosting on it a breeze, and leave more time to focus on delivering value to the customer.

cuuupid 4y ago

C’mon guys, this week it was my turn to post the AWS bad article

shrubble 4y ago

Small companies and startups can get pretty far with 1 dedicated server and good backups...

Octabrain 4y ago

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

ianbutler 4y ago
You have to concede that that's most of the industry right? The state of implementing IaC is new and foreign for the majority of teams.
shadowgovt 4y ago
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.
throwaway2016a 4y ago
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?
- acdha 4y ago
  > 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. Yeah, it’s about 20 minutes if you use the VPC and Lambda modules from https://github.com/terraform-aws-modules https://github.com/terraform-aws-modules. I could see a week if you had to learn all of this first with little prior experience but that’s true of everything. A newbie running a Linux colo server isn’t going to get all of the security & reliability issues right in less time, either.

valenterry 4y ago

So what, the suggestion is to go with Heroku instead? I think fargate + docker is super easy to setup, run and maintain. Maybe Heroku makes it a little bit easier, but that's about it. Once you leave the Heroku ecosystem you'll have lost all the time you saved. I'm not convinced.

arcbyte 4y ago
I spent a few evenings going the ECS route and the complexity and cost of just a single api available to the internet and a database kept ballooning to way more than what I wanted to pay for and deal with. Fargate, image repo, NAT gateway, I don't even remember all the nonsense at this point but it was ridiculous. I took a look at a few alternatives and DigitalOcean's App service was night and day easier, faster, and cheaper to deal with.
- valenterry 4y ago
  Interesting, have never tried out DigitalOcean. Maybe I should.

raydiatian 4y ago

Gross, this article mentioned terraform. Never use terraform, it is a silly thing.

f0e4c2f7 4y ago

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.

dijit 4y ago
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.
- mwcampbell 4y ago
  > how far a single node machine will get you. This. I took the wrong lesson from the DDoS attacks on Linode in late 2015 (particularly the one on Christmas Day), and the intermittent issues I encountered with DigitalOcean and Vultr in 2016 while both providers were still fairly young. A single dedicated server from a mature provider (ideally not during its hyper-growth phase) is pretty reliable.
- sofixa 4y ago
  > what's weird though is how many mega-corps are going away from Custom Hardware in Custom Built DC towards Cloud It costs a lot of money to run your own datacenters, and very very few companies are capable of doing it as good as AWS or even Scaleway/OVH can. By that I mean, waiting weeks/months to get through tickets, approvals, multiple different teams just to get a server deployed. Then waiting a few more weeks for monitoring/backups. Allowing developers and related to have hardware/software at a whim is a massive advantage.

ABraidotti 4y ago

> It costs how much?! 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.

auggierose 4y ago
> GCP? Come on. What's wrong with GCP?
- shmoogy 4y ago
  Trust issues
- smolder 4y ago
  The G. Products from Google are often transient, support is often non-existent. It doesn't create confidence for people who might be investing big into proprietary cloud features.
- Gigachad 4y ago
  Lots of people have had their servers randomly deleted one day because a google script thought they were a bot. And then of course, there is no one to call at google to have it resolved.

deleted 4y ago

[deleted]

scarface74 4y ago

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.

pkos98 4y ago
Hey, coincidentally I am about to start a role in "Application Modernization" as Cloud Solution Architect at MSFT (though I only have experience with AWS). Do you mind if I ask u some further questions via the email in your profile?
- scarface74 4y ago
  I’m not even sure if I have access to that email. My username is the same on Reddit as it is here. DM me there. I come from a .Net background , so feel free to reach out.
nicoburns 4y ago
What advantage do you see companies getting from using AWS's proprietary products over standard open source equivalents?8
- scarface74 4y ago
  I’m not the sales guy. I’m not here to do sales talking points. I’m going to speak from an on the ground hands on keyboard implementation person. AWS offers plenty of hosted versions of open source solutions and API compatible services like DocumentDB with Mongo compatibility. If I’m working with a customer that prefers the open source solution and there is an equivalent on AWS, I’m going to suggest that. My goal is never to introduce too much new technology to an organization unless there is a compelling need. I’ve recommended everything from a straight lift and shift, to hybrid, to full on all in on AWS depending on the use case. I’m not dogmatic and I’ve never been told “get the customer all in on our services so we can lock them in”. I’ve implemented pure AWS CI/CD solutions, integrated with Azure DevOps, done lift and shifts with Jenkins, etc. I’m judged completely by outcomes and whether the customer is satisfied. But I’ve been railing against worrying about “lock-in” wat before coming to AWS. I’ve been part of numerous large scale migrations and implementations. If you’re at any scale, you’re always both technically and organizationally “locked in” to your infrastructure choices and migrating involves, dealing with CxOs, PMO, retraining, security, regressions, etc. It’s usually much easier to just have a conversation with your account manager.

daniel-cussen 4y ago

sputknick 4y ago

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.

dalyons 4y ago
Why would they pull back from the cloud, instead of just implementing some basic infra ownership and cost auditing processes?
- sputknick 4y ago
  Good point, I explained that poorly (sorry, was half paying attention to a conference call). I meant "pull back" as in reduce their number of instances, which would reduce their monthly spend.

CharlieDigital 4y ago

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

pclmulqdq 4y ago
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.

Entinel 4y ago

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

Aeolun 4y ago
> no one ever got fired for picking AWS It’s also nowhere near as bad as Concur/Oracle/IBM. Though that’s a fairly low bar.

atemerev 4y ago

To start working, you need a VPS instance, a Postgres, and a backup scheme. 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).

eranation 4y ago

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

philliphaydon 4y ago

This might be true if you’ve never used AWS before. But if you know AWS it doesn’t take anywhere near that long. I’m building a PBBG and have it on AWS. Built the site in .NET with SignalR, MartenDB/PostgreSQL. Needed to host it. 2 evenings to write a cloudformation script which builds a VPC. Public and private subnets. RDS. A tiny instance to act as a nat gateway (for servers in private subnet). A small server with HAProxy for load balancer. A tiny server for redis. 2 web servers. Plus some sh scripts to build the project. Zip. Ssh jump to the server and deploy. Total cost is like $42/m. Used a tiny instance for nat gateway cos aws nat gateway costs $32+ingress. Used tiny instance for redis as it’s only used for signalr connections across servers and services. Tiny instance for HAProxy cos aws application load balancer is $15/m. I could consolidate 3 of the servers into 1 but I choose not to. You can build flexible things on AWS. The problem with AWS is it’s very easy to just spin up random stuff and not care about cost and blow out a budget quickly.

jarym 4y ago
> Used a tiny instance for nat gateway cos aws nat gateway costs $32+ingress AWS NAT gateway is certainly pricey. And doesn't even support NAT traversal which means P2P/STUN stuff is out (this is in contrast to GCP which does support it). C'mon AWS you can do better!

TekMol 4y ago

AWS is many things. Their CloudFront service is pretty awesome. You just put it between your server and your users and BOOM all your static content gets delivered lightning fast via Amazons world wide CDN. And it costs like $10 per month millions of requests.

Cloudef 4y ago

AWS is very good and cheap once you know how to use it and what parts. The alternatives most likely run on top of AWS anyhow. I use terranix https://terranix.org/ https://terranix.org/ instead of straight terraform. I can compile, package, deploy everything just with nix.

xcskier56 4y ago

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.

revolutukr 4y ago

These shock jock articles are boring. Step 1: Write an incendiary title Step 2: Make definitive statements meant to be applied broadly but actually targeted at a specific situation that the author is experiencing, or comes from the author's own problems with something. Step 3: Make sure to cast doubt and insecurity, making somebody else feel like they made the wrong choice, even when everything is working perfectly Step 4: Street cred improved!

marcus_holmes 4y ago

Couple with "you should not be using Kubernetes, probably" and "you should be writing a monolith, probably".

clncy 4y ago

> And often it is so alluring that actual requirements and costs fly out the window. Need to scale... infintely? Just use Lambda Functions. I don’t know why the author singles out Lambda. For many use cases their ongoing maintenance is close to zero.

tpict 4y ago

I can see how this makes sense for a startup etc that has passed some threshold of operational complexity. As an “indie hacker” there is no way I’d be able to move out of the cloud without my costs going up by an order of magnitude.

ctvo 4y ago

- Time it took to learn the skills to write a scalable service that can handle 100K events per second: 3 years - Time it took to write that API on localhost: 4 days - Time it took to learn Terraform and some AWS services, to create the API gateway, database, lambdas, queues, Route 53 records: 1 week - Time it took to learn AWS IAM policies to create the IAM policies in Terraform: 4 weeks Author conveniently left out a few bits of information. Once you learn IAM and Terraform, I'm doubtful it takes you another 4 weeks to setup the policies for a new project.

JackFr 4y ago
In my experience Terraform was a horrible pain point, and yet I'd happily suffer it again. We can spin up and spin down transient UAT environments which are pristine and match PROD exactly in a matter of seconds and we can robustly test infrastructure changes. The improvement in developer productivity that entailed was worth the cost.

727564797069706 4y ago

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.

deleted 4y ago
[deleted]
nine_k 4y ago
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.
- Nextgrid 4y ago
  > 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. You can replace "couple VMs" with a dedicated Hetzner/OVH/Kimsufi server, it'll be the same except you won't get ripped off on egress bandwidth and performance.
  - nine_k 4y ago
    I agree that AWS egress bandwidth is a rip-off, but cloud != AWS only. Many cloud providers, from DO to Vultr, offer sane egress prices. The cheapest dedicated server at Hetzner (an excellent provier indeed) is €44.39 / mo, while their cheapest VM option is €4.51 / mo, literally an order of magnitude less. If you don't need the power of a dedicated server for your small project (and even 10 small projects), you don't need to buy it. You can't have a free dedicated server, but many small projects can run either entirely within free tiers of some cloud providers, or for pennies a month based on usage. OTOH you of course can run such small projects from your desktop at home, or maybe even from your NAS or router if they are beefy enough, entirely under your control, and for free! The key value prop of the cloud for me is elasticity. Say, our project spins up more nodes in anticipation of daily waves of traffic, and then spins them down to save cost when the load goes way down. This won't work so well with long-term dedicated servers.

syrusakbary 4y ago

This article has so many gems... > Using the shiniest new technologies is rarely the cause for success, it's usually the result > Culture of simplicity eats strategy of complexity for breakfast

osigurdson 4y ago

I think AWS is shooting themselves in the foot with their ridiculous EKS offering. The fact that it is necessary to first download a 3rd party tool (eksctl) to get anything working is insane. Then, getting basic things working like connecting a load balancer involves importing all kinds of random policies and configuration (which does who knows what) from random github repositories is perhaps even more ridiculous. The same thing in GCP takes nearly zero effort. I can understand why AWS would try to steer people away from Kubernetes since it has a commoditizing effect. However, it could end up steering people away from AWS entirely.

cliftonk 4y ago

I generally agree that no one that isnt a professional devops person (or has spent months tuning IAM and route53 policies) should be using AWS. That said, GCP is so much easier to use and easily usable by a novice because it has a lot of good defaults. Compute and egress costs can be prohibitive at scale, but features like storage + bigquery (OLAP SQL db where u only pay for queries) are basically free for low-to-moderate volume workloads.

solatic 4y ago

> It costs how much?! Less than $5/month. Yes, on AWS. Serverless (the genuine kind, which scales to zero with pay-per-request) is pretty much free until you have actual users, and once you have actual users, you have actual revenue to pay your cloud bills. Unless your ($revenue / $hosting_costs) is less than 1.0, in which case, you don't have a business. > "(LISP) programmers know the value of everything and the cost of nothing". A specific technology product never exists in a vaccuum — it has to communicate and co-exist with other components in the system. There are costs associated with every choice, often hidden costs. An odd choice of quote, considering the author is promoting choices that costs orders of magnitude more money in the earliest stages, and inevitably provoke high migration costs when it comes time to move off those platforms. > Cultivate a culture of ruthlessly fighting complexity Again, an odd claim. Stacks like AWS Lambda and DynamoDB let me forget about scaling concerns* (asterisk because this is true in the early stages, slightly less true later, but still mostly true compared to traditional architecture). Those concerns absolutely rear their head when handing off to a site like Render that refuses to publish public pricing for their largest database instances, or talk about very common usecases like read replicas for analytics workloads. > the harsh truth is that neither Lambda Functions, nor Kubernetes, nor Kafka on their own will magically make your app work correctly, be performant and deliver value. But Redis, PostgreSQL, and PaaS-style service deployment magically will? You mean, early startup CTOs need to actually think about the architecture they propose to build to satisfy business needs? gasp > "Why do we think this choice will provide the most value for users compared to the alternatives?" Because serverless means not needing to hire DevOps. Because most companies running Kubernetes do not get anywhere near the ~38+% efficiency (last time I ran the numbers, and that's for production environments, not even including staging/testing/development environments) they need to make Kubernetes more cost-efficient than AWS Lambda, because developers just don't have time to figure out why the hell their services need a guaranteed vCPU, won't perform with less, and in the meantime their services are using less than 20% of the resources they requested - and they particularly don't have time to figure it out when Customer Support is happy, Product is happy, and Finance will cough up whatever budget is needed so long as Engineering says that it's "necessary". Because founders who actually think about optimizing for value, will optimize for what is scarce, and what is actually scarce is not money (plenty of money out there looking for the right investment opportunities that check all the right boxes), it is people. Serverless means hiring fewer people because you hand off undifferentiated heavy lifting.

Kon-Peki 4y ago

These kind of blog posts treat this as a technical problem instead of a business problem. Until you get some unicorn that says "we are profitable at price $X and all of our competitors are losing money at $X + $Y, and it's because of our software architecture and infrastructure choices", nobody is going to be convinced.

vcryan 4y ago

I disagree. As a small company, having all the various AWS services available is a major competitive advantage.

jabart 4y ago

If you are a starting out, you don't have to use terraform, use the console. Nothing stops you from using the managed services in a heroku box either. Need a queue for your API Heroku->SQS. Need storage, Heroku->S3. The industry always talks about best practices but rarely mentions maturity models which this article gets close to brining up but stops short.

Thristle 4y ago

> Unless you hire a good (read: expensive) devops person to look after your infrastructure, clickops-ing your way through the AWS console will likely leave behind a pile of unused instances and components that will eat into your budget. While this is true-ish (finding lost resources or just not creating them in the first place is not that complex), when the day comes that you will need/want to move to one of the cloud providers you will need a good devops to handle that hybrid cloud environment and making the transfer as painless as possible. cross cloud routing, DB migrations and not to mention setting up secure access for all of it is less complex in my POV then cost managing your cloud account

gbro3n 4y ago

There is a middle way, just set your boundaries on which AWS services you want to use. 1 x EC2 server + 1 x application load balancer and a few S3 buckets works well for my hobby projects (ALB is just for multiple domain SSL and reverse proxy). You can run docker on the EC2 and deploy containers. Yes there is a small amount of setting things up in the AWS UI and some bash scripting for deployment, but then you'd have to configure your DNS and firewall somewhere with a VPS anyway.

fareesh 4y ago

I am currently in the middle of setting up AWS and that decision graph made me chuckle because it resonates quite deeply. I need to do GPU inference but I don't want to run the machine 24x7. I may use it for about 4 hours per day at best. Lambda doesn't offer GPUs and neither does ECS+Fargate. It seems like I could setup an endpoint using Sagemaker and then destroy it when no longer needed, and automate all of this but it feels quite messy. The other route is perhaps I can launch an instance every day with ECS and then get rid of it. All these routes seem quite inefficient. There seems to be something called Elastic inference where I can provision the right amount of GPU resources - but it seems like I'll need a spare EC2 instance to do that if I'm not mistaken, which is not ideal either. I guess all this stems from the fact that there is no straightforward virtualization for GPU workloads and so they have to provision them 1:1 which currently they are not equipped to do. Has anyone run into a similar problem and found a more elegant solution? All of the above are very messy. Is there some obvious choice I am missing?

mwcampbell 4y ago
If your GPU inference can run on an Intel integrated GPU, you could rent a dedicated server from OVH for ~$130 a month and use the integrated GPU on that. I don't know about affordable dedicated servers from mature providers with Nvidia GPUs.
- MacsHeadroom 4y ago
  I pay a tiny fraction of that for a dedicated served from Hetzner with a modern iGPU transcoding and streaming video 24/7.
Moissanite 4y ago
Depends on what "4 hours per day" really means. If you want an interactive endpoint, putting in the work to set up an ECS task you can start and stop feels like the best approach. If you have longer-running inference tasks and just want to pick up results asynchronously, Batch (which is a layer on top of ECS) seems like the way to go. SageMaker might have an abstraction which is a closer fit for your particular use-case, but I'd be wary of potential cost excesses; running on raw EC2 and automating the lifetime somehow is inevitably going to be the cheapest route.

rozenmd 4y ago

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)

rkangel 4y ago

Disclaimer: not a backend or web engineer, I mostly write embedded software, but inevitably need to implement services from time to time (and had a startup at one point) My response is "yes but what about databases". There are any number of ways of hosting my application - "put it on a VM" is a perfectly reasonable approach, particularly as my preferred platform is Elixir which is pretty monolithic anyway. That's fine for the app, but what about the DB? I think I know just enough to know that hosting Postgres properly (i.e. reliably and performantly with appropriate backups) is not that easy, and I'd like someone else to do it for me. For my startup I used App Engine (Flexible Environment) and Cloud SQL. That worked well in that I had the "two instances behind a load balancer" that you want for seamless upgrade, and managed SQL without having to delve into all the many Google Cloud services for networking etc. etc. Everything else was just 'more elixir' which is easy to test locally.

mwcampbell 4y ago

Always remember, HN itself runs on a single dedicated server from a fairly small provider (m5hosting.com). IIUC, they have a backup server. But still, if it's good enough for HN, it's good enough for lots of us.

deleted 4y ago

[deleted]

0xbadcafebee 4y ago

Holy oversimplification, Batman. If you hire people who don't know how the cloud works, then of course their time will be sucked up by learning how it works. If you hire people who know how the cloud works, it is a productivity multiplier. Use the tools that you know. BUT. If you have to build a giant wooden sailing ship, and all you know how to use is a Swiss army knife... and you want to get that ship done this century..... you need to learn new tools.

nkotov 4y ago

A whole lot of nothing being said. Use the right tool for the right job. If you're familiar with AWS, use it and get running and focus on delivering product instead of fine-tuning all the settings and worrying about the perfect cloud environment. My honest opinion, using some third party tools/services on top of AWS only creates tech debt. Over the last two years, AWS has improved a lot of their tools to be incredibly easy that any developer can use it. Developers should be able to understand how their applications run in the cloud provider as well.

mattferderer 4y ago

TLDR - Author seems to value simplicity & focusing on value for users. Doesn't like AWS/Google/etc. because they have to many advanced features. Suggests using Heroku instead. The first part I think most anyone would agree with. The 2nd part doesn't make sense. AWS/Google etc all have simple ways to setup a web app & database without messing with containers, microservices, event architecture etc. As for cost, they all offer generous free tiers for learning & hobby projects. If you want to make a business out of it, check out their also very generous programs for startups with over $100,000 of free services. Azure is over $150k. https://aws.amazon.com/activate/ https://aws.amazon.com/activate/ https://www.microsoft.com/en-us/startups?rtc=1 https://www.microsoft.com/en-us/startups?rtc=1 https://inthecloud.withgoogle.com/startup/dl-cd.html https://inthecloud.withgoogle.com/startup/dl-cd.html Digital Ocean, Cloudflare and many others also offer great incentives to get you to build on their platform for cheap or free in hopes that you succeed & stay with them.

effnorwood 4y ago

monlockandkey 4y ago

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

taylodl 4y ago

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.

scarface74 4y ago
> if like me, you're working for a Fortune 200 company and it takes multiple ServiceNow tickets to get on-prem hardware “I didn’t get into the cloud to avoid administering servers . I wanted to avoid server administrators”
ericbarrett 4y ago
> If, like me, you're working for a Fortune 200 company and it takes multiple ServiceNow tickets to get on-prem hardware What's stopping them, after they "embrace the Cloud," from making it take multiple ServiceNow tickets and several months to change an IAM policy? This has been my experience in very large corps that do use AWS. Typically it's also made a violation of policy to use a team-specific cloud account. P.S. After having helped a mid-sized company migrate some core functions from DC to cloud, I agree with your startup advice.
- taylodl 4y ago
  You are correct, nothing stops us from taking our terrible on-prem practice and applying them to the cloud except for one thing - it will be more obvious that we screwed the pooch because they let some renegades in before they were able to nail everything down. Now they can't hide behind their gobbledygook BS when they try to apply their existing practices to the cloud. My team is respected so much that we're able to push back on their nonsense in public meetings with the suits. Simply put, I'm enjoying First Mover advantage. Also, doesn't hurt that before joining this team I was on the Enterprise Architecture team and I literally wrote our Cloud Policy! I think that was well-played, even if I say so myself! :)

remram 4y ago

Why do you need IAM policies at all to run a service that works on localhost on AWS? I would expect that you need IAM policies if your app integrates with the AWS platform, which it definitely wasn't doing on localhost, or if you are running multiple services in the same account and want to lock them down (e.g. not have services access each other's S3 buckets and such).

g9yuayon 4y ago

> Terraform to create the IAM policies: 4 weeks 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.