[0]: https://cloudcustodian.io/

https://www.marketwatch.com/story/capital-one-fined-80-milli...

Edit: I wonder if you could put this inside of a lambda with just a role.

Depending on my mood I either use the web page or some simple curl aliases to start and stop an instance.

I had been looking at creating a lamba to check for the existence of pods, services, alternate namespaces etc., as I learn K8s on AWS, to shut down the cluster when I'm not working on it.

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

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.

Though I find a stronger argument in using containerisation to ensure an identical application run-time environment no matter the infra it’s running on.

If we are talking about infra engineering, then sure. That’s where I find localstack helps

The reason I'm asking is because on my free time I'm developing a cloud IDE but I'm having trouble understanding the market. I beleave cloud dev services will be a huge market. But I don't understand how people use it practically in their dev setup.

I found at first testing was arduous, but you learn to adapt. In my case, I increased the amount of debug logs my application throws (can also be useful to enable in prod when trying to hunt down an issue) and invested time in creating unit/integration tests that run outside of the container/lambda to validate specific paths/features. Worst case there's always docker exec and language-specific debugging when I want to dig in manually.

I'm still pretty skeptical about serverless (I mostly use it for cloud-specific automation), but as much as people like to shit on Docker it's been pretty great to use from an ops perspective. I interpret most negativity about it as curmudgeonly reactions to the admittedly excessive hype in the technologies, with some fairly pedantic complaints about the (imo minimal) overhead such technologies incur thrown in as an uninteresting justification.

If they don't work the same on local computer than on ECS perhaps docker failed to deliver what promised?

BTW: I absolutely hate debugging in AWS, it's such a nightmare, docker was the first thing that made thing hard even on premises, but AWS pushed things to 11.

I think the key to sanity if you have to use public cloud is to put extra effort so you discover all bugs locally before you deploy to public cloud. Which probably is not a bad thing.