Earlier quoted context omitted.
What happens when you need 40 micro-services running to render your frontend?
You ditch all the microservices and develop the app like a normal human being.
That's an answer to a question he didn't ask.
Show HN: Tiny CLI to save AWS costs in dev environments when you're sleeping
41–50 of 56 posts
Re: Show HN: Tiny CLI to save AWS costs in dev environments when you're sleeping
#42Great addition to pile of scripts to take with you on problem solving missions. I have something similar, but written in terraform.
WRT AWS cost visibility, I find it is usually faster to spin up and grab most of the relevant information using mlabouardy's [komiser](https://github.com/mlabouardy/komiser) than to try and standardize yourself.
Not shilling, just a tool I like.
Re: Show HN: Tiny CLI to save AWS costs in dev environments when you're sleeping
#43Just 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…
Are you aware of cloud custodian out of Capital One? [0] Does this and much, much more (like delete noncompliant security groups, etc). [0]: https://cloudcustodian.io/
I'm aware that Capital One was found guilty of not properly securing customer information when they started moving it to "the cloud" (AWS). I'm also aware that the person who orchestrated the data breach, by exploiting the bank's AWS (mis)configuration, had been hired by Amazon as a developer. Maybe the bank's IT staff created "cloud custodian" after the incident.
https://www.marketwatch.com/story/capital-one-fined-80-milli...
Re: Show HN: Tiny CLI to save AWS costs in dev environments when you're sleeping
#44Earlier quoted context omitted.
Are you aware of cloud custodian out of Capital One? [0] Does this and much, much more (like delete noncompliant security groups, etc). [0]: https://cloudcustodian.io/
I'm aware that Capital One was found guilty of not properly securing customer information when they started moving it to "the cloud" (AWS). I'm also aware that the person who orchestrated the data breach, by exploiting the bank's AWS (mis)configuration, had been hired by Amazon as a developer. Maybe the bank's IT staff created "cloud custodian" after the incident. https://www.marketwatch.com/story/capital-one-fined-8…
Custodian was already there , they have a strict pipeline but what I hear is that the environment where the hack took place was bypassing the normal organisational pipe governance and did not even have coverage of the custodian on the account. Basically shadow it. I still put a lot of blame on the way AWS Iam makes it incredibly hard to stop the use of the credentials outside the vpc in the event they are stolen , for example source ip restrictions do not work if the bucked it using kms encryption because kms will decrypt on users behalf appearing to come from a different ip than the user . The called via is a farce that only work with about 4 services out of hundreds and the meta data v2 with its ip level TTL is a marketing gimmick
Re: Show HN: Tiny CLI to save AWS costs in dev environments when you're sleeping
#45Earlier quoted context omitted.
How do you test or develop against cloud resources like ECS using a local PC?
I would like to know how and why you use resources like ECS. et.al. There reason why I do not like to use cloud/serverless is because I find debugging is much easier on a local computer or a server I have root/metal/hardware access to. And that serverless have a very slow iteration rate, it can take minutes just to run a simple test that would be instant locally. The reason I'm asking is because on my free time I'm d…
I use it (and similar tech) because I don't want to think about individual boxes at scale, rather instances of an application. Containers + orchestration allow me to develop and test in the exact same environment my apps will be in in prod, which allows me to mostly remove the hardware and OS as a variable that could affect its runtime behavior. They also make it easier to spin up a local copy of my services' runtime environments for testing, as I need only describe it in a simple yaml file and spin it up w/ docker-compose in a single command.
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.
Re: Show HN: Tiny CLI to save AWS costs in dev environments when you're sleeping
#46While this only works with instances, I usually just cron the shutdown command with a future time. Nice thing is, if working late I give myself a couple hour window to cancel shutdown on any nodes I'm still using.
echo "0 22,0,2,4,6,8,10 * * * /sbin/shutdown +115" > /etc/cron.d/autoshutdown
I'm all for a better tool, just wanted to point out a builtin alternative.
Re: Show HN: Tiny CLI to save AWS costs in dev environments when you're sleeping
#47Earlier quoted context omitted.
Im very interested in learning about your work flows, like how does a typical day look like? I do all my work on a local pc and only use servers for production. So im interesting in how/why you use the cloud stack
How do you test or develop against cloud resources like ECS using a local PC?
Hmm... ECS is for running docker containers.
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.
Re: Show HN: Tiny CLI to save AWS costs in dev environments when you're sleeping
#48Any similar for other cloud services like azure, gcp and especially digital ocean
Re: Show HN: Tiny CLI to save AWS costs in dev environments when you're sleeping
#49Just 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…
Im very interested in learning about your work flows, like how does a typical day look like? I do all my work on a local pc and only use servers for production. So im interesting in how/why you use the cloud stack
Not OP, but in my company we do develop locally, however, merged feature branches are deployed to a AWS environment for testing. The environment is identical to production, but with smaller instances. Betas are deployed to yet another identical environment for QA to approve the changes. All three environments are managed by the same Terraform configuration to ensure they are identical.
Re: Show HN: Tiny CLI to save AWS costs in dev environments when you're sleeping
#50Just 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…
Are you aware of cloud custodian out of Capital One? [0] Does this and much, much more (like delete noncompliant security groups, etc). [0]: https://cloudcustodian.io/
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 :)