So, we all know how managed solutions vs unmanaged solutions discussions used to be raging a few years ago.
Then Microsoft stepped in to make it clear that managed solutions are recommended for production environments and unmanaged ones are only supposed to be used in development.
This is where things currently stand, and this is what we are all recommending to the clients, but, come to think of it, I would probably want to see more explanations than “it’s better because we say so”.
Unfortunately, looking at the ALM demos, this is how it usually is:
- Managed solutions should be used in production
- Managed solutions can be deleted
- Components in the managed solutions can be locked down
- Managed solutions support layering
I see how the ability to “delete” managed solutions can be important for ISV-s. Although, as soon as we create a dependency in our own solutions on those third-party managed solutions that ability becomes pretty much non-existent.
I also see how it may be useful to lock down some components of the managed solutions, but possibly, it’s an ISV thing, too? I’ve never used it for the internally developed solutions, even for the “core” ones.
Layering, although it’s an interesting concept, is, arguably, one feature that can mess up quite a few things. There is a lot of functionality in Power Platform that had to be implemented around layering to support it better (solution history screen, component layers screen, merging, etc). Just to hypothesize, would not it be easier not to have layering? As in, make everything unmanaged and leave it to the admins/developers to make sure solutions are installed in the right sequence.
I guess the core problem is “merging”, and all that layering is meant to facilitate/resolve merging issues (or, at least, to put some rules around how it’s done). Given that the conflicts are still not getting resolved in the same way it’s done with pro-code, though, I wonder if it would be better/easier to just go with “most recent change wins” approach (which is, basically, “unmanaged”). After all, how often would you actually even try resolving a conflict directly in the XML file when merging in the source control? I would just overwrite in those cases.
So, I wonder, is there someone there who can clearly state the advantages of managed solutions, possibly with good examples, so that we could all say “yes, you nailed it”? Would be great to have this kind of closure to the old question of why should we be actually using managed solutions.
One point top of my head is the ability to “cleanly” introduce new solution versions.
By that, I mean the following:
1. I have solution version 1.0 in PROD
2. I now have a newer version, version 2.0.
3. I can import version 2.0 as a holding solution into PROD. Since it is a holding solution, both versions 1.0 and 2.0 exist in PROD now. (albeit the solution components to remove will also persist at this stage)
4. Users do their testing and are happy with version 2.0, at which point, I apply the solution upgrade.
OR, if case of any issues etc., I delete version 2.0 and this ensures version 1.0 comes back into effect.
Full disclaimer, this was a big win when doing manual deployments.
In the automated CI/CD processes, preference is to restore the entire environment back (at the risk of losing some data)
This could be useful, but this creates a few problems:
– Once the holding solution is removed, your remaining data might get stuck in the inconsistent state (as in, your holding solution had a flow which was updating a field. Now, without that Flow, that field is supposed to have a different value based on the previous version “business logic”)
– I suspect it depends on the client whether this approach is possible. Most of the times, I would probably prefer to UAT as much as possible, then do production deployment, then apply fixes as necessary (if it all goes south somehow, then restore from the backup, but that would be my absolutely last resort). This actually explains why I don’t see big issues with unmanaged – in practice, I rarely use solution-based “rollback”
I’m having the same thoughts about managed vs unmanaged, my problem would be with Microsoft’s “recommendations”. Are they just recommendations or is this going to be the future? Will the unmanaged solutions be discontinued?
I don’t believe they’ll be discontinued, since we need them for development. At the same time, Microsoft has been very consistent lately in recommending managed solutions for production, so, just purely from the support perspective, it might be better to use managed solution in the non-development environments.
There are specific scenarios where the managed concept seems to be more valuable. As mentioned an ISV scenario makes sense because it’s an add-on product. An admin should be able to easily remove such a component without fishing through the customizations to remove pieces manually. Another scenario where managed seems to have benefits is in a more complex system where multiple teams are working on different apps without the same environment. There’s usually a base/global solution and then app targeted for specific use cases. Each of the applications can then be installed and upgraded on their own release cycle.
On the flip side it seems more customers encounter problems with managed solutions. I’ve seen customer lock their system up because of cross dependencies between solutions. One customer accidently imported their managed solutions into their development environment had no backups. It seems I’ve heard more cursing when it comes to managed solutions. In the scheme of things other than the component clean up when upgrading to a new solution version I’m personally having a hard time seeing a significant value. The product team often sights that the components are secured when they are managed as one of the main benefits, but others have argued that system security can also be handled in other ways.
The product team has been pushing the managed concept more in the last few years. When it was first introduced they didn’t say much other than it was good for ISV’s. Now they’re pushing harder for it. When it comes to product team recommendations you have to remember there’s a difference giving advise from the standpoint of a developer of an application versus someone who has to use it in real world scenarios. The practical application of managed solutions seems to be at the least a journey that has elements of danger to be avoided. The thing I find interesting is the fact that after all these years I still haven’t seen a significant and compelling argument with examples of why we should all go managed. Perhaps there are some other motives from the product team to head in this direction, but if so I don’t think they’ve expressed that in an effective way. Until then I think team unmanaged will remain a fairly healthy perspective for many projects.
That’s nicely put:) But, in reality, I’ve had a couple of situations where recommending a more balanced approach would not do me any good in the discussions with new clients, since, after all, Microsoft is clearly recommending managed, and, generally speaking, any new client would prefer to go by what Microsoft is recommending (for various reasons, including presumably better support etc)
I think what also should be considered is there are more than one type of person making the ‘apps’ or config settings. For people who make a living at it, managed doesn’t seem to hold that many advantages and as I have experienced many times, a lot of problems. For the accounting worker given the customization job for the small online instance, managed is probably a good thing. So how each type of system is designed, developed and deployed is going to depend on the situation.
I had one of the new devs mistakenly add a ‘patch managed solution’ to prod, and now there is no way to get rid of it (at least that I’ve found so far) and yes, it almost stopped us from being able to import the real unmanaged solution for deployment.
Overall, I’ve not found a solid reason outside of a ‘product’ that I would use them for.
Hi Alex,
Noted you mentioned the performance considerations and layering. A while back I was curious about just how deep the layering could get (I had a client with 20+ layers of solutions!) So, I did a simple test, deploying hundreds of layers, and posted results if anyone is curious: https://helpfulbit.com/maximum-solution-depth/
If you’ve got a bit, I’d love to chat with you about the technical differences between managed vs unmanaged solutions, how it affects ALM workflows / CLI Usage, etc. I’ll reach out.