Does GPC support ipv6 only subnets? Some cursory pokes around I can not tell. (I really only work with AWS). Azure? Any other notable services providers have done this yet? I can not tell if this is long overdue or actually something to take note of.
In Azure, enabling IPv6 in any way is a terrible mistake that will break your IPv4 network.
There is zero benefit to enabling IPv6 in Azure, because they carefully prevent any use of the beneficial features of IPv6 that make it worthwhile over IPv4.
A key purpose of IPv6 is no longer needing NAT to the point that IPv6 implementation typically do not support NAT at all -- so Azure engineers developed their own custom IPv6 NAT to force NAT on all of their IPv6 users.
Another key purpose of IPv6 is the enormous address space, which means you no longer need to carefully "carve up" and manually allocate addresses in a stateful way -- Azure engineers restricted IPv6 public address prefixes to blocks of just 16 addresses. Not /16 or anything like that. No. Sixteen.
To assist migration, IPv6 is designed to be dual stack and coexist side-by-side with IPv4 with no (or minimal) impact. Azure engineers made sure that if you turn it on, wildly unrelated IPv4 features will break. In other subnets. Even other virtual networks! Critical features are masked out, making this a non-starter for practically everybody.
To enable layered systems to be migrated, IPv6 is sufficiently "compatible" with IPv4 to allow the use of relatively simple protocol-translating middle boxes. So you can have IPv6 on the outside and IPv4 on the inside, or vice-versa. Not on Azure! It's only IPv4-to-IPv4 or IPv6-to-IPv6. You can't have both, and you can't translate. PICK ONE, NOW.
It's shameful.
Seriously, if any Microsoft network engineers stumble upon this post, you should feel bad. It's 2021 when I'm writing this, mere days from 2022, and you've utterly failed to even begin to support the transition to IPv6 in the public cloud.
All these things sound to me like their internal network only supports IPV4, and they simply maintain some mapping of which IPV6 address maps to which IPV4 address and they convert packets where needed so the customer sees IPv6 yet all packets flow over the wire as IPv4 with no additional headers (so that MTU doesn't need to be decreased)
To me it feels like the entire thing was engineered with only IPv4 in mind from day one, and a decade into it some customer demanded IPv6 support. So of course, some middle-manager at Microsoft gets assigned the "task" of enabling IPv6, and he dutifully went over to the engineers and asked them to turn it on. Horrified, they tried to explain that it's a ground up re-engineering of their entire network stack, at which point I don't need to have been in the room to play out the conversation that unfolded in that meeting room line by line:
"Just tell me what the minimum set of tasks is to enable IPv6!"
"You don't understand, it's not like turning on a tap! We have to redo all of the infrastructure around networking!"
"Do we need all that? Just tunnel the packets or something!"
"That's not the same thing, that's only supporting IPv6 in a technical sense, it doesn't really mean the same thing as doing it properly, and it won't work long term. It'll have to be ripped out and replaced, but while maintaining backwards compatibility with a jury-rigged IPv6 implementation. It'll be a nightmare!"
"Don't worry about that now, I just need to say that we've enabled IPv6 so I can satisfy this requirement."
"It'll just tick the check box! Nobody will be able to actually use it! Our customers will be confused and support will have to deal with the fallout!"
"Let me deal with that."
Etc, etc...
Translation: I just want my KPIs so that I can get my bonus. I'm quitting before the fallout hits.
GCP has support for IPv6 dual stack in only 4 or so regions: https://cloud.google.com/vpc/docs/vpc#ipv6-regions not only that but enabling IPv6 is not as simple as it is in AWS and requires a lot of manual fiddling with the subnets. Once enabled it does give you a prefix that is automatically assigned to each VM in the subnet which you can use for containers and the like.
I tried a dual-stack vnet in Azure earlier this year, and eventually had to rip IPv6 out of it: flexible Postgres servers couldn't be instantiated into an IPv4-only subnet (yes, IPv4) if the vnet had IPv6 at all. (Worse, attempting to do so caused the API call to create the flexible PG instance to just time out, and it for some odd reason has a two hour timeout that suggests it's a transient internal error & you should retry. So, four hours.) I didn't really expect flexible PG to support IPv6, but that it seemed to poison the support for IPv6 for the rest of the vnet was really, really disappointing.
I consider Clouflare to be the least reliable cloud service provider out there. So many CDN and DNS related outages thanks to poor engineering release practices. Considering those are their bread and butter services I wouldn't ever rely on any of their other services.
It is simply incorrect. We have most of our customers on Cloudflare and the larger customers are on enterprise deals. My only criticism to Cloudflare is simply that it is just not as stellar as some of the more expensive alternatives. It is not a high end service but still the right choice for a lot of sites.
When it happens, it breaks a lot of the internet, but "so many" is stretching it - the entire CF network has only gone down a couple of times in the time I've known about them (~6 years).
They extensively use Cloudflare, other than for voice channels which don't use CF's tcp/udp proxy (to minimize ping, since GCP is usually peered better globally).
Cloudflare user for all my services here. I can't remember any downtime ever outside of the couple times where they got massive press over it (because, like, the whole internet broke)
@sungrokshim, thanks for the input. Wallaram is on my radar. Glad to hear it recommended though.
With your setup (cert-manager + ALB + nginx-ingress) I suppose you are using the private ACM certs? Or does having nginx-ingress in the mix allow you to use certs from other CAs, i.e. letsencrypt?
With a few other other elements (i.e. weather) added to learning model I bet this would be super accurate! Pretty neat. I love finding use at home DIY use cases with commodity hardware, ESP32s ftw.
Hmm, I suppose this is useful for super large orgs? I feel managing the IAM policies around this is pretty much the same level of complexity as managing access to a bastion host to open a ssh tunnel through.
We use GSuite SSO with Context Aware Access and other such policies to gate access to the browser. So that means that we could give out access via CloudShell, and now those commands are gated by those same policies. That's really nice from a security perspective.
In our case, since we do development in a ChromeOS environment, and the browser is relatively isolated from the Linux VM, it also likely prevents classic SSH-hijacking.
It’s an order of magnitude less work to set an IAM policy because that doesn’t require ongoing maintenance commitments. An IAM policy is a one-time setup cost and the limited duration keeps people honest about not accumulating unmanaged local state. It’s also handy for non-administrators to contain a compromise or error - if someone pops a shared system multiple users will be affected.
I tried this product thinking it would be super useful... not the case. Ended up spending a few days total rolling our own internal tools and way happier we did. I love leveraging saas products but this one just fell flat for me. It felt too constraining.
Curious to hear from a real customer of theirs how they are using this service?
Thank you for the comment! Do you mind sharing what exactly you were trying to build and how Retool was too constraining? We'd love to learn which use cases we could be doing better in, so we can improve (even if we're able to convince you to try it again!). Thanks!
Encapsulating HTTP request in Bitcoin transactions? Sounds like the throughput limitations of Bitcoin would make this a super slow decentralized web protocol?
My understanding of their white paper is that they are using Bitcoin transactions (for whatever reason, and quite possibly not a technical one), but actually recording them on the Blockchain is optional.
Nexkey | Full Time | Lead Backend Engineer, Lead Deepstack Engineer | San Mateo, CA & Remote
Nexkey is smarter access for every workspace.
Founded in 2013, Nexkey is a startup based in San Mateo, and is well-funded by Upfront Ventures and K9 Ventures. Nexkey is the combination of hard- and software solutions to simplify access and key management.
Our unique hardware can make any door smart - main doors, meeting rooms, garages, and even file cabinets all connect to the Nexkey platform. Our easy-to-use app and cloud services let office managers control smart keys and unlock doors instantly with their phone. Nexkey improves workplace security while reducing office management costs and forever eliminates the need for physical keys.
This position has a ton of ownership. You own our backend.
Curious where you would consider chart.io to fall in this ecosystem?
I have been using it for its seamless AWS Athena integration to get a handle on load balancer logs when needed. However it is pretty pricey. Would love to move to an open source solution. However my use case feels a little different than what was mentioned above?
In theory you are saving some money for not using a database, redshift is also pricey. Have you considered that? The free solution is python + altair in a jupyter notebook, but you would have to decide if it is worth your time to setup.
