In 1995 I Helped Build Internet Banking. There Was No DevOps.
A system that handles other people's money cannot go down. That was as true in 1995 as it is now. What has changed is everything around it. The tooling, the words, the speed. What has not changed is the part that actually keeps a system running when it has to.
I was at Atos Origin, then still BSO, and got seconded to Digital Equipment. Digital Equipment held the contract to deliver a portal system to ABN AMRO: direct B2C banking online. View your accounts, place payment orders, manage an investment portfolio. In 1995 that was new. Most people had never seen their bank account on a screen at home.
A team of about twelve built it, with the composition shifting over time. It had to run 24/7 and it handled real money. The portal we wrote ran on a DEC VAX in the machine room, sitting between the customer and the IBM mainframes of what we called the back office. The mainframes did the heavy lifting and fed us batches. The VAX was, in effect, a cache between the customer and the big systems. The bar for "working" was not "the demo runs". The bar was "a customer can place an investment order at any hour and it processes correctly". Prices move. A dropped order or a delayed one was not a bug ticket. It was someone's money. The contract allowed sixteen hours of unplanned downtime per year. Sixteen, for the whole year.
We held that bar without a single tool that a team today would consider basic.
How you kept a system up in 1995
There was no deployment pipeline, and nobody had a role called DevOps. What there was, instead, was layers of people. First-line support sat at the bank and handled customer questions during office hours. Second-line was an in-house team at ABN AMRO, on standby around the clock. They fixed what they could in the running system, and they were the ones who actually rolled our updates onto production. We were the development team at Digital. We built and tested each update on our own environment and handed over a tested version. We did not touch production ourselves.
We were also third-line. When second-line hit something they could not solve, the chain came to us, and at the end of that chain was the consignatiedienst, the on-call duty. One person carried it for a full week. When the pager went off, you called back and tried to talk it through. If you could not fix it on the phone, you had to be physically present in Amstelveen, where the systems ran, within half an hour. Not dial in. Get in the car and drive. If it was bad enough, you could ring teammates out of bed.
There was no auto-recovery. When something fell over at night, it did not heal itself and page a dashboard. It paged a person, and that person was on the road by the time most monitoring tools today would have finished sending the first alert. The sixteen-hour number was real, and the thing standing between that number and a breach was a tired engineer who had agreed to be reachable, and reachable meant present.
There was no observability stack either. You knew what the system was doing because you had built it and you read the logs yourself. The whole picture of how it ran lived partly in the code and partly in the heads of the twelve people who wrote it.
None of this was heroic at the time. It was just the job. You held the line with attention, layered responsibility, and a willingness to drive to Amstelveen at three in the morning, because there was nothing else to hold it with.
How you keep a system up now
The tooling caught up, and then some.
A release now goes out through a pipeline. Code is reviewed, tested automatically, deployed by a machine that does the same steps the same way every time, and rolled back with one command if the new version misbehaves. The careful handover between a development team and a separate team that rolls to production still happens, but the steps that used to depend on a person doing them right are now done by a machine that does them the same way every time.
Recovery is built in. Health checks, automatic restarts, redundancy. A node falling over at night is often handled before anyone wakes up, let alone before anyone gets in a car. The pager still exists, but it goes off less, and when it does there is a dashboard telling you what happened instead of a cold log file and a half-hour drive to Amstelveen.
You can see the system. Structured logging, metrics, traces. You do not have to hold the whole picture in your head, because the system tells you what it is doing. I build this way daily, with AI-assisted development on top, which writes a lot of the plumbing that used to eat the afternoon.
New beats old. I am not nostalgic about doing deployments by hand. The modern stack is better in every measurable way, and I would not go back.
The part that did not change
Here is what twenty-five years of better tooling did not replace.
The pipeline does not decide what "correct" means for an investment order. The health check does not know which failures are the ones that cost a customer money. The observability stack shows you everything, which means it shows you nothing until someone has decided what is worth watching. AI-assisted development writes the deployment script in seconds, and it will write a confident, plausible one that quietly skips the case you needed it to handle.
Every one of those tools removes manual work. None of them removes the judgement. Someone still has to know that a banking system's real requirement is not "stays up" but "processes the right order correctly, every time, even under load, even at night". Someone has to decide what the system must never get wrong, and design so it cannot. The 1995 version of me did that with a pager and a half-hour radius around Amstelveen. The 2026 version does it with a pipeline and a dashboard. The deciding is the same work.
That is the through-line under thirty years of this. Tools change what is cheap. They do not change what is hard. The hard part has always been knowing what "working" actually means for this particular system, and refusing to ship until it does. In 1995 the discipline was visible because it was all you had. Now the tooling hides it, which is the real risk. It is easy to mistake a green pipeline for a system that works.
A banking portal in 1995 taught me the difference between a thing that runs and a thing you can trust with someone's money. The tools that tell me a system is healthy have improved beyond recognition. The question of whether it actually is has not moved at all.
Kort samengevat: in 1995 hielp ik bij Atos Origin, gedetacheerd naar Digital Equipment, een van de eerste internetbankierportalen in Nederland bouwen voor ABN AMRO. Rekeningen inzien, betaalopdrachten, een beleggingsportaal. Het draaide 24/7 op een DEC VAX en verwerkte echt geld. Die VAX stond als een soort cache tussen de klant en de IBM mainframes van de backoffice, die het zware werk deden en ons batches voerden. Contractueel mocht er maar zestien uur ongeplande downtime per jaar zijn. Er was geen DevOps, geen CI/CD, geen pipeline. In plaats daarvan lagen lijnen support: eerste lijn bij de bank, tweede lijn 24x7 in-house bij ABN AMRO die onze updates op productie uitrolde, en wij als ontwikkelteam bij Digital die geteste updates opleverden. Wij waren ook derde lijn. Wie consignatiedienst had, een week achter elkaar, moest bij een storing terugbellen en desnoods binnen een half uur fysiek in Amstelveen staan waar de systemen draaiden. Niet inbellen, maar rijden. De moderne stack is op elk meetbaar punt beter, en ik wil niet terug. Maar het deel dat ertoe doet is niet veranderd: een pipeline bepaalt niet wat "correct" betekent voor een beleggingsopdracht, een health check weet niet welke storing een klant geld kost, en AI-augmented development schrijft moeiteloos een plausibel script dat net het geval overslaat dat je nodig had. Gereedschap verandert wat goedkoop is, niet wat moeilijk is. Het moeilijke is altijd weten wat "werkt" echt betekent voor dit systeem, en niet opleveren tot het zover is. In 1995 was die discipline zichtbaar omdat het al was wat je had. Nu verbergt het gereedschap het, en dat is het echte risico: een groene pipeline aanzien voor een systeem dat werkt.
Jan Keijzer is owner of Imperial Automation and a freelance Senior Software Engineer. He builds products from zero for founders who have an idea but no technical partner. Python, FastAPI, LLM workflows, AI-augmented development. PhD Reactor Physics, TU Delft.