3 ms·

> 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

> 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...

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...