Deployment times for config changes have been operating at the sub-5m timeframe for at least two years. It used to take hours (never days) to propagate changes across the server estate, but not anymore. And while we were admittedly late to the DevOps train, we have made up lost ground. We have nearly 100 individual APIs to control almost any aspect of our products. CLIs if you don't want to write to the API. A Sandbox to test config changes locally. The ability to validate OAuth tokens at the Edge, cache GraphQL responses, and throttle and/or quota API traffic on a global basis. Hashtag "legacy CDN."
I'm not talking about Akamai directly, I'm talking about the Azure interface, which is as close to Akamai as most HN commenters are likely to get. Akamai itself is great but the Azure interface makes you (and VZN) look terrible
> Deployment times for config changes have been operating at the sub-5m timeframe for at least two years.
Fastly is sub 5 seconds.
> And while we were admittedly late to the DevOps train, we have made up lost ground.
Not anywhere close. Your cache invalidation takes forever. Ability to assign tag objects does not exist. Engaging "professional services" to make a config change like it is 2002?
> Not anywhere close. Your cache invalidation takes forever. Ability to assign tag objects does not exist. Engaging "professional services" to make a config change like it is 2002?
Akamai also has a fast purge these days, sub 5 seconds as well I believe. Works nicely.
Fast purge only works on certain kind of objects in certain kind of configurations, not to mention the idea of "I would like tom make 20k purge requests in a second via an API" is met with stares.
Interesting. I only have experience with the occasional simple (manual) purge and I could verify the object was invalidated quickly. Can you elaborate on an example config where this goes awry?
Fast purge works with all kinds of site delivery ( and site delivery based ) products. Unlike modern CDNs Akamai other products ( such as for example VOD and media services ) do not live in the same object space and hence are not fast purge compatible.
You would think purging a video stream would be the same as purging a standard site delivery object, after all it the stream is http(s) accessible .m3u8 and a pile of .ts chunks but that's not the case -- in some cases it can take up to one hundred and twenty minutes.
Disclaimer: I work at a company that is both an Akamai and a Fastly client. I worked with Fastly first, then Akamai after. Opinions are my own and not the views of my employer.
There has definitely been a push to catch up, but I wouldn't say you're there yet. The Terraform provider for instance is not up to par with the Fastly one. Having attended an Akamai DevOps workshop not so long ago, there didn't seem to be an easy way to use the CLI tools to configure a property in an idempotent way in a CI/CD pipeline. Maybe things are different now.
Akamai has some advantages for enterprise customers though such as easy assignment of cost using the CP codes. That's very handy. The integration with Let's Encrypt is also very nice.
Fastly delivers in it's simplicity and documentation. Whatever use case you need, you'll most likely find it in their docs and on their blog. Being able to use VCL to configure your caching is in my opinion way easier (and with less limitations) than the Akamai rule tree (even if you don't have previous Varnish experience). Varnish's finite state machine makes it easy to configure and debug any kind of behavior you want. The Akamai rule tree has caused me quite a few 'WTF' moments. It's difficult to debug when something doesn't behave as expected and there's a certain amount of 'black magic' in the behaviors sometimes that makes it difficult to judge what the outcome will be.
The good thing is that both companies have different features and get pushed to incorporate features deemed useful by their customers at one or the other provider.
Deployment times for config changes have been operating at the sub-5m timeframe for at least two years. It used to take hours (never days) to propagate changes across the server estate, but not anymore. And while we were admittedly late to the DevOps train, we have made up lost ground. We have nearly 100 individual APIs to control almost any aspect of our products. CLIs if you don't want to write to the API. A Sandbox to test config changes locally. The ability to validate OAuth tokens at the Edge, cache GraphQL responses, and throttle and/or quota API traffic on a global basis. Hashtag "legacy CDN."
reply