4 ms·

My wife worked at Travelport in the late 2010s. They ran a lot of Delta’s systems but Delta of course has their own infrastructure. Some of the history of Delta

My wife worked at Travelport in the late 2010s. They ran a lot of Delta’s systems but Delta of course has their own infrastructure. Some of the history of Delta’s teams is intertwined with the companies that were merged together to form Travelport. From what I could tell from her talking about work it wasn’t particularly far off the state of the art at the time. They had a fancy new AWS hire to help lead them into AWS from mainframes. That didn’t fully work out but they still had a bunch of containerized .Net and Java running. Mostly this whole back and forth argument sounds like a ball of pain with everyone upset at each other and very little of it mattering unless lawsuits are filed. If Delta is using Windows at IBM it doesn’t make them “ancient.”

38 2y ago
> containerized .Net and Java Gross. If that's the alternative I would rather stick with mainframes. People forget that it's perfectly fine and even better to just run code directly in many cases.
- Yasuraka 2y ago
  Containers are not VMs, code runs directly on metal and performance is pretty-much-native. https://web.archive.org/web/20150218172511/http://domino.research.ibm.com:80/library/cyberdig.nsf/papers/0929052195DD819C85257D2300681E7B/$File/rc25482.pdf https://web.archive.org/web/20150218172511/http://domino.res... This is from 2015, and it improved from there (e.g. the daemon-less podman matured, NAT is no longer needed). That said, I'd happily take even the performance impact of VMs and order a few more servers, if it means that I won't have to deal with dotnet/java runtimes being shared by multiple applications.
  - 38 2y ago
    If you need a container, your stack (dotnet/java) sucks. That's why Amazon deprecated the Go container, cause it's just not needed
    - consteval 2y ago
      Yes those langs have large runtimes. But even for compiled native languages, if you have a lot of dependencies you will require containers sooner or later. Go doesn't really have the huge dynamic-linking ecosystem. But, if you do and then project X and project Y diverge on versions... you have a problem. Also containers can automate deployment easier. Like the line from bare server -> full deployment is much faster if you use containers.

38 2y ago

> containerized .Net and Java Gross. If that's the alternative I would rather stick with mainframes. People forget that it's perfectly fine and even better to just run code directly in many cases.

Yasuraka 2y ago
Containers are not VMs, code runs directly on metal and performance is pretty-much-native. https://web.archive.org/web/20150218172511/http://domino.research.ibm.com:80/library/cyberdig.nsf/papers/0929052195DD819C85257D2300681E7B/$File/rc25482.pdf https://web.archive.org/web/20150218172511/http://domino.res... This is from 2015, and it improved from there (e.g. the daemon-less podman matured, NAT is no longer needed). That said, I'd happily take even the performance impact of VMs and order a few more servers, if it means that I won't have to deal with dotnet/java runtimes being shared by multiple applications.
- 38 2y ago
  If you need a container, your stack (dotnet/java) sucks. That's why Amazon deprecated the Go container, cause it's just not needed
  - consteval 2y ago
    Yes those langs have large runtimes. But even for compiled native languages, if you have a lot of dependencies you will require containers sooner or later. Go doesn't really have the huge dynamic-linking ecosystem. But, if you do and then project X and project Y diverge on versions... you have a problem. Also containers can automate deployment easier. Like the line from bare server -> full deployment is much faster if you use containers.