> X should be easy
> proposes solution that involves YAML
Am I crazy, ignorant, or is YAML the most tedious and error-prone format edit?
Libaws: A simpler way to declare AWS infrastructure
11–20 of 93 posts
Re: Libaws: A simpler way to declare AWS infrastructure
#12IMO, this is seeing everything as a nail when you're a hammer. AWS provides extreme flexibility. This really only becomes valuable once you hit a scale that you can optimize your infrastructure around the shape of your needs. * Need some heavy workload to run in the most cost effective data center at the most cost effective time. Yep, AWS is great for that. * Need a specialized GPU set. Yep, AWS is great for that. *…
> AWS provides extreme flexibility. This really only becomes valuable once you hit a scale that you can optimize your infrastructure around the shape of your needs.
This is upside down? When you hit the scale where you get value from modelling your infra around your business use cases that's when you go on-prem or use services that let you rent bare metal. Before that you use cloud.
Re: Libaws: A simpler way to declare AWS infrastructure
#13> X should be easy > proposes solution that involves YAML Am I crazy, ignorant, or is YAML the most tedious and error-prone format edit?
I have grown to loathe YAML over the years. It is a giant foot gun of a mess of syntax.
I lile python, I like significant whitespace, I hate how YAML does it.
Re: Libaws: A simpler way to declare AWS infrastructure
#14Why should it be? is Linux easy? Is Windows? AWS (as is GCP and Azure) can basically be thought of as an entire operating system, with extremely low level concepts (VPCs, EC2 machines), mid-level (Lambda, StepFunctions, EventBridge), and high-level (Translate, Comprehend, Rekognition, etc) I am not sure if this library helps. It presents its own opinionated flavour of AWS but doesn't really hide enough of the details…
100% agreed "Piloting a passenger plane should be easy" "Performing brain surgery should be easy" None of that should be easy. AWS is not meant to be focused on ease of use in the first place. It offers brutal power to those who know how to operate it and brutal ways to fuck up if you don’t. The shipping of applications mentioned by the comment in this thread is not a valid statement either.. there are countless serv…
> "Piloting a passenger plane should be easy"
> "Performing brain surgery should be easy"
> None of that should be easy.
Why shouldn't those things be easy? Wouldn't it be better if they were? It would mean more people could do it well (I'm not saying let anyone do it!) and it would presumably have come about as a result of better understanding and tooling. Imagine if people didn't die on the waitlist for the best neurosurgeon in the country, because we'd made brain surgery easier and so now all the neurosurgeons could do that one formerly-super-difficult surgery.
Re: Libaws: A simpler way to declare AWS infrastructure
#15I think AWS is getting there, but hiding either with the cost of hiding complexity with tools like AWS CDK or even actually with services like AWS Lightsail designed for people that doesn't care about building blocks (ec2, s3, route53, sqs, sns, etc...)
Re: Libaws: A simpler way to declare AWS infrastructure
#16AWS is very easy for me when all I have to do is launch ec2 instances ^.^
Re: Libaws: A simpler way to declare AWS infrastructure
#17Why should it be? is Linux easy? Is Windows? AWS (as is GCP and Azure) can basically be thought of as an entire operating system, with extremely low level concepts (VPCs, EC2 machines), mid-level (Lambda, StepFunctions, EventBridge), and high-level (Translate, Comprehend, Rekognition, etc) I am not sure if this library helps. It presents its own opinionated flavour of AWS but doesn't really hide enough of the details…
> if you don't want to think about services at all, use CDK constructs
This is the level that it makes sense to use AWS at if you're a small team. 10 lines of code/5 minutes and you have a deployment of https terminated load balanced containers that scale with your usage. It just works, it scales, and for small teams it saves a huge amount of time (and Dev effort - instead of focusing on setting up the correct nginx or haproxy settings I can write my app).
Re: Libaws: A simpler way to declare AWS infrastructure
#18Earlier quoted context omitted.
> Why should it be? There exists a cohort of internal customers at medium-to-large sized software companies that need to ship new applications without being bogged down by the decisions of how to get that thing running and playing nicely with the rest of the ecosystem. For the same reason they don't give their end users CRUD APIs to use their products, it doesn't always make sense to give our developers the entire su…
At my old job, SecDevOps built a metric fuckton of monitoring of all AWS accounts in the Organizations, as well as some pretty complex pipelines that checked the typs of infrastructure being built. Everything built in AWS was done with Terraform (minus some bootstrapping of accounts and orgs). Custom terraform modules were built which were guardrails of underlying raw Terraform providers. I'm not saying it's ideal, I…
I'm not really familiar with terraform, I'll check it out.
Re: Libaws: A simpler way to declare AWS infrastructure
#19Terraform modules? In particular, https://github.com/terraform-aws-modules/ is a better solution for anyone looking for this IMO.
(Yes there is a comparison to 'terraform' in the Readme - I'm not convinced it's considering modules, versus just using the AWS provider directly. Another bonus of using tf modules over this: you can eventually realise you need to graduate to using the AWS provider directly, and do so quite easily (cf. `terraform state mv`).)
Re: Libaws: A simpler way to declare AWS infrastructure
#20Why should it be? is Linux easy? Is Windows? AWS (as is GCP and Azure) can basically be thought of as an entire operating system, with extremely low level concepts (VPCs, EC2 machines), mid-level (Lambda, StepFunctions, EventBridge), and high-level (Translate, Comprehend, Rekognition, etc) I am not sure if this library helps. It presents its own opinionated flavour of AWS but doesn't really hide enough of the details…
My anecdotal evidence is developers struggle big time to deploy simple stuff to AWS. "Easy things should be easy" isn't part of their philosophy. Not complaining thought, I make good money understanding AWS so others don't need to. > Why should it be? Because if they don't focus on developer experience, they might end up being treated as a commodity. Eventually someone will eat their lunch.
> isn't part of their philosophy.
There is no one AWS philosophy. The philosophy of foundation networking services is going to be different from higher-abstraction services.
They are for different customers with different needs.
> Because if they don't focus on developer experience, they might end up being treated as a commodity. Eventually someone will eat their lunch.
That's certainly true.