> It...handles 50,000 transactions per second with sub-100ms latency on hardware that costs a fraction of an equivalent cloud footprint. It has been doing this for 60 years.
There is a parody youtube video in which one delusional pro-blockchain speaker is talking about how he wants his food to be put on blockchain which was the audio part, the video part was showing how a no-name China restaurant is using oil from sewers to cook food.
It is interesting to think how AI will potentially change the dynamics back to this from general purpose software.
In a world where implementation is free, will we see a return to built for purpose systems like this where we define the inputs and outputs desired and AI builds it from the ground up, completely for purpose?
Interesting to note right at the start of the article that they sat on a plane next to each other in 1953 but the formal partnership between AA and IBM was not till 1959 - 6 years later! The article makes it look like all this happened magically fast but in reality a reminder that things take time!
>> is almost mythological. In 1953, C.R. Smith, president of American Airlines, was seated next to R. Blair Smith, an IBM salesman, on a cross-country flight. By the time they landed, the outline of a solution had been sketched. IBM and American Airlines entered a formal development partnership in 1959.
edit: oh and then the actual system didn't actually go live another 5 years later - in 1964. Over a decade after the two of them sat next to each other.
Reminder to myself when my potential customers don't sign the deal 5 minutes after my pitch!
ITA Software integrated with the mainframe network, and was acquired by Google.
An exec made a public quote that they couldn't have done it if they hadn't used Lisp.
(Today, the programming language landscape is somewhat more powerful. Rust got some metaprogramming features informed by Lisps, for example, and the team might've been able to slog through that.)
SABRE, is a reminder that things that are well designed just work.
How many banks and ERP's, how many accounting systems are still running COBOL scripts? (A lot).
Think about modern web infrastructure and how we deploy...
cpu -> hypervisor -> vm -> container -> run time -> library code -> your code
Do we really need to stack all these turtles (abstractions) just to get instructions to a CPU?
Every one of those layers has offshoots to other abstractions, tools and functionality that only adds to the complexity and convolution. Languages like Rust and Go compiling down to an executable are a step, revisiting how we deploy (the container layer) is probably on the table next... The use case for "serverless" is there (and edge compute), but the costs are still backwards because the software hasn't caught up yet.
>TPF is not modern. It would fail every architectural review a contemporary engineering team would apply to it. It also handles 50,000 transactions per second with sub-100ms latency on hardware that costs a fraction of an equivalent cloud footprint. It has been doing this for 60 years.
What kind of review would it fail? Sounds like it's pretty well designed to me.
Interesting they went from 90 minute manual booking time to microseconds. I’m unsure of what the landscape was really like before Unix and such, maybe this was just how software was and everything was a bespoke ordeal. But, it makes me wonder if something less fast could have been “better”. As in, faster to build or easier to maintain/improve, something where we still weren’t talking about wrestling with legacy software that runs the world, those kinds of things.
Even 1 second transaction speed sounds slow today but if it’s replacing a 90 minute manual process I’d rather have that solution now than a microsecond fast solution that takes 5-10 years.
This wasn't the first electronic reservation system. It was preceded by the Magnetronic Reservisor, custom built for American Airlines by Teleregister. It didn't use general-purpose computers. It had magnetic drums and remote terminals, but it was not general purpose.
Teleregister built a range of such special-purpose systems, for several airlines, railroads, and air traffic control. General purpose CPUs were both too expensive and too slow for these jobs in the early 1950s. Using a general purpose computer for everything didn't really happen until the minicomputer era in the mid-1970s. SABRE had to wait until general-purpose computers got better.
It's interesting that transaction processing operating systems died out. Tandem's OS worked that way. But the
run transaction program once and flush it approach is almost dead. Except, amusingly, for CGI programs, which are true use-once transaction programs, with an inefficient implementation.
Fitness for purpose beats fashionable architecture" — this matches something I've seen in automotive. Systems that would fail every modern review but have been running correctly for longer than most of the team has been alive. Looking forward to Part 2 on the PNR.
15 comments
[ 6.0 ms ] story [ 34.0 ms ] threadEat that, Bitcoin.
https://en.wikipedia.org/wiki/Gutter_oil
In a world where implementation is free, will we see a return to built for purpose systems like this where we define the inputs and outputs desired and AI builds it from the ground up, completely for purpose?
>> is almost mythological. In 1953, C.R. Smith, president of American Airlines, was seated next to R. Blair Smith, an IBM salesman, on a cross-country flight. By the time they landed, the outline of a solution had been sketched. IBM and American Airlines entered a formal development partnership in 1959.
edit: oh and then the actual system didn't actually go live another 5 years later - in 1964. Over a decade after the two of them sat next to each other.
Reminder to myself when my potential customers don't sign the deal 5 minutes after my pitch!
Closed the tab.
An exec made a public quote that they couldn't have done it if they hadn't used Lisp.
(Today, the programming language landscape is somewhat more powerful. Rust got some metaprogramming features informed by Lisps, for example, and the team might've been able to slog through that.)
How many banks and ERP's, how many accounting systems are still running COBOL scripts? (A lot).
Think about modern web infrastructure and how we deploy...
cpu -> hypervisor -> vm -> container -> run time -> library code -> your code
Do we really need to stack all these turtles (abstractions) just to get instructions to a CPU?
Every one of those layers has offshoots to other abstractions, tools and functionality that only adds to the complexity and convolution. Languages like Rust and Go compiling down to an executable are a step, revisiting how we deploy (the container layer) is probably on the table next... The use case for "serverless" is there (and edge compute), but the costs are still backwards because the software hasn't caught up yet.
What kind of review would it fail? Sounds like it's pretty well designed to me.
Even 1 second transaction speed sounds slow today but if it’s replacing a 90 minute manual process I’d rather have that solution now than a microsecond fast solution that takes 5-10 years.
Teleregister built a range of such special-purpose systems, for several airlines, railroads, and air traffic control. General purpose CPUs were both too expensive and too slow for these jobs in the early 1950s. Using a general purpose computer for everything didn't really happen until the minicomputer era in the mid-1970s. SABRE had to wait until general-purpose computers got better.
It's interesting that transaction processing operating systems died out. Tandem's OS worked that way. But the run transaction program once and flush it approach is almost dead. Except, amusingly, for CGI programs, which are true use-once transaction programs, with an inefficient implementation.
[1] https://www.youtube.com/watch?v=F4d-OFDs1hY
[2] https://s3data.computerhistory.org/brochures/teleregister.sp...