Two App Service Plan option for Umbraco Cloud websites to separate Umbraco backoffice from the Front-end website for scalability #959
NurhakKaya
started this conversation in
Ideas
Replies: 1 comment
-
|
Some may argue that this could double costs for clients using the Umbraco Cloud website. However, this approach allows us to reduce Azure resources for the back-office site, as it is accessed by some users (fewer than 100 in most cases) and services. We can also limit resources for the front-end website by implementing auto-scaling, which adjusts the number of instances based on things like server requests and CPU usage. This strategy can address many performance issues effectively and may not be overly costly. Most clients are likely to accept some extra expenses if the solution is scalable and future-proof. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Currently, an Umbraco Cloud project operates on a single App Service within one App Service Plan. This setup means that both the Umbraco backoffice and the front-end websites are hosted on one single server, using the same URL, and we cannot scale out the front-end website instances because we are limited to one instance for the Umbraco backoffice.
With a two App Service Plan option, you can run your Umbraco backoffice on one App Service (in its own App Service Plan) and your front-end Umbraco website on another App Service (in a separate App Service Plan). This architecture opens up many opportunities, such as blocking access to the Umbraco backoffice from the front-end URL, enhancing security for accessing the Umbraco backoffice, and creating scaling rules for the front-end App Service Plan to accommodate increased traffic and usage.
Taking it a step further, you could introduce Failover Groups for Umbraco Cloud. This setup would allow the front-end website to run on two different servers located in two regions. If one region goes down, the other would continue to serve the website. In all cases, you would deploy the same code with only minor configuration differences, using a single Umbraco database.
I discuss some of these opportunities in my blog article, which will help more agencies consider Umbraco Cloud for their clients, as this approach is already being adopted by several agencies managing their Umbraco CMS (not Umbraco Cloud) websites.
For more details, you can read the article here: How to Build Scalable, Secure, and Resilient Umbraco Cloud Solutions.
Beta Was this translation helpful? Give feedback.
All reactions