In addition to what the others have written, let's not forget the abstraction of storage and networking. Docker let's you present virtual network interfaces to the software, so the config can be the same everywhere. Every container thinks it's listening on port 3000 on its local host. Without Docker, if you want to run 2 or 3 different bits of software on the same host but listening on different ports, that's has to be part of the software config, not external to the software config. With Docker, every instance of the software inside a container can have the same network config, but external to the container you can do whatever network jiggery-pokery you want to line it up.
Likewise Docker volumes and mount points. The software gets an abstracted filesystem that's actually a "volume". Could be a chunk of local filesystem, an NFS mount, whatever. The software doesn't need to know. It just acts like it's the only software on the "system" and writes to any path that it can find. It can't corrupt any other containers also running on the same host by writing global configuration files or making "system-wide" changes because those system wide changes are contained to the container.
Docker also abstracts a ton of sysadmin/deployment type tasks. I have 1 container of app X running on host A. There's a load spike. I want a second instance of app X running on host B. Ok. Load spike is over, I want to get rid of the instance of app X on host B. Docker makes this kind of dynamic deployment/destruction automatable via APIs and there's huge libraries of software out there to do it. I don't know about the .NET packaging/deployment (NuGet, etc.) and whether that's as easily done.
It sounds like you know a lot about .NET, and I know very little. So it's entirely possible that Microsoft has solved the network and storage abstraction in ways I don't know about. In that case, if you don't NEED Docker, because you have this homogenous environment and effective isolation controls built into it, be comfortable in your lack of need.
I’m typing this on an iPhone 8+ because I’m unwilling to move to faceid only. So I admit I’m coming from a position of ignorance, having never relied on faceid day to day. Part of my reluctance is that I want to authenticate when I choose to. FaceID feels like I can’t do that. Hold my device in front of my face and it will unlock whether I want it to or not. I’m already staring at the phone when an app asks to authenticate. I like the fact that I have to deliberately move my thumb to the reader to authenticate.
I have had to unlock my phone while driving so my partner can get something. Her finger isn’t authorised. :) I can touch my phone and unlock it without looking away from the road. FaceID seems badly suited for the car, unless you just have your phone unlocked all the time or CarPlay.
How much you wanna bet it's nothing nefarious? Just the performance of the forums is so terrible that the extra traffic was clobbering them and they just deleted the post to get load back under control. :)
Reading this snippet in the article about leader election in distributed systems: "Each item of data still belongs to a single leader, but the whole system contains many leaders.". It could not be a clearer statement of Conway's law[0]. Orgs ship their org chart. The technical architecture at AWS absolutely reflects the org chart and business organisation of Amazon generally.
The people desperate to use IPv4 are not AWS themselves. AWS doesn't buy stuff just to have it. They buy it because customers are using it. AWS customers are moving stuff out of their data centres and don't know how to use serverless, load balancers, dynamic cloud capabilities (like spinning down instances when they aren't in use) and so on. Customers are doing lift-and-shift in vast volumes and they're doing it in the only way they know how.
If you believe that cloud providers just copy your data willy-nilly from place to place, you've obviously never dealt with the cloud before. They go to great pains to earn trust by making sure that your data only lives where you put it. You haven't read any of their documentation, you haven't looked into the independent, third-party audits that verify that their documentation is true. You know what region you put your data in, and the cloud provider doesn't surrepititiously copy places without your knowledge. If your approach to risk management is that cloud providers will do the opposite of what they write in documentation and that the third party auditors are lying or not actually seeing what really happens, you'll never be able to use any equipment that you don't personally manage. You'd never be able to use a managed data centre or a so-called "private cloud" either, because all these providers could just tell you one thing and do another.
Then there's the simple fact that it doesn't scale to copy everybody's data to the US. When you're as big as one of these major cloud providers, that's just simply not possible.
The Scroll article itself has no named author. If this article was true, why wouldn't the author put their name to it? The answer to that is because this is just a rip-off of a different article written by a different author, who did put their name to it. Microsoft has issued a formal clarification on this particular article. https://news.microsoft.com/en-in/setting-the-record-straight...
Read more carefully before you worry. You're not reading facts and making sober decisions. You're reading a headline that isn't supported by the article it is attached to. You have to go read up on facts and understand the cloud before you can make sweeping judgements like this. You know very little about how the cloud works, so you worry a bit. That's prudent. But the way to cure ignorance is not to avoid the subject. The way to cure ignorance is to read.
This is an idiotic article. Read carefully before you decide what you think.
1. Scroll anonymously reposted a poorly-written article from DNA. (First link in first sentence)
2. Look at the facts quoted in the article. "Banks know that Microsoft MIGHT be sharing". (emphasis mine) What does the title say? It doesn't say what the banks say. Banks know that it COULD happen under some circumstances. The article title omits any sense of uncertainty and says it definitely already has happened. Those are different.
3. The article quotes a number of 3,036 requests for "Indian customers in the US" which means NOT PEOPLE IN INDIA. And certainly not customers of RBI in India (which the article would have you believe). Indian nationals living in the US have a different expectation with respect to US law enforcement.
This was wild conjecture, un-sourced anonymous writing, and it was poorly fact-checked. It looks like the author saw a single document that they didn't understand. Then they wrote a bunch of conspiracy theory bogey-man nonsense that has nothing to do with the document they saw.
Stick to the topic, and don't go meta. Leave out things like "when I was preparing to submit this talk proposal" or "as I was creating the slides for this talk." Talk about the topic, don't talk about the talking.
Know the language and culture of your audience. If it's a mixture of people who don't speak English (or whatever language) as their first language, take care to avoid colourful metaphors that make sense to a native speaker but which confuse non-native speakers. I've confused people with expressions like "inside baseball" or reference to "Goldilocks values" (not too much, not too little). Good metaphors are valuable. Metaphors that depend on too much cultural context are unhelpful.
Likewise Docker volumes and mount points. The software gets an abstracted filesystem that's actually a "volume". Could be a chunk of local filesystem, an NFS mount, whatever. The software doesn't need to know. It just acts like it's the only software on the "system" and writes to any path that it can find. It can't corrupt any other containers also running on the same host by writing global configuration files or making "system-wide" changes because those system wide changes are contained to the container.
Docker also abstracts a ton of sysadmin/deployment type tasks. I have 1 container of app X running on host A. There's a load spike. I want a second instance of app X running on host B. Ok. Load spike is over, I want to get rid of the instance of app X on host B. Docker makes this kind of dynamic deployment/destruction automatable via APIs and there's huge libraries of software out there to do it. I don't know about the .NET packaging/deployment (NuGet, etc.) and whether that's as easily done.
It sounds like you know a lot about .NET, and I know very little. So it's entirely possible that Microsoft has solved the network and storage abstraction in ways I don't know about. In that case, if you don't NEED Docker, because you have this homogenous environment and effective isolation controls built into it, be comfortable in your lack of need.