Blueprints - Feature add to redeploy a single component of a blueprint

At the moment you can only deploy a Blueprint in its entirety. It would be very handy to be able to redeploy a single component of the Blueprint, possibly as an option from the Apps → Instances → Actions button

Example/Use case(s):
What if the Blueprint has 3 web servers behind a load balancer, an application server or 2 and a DB cluster and 1 web server develops a problem. Instead of deploying the entire app, you might want to only destroy and redeploy that 1 web server. In this example, things could be fixed without any downtime as traffic would be directed through the remaining 2 web servers while the 3rd gets rebuilt.

Hello @Stephan!

I think there are two ways to handle this currently.

Allow Existing Instances

If you have multiple instances added to your Blueprint for each tier, that is the Web tier has multiple instances defined, you can configure the instance in the Blueprint to “Allow Existing Instances”, which would let you add instances to a deployed App later (then delete the broken):

Example of adding an instance to the App after it is deployed:

Scale Factor

The other option is Scale Factor, which may also do what you are looking for. It might take some changing of your Blueprint to utilize it though. For example, if you have a blueprint today with 3 tiers as you mentioned:

  • Web
  • Application
  • Database

In the case above, you’d want to have each tier of these as a single instance, not have an instance per server/VM. Then on each instance, you can set “Scale Factor” on each instance, which will provision the instance with multiple servers in it.

Here is an example with more than 1 server inside an instance:

This allows you to add/delete nodes manually or also set a Scale Set when provisioning (or after).


Finally, you can add a new node to the instance:

Adding a new node will run the logic you have configured as far as workflows and other settings.

Would these do what you are looking for?

1 Like

Thanks Korey. That is an interesting workaround. It could work.

The reason I was proposing it as a single step option is it could open the door for self healing applications. If built correctly the system could pick up the failed node and just rebuild it without any intervention.

Implemented wrong, that could be very dangerous, but I think it could work.