codingfreaks.de
Azure 2025 | codingfreaks
Excerpt
I think Microsoft made a lot of promises they did not keep up with and started to diverge from their community if you like. There was a time when they announced quality initiatives internally for instance. Reading about this seems funny today. Instead of developing products seriously on their Azure platform some of them are poorly designed and maintained. A few did not even see serious updates for longer periods. Instead the focus is almost always shifting with the potential of revenue for Microsoft. … - BigData tools which are now completely overhauled - The fail in providing managed blockchain products - Starting Bicep and not pushing it seriously - Trying to convince people that Bastion is the way to interact with your VMs. - Connecting Windows with Azure no matter what. - Bringing in MariaDB and MySQL and leave it at poor states - Not fixing serious issues with the backplane like stupid naming conventions and network issues - Creating marketing-driven default settings of products like GRS storage in the portal. - The focus on low-code-solutions like Function Apps. This list could go on for some time. The current pig is obviously AI. We experience network issues, backplane overloads and highly unstable APIs all over the place. It is not proven but plausible to assume scaling issues in data canters as a cause. … A good example of the ill-headed Azure development if you ask me is the time Microsoft gives those issues at the Build conference and similar events in the past years. One of the baddest ideas they hat IMHO is the “.NET Aspire” program. I’ll come to that later a little bit but I guess that if, lets say, a Aspire guy meets one responsible for governance in customer clouds at the cafeteria those will get into physical fighting probably. The contradiction between those 2 areas alone is so huge that I watch this unfolding shaking my head in disbelief. … What you really should do is to ask: “What is the VM doing?“. Instead of spreading the so often bad architectures and now run them in Azure you should finally get rid of this and rebuild it natively in Azure. Azure can be so nice, cost-effective and still usable if you follow things like the Cloud Adaption Framework. But this demands planning, knowledge and first and foremost a certain culture in a company. … If you don’t use Azure as your VM-outsourcer it is basically empty if you don’t hire devs to put workload in it. Turns out, most devs hate Azure to the guts because it demands a lot of tedious steps for them (Entra ID and other stuff). This is not because Azure is bad but because nothing is prepped in a way a developer would expect it to be. This is where now AWS and GCP being heavily promoted at universities can shine. … ## Inversion of control There is this pattern in programming where you do certain things differently like instantiating objects. This IoC I think should be applied to Azure environments as well. What a lot of customers do (because they even get advised in that direction by MS employees) is to basically lock down their Tenant and whitelist allowed resources, operations and so on. This is not giving you the potentials of Azure as a developer. You will still get silly processes to follow and in the end your time-to-market might be even lower. Also it denies trial-and-error approaches and this limits the experience that you gain in Azure. … Just the product “Azure Function App” is something I can’t appreciate. It can run arbitrary code inside of something that is maintained by operators who are not able to check what it is doing. So what do you expect to happen? Some now say that you could use pipelines to check those functions. For a lot of devs the reason to use them was not to have to bother about those things and have something that can be changed directly in the portal. You wouldn’t believe how many times I saw somebody copy-pasting important code from VS code to the function app in the portal and happily hit save-buttons. … ## Conclusion Azure is complicated in detail because it has to be. Microsoft has to give us control and power over those things and with that comes a lot of work and responsibility. Azure is a cloud made for developers. Enabling those people is crucial to really gain benefits from it. The one thing it requires is the readiness for mind-shifts. It starts with the amount of time I give my technicians and ends with the open-mindedness of admins and devs. So: Business as usual.
Related Pain Points
Azure API instability and network backplane issues
8Azure experiences widespread unstable APIs, network issues, and backplane overloads particularly affecting AI services. Issues include resource naming convention problems and potential datacenter scaling limitations, with instability increasing across the platform.
Azure Function Apps lack security and operational oversight
7Azure Function Apps allow arbitrary code execution maintained by operators without visibility into what the code does. The portal-based code editing encourages insecure practices like copy-pasting production code directly into the portal, and the original developer value proposition of not managing infrastructure is compromised by pipeline requirements.
Half-baked and inconsistent service quality
6Many AWS services are incomplete or poorly designed (e.g., SageMaker Studio vs regular SageMaker). The vast product portfolio means quality varies significantly and some products are not production-ready.
Overly restrictive tenant governance prevents developer productivity
6Many organizations lock down Azure tenants with whitelist-based resource and operation controls on administrator advice. This prevents developers from gaining practical Azure experience through trial-and-error, increases time-to-market, and reduces the platform's developer benefits despite Azure being designed as a developer-first cloud.