1) Slots are a great feature but using them in production we found it was risky in terms of sharing the same resources on the app service. Often times the app service memory and cpu would spike during deployments and sometimes impacting the production app.
2) The cost of using App Service in a micro-services architecture was incredibly expensive. You essentially have to create an app service plan / micro service, which isn't cheap.
3) We had issues with app service where it was closing socket connections for high volume I/O. After several months with MS engineers we ended up having to replace out entire HTTP client code across all of our services and request MS to increase the number of active TCP connections in our subscription.
4) The load balancer doesn't restart or remove a service out of the pool if it fails. Nor can you restart the specific service manually. You end up having to run two separate app service clusters when this happens.
All in all its a hacky solution and doesnt even compare to AWS offerings.
I am a SRE from Argentina who moved to The Netherlands and is constantly learning and willing to help others learn.
Find my posts in English and Spanish!!
Jamie, I use web apps in production with a prety decent load, seems you might have an edge case but I can give my modest opinion on the points you mention:
1) Slots should not run code constantly but is true that when you deploy code to them or directly to the app, there is an spike in the CPU usage to 100% for a couple seconds (2 or 3), I experience those as well, true.
2) This is cost effective only if you have more than an app/microservice running in the same app service plan, but I also think in case of real microservice infrastructure, app services are not the best, I would go to AKS instead.
3) Yes, I heard of this problem before, socket connections getting killed randmly when high IO usage, I never faced those personally but I had read that previously.
4) Sadly, this is true in some cases, not long ago I had one instance failing and one working fine and the load balancer was still routing traffice to the faulty one, the thing is that the problem was in the app and not in the infrastructure so for Azure everything "was just fine". In "Diagnose and solve problems" you do have the functionality to restart instances one by one, this is something I learned during that incident.
I hope some of this is of any use to you or anyone else.
We were topping out at around 60 req/sec per app service.
Also try putting an app service n a vnet without having to pay their insane fees for ASE.
I give a lot of credit to MS for investing in Azure, but often I feel they push products onto organizations that haven't been battle tested, leaving their customers to find all the pitfalls.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Azure app service is garbage in high volume production scenarios.
Interesting - do you have any specifics on those limitations?
Sure thing. Here are my experiences.
1) Slots are a great feature but using them in production we found it was risky in terms of sharing the same resources on the app service. Often times the app service memory and cpu would spike during deployments and sometimes impacting the production app.
2) The cost of using App Service in a micro-services architecture was incredibly expensive. You essentially have to create an app service plan / micro service, which isn't cheap.
3) We had issues with app service where it was closing socket connections for high volume I/O. After several months with MS engineers we ended up having to replace out entire HTTP client code across all of our services and request MS to increase the number of active TCP connections in our subscription.
4) The load balancer doesn't restart or remove a service out of the pool if it fails. Nor can you restart the specific service manually. You end up having to run two separate app service clusters when this happens.
All in all its a hacky solution and doesnt even compare to AWS offerings.
Jamie, I use web apps in production with a prety decent load, seems you might have an edge case but I can give my modest opinion on the points you mention:
1) Slots should not run code constantly but is true that when you deploy code to them or directly to the app, there is an spike in the CPU usage to 100% for a couple seconds (2 or 3), I experience those as well, true.
2) This is cost effective only if you have more than an app/microservice running in the same app service plan, but I also think in case of real microservice infrastructure, app services are not the best, I would go to AKS instead.
3) Yes, I heard of this problem before, socket connections getting killed randmly when high IO usage, I never faced those personally but I had read that previously.
4) Sadly, this is true in some cases, not long ago I had one instance failing and one working fine and the load balancer was still routing traffice to the faulty one, the thing is that the problem was in the app and not in the infrastructure so for Azure everything "was just fine". In "Diagnose and solve problems" you do have the functionality to restart instances one by one, this is something I learned during that incident.
I hope some of this is of any use to you or anyone else.
We were topping out at around 60 req/sec per app service.
Also try putting an app service n a vnet without having to pay their insane fees for ASE.
I give a lot of credit to MS for investing in Azure, but often I feel they push products onto organizations that haven't been battle tested, leaving their customers to find all the pitfalls.