Generally these limits exist so customers don’t accidentally spend more than they intend to — e.g. implementing a sort of infinite loop where Lambdas call each other constantly. Sounds implausible but I’ve seen that more than once!
In principle I agree with this, but do feel this is said more readily about Cloudflare than other companies it could said about - such as Amazon (via AWS), Google and Microsoft.
Perhaps my own mental model is wrong, but I see them as a credible challenger to those very oligopolistic companies, and wish there were more Cloudflares.
You might enjoy the SRE path, or other closely-associated roles. Being naturally apt at debugging / optimising systems is a huge asset for us, and you might find a lot of satisfaction that way.
Not from the company but we do something similar with opentelemetry. It’s true, because you pay for the total allocation of CPU/memory on Fargate, so you can add a sidecar container into that total allocation with a small deduction from the amount left available to the app itself.
E.g.
Before: 512MB for task, 512MB available for the application
After: 512MB for task, 412MB available for the application, 100MB available for sidecar
This can be true, but I would argue not always. Some DevOps teams work in the old mode of “throwing code over to Ops to run” - this isn’t what DevOps intended, but happens.
When they work well, they’re doing things like authoring reusable (by product eng. teams) infrastructure modules, or helping to build “you build it, you run it” tooling like monitoring stacks etc. They’re also helpfully/hopefully subject matter experts on CI/CD, your cloud/hosting of choice, security stuff - things that general developers have mixed levels of interest or competence in.
Bit disingenuous to credential Tommy Robinson as a “citizen journalist”, given he’s notoriously the face of a far-right organisation and is a convicted, violent criminal.
That doesn’t mean he should have his speech curtailed, but does warrant an accurate portrayal if you’re using him as an example in an op-ed…
As someone on the “buy side” of Cloudflare-like services, that’s not how it works. How could a third party like Cloudflare protect my unprotected IP address? A very basic part of using a CDN/DDOS protection product is not allowing raw traffic to your origin server.
RE “as long as no one leaked their IP” - the IPv4 space is quite small. It’s trivial to scan it and discuss unadvertised, but ultimately very public, servers.
If customers don’t already have an understanding of both of these points, then they need to increase their competence in areas that are, frankly, pretty basic.
My partner works in buying for physical retail (caveats: nothing to do with software, also she’s generally worked mid market and above, rather than anything high volume/low cost) and I believe _margin_ is often 30-60%, or a range similar to that. Larger retailers will also have agreements with suppliers where the margin is stipulated, I believe per SKU.
Obviously the comparison is slightly Apples to oranges, as physical retailers have massive overheads/COGS that Apple don’t incur for the App Store.
It’d be interesting to know - what are the expectations made of you? In this environment, I’d expect there to be dedicated support for teams operating their services - i.e. SRE/DevOps/Platform teams who should be looking to abstract away some of the raw edges of operating at scale.
That said, I do think there’s a psychological overhead when working on something that serves high levels of production traffic. The stakes are higher (or at least, they feel that way), which can affect different people in different ways. I definitely recognise your feeling of exhaustion, but I wonder if it maybe comes from a lack of feeling “safe” when you deploy - either from insufficient automated testing or something else.
(For context - I’m an SRE who has worked in quite a few places exactly like this)
I’d guess it’s not the usage of a VPN that has triggered this, but rather a new account immediately presenting multiple IP addresses. I’d guess that would trigger abuse flags at most places (especially from known VPN IP addresses which tend to have a lot of malicious activity originating from them).
This isn’t to defend them - it seems very odd to immediately permanently suspend accounts like that!
I don’t really think “serverless” is supposed to mean “no servers are involved in hosting your code”. It really is meant to mean that you/your engineers do not need to worry about servers, because as you’ve said, you don’t need to worry about them. So it’s _as if_ there were no servers, to you.
IMO, any singular word applied to a software engineering concept wouldn’t paint the full picture. But using AWS services as an example, I don’t think it’s intentionally misleading, or of malicious origin, to describe Lambda & Fargate as “serverless”.
To be clear, they did “damage” was to our bottom line. Most sites don’t capacity plan for random cliff walls of 2-10x traffic (clearly we should!). We’re scalable enough to handle that traffic after a period, but a) it caused intermittent periods of low availability (costing us money because we didn’t generate income the way we normally do) and b) cost us money from scaling all our services up.
It’s just selfish. If you’re going to take the product of other people’s work in a manner they don’t consent to, at least do it in a way that doesn’t cost them twice over.
My point was more that we can accept with, and live with, scrapers but expect some minimal level of consideration if you’re going to abuse our very expensively gathered dataset. Sending us 10x daily traffic so you can scrape quicker than the fair usage policy of our API allows is just… poor etiquette? Unkind? Not really sure how to phrase it. I’m exhausted after multiple 18 hours days trying to keep our website online for the public.
Having spent a week battling a particularly inconsiderate scraping attempt, I’m quite unsurprised by the juvenile tone and fairly glib approach to the ethics of bots/scraping presented by the piece.
For the site I work for, about 20-30% of our monthly hosting costs go towards servicing bot/scraping traffic. We’ve generally priced this into the cost of doing business, as we’ve prioritised making our site as freely accessible as possible.
But after this week, where some amateur did real damage to us with a ham-fisted attempt to scrape too much too quickly, we’re forced to degrade the experience for ALL users by introducing captchas and other techniques we’d really rather not.