When you look at the headers of major websites, you’ll see us. If it has to be performant, secure, scaled worldwide, and always-on, it uses Fastly.

We're a globally edge cloud platform for performance and security, emphasizing open standards, sustainable engineering, and resilience-by-design. We're hiring across compute, security, platform engineering, network and edge protocols, release engineering, network architecture, client services engineering, and more.

Rather than building walled gardens, we co-founded the Bytecode Alliance, heavily upstream our work to open standards, actively author IETF drafts, and power the global infrastructure for open-source Python, Rust, Ruby, OpenStreetMap, and much more.

* The Stack: Rust, C/C++, Go, Javascript, Typescript, WebAssembly (Wasm/WASI), Wasmtime, Cranelift, eBPF/XDP, QUIC, HTTP, TLS, TCP, Varnish/VCL, Linux kernel internals, distributed systems, professional services.

* Apply: https://www.fastly.com/about/careers

Not to completely change the topic, but to add context, the Ruby Central drama that has unfolded over the past few weeks originally began as a brainstorm to raise ~$250k in annual funds.

Regardless of how you, as an individual, might feel about "DEI," imposing onerous political terms on scientific grants harms everyone in the long term.

We'd argue our stance and focus are a bit different. Our stance is -- we help eng teams and the open web with whatever their preference for AI might be.

If you want to go all in and monetize AI traffic or sign an agreement with a foundation model for training, we have tools that can help you do that. If you want to go scorched-earth on AI bots that try to scrape your systems, we can help you do that too.

It's all about helping engineers tasked with tough problems get their jobs done, regardless of whether the flavor of the week is AI or something else.

>Thanks to UC alumnus Luama Mays, JD ’66, for sharing a copy of the declaration with UC Magazine. Mays was a pilot who befriended Armstrong while the former astronaut was teaching at UC and Mays was running an aviation company. Initially Armstrong called him, without even identifying himself, asking for a ride on Mays old "bubble-style" helicopter left over from the Korean War. It was exactly what Armstrong had trained on in preparation for operating the lunar module.

But to your point, the real kicker is the "many sites aren't going to get feedback from the real people they've blocked" since those tools inherently decided that the traffic was not human. You start getting into Westworld "doesn't look like anything to me" territory.

Without going into too much detail, this tracks with the trends in inquiries we're getting from new programs and existing members. A few years ago, the requests were almost exclusively related to performance, uptime, implementing OWASP rules in a WAF, or more generic volumetric impact. Now, AI scraping is increasingly something that FOSS orgs come to us for help with.

Comments URL: https://news.ycombinator.com/item?id=40750360

Points: 39

# Comments: 11

For an enterprise company, there is no data more important or highly valued than the CRM. Also at a mature company, sale motions are already dialed in, and comp plans typically only change 1-2 times a year (more than one change a year is bad for org morale). Large overhauls can be a pain, but they're extremely infrequent and ideally scheduled well in advance.

Once the system is operating and the daily, weekly, monthly, and quarterly cadence reports are dialed in, you just need to make sure the system continues to run, and deal with any special odd projects or reporting requirements from the sales execs you're working with.

Your sale exec partners have every incentive to get their processes right the first time, and rarely change them -- change disrupts any team (not just engineers), only with sales teams, that change results in tightly trackable lost revenue.

Its not "zero work", but it fits the "2 hours of active work, then chill" requirement. You'll have a busier end of quarter, but the first 2-3 weeks of the quarter will either be crickets or greenfield work.

Edit: this role can legitimately be fun too. You're at the nerve center for how the company actually makes money, and you get to have a cross sectional view of all other functions as a result. You'll see "how the sausage is made" but you only have to report on it and build the tracking systems -- you're not on the hook for performance or output. Also, sales people know when they have a good CRM process and are some of the most grateful folks in the world to those who help them. If you do a good job for your users, you'll be getting public shoutouts every day.

A second answer - there are a bunch of bottom-barrel commoditized pipe services. You likely haven't heard of them because they're so generic. They've existed before Cloudflare, and more will be created in the future https://www.citrix.com/products/citrix-intelligent-traffic-m...

The discussion around _quality_ of calories, the mix of macronutrients for performance, etc is an entire separate can of worms.

The industry we obsessively study/studied was hospitality, where service is literally the differentiator between the "pretty good" and the "absolute best in the world," and we've been pretty meticulous about iterating and building upon our service ecosystem (it's way beyond just one team at this point) like one might do with a software product. Most of our customers, from the small ones in the early days to the huge internet juggernauts we've had the privilege to work with use us as the standard to which all other vendors are measured, sometimes quite literally in a very odd way. So, I don't know if we got lucky with some stinker incumbents, or we stumbled on to something completely different, but we've got a good system in place that's built a pretty solid competitive moat.

I guess if folks on the thread are still reading and interested in replicating this at their startups, my advice is: study elite hospitality and restaurants, not tech. I'm very rarely impressed with the service ecosystem in the tech world, though it happens, but I can learn something massive every day from hospitality.

* AWS is bad at customer service, even for their large or premium customers. If you position yourself, and _seriously_ invest in making your company's culture rooted in exceptional customer service, that's a foothold.

* Don't compete on price. This is hard for most tech startups, as pricing is a very difficult thing to do properly, but resist the urge to drop price to compete. You'll never have the scale, the supply chain masterminds, or the financial modeling to compete with AWS on price, so position yourself as a premium or luxury offering and don't be afraid to price accordingly. If you do the first step properly (a deeply rooted culture of service) you'll be able to justify the price.

* AWS has great uptime, but often the actual operating performance of their service isn't that great, especially when you push the products beyond the 80% use case. They know that for the majority of their customer base, best-in-class performance isn't actually business critical (despite how flashy it sounds). However, there is absolutely a market for people who truly need best in class performance, or product flexibility, or some other best-in-class trait (latency, interaction design, etc.). Find who these people are, and optimize for that ruthlessly. This focus, in combination with the culture of exceptional service and positioning your brand as a premium provider, puts you into a completely different market space than AWS.