How to Structure Azure Applications for Production and Development Environments?

Question

Hi everyone,

We are working on implementing the authorization and permissions process in our application and have encountered a question where we need some guidance.

Our project includes two applications:

1. A web application (an analytics dashboard)
2. An Outlook Taskpane application (with a frontend repository)

Currently, in Azure, we have the following applications set up:

• Frontend Dashboard PRODUCTION
• Backend PRODUCTION
• Frontend Taskpane PRODUCTION
• Frontend Taskpane DEVELOPMENT

We are considering adding two more applications: Backend DEVELOPMENT and Frontend Dashboard DEVELOPMENT. However, after discussions with our DevOps team, we started wondering if it’s possible to manage with just two applications: one for PRODUCTION and one for DEVELOPMENT.

Questions:

1. What are the best practices in structuring applications in Azure for production and development environments?
2. Should each service or microservice have its own Azure application, or is it more efficient to use a shared application for both frontend and backend services?

After studying this forum, I found that using a separate Azure application for each project/microservice environment is often recommended, as it allows better control and easier diagnosis of potential issues in the future.

Additionally, I’d appreciate clarification on the difference between the scopes defined in manifest.xml and those in authConfig.ts. Both seem to manage permissions, but what is the specific distinction in how they are applied?

Thank you in advance for any advice or recommendations!Hi everyone,

We are working on implementing the authorization and permissions process in our application and have encountered a question where we need some guidance.

Our project includes two applications:

1. A web application (an analytics dashboard)
2. An Outlook Taskpane application (with a frontend repository)

Currently, in Azure, we have the following applications set up:

• Frontend Dashboard PRODUCTION
• Backend PRODUCTION
• Frontend Taskpane PRODUCTION
• Frontend Taskpane DEVELOPMENT

We are considering adding two more applications: Backend DEVELOPMENT and Frontend Dashboard DEVELOPMENT. However, after discussions with our DevOps team, we started wondering if it’s possible to manage with just two applications: one for PRODUCTION and one for DEVELOPMENT.

Questions:

1. What are the best practices in structuring applications in Azure for production and development environments?
2. Should each service or microservice have its own Azure application, or is it more efficient to use a shared application for both frontend and backend services?

After studying this forum, I found that using a separate Azure application for each project/microservice environment is often recommended, as it allows better control and easier diagnosis of potential issues in the future.

Thank you in advance for any advice or recommendations!

P.S.
Additionally, I’d appreciate clarification on the difference between the scopes defined in manifest.xml and those in authConfig.ts. Both seem to manage permissions, but what is the specific distinction in how they are applied?

Answer 1

Hi, As per my colleagues comment we need more for the second half of the question.

To the first half I can try and answer generally

Questions:

1. What are the best practices in structuring applications in Azure for production and development environments?
2. Should each service or microservice have its own Azure application, or is it more efficient to use a shared application for both frontend and backend services?

You have more or less answered your own question here :-D

After studying this forum, I found that using a separate Azure application for each project/microservice environment is often recommended, as it allows better control and easier diagnosis of potential issues in the future.

So at a minimum (and as you suggest) you need a PROD and NON-PROD environment - this is obvious because you need somewhere to stage/test new functionality or fixes to existing functionality without impacting the users of your application - until you are sure the changes are stable enough to "ship" (or deploy).

How many resources you need and how you distribute your applications depends on the resources you are using . For example the answer differs somewhat between Container Apps or K8S/AKS and App Service

But generally you're spot on with your comments. Think about the following things in terms of your two projects:
*Will my application need to be updated independently and how "closely coupled" are my applications or components? (The correct answer should be they are not closely coupled)

Example: Your taskpane and front end sound like separate logical components, possibly each with it's own repo and backlog? If this is true then you should host them independently because then from a devops perspective you can ship changes to one without impacting the other

*Will my apps or components need to be scaled independently ?

Example: Perhaps you will receive far more user load on your web app than your task plane app? If this is true then you would want to host them independently to be able to set vertical scale , and horizontal scale rules. Doing this also means you dont run into any "noisy neighbour" issues if one app is busier than the other (no competition for resources)

*Do I need to independently host the backend and frontend components?

That somewhat depends - in this case it's probable that the backends are closely coupled to the front ends given (from what you say) the task pane backend is for the task pane app alone? If this is true then the above advice may apply. It could be you can update the front end of task pane independently to the backend . It could be that you need more resources in one than the other. If true then independent hosting will be helpful. But, it could be that they're fine to be hosted together and indeed this could save money as well as making devops part a bit simpler.

This isnt really the right forum to go into depth - for that you really need proper consultation but hopefully the comments reenforce that you're thinking along the right lines