[eh_why_not]

> All current China CDN customers must complete the transition to our Partners’ solution by June 30, 2026...

Can anyone here who works in the field shed some light on why it takes a whole 1.5 years for such a change to take effect?

What's involved in a CDN transition that can't be done in, say, 6 months?

[wafflerewire]

My enterprise sized day job is an Akamai customer. Nothing in China directly so we won't be directly impacted.

As a hypothetical, if we got told that we had to switch providers to stay in a region, we'd need to rebuild pipelines, EdgeWorkers, edge caching rules, origin routing configurations and probably more I'm not aware of. Plus testing all of those changes in a non-breaking way across the entire enterprise. Along with all the normal business delivery priorities.

It'd probably take a solid year for us to fully execute it.

[biesnecker]

This. People tend not to realize how sprawling enterprise software stacks tend to be, how many implicit dependencies have to be untangled, etc. Even simple things can take years and complicated things often just don’t get done at all.

[colechristensen]

Yes, dealing with the mess that is your software stack, the mess that is your corporate structure, and the mess that is your change management process means that things a couple dudes in your startup could accomplish in a week would take a year at a crusty enterprise.

[viraptor]

There's also a finance process. Akamai deals mostly with enterprise customers, which means step 1 may be technical validation, but step 2 is negotiating an appropriate contract with another provider, which may take weeks on its own without a clear go/no-go answer in the meantime.

[mihaaly]

Sounds fragile and pretty exposed.

(Also a complete layman here)

[freedomben]

It's actually the opposite. I thought the same thing before working in big enterprise though so I definitely understand how you could think that.

In reality everything takes 10x longer because things are done in a very thorough way and typically with significant redundancy (high availability). The code bases are typically shite and personally I'd rather eat nails than work on them, but they are reasonably well tested and changes are typically done very conservatively. Big enterprise devs are also really good at not breaking production. As much as I detest that environment, I do think startups in general could learn a great deal about not breaking production from the big enterprise people.

[mihaaly]

What I meant to be dependent on a single essential service that much with that much difficulty to overcome. Smells like lots of trust and hope (of things will stay as they are for long) put into the architecture. It is nice there is a workaround, and there is a will for workaround, in this situation for instance.

[n144q]

No, quite the opposite. Big companies likely also have other big(ger) companies as partners/customers, all of which want stableness and see things keep working. Therefore companies need careful planning, execution and testing to ensure there is minimal disruption.

Startups and a certain company can move fast and break things. But not everyone can do this.

[remus]

I don't think it's particularly fragile. Big systems have big dependencies, and moving those dependencies takes time if you want to minimise risk.

[jpollock]

Vendor validation alone can take months, and that's before you start the technical process of migrating.

This is a company who is in front of your business, do you trust them?

I expect a lot of businesses will take the opportunity to send the contract out for tender.

[dogma1138]

It’s the difference between all hands on deck for 6 months and a reasonable pace over 18 months.

If you are just running a single website with DNS fronting that’s not an issue.

But large customers tend to have more advanced connectivity on L3/4 and asymmetric routing.

Then there is the CDN part itself are you only using the basic auto caching? That’s not a problem but if you manually manage it then all that needs to be converted as well and there is no guarantee that the partner API would be compatible or even have the same functionality as your current CDN.

[Aissen]

It's specifically because Akamai wants to preserve its reputation amongst enterprise customers paying $$$ that it's giving such a big delay. And I can predict it won't be enough for many.

[freedomben]

No doubt there be a lot of companies who don't finish until nearly the end. Barring legal reasons, I'm guessing there will actually be an extension because enough corps won't be ready at that point. Also would expect Akamai to offer extended support beyond that date (for a significant cost) on a customer by customer basis.

[inkyoto]

Because Akamai is substantially more than a CDN (arguably, CDN is now a smaller – albeit not small – part of their business): it is also certificate management, WAF, web app/API protection, IAM, edge DNS, edge workers, complex CDN rules, analytics and a whole bunch of other stuff.

Enterprise customers also typically and mostly use Akamai in non-CDN scenarios so they will have a hard time migrating off it if a need be, especially if they have invested heavily in Akamai.

[donavanm]

CDNs are much more than dumb http1.1 compliant content caches these days. And every CDN has a huge number of integrations and functionality. All of which have a different impleme tation and behavior for different providers. Its probably a good analog to an infrastructure (“cloud”) migration. And even harder to test, validate, and switch the actual service provider as they _are_ “the front end.”

[pfraze]

Also consider that every company has their existing roadmap. Getting the work scheduled can be difficult.

[pyb]

Anything less would be throwing your customers under the bus.

Of course there are well known companies out there closing services with a only couple months notice ; but that's not an example to follow.