You have created a service instance and are outgrowing some aspect of it. You now need to increase the capabilities of the service. For a database service, this might mean you need more storage space or the ability to make more simultaneous connections to the service. For web service, it might mean you need to be able to send more requests per second to the service. In short, you need to upgrade your plan.
At the moment, PWS only supports service upgrades by swapping out an existing service instance with a new, likely larger service instance. This is necessary because services acquired through the marketplace are based on service plans and not simple quotas. This is a bit different than traditionally hosted services where an administrator could login to the service and adjust the quota of a given user to give a user more functionality.
Given this difference, the general process for a service upgrade looks like this:
- Create a new service, selecting a plan that will meet both your current and future needs. From the command line, you can use the `cf marketplace` command to view available service plans and create a new service instance with the `cf create-service` command.
- Unbind the existing service from your application. This change will not take effect until the service is restarted. It can be performed from the command line with the `cf unbind-service` command.
- Bind the larger service instance that was just created to the application. This change will not take effect until the service is restarted. It can be performed from the command line with the `cf bind-service`.
- Restart the application. Upon restart, the application will stop using the old service and start using the new service. This can be performed from the command line with the `cf restart` command.
These steps can be performed from the command line or through the developer console.
Impact / Risks
As mentioned above, the migration process discussed in this article works by swapping out your existing service instance with a new, larger one. Because it results in a new service instance being created, none of the data from the old service will be available on the new instance until you migrate it from the old instance to the new instance.
The process outlined above does not handle migrations for you. For services that store data, you would want to perform a data migration prior to the last step which is restarting the application. Exactly how you orchestrate this migration depends on your application and the services it is consuming. Careful planning and consideration should be given to this process to minimize downtime and possible data loss.
Support for in-place upgrades, where no data migration is necessary, is currently in development and should be available for select plans on some types of services. We don't currently have a list of what in-place upgrades will be possible as the process depends largely on the service provider's support for upgrades. More information will be available on this when this support is rolled out to PWS.
Selecting the proper storage plan for your application can be difficult. To help with this process, we offer the following guidelines that you can use augment your normal planning and sizing process.
- Free tier services should only be used for development, testing or other cases where data retention does not matter. In other words, free tier services are only suggested for situations where it's acceptable to simply throw out your data and start over.
- Production applications should be deployed with a paid service that is sized appropriately to handle the needs of the application for the foreseeable future or at least for a period of time whereafter you are comfortable performing an upgrade and migration based on the instructions above.
- If you need a more elastic storage model, you might consider using your own service or a third party service not purchased through the marketplace. For instructions on using a service not purchased through the marketplace, see the linked KB article.