Modern cloud architecture on AWS: server fleets and databases • Hacker News Board

Re: Modern cloud architecture on AWS: server fleets and databases

#51

Post by scarface74 » Sun, Feb 09, 2020, 9:57 AM UTC

viraptor wrote: post #42

scarface74 wrote: post #40

Earlier quoted context omitted.

Why would you ever use Terraform over CloudFormation? There are so many parts of AWS that use CF and that you can modify from the getting started templates like CodeStar and exporting a SAM template from your lambda template. Before someone comments on how TF is “cross platform”, all of the provisioners are vendor specific. As far as what other services to use, if you are hosting your own services on AWS instead of u…

> Why would you ever use Terraform over CloudFormation? 1. You're using Terraform already for resources outside of AWS (cdn, monitoring, dns, anything else) and want to stay with a common tech. 2. You're running into cases that CF doesn't support and have to generate your descriptions externally, or use sparkleformation hacks. 3. You want to manage a new AWS service. (CloudFormation support lags behind Terraform, new…

In cases two and three it’s just as easy to write a custom resource....

Re: Modern cloud architecture on AWS: server fleets and databases

#52

Post by viraptor » Sun, Feb 09, 2020, 10:14 AM UTC

scarface74 wrote: post #51

viraptor wrote: post #42

Earlier quoted context omitted.

> Why would you ever use Terraform over CloudFormation? 1. You're using Terraform already for resources outside of AWS (cdn, monitoring, dns, anything else) and want to stay with a common tech. 2. You're running into cases that CF doesn't support and have to generate your descriptions externally, or use sparkleformation hacks. 3. You want to manage a new AWS service. (CloudFormation support lags behind Terraform, new…

In cases two and three it’s just as easy to write a custom resource....

You mean just as easy to write/test/deploy a custom resource as it is to use a ready one? I disagree. I think there's a few days of work of difference in that case.

Re: Modern cloud architecture on AWS: server fleets and databases

#53

Post by scarface74 » Sun, Feb 09, 2020, 12:07 PM UTC

viraptor wrote: post #52

scarface74 wrote: post #51

Earlier quoted context omitted.

In cases two and three it’s just as easy to write a custom resource....

You mean just as easy to write/test/deploy a custom resource as it is to use a ready one? I disagree. I think there's a few days of work of difference in that case.

Actually, no.

Examples for creating them in Java, Python and Node are here

https://github.com/stelligent/cloudformation-custom-resource...

Just add a few lines of code for create, update and delete for your resource.

For Node and Python, you can write them in the web console, test them, copy the code to your git repo and export the SAM CF template for your CI/CD process.

Re: Modern cloud architecture on AWS: server fleets and databases

#54

Post by CoolGuySteve » Sun, Feb 09, 2020, 12:42 PM UTC

nostrebored wrote: post #50

CoolGuySteve wrote: post #34

Earlier quoted context omitted.

I went with Aurora Postgres recently for a new application and to be honest it fucking sucks. When it scales up, queries start to fail and there are long delays. I had to add a try/retry loop around all my inserts to avoid losing data. I definitely wouldn't recommend it for bursty applications where it needs to rapidly scale up. The thing that bugs me is that I know a similar workload works fine on a relatively cheap…

... were you not handling errors on database inserts through well established concepts like exponential backoff and retry already? that seems like a colossally bad idea If you don't need the striped storage model and guarantees that Aurora provides, it might not be the service for you

Normally I’d agree with you but I was only doing a dozen or so inserts per second for maybe a minute or two after hours of idleness.

There was no back off because it was never needed before, even the shittiest instance could handle it without issue but Aurora failed spectacularly.