Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

You setup VNETs with private endpoints and then configure your and the azure DNS to talk together with magic, and you can do what it is you want to do. Then you can use public gateways or front doors for anything facing the public. I’m not a big fan, but it’s not like it wasn’t very complex before. It’s just that now developers are more exposed to the insane mess that is enterprise networking where before it was strictly an ops thing. It’s still mainly an ops thing, which is why I called the DNS setup magic because that’s the part of it I don’t ever touch. Of course you do need to plan ahead, especially if you’re using app services and multiple subscriptions as you can’t share subnets, and also don’t want to run out of IP address space I’d you use app slots.

What I don’t personally get with Azure is why the “default” settings for enterprise isn’t that everything is not on the internet. Then when you need to do something on the internet, you’d need to open up. You’re likely going to need to set up a bunch of things like load balancer a and what not anyway, so the process of putting something on the internet is complicated to begin with, but everything should just be off the internet by default. At least as some Enterprise setting or whatever.

But I guess part of it is that Microsoft sells Azure certifications and need it to be hard. But why would you want to worry about all this complexity in 2023? At least as the default. It’s fine that it’s very customisable.



> What I don’t personally get with Azure is why the “default” settings for enterprise isn’t that everything is not on the internet. Then when you need to do something on the internet, you’d need to open up.

Because every major cloud provider made the mistake of using IPv4 networking for backwards compatibility with their customer's software from the 1990s.[1]

What they should have done is used IPv6 by default, and provided each customer subscription/account with a /56 in each region sharing a common prefix, e.g.: /48.

All of the private networking complexity just evaporates and turns into trivial firewall rules.

The "allow our vnets only" rule becomes a single /48 subnet allow rule. Want to trust a foreign tenant? Add their single /48 prefix and done! No NAT!

Service Endpoints and Private Endpoints are required only because IPv6 RFC1918 private ranges are too small, and hence overlap between customers. Remove the overlap and you remove the need for any kind of tunnelling or SDN magic.

No more split DNS either: the AAAA records are always the same for every name, whether "inside" or "outside" the network. At most, you might need "private records" that resolve only if the request query comes from the customer's /48 prefix.

And on and on...

IPv4 ought to have been an optional compatibility add-on, a side show to secure-by-default IPv6.

[1] Sadly, there's still software being written today that doesn't work with IPv6.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: