I'm not the person you're responding to, but also think NULLS DISTINCT makes sense in many cases. NULLs often represent missing data. Imagine storing a customer's address and the street name is NULL. If several customers have a street=null, it doesn't mean that they have the same street. So from a data perspective, it makes sense to treat these unknown values as distinct.
For filtering and aggregation I still welcome the change, as it makes sense in many cases to treat them as not distinct.
You've clearly been working with the right people. I constantly get screenshots of error messages (not even the text of the traceback so that I could copy it) with questions about what that means. It takes some training for people to be able to read tracebacks correctly, especially if they have no other programming experience.
I always wondered what latency requirements they must have in a distribution center that has to route packages dynamically and make those routing decisions within milliseconds. Surely there must be a lot of logic at the distribution center, they probably are their own data centers. Or can you really have 10+ms latency for each decision?
They could get back to colocation. I think even AWS & Co don't own all physical buildings, they also rent parts of data centers in some locations. You don't need to own real estate or a physical building to run servers.
With airplanes especially, optimal utilization is key. Routing millions of packages a day through such a complex network around weather and other incidents while keeping SLAs is simply astounding.
They're not really competing on price but on quality. They make the most money with super urgent deliveries. If they offer later pick up times or earlier guaranteed deliveries, customers will be happy to pay more. And their IT system is crucial for that.
That's like running against cost limits in AWS. If no money is spent, you won't have the flexibility. But it's not the fault of private clouds, they can be as flexible as a public cloud.
I've seen that with a core banking system. A decade later it's still running, with many patches in other systems to avoid its shortcomings. there's still no viable plan for migration.
Just because you don't invest in a system doesn't mean it becomes obsolete.
> The hardest part about the above isn't the tech, it is the internal norms that you're fighting against (e.g. staff have had terminal access for tens of years, and know the commands to get their work done by memory).
I have sympathy for those people. Not a fan of AS/400, but working in those terminals is incredibly fast once you know all shortcuts. Modern GUIs, especially using all those fancy frameworks, are much slower. If the alternative to the terminal is a new web application, it's extremely likely that it'll be harder to work with.
That's how you do it. You don't stick with on-prem but just build your own cloud. At that size, AWS won't really buy hardware much cheaper than you. And while you can't build every cloud product that AWS has, the most popular ones are open source anyway.
They have up to three racks for a flight simulator? I would've never thought they're that complex. Do they need that much computing power or is it other devices that are needed?
No one says you can't have both. An on-prem data center for reliable workloads and cloud to try out new stuff and products or to get short-term capacity. But in the end, 95%+ of servers in your data center will run 24/7 and for years on the same software. No need to outsource that.
I'm confused about the first data center in 2008. Surely they had data centers before that, or were they outsourced before? Automatic routing of deliveries has been the standard for many decades, I'm sure the code on their mainframes is much older than just 14 years.
Fedex isn't building their own vehicles, same as they wouldn't build their own servers. But going cloud is more like outsourcing all transport activities to other logistics companies. No one says they have to do every part of DC ops themselves, but outsourcing everything and using proprietary products makes them very vulnerable.
For a logistics company, the IT system is the differentiator. Reliably routing and tracking packages to maximize utilization of trucks and planes allows them to be cheaper and faster. That all depends on both hardware and software. So I'd definitely think that running their own systems should be a given.
As any cloud, you should always have spare capacity on-prem. Spinning up a VM on-prem doesn't have to be slower than in the Cloud. At this scale, you're just your own cloud provider.
> Clearly FedEx is saving $400M/year while also funding Bezo's trips to space, no?
I wonder how much they'd save if they rebuilt their infrastructure with own DCs. There are huge savings in decommissioning mainframes, switching to free software and automating more. At the scale of Fedex, I don't think they'll spend much more on hardware and ops than AWS.
Another reason why not everyone should use the cloud. Sure, the cloud can be as secure as on-prem or even safer in many cases. But it's just so easy to keep on-prem data safe by just not connecting it to the outside world. If no server can be accessed from anywhere but the premise, leaks like these just can't happen. A key won't help you unless you can break into the police building.
Access just based on credentials seems so wrong anyway. There should always be whitelisted IPs for sensitive stuff like that.
I think it's never right to pull the lever, unless there aren't any humans on the other track. I'd sacrifice an animal or objects, but people should never be sacrificed for other people, unless they actively choose to.
It's not that unrealistic. Imagine driving a car and a kid runs onto the street. You can swerve onto the sidewalk but there are people walking there you'd hit. The question if you'd take action to save someone to (potentially) kill someone else is interesting. And it has been discussed in the context of self driving vehicles.
But from all I remember, the outcome always was that an AI should never actively make a decision to sacrifice someone. And that's also how I view the trolley problem. Actively making a decision feels worse for me, even if fewer people die in the end.
I'd say that for many large companies, Jira is better than the alterntive of having multiple systems that need to be kept in sync. Steering any large company will be a mess, no software will ever make that easy. And any software designed to be that flexible will end up being slow eventually.