Loosely, think of Azure as Microsoft's answers to AWS, et al. Heavy reliance on LDAP where applicable, but also key-based auth with REST. Nothing too terribly different from other platforms when you're just the consumer/client (the mobile app).

It's like nothing else from a management and configuration perspective. I don't have very much experience on the management and config side, but just enough that I walked away shaking my head thinking "wow, anything that can make Google API setup seem simple... sheesh."

But if you're not involved as systems management, being an azure consumer is dead simple.

We currently have small Tomcat 8 web app that exchanges data with the mobile clients using simple Java servlets and saves data from the mobile apps in a database. Plus it writes out XML and PDF files on the server and has to manage unstructured data (photo, video, PDF, etc content). So I guess I'm looking for guidance on whether to have Azure host the existing Tomcat web app in container/AKS (), re-write the server code to be ASP.NET (or something), or perhaps some other solution. It also has to scale way bigger than we were planning for (from dozens of simultaneous users to hundreds, perhaps even over a thousand).

The only thing that's scale-questionable in what you describe is the PDF generation. That might be something to offload to a set of worker machines with an F5 instance (or whatever round-robinner du jour is the family favorite) doling out the duties. XML generation can get pretty resourcey, but redoing the biz-logic in .NET gets you a lot of stuff - including all that - for free, and pretty well optimized. Especially in later .NET versions. I used to use subclassed XMLDocument class objects for a lot of stuff, adding whatever biz logic needed to be added and handing them around as functional data containers, either to other native .NET processes, or anything that could read and write XML, with factories on the (re)intake, and natural serialization handling non-native stuff. Worked a charm. Scale of that order won't be a problem on one or a couple of even middle-weight servers.

I assume the PDF stuff isn't worth caching since it's dynamic, one-off data each time?

Might be worth proofing out. I believe the MS stuff is (finally) native to the platform, and should be fast and clean, without extra dependencies. I admit, it's been a while since I've hammered on a lot of .NET code in my every day(~4 years). I got really spoiled coding REST APIs in Node, and writing Swift and Flutter code for mobile. I still do a bit of it, but just not my every day stuff any more.

FWIW, if you want to entertain some Node coding, there are several PDF generation libraries that run in Node, and from what I've seen they're pretty clean and tight, memory wise, and in at least one case they're spawned out to a new process that's monitored by the library you call in your Node code. But if you're constricted to Azure, I think you already have a real clean road ahead of you with the .NET stuff.