Title gets to the root of the question but I'd like to propose a scenario and the issues I'm running into.
In this scenario we have a series of Domain Controllers that have been deployed by a (very) simple Service Template. It has a single machine tier with minimums, roles, availability groups set. For the most part it works as expected.
It has two things we'd like to "update" however:
1. As this was an early template, its using the generic Machine Tier name "Small_VM - Machine Tier 1". You can how we'd rather it be named something a bit more obvious like "domain controllers".
2. We'd like to add a new Tier. In this case an RODC tier (possibly others).
Changing the number of tiers in a deployment or even just the name of tiers seems to me like something that should be ... well... trivial. But it seems impossible at first glance.
Here's the walls I'm hitting:
Problem 1: renaming a machine tier.
At first glance this seem easy: you have to create and publish a new version of the service template, then apply it to the deployed service (the existing template is locked as read only). So I change the name of the machine tier in question, save the "new" template ... then publish it.
The update status shows up as expected. Good.
When I attempt to apply the template, however, it fails saying it can't find the machine tier in the new template. I need to make sure the tier exists in BOTH templates for it to update ... which forces me to continue to use the name I'm trying to get rid of :/. Well that kind of defeats the purpose ...
To try to be clever, I tried renaming the deployed service group BEFORE applying the template ... only to run into the same problem. No matter what I do the deployment seems to want to compare not only the existing service ... but the original template. I'm not sure why it needs to see the old template ... matching template to service should be enough ... but at any rate ... what am I missing?
Why can't I simply update the name of a machine tier without completely "breaking" service templates? This seems like a big problem unless you think services will remain static ... which is ridiculous.
Problem 2: Adding Machine Tiers
Spin off on the first problem ... lets accept that the original machine tier has to forever have a name of "mistaken name I dont want" ... fine lets add a new tier. SO again, copy the deployed template (locked read only as it's deployed), add the new machine tier ... publish .... apply.
This appears to work great ... except the new machine tiers never show up.
To clarify: If I were to deploy a brand new 3-machine tier service from a template, that new service will show all 3 tiers on deployment, EVEN IF the minimum machine count is set to 0. I can click on any one of them and "scale out". HOwever, if i apply a new template onto an existing deployment ... and that new template includes new machine tiers .... they remain unavailable. I never "see" them in the deployed service that has the new template deployed ... so I can't right-click the tier and select "scale out".
If you combine these two apparent limitations with the fact that you can never "move" a machine from one service template association to another ... then services and templates become horrifically rigid constructs that are best avoided ... it's far better to go no deeper than VM templates (built from various profiles) and just skip service templates ... as they are needlessly rigid and prevent you from ever actually evolving your service which seems rather silly.
So I have to be missing something: how is the service/template model supposed ot work that gives me the control of revisions but the flexibility to actually make changes beyond simple OS patch swaps?