3 ms·

> It literally just works In only a few toy scenarios! For example: Azure SQL Database, Managed Instance, and SQL 2022 in a VM all support AAD authentication

> It literally just works In only a few toy scenarios! For example: Azure SQL Database, Managed Instance, and SQL 2022 in a VM all support AAD authentication. Okay. SQL 2022 supports only user accounts and not managed identities. SQL Managed Instance requires an additional global AAD permission button to be pressed post-deployment or it won’t work. This can’t be templated. The first two have AAD permissions controlled via their template (ARM API) — but only exactly one full admin group. All other permissions must be assigned via T-SQL. Again, can’t be templated via ARM. (Microsoft has better data plane RBAC for random open source products than their own flagship database!) User access audit logs are easily collected for Azure SQL Database, needs manual T-SQL for SQL MI and is missing in action for SQL Server. This is just SQL, which now at least supports user-assigned managed identities… if you include the latest SQL client which has a breaking namespace change and hence won’t work with third-party code. It also drags in 500 MB of dependencies. Lightweight functions, you were saying? Hmmm… Anyway, I got fed up with the whole thing when I tried hooking up a Storage Account in the same way and discovered that it didn’t support UMSI in connection strings — you need two code paths for dev-time and runtime! Up until recently the whole thing was an unstable mess. Authentication would take 5 seconds in some scenarios and then wouldn’t cache the tickets properly. It turns out that every Azure team is implementing the whole thing separately! It’s not at all like traditional AD where the platform provides the authentication functions in a uniform way and apps can just pick up the ambient tokens. No, in this shiny new world every service does RBAC differently, connection strings differently, auditing differently, caching, config, and on and on. All of this within 100% Microsoft products and services. It’s a poorly thought out mess.

bob1029 3y ago
> In only a few toy scenarios! I am not sure I understand. The "toys" you describe are all we need to get the job done. Azure SQL Hyperscale, Azure Functions C#/v4, AAD, another region for DR (SQL geo replica + Function App x2) and that's about it... Why do we want to make this hard? If you want to try to force the square peg through the round hole, I get it. It's going to be a clusterfuck as you describe. But, I decided we were going to get completely trashed on the Microsoft kool-aid so we don't have to worry about 3rd party clients and other non-happy-path integrations. I click 1 big dumb button in my Visual Studio client and some time later my app is running on a live URL completely managed by Microsoft. This is a pretty good life. I don't have patience for things like I used to. Leadership & investors are not giving me much to work with these days.
- jiggawatts 3y ago
  > square peg through the round hole ... Why do we want to make this hard? I work in a job where I don't get to make product decisions, I just have to "make it work" on the cloud. Despite this, the only applications I've worked on in the last three years have all been ASP.NET web apps with SQL databases. Even with this pretty vanilla combo, I found hundreds of bugs or interoperability issues in Azure. These aren't esoteric things, they're not round pegs and square holes. These are Microsoft-shaped pegs that ought to fit into Microsoft-shaped holes. Things get messy the instant you step off the "tech demo MVP" happy path. Like I said: Third-party code that talks to SQL, Storage Accounts, or SQL databases other than the one of their two Platform-as-a-Service offerings! Even if you stick to just functions and Azure SQL Databases, there are still limitations and issues. Templating is painful or impossible. Data-plane RBAC is missing in action. Etc... If you're a solo developer working a tiny app deployed with click-ops to a single region, then I suppose it is "fine". For everyone else, it's not so fine...

bob1029 3y ago

> In only a few toy scenarios! I am not sure I understand. The "toys" you describe are all we need to get the job done. Azure SQL Hyperscale, Azure Functions C#/v4, AAD, another region for DR (SQL geo replica + Function App x2) and that's about it... Why do we want to make this hard? If you want to try to force the square peg through the round hole, I get it. It's going to be a clusterfuck as you describe. But, I decided we were going to get completely trashed on the Microsoft kool-aid so we don't have to worry about 3rd party clients and other non-happy-path integrations. I click 1 big dumb button in my Visual Studio client and some time later my app is running on a live URL completely managed by Microsoft. This is a pretty good life. I don't have patience for things like I used to. Leadership & investors are not giving me much to work with these days.

jiggawatts 3y ago
> square peg through the round hole ... Why do we want to make this hard? I work in a job where I don't get to make product decisions, I just have to "make it work" on the cloud. Despite this, the only applications I've worked on in the last three years have all been ASP.NET web apps with SQL databases. Even with this pretty vanilla combo, I found hundreds of bugs or interoperability issues in Azure. These aren't esoteric things, they're not round pegs and square holes. These are Microsoft-shaped pegs that ought to fit into Microsoft-shaped holes. Things get messy the instant you step off the "tech demo MVP" happy path. Like I said: Third-party code that talks to SQL, Storage Accounts, or SQL databases other than the one of their two Platform-as-a-Service offerings! Even if you stick to just functions and Azure SQL Databases, there are still limitations and issues. Templating is painful or impossible. Data-plane RBAC is missing in action. Etc... If you're a solo developer working a tiny app deployed with click-ops to a single region, then I suppose it is "fine". For everyone else, it's not so fine...