aramalipoor

how do you see which agent on which machine is waiting on you? or do you check each orchestrator by hand

In a world where AI is the main code author we shouldn't be reviewing code down to syntax and every symbol... We don't think about which CPU register stores our variables anymore, because we trust the compilers. That trend will happen for code the stronger models get.

We need a new way to judge high-level decisions, relationships, dependencies, interfaces, and have an easier way to reasons about huge AI generated code.

That's a good alternative for EC2 / RDS instances but when it comes to other cases like DynamoDB provisioned throughput or Kinesis shards or ElastiCache it wouldn't help much

There were a few reasons why I couldn't use IaC:

1) Using conditionals to achieve this usually makes terraform unmanageable specially if your terraform is complex.

2) Sometimes you'd need to do more complex steps to save some money, for example in case of ElastiCache you'd need to snapshot/delete/create.

3) Using terraform in a Lambda to schedule this was not straightforward (in my current company) so I gave up making it work :D

Posted an answer to another similar question: https://news.ycombinator.com/item?id=24250329 hope it helps when developing with your IDE :)

It really depends on the company and developers preferences. For our company's case we do have a "dev" AWS environment for a couple of reasons:

1) To avoid having a side-IaC for your dev env (e.g. using docker-compose/local k8s/localstack) which could take same time as your prod-IaC (terraform/CloudFormation) to prepare. Instead of hours preparing/debugging local dev we can work on great features or refactoring some tech-debt in the real code.

2) Since we have many other teams and upstream dependencies it's much easier to deploy on a AWS when testing complicated features. In an ideal world you shouldn't need it but unfortunately it's never ideal world.

3) Local dev solutions could easily end up with "but it worked on my laptop" due to various reasons from Docker host configs, to localstack deviations from real AWS resources, etc.

But at the end of the day you should see what makes more sense for you :) I guess for many people spending time on preparing a great local dev using docker-compose/k8s/swarm/localstack is cheaper than using AWS for dev anyway.

Thanks for sharing this. Looks like a sophisticated solution, although might be too complex and enterprise-y for what I needed as a sleepy developer, but is definitely worth having a look :)

Thanks for sharing your experience. Both of them sounds like great ideas, will add them to ToDo right away :)

Thanks. Agree with you, having it in a Lambda with a scheduled trigger or even manual trigger will be really useful.

Thanks. Shutting down K8S cluster when not using is a really good idea. Maybe one day I play around with AWS's k8s cluster and add the trick to aws-cost-saver.

Pull requests are also welcome if you have time :) the logic must be similar to EC2 or RDS tricks: https://github.com/aramalipoor/aws-cost-saver/blob/master/sr...

Just published a tiny CLI utility to save some bucks on AWS development environment while I'm not really working.

https://github.com/aramalipoor/aws-cost-saver

The idea is to stop/shutdown any resources (such as EC2 instances, RDS databases, ECS tasks, etc.) when you're done for the day and restore them back up next time you continue.

Currently it's in a very early stage, a hobby side-project :)

Ideally I'm thinking to provide a CloudFormation template or terraform config for example, to provision a scheduled Lambda with predefined "start of work" and "end of work" times and have it automatically do that for you.

I'd like to know if something like this would be useful for you too and what do you think about it?