71–80 of 93 posts
It's funny to me why people aren't aware of CDK. It's literally no different than writing code. You don't have to depend on anyone, you can customize this to no end, its part of your codebase. from aws_cdk import aws_s3 as s3,naws_iam as iam,bcore class S3Template(core.Stack): def __init__(self, app: core.App, id: str, **kwargs) -> None: super().__init__(app, id) myBucket = s3.Bucket(self, 'MyFirstBucket', bucket_nam…
Careful, sarcasm is hard to detect online
There is no tool in the world that will make you good at something you don't know. If you allow me a story, I sail on a kind of boat, called a squib. For the foresail, eg the sail that is in front of the mast, it has the regular sheets, a Cunningham, a halyard tensioner and barber haulers. The squib is a very easy boat to sail, notoriously hard to sail fast. Complaining about AWS being complicated, is the same as com…
For the most part, the constructs provided out of the box has good defaults and the documentation helps. The aws-cdk support team is also responsive on issues/bugs reported.
This is just based on my experience and I started off as a total noob on AWS.
IMO, 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. *…
Some feedback on this idea from someone who works at AWS and has worked on similar tools to make AWS easier, such as AWS Copilot ( https://aws.amazon.com/blogs/containers/introducing-aws-copi... ): The hard part isn't making AWS easier, it is making a tool which is both easy and flexible enough that a user can do what they need (within reason), then outgrow your tool and move on. In specific any tool based abstractio…
In case of cloud providers its quite often that Terraform Providers are updated faster by dedicated teams than their own Cloud solutions. Cloudformation or AWS CDK are upgraded slower than providers for example. So this argument is mot.
I am convinced that AWS is intentionally obtuse in order to promote job security for engineers and thus be the preferred platform
I am convinced that AWS is intentionally obtuse in order to promote job security for engineers and thus be the preferred platform
As someone who has worked within AWS, and also used AWS as a customer at multiple companies, I totally understand that sentiment. But I wouldn't want to solve some of the problems myself, rather than using their services.
Sure, but vanilla setups should be trivial and optimised for cost. That is not to their or their consultants’ benefit.
I mean, whenever I asked someone ‘how do I do this in aws’, they tell me ‘oh that is a bog standard blah setup, very Simple’. So if that is simple, why is it so hard to set up as a novice (with 20 years of rack server bare metal hosting experience). I had to learn everything about aws in order to figure out that all experts saying things are ‘simple’ were still not providing optimal solutions for my vanille, and for decades unchanged across many different applications, hosting wishes. If you don’t know literally everything about aws and hired a consultant or a team to set it up, you are probably (massively) overpaying. And often, as I see at clients, for vanilla stuff that should be 1 click setup. But yes, I guess tool providers should provide this on top, not aws itself.
> X should be easy > proposes solution that involves YAML Am I crazy, ignorant, or is YAML the most tedious and error-prone format edit?
Do you edit Python Pickle files by hand?
Earlier quoted context omitted.
In case of cloud providers its quite often that Terraform Providers are updated faster by dedicated teams than their own Cloud solutions. Cloudformation or AWS CDK are upgraded slower than providers for example. So this argument is mot.
It's a mixed bag. From what I've seen its 50/50. Sometimes Terraform providers are way behind, and sometimes they are ahead. Additionally, the low level providers which are easiest to keep up to date don't really abstract much. It is mostly a one to one API mapping, so it doesn't make the AWS experience any "easier". I'm specifically speaking about tooling that attempts to abstract and simplify the AWS experience. Th…
Managers are long looking for a way to hire cheap labor. Issue us cheap labor lacks knowledge required to build soecialized things. And thankfully it will never change, no tool can provide that.
Earlier quoted context omitted.
I'm really fascinated about why so many infrastructure-as-code tools are actually infrastructure-as-markup. Many of them seem to "evolve" until they're awkward attempts at bolting full programming language semantics onto that markup language. I imagine it started out as wanting to keep a simple configuration-style format for infrastructure but fell apart when people's stacks grew large and complex. Projects like Pulu…
In the early days, people would write imperative scripts to provision infrastructure, but once it's out there you can't just delete resources that you no longer want by deleting the relevant blocks from your script and re-running it--you had to delete them manually or write a "migration script". This was untenable. Then some tools came out which let you use YAML or JSON to describe the desired state of the world, and…