Are you using Azure App service deployment slots? Is it really zero downtime?
The answer might vary, but my response is both “yes” and “no.” It’s “yes” if you have a SPA (Single Page Application). However, if you’re dealing with a complex project that has interdependencies among multiple web applications or services, the answer is “no.”
In my case, we had multiple web services with interdependencies. Our product was a single instance for each customer. Additionally, there were post-deployment jobs to run. Azure App Service takes more time to perform a swap over direct deployment, and the warm-up time for slots can vary. The Infrastructure as Code (IaC) also becomes increasingly complex.
Our product consisted of around five core components, and we had a database along with custom configurations (not AppSettings or connection strings) that couldn’t be moved to App Service due to legacy support. To update the components, we first had to update the database, which would temporarily bring down the service endpoint. Unfortunately, all workarounds failed to achieve true “zero downtime,” and the custom configurations introduced additional downtimes.
we were using the staged slots for around 2+ years and we realized the following on slots based deployments
Overhead and Management:
While deployment slots provide flexibility, managing multiple slots can introduce additional overhead. Each slot may require separate DNS records, network rules, SSL certificates, and other configurations.
If you choose separate app services instead of slots, you avoid this overhead but lose some benefits like seamless swapping and prewarming.Complexity in Pipelines:
When using deployment slots in DevOps pipelines, be cautious about swapping across environments. Improper use can lead to unexpected results.
It’s essential to understand the behavior of slots during swaps and ensure proper testing to avoid downtime and longer deployments3.Increased Cost\Time\IaC complexity.
Stage slots demand unique resources apart from prod but that will end up in increasing cost and deployment time.
Considering all these challenges, we decided not to use slots. As a result, we observed a drastic increase in deployment speed by 4X, and we reduced costs by almost 1.2X. Instead, we now create a new test infrastructure, test the product, and deploy directly to production
Top comments (0)