Hi sure! I wont be able to respond until later, but PM away!

A thing that bit us a couple of times early on, is that if your app just throws a 500, dapr will retry the message - that caused some infinite retry loops early on in our journey. So global exception handlers in your apps are probably a must. You have to design failure modes really carefully.

Apart from that we're super-happy. Especially testability of apps are a lot easier, as you can simply test "given this rest input, assert x and y" - we're a python shop so we use "pytest-httpserver" to "fake" the dapr sidecar during testing. That works super-well.

For us, no. It's done what we needed. I would say that dapr is more tuned towards smaller quick-to-process messages than heavier ones, as there's some coordination between the sidecar and the main app, esp during shutdown. THere's some old issues around that on gh, f.ex github.com/dapr/dapr/is...

yup correct. No issues at all, dapr sidecars are very lightweight. We haven't seen anything weird. Important to deploy the sidecar injector in HA mode, so you're guaranteed that sidecar injectction actually occurs.

we've been using dapr for 3-4 years now. It used to have some rough edges, but those are mostly ironed out. It's a good tool.

Tailscale funnel is the perfect use-case for this. 3-minute (free) setup and you'll be up and running.

TLDR: So far I like #Azure more than I expected to.

...without having to resort to iam role assumption mess. One identity if you're a human, one identity if yo're a workload workload. No fuss. It's how it should be.

6. Not having to deal with multi-account roles and tribulations is a blessing. Azure and GCP definetely got it right, AWS got it wrong. And even if you do choose to split your cloud stuff into multiple Azure subscriptions, it's still easy to design cross-sub access...

5. Provisioning stuff in Azure with an IaC tool is more complex than AWS due to the complexity of the objects. Some attributes are required although there's only a single valid value for that attribute. AWS objects are generally "flatter" and less esoteric.

4. Documentation is still weak. Azure have this tendency to document the obvious stuff you kindof already understand, but leave out the difficult stuff - the information you're really looking for.

3. Azure's Kubernetes service is good - I can't find any area where it's noticeably worse than EKS. It's really apparent that they have access to some really smart Kubernetes folks like @brendandburns.bsky.social

2. Azure's control plane is still more unstable than AWS. Permissions changes take a while to propagate (in AWS that happens almost instantaneous), setting up a thing might fail with a mysterious error but succeed when retried.

1. A lot is better than what it used to be in #Azure. A common auth model similar to IAM Roles now exists, albeit a bit simpler. I'm not sure that's a bad thing, #AWS IAM is quite complex. So giving a pod access to a storage bucket is now mostly a non-issue.