steelaz

This incident made me look at the SLAs we have with GitHub, since our company is on the Enterprise plan. Interestingly, it seems that only failed GHA invocations are counted towards an SLA breach. We informed engineering to stop using GHA while the incident was ongoing, but it seems what we should have done was to hammer them without remorse to get the whole incident period (10+ hours) counted towards an SLA breach. What a scummy SLA design.

Threw me off at first as well. I was thinking of tasks per month. But this seems to be just pay as you go top-ups. Makes sense from a freelancer perspective. If I have work, I top-up my account. If there is none, I don't feel pressure like from all the other monthly subscriptions.

To be fair to AWS, they announced the deprecation of MySQL 5.7 in January 2021, and many emails warned of this change throughout 2024.

Couldn't agree more. Twilio has been profiting from these scammers for years. We had several calls with our account manager and "fraud expert", and the answer was always the same - migrate to Twilio Authy. The problem is that with Twilio Authy you are basically paying the same amount, it's just that the cut or "protection fee" is not going directly to scammers, but to Twilio.

The last time we talked to them, they bragged about how good their algorithm to detect fraud is and that we should take advantage of it by onboarding to Authy. I asked them why they just don't offer it to all customers, since their platform is enabling scammers. And the manager said, I'm paraphrasing here, "well, we are for profit company".

Happened to us as well a while back. We tracked originating IPs to the same telco that was sending SMS to their own numbers through our platform. I couldn't believe it.

We got rid of all IAM users used by applications and moved to role-based access. Nowhere in the application do you need to enter AWS credentials. AWS SDK will attempt to discover short-lived credentials for you and will assume the role specified at the infrastructure layer, e.g. in a task definition.

Yes, but even in your example, that's 20% of resources going to the sidecar. Not to mention sizing correctly multiple containers in a single task gets complicated.

This is cool product, but but I don't undersatand this statement:

"Importantly, Akita did not impact processing loss or extra costs inside AWS, a main concern at our company stage."

Author specifically talks about AWS Fargate and links to Akita docs where it says in AWS Fargate setup, Akita agent should run as a side car in each container you deploy. How can that not bring significant amount of extra compute cost?

We run very similar scaffolding to host different workloads, except we run it on ECS, so you could complicate reference diagram even further.

In reality, when we had to add Wordpress to our workloads, there was nothing special we had to do except for introducing EFS. All our workloads before that didn't require keeping state on a file level.

And just like that we had a scalable/HA Wordpress setup with pretty decent performance.

If true, what does that mean to AWS regions in China?