One Year's Notice, Then the Component Is Gone

Cloudflare is taking over the team behind Deno, and the hosted service that goes with it will be shut down in a year. Deno is a runtime for JavaScript, the layer that a good part of modern web software runs on in the first place. A commentary at heise measures the project against what it set out to do, namely independence from one large vendor. You will find the news and how the developer community reads it at LWN as well.

For you as a client, the interesting question is not whether Deno was good technology. It was. The interesting question is what happens when something like that sits deep inside your software and you only hear about it once the shutdown date is already set.

Trouble rarely comes from the big thing

Nobody discontinues your ERP system without you noticing. The dangerous parts are the small components nobody ever talked to you about, because they were a matter of course while the thing was being built. The library that generates your PDF invoices. The service that works through the background jobs overnight. The runtime the customer portal runs on.

Parts like that show up in no proposal unless someone asks for them. And they do not disappear with a bang, they disappear with an email to developers that you never get to see.

Four questions before you sign the contract

You do not need to understand what a runtime is for this. You need four answers in writing.

One. Which third-party components does this stand on, and who is behind them? Ask for a short list of the load-bearing parts, five to ten lines, with one sentence each on who runs the project and how it is funded. A project under a foundation behaves differently from one under a company that has just raised capital.

Two. How deep does the component sit? There is a difference between a library that gets called in three places and a runtime that everything is built on. Ideally the answer is "at this one place, and behind it our own logic starts".

Three. Is there a second thing that does the same job? If the component serves an open standard, there is a replacement. If it serves one vendor's peculiarity, there is a rebuild.

Four. What does getting out cost, roughly, today? Not to the day. The order of magnitude is enough. Two developer days, two weeks or three months are three completely different answers, and every one of them is usable. No answer is the only bad one.

What tells you in a proposal how replaceable something is

You do not need to read any code for this. There are signals you can see in the text.

• Standards are named, not just product names. A PostgreSQL database, S3-compatible file storage, containers per OCI, mail over SMTP. Those are things with more than one provider.
• Between your business logic and the third-party service there is an interface of your own. In the proposal that sounds like one or two extra days of work. It is the place where the swap happens later, instead of being spread across the whole project.
• There are tests for your processes, not just for the integration. If the test checks that an order turns into the right invoice, that check still holds after a change of provider. It is the promise that the same thing comes out after the rebuild.
• The operations question is answered. Where does it run, who maintains it, and how do you get back out.
• It says in which format your data comes out. "Export available" is not enough. An export that another system can read in is the promise.

On operations, by the way, you have three options and not two. You can run it yourself, with your own people. You can rent per head and month. And in between there is the option where third-party software runs on a server that belongs to you, maintained by someone else. That is the category we work in, and it is the reason why a change of provider with us is a move rather than a rescue operation.

One example from our own operation, because you cannot read it anywhere else. The platform for Kunst gegen Bares generates text suggestions per channel with a cloud model. The call for that sits behind an interface of our own, because we expect prices, models and providers to change several times before the way the stage works changes. Publishing goes through an external service, and it will stay that way, because anyone who wants to post on Instagram sends data to Instagram. Replaceable is not the same as in-house.

Who decides whether you rebuild

An end-of-life announcement with a year's notice is not an emergency. It is a date in the calendar. And it is exactly the kind of decision no system should make for you, not even one that otherwise automates well.

The developer delivers the finding and two numbers. What does the rebuild cost now, and what does it cost to wait until the last month. Add one sentence on what happens if you do nothing at all. Sometimes the honest answer is that the part simply keeps running after the shutdown date, because it sits on your own hardware and only stops getting updates. That is a risk, but one you can put a number on.

You are the one who decides. You know whether the season starts in spring, whether a certification is coming up, and whether two weeks of developer time are even free this quarter. The machine can put the list of affected places in front of you in an hour, where a person would need two days. Which of them you touch stays a question with your money and your calendar in it.

And if nobody can tell you today which third-party components are sitting in your software, that is the first task. Not the rebuilding.