> The business case is that someone else is doing the infrastructure management for you.
Many business people believe that moving to cloud can reduce the headcount needed for managing the infra, but that is usually not what's happening. You will still need more or less the same amount of people to patch the OS and configure the networking, but with a slightly different skill set -- instead of Cisco IOS commands, they now need to deal with AWS transit gateway.
Every data center I worked with offers on-site remote hands that will rack new servers or replace hard drives or PSUs for you. There are also third-party companies that offers this service. Redundant power and air conditioning are the responsibility of the colocation provider and those are covered by the SLA. Those data centres do have generators on-site.
That said, configuring you top-of-rack switch is usually not covered by the co-location contract. This need to be done by a network engineer, usually the same person that would manage VPCs.
> Section 6.1.3.2 of [RFC1123] is updated: All general-purpose DNS implementations MUST support both UDP and TCP transport.
For stub resolvers like the ones provided by glibc and musl:
> Stub resolver implementations (e.g., an operating system's DNS resolution library) MUST support TCP since to do otherwise would limit the interoperability between their own clients and upstream servers.
A market has two sides: supply and demand. The assumptions only involves the supply side but we do not know much about demand, so would be hard to give a full picture of how the market would look like.
That's said, if we have ample supply of any given commodity/occupation, then the market will greatly shaped by what the demands look like.
We should have a linter for issue/PR comments that flag out sentences starting with “You are...”. The scope of the comments should be limited to the issue or code and must never extend to the person that bring it up.
You might have uploaded your name and face willingly to Facebook in order to set up your profile, but without proper safeguards and legislation, the data might be used to train an AI model to use your face to identify your relations with other user using photos, which they also willingly upload, to power features such as people you might know and of course, advertising. The data might also be sold or transferred to third-parities like Cambridge Analytica for political advertising or government agencies for "national security" -- all without your explicit consent.
It is true that it does not matter if a piece of data is stored in either side of the Atlantic, but this is not a engineering problem about data locality and latency. As someone who spent months working on a global distributed GDPR-compliance identity store, my life will be much easier if the problem can simply be solved by paying a slightly higher inter-region data transfer fee.
Unfortunately, US and EU here are not referring to cloud regions, but as jurisdictions because different laws on data protection apply. None of us likes this kind of complexity, but "power move" would be an overly-simplified abstraction of this problem.
I only said this "proxy" need to be dual-stacked. This "proxy" or "gateway" or whatever refers to the public facing part of the their stack -- if they don't have a public facing part then they don't have this problem.
The "proxy" can outsourced or manged on-perm and does not have to be shared with anyone. This "proxy" may or may not be a L7 proxy that only understands HTTP.
I run my own proxy for HTTP(S), SSH, SMTP and DNS. It took me about 1 hr to set it up. Only 4 IPv4 address are used for my whole stack, the rest are all IPv6-only.
This would make sense if (and only if) all other things are equal. In reality it is slightly more complicated than that.
The second-largest chain, Jumbo, will happily accept my AMEX credit card. In many cases, the groceries are even (slightly) cheaper there. That's why it has been my preferred place to do the groceries for years. But I find my self goes to ah much more often than Jumbo recently, simply because I moved and there is one right across the street.
As a general rule, ah (and bol.com) do not accept credit cards (or debit cards that need to go through the credit card network). This can be independently verified on Google Maps if you look for those 1-star reviews.
There are a small handful ah branches (see below) in tourist spots that does accept credit cards. In all other places, you should see posters apparently made by the staff that puts red crosses on Visa, MasterCard and AMEX logos near the entrance and/or the checkout kassa.
> In sommige winkels kan je met je creditcard of buitenlandse pre-paid debetkaart betalen: de winkels op Schiphol, veel stationswinkels, de winkel achter het paleis op de Dam in Amsterdam en de winkel aan de Weteringschans in Amsterdam. Bij alle andere winkels kan dit niet.
I live in the Netherlands and biggest supermarket chain here, Albert Heijn, is strictly Mastro-only. This is not a problem for the locals, but you will find angry reviews left by tourists on pretty much every ah branch in Amsterdam on Google Maps.
I am also skeptical about their claim for taking care of tax management.
I had contacted Paddle for UK VAT invoice for our Setapp for Teams subscription and their incompetence is phenomenon: first they used an EU VAT number (this is post-Brexit), then they fixed the VAT number but the amounts are in the wrong currency, one of the support agents even get my name wrong once...
Most importantly, I should not even have to ask for a VAT invoice in the first place.