Managed Applications are a powerful way to deploy your custom software into the customer’s tenant. Until now, there was one deployment model for Managed Applications that allowed a publisher to administer the solution within the application within the Managed Resource Group (MRG). New capabilities have been added enabling different deployment and management models for Managed Applications.
This article explains the different deployment architectures and gives you the information you need to choose one based on your needs and those of your customers.
Traditional deployment architecture
Until recently, the deployment and maintenance model for Managed Applications called for the publisher to access the solution in the MRG and perform any needed administration or ongoing management.
This “publisher managed” architecture is the right fit for many ISVs selling their solution in the Azure Marketplace, but is limiting for customers who don’t want the ISV performing maintenance in their tenant. Further, not all ISVs want to be responsible for ongoing maintenance like patching VMs or backing up databases.
New deployment architectures address these limitations and expand the options available to ISVs and customers using Managed Applications.
New deployment architectures
The pre-existing model of publisher-managed Managed Application solutions is still available, but there are now three more deployment architectures available to you. The list of deployment models is as follows.
Publisher managed application
This is the same deployment model that has been available for Managed Applications since they were introduced. In this model, customers purchase the Managed Application solution and the ISV uses the Azure portal’s Managed Application Center tool to access the resources in the MRG for ongoing maintenance or administration.
The customer still has read access to the deployed resources in the MRG such that they can see the components of the solution, but may not change anything. For example, if a solution contains a VM, the customer cannot start and stop the VM, but the ISV could.
Choose this deployment architecture when the ISV wants to protect their IP and be responsible for ongoing maintenance of the solution.
Customer managed application
In this deployment model, a customer has full access to the MRG and its resources. When a Managed Application is customer managed, the ISV cannot access the MRG at all. The customer has owner or contributor access to all items in the MRG, but the Managed Application itself doesn’t even appear in Managed Application Center for the ISV, thereby preventing the ISV from accessing the solution.
Choose this deployment architecture when the ISV chooses to enable the customer to maintain the solution and avoid ongoing maintenance activities and their associated costs.
In the open application deployment architecture, both customers and ISVs have full access to the solution. This option is available for situations in which the ISV wants to share maintenance activities with the customer.
This model is appropriate when the ISV is not concerned about protecting their IP and don’t mind the customer has full access to the MRG and the resources within it. For example, in this mode the customer could start and stop a deployed VM unlike in our previous publisher managed example.
Locked applications are read only to the customer, and are not accessible by the ISV at all. Just like in a customer managed architecture, the Managed Application does not appear in the ISVs Managed Application Center service in the Azure portal. This means the publisher has no access to the MRG.
Customers maintain read access to the resources in the MRG as most customers want to see the services running on their tenants.
In this model, the application is unmanaged. Like a customer managed application, publishers are disallowed from accessing the MRG. A locked application is unmanaged by design.
Visualizing the deployment architectures
The following image illustrates the different deployment modes.
Configuring in Partner Center
The deployment modes for a Managed Application are configured on the Technical Configuration tab of each plan within an offer. This allows different plans in an offer to have different deployment architectures.
There are two settings in the plan’s technical configuration enabling choices to the ISV for defining the deployment architecture.
In each plan’s technical configuration in Partner Center, ISVs can designate their own access to the solution via the Publisher Management option as show below.
Enabling this access allows publishers to access the MRG. Disabling management access makes the solution completely invisible to the ISV. On the plan’s technical configuration, the ISV can select customer access modes via the Customer Access option as shown below.
As you can see by the message shown inside Partner Center, there are implications for using metered billing in the different Customer Access modes. The specifics of metered billing are beyond the scope of this article. More information on metered billing from Managed Applications can be found in my earlier article on the topic.
New deployment architectures for Managed Applications enable different management models for both ISVs and customers. Introducing these options offers choices to the ISV when creating their marketplace offers, enabling different management models for their deployed Managed Applications.