Google created a great development model with App Engine (GAE), and while it runs on its own infrastructure, it gives access to the best ops: Google’s. Without the need to care about ops, or the need to think about how to scale, developers can focus entirely on the application logic, which is the brilliance of the model. On the GAE platform, Google takes care of upgrading, hardware, software, API levels,changes in pricing and SLAs accordingly, mostly in the good, and sometimes in the bad.
With AppScale, we strive to reach the same no-ops experience as you have in Google Cloud Platform, and yet give the flexibility to our customers to control the when, and how to do ops if they so choose, or need. On AppScale you have the full stack at your application’s disposal, and a full control of what, where, how much, and how the App Engine application will perform and behave.
The need to Upgrade
Upgrades are an integral part of the software lifecycle. Sometimes it is for security reasons: a new vulnerability has been discovered, or ACL needs to be improved, or a potential hole has been found. Security updates are extremely important. They don’t usually change the application behavior in any way the end user will see, and they need to be applied promptly.
Some upgrades are bug fixes, or small improvements. They can be part of the application itself, or part of the software stack upon which the application relies. Within App Engine, the developer has a lot of control (and responsibility) over both aspects: the former affects the end-user directly, and it is perfected with the release of a new application version that can be deployed on App Engine at any time. The latter usually doesn’t affect the end-user, but can make the application faster, more reliable, or remove that ugly workaround. For the dependencies closer to the application (ie: deployed with the application) they fall within the previous point while for upgrades of the App Engine platform itself (whether Google is doing the upgrades or AppScale) it is usually transparent to the developers and users.
AppScale provides the same workflow as Google when it comes to updating the application; that is the developer deploys a new version of the application at any time she desires. Software stack upgrades (AppScale itself and/or any of the underlying projects or dependencies) are handled by the administrator of the deployment in terms of when and how to upgrade.
With AppScale 3.0, amongst other nice features, we introduced the upgrade command. With this new command we are simplified the maintenance of an AppScale deployment, following the philosophy of “lean-ops” and allowing AppScale users the full-control of the process.
Upgrading an AppScale deployment requires a few steps, and this new AppScale tool conveniently groups them together. At a high level we need to:
- Stop a deployment if it is running: this step is absolutely needed when upgrading major versions. For minor or patch releases, it can be done on a running system on a case-by-case basis;
- Upgrade all the underlying packages: since we are based on stable releases, this brings in desired security patches;
- Upgrade the AppScale dependencies: some of our dependencies are not yet packaged, so we install/upgrade them during our build process;
- Upgrade AppScale itself: the upgrade will pick the latest stable release, although there is a way to upgrade to the current development code for the adventurous lot;
- Upgrade/modify any metadata associated with the deployment (if needed).
AppScale 3.0 brings a new datastore layout which dramatically increases the Datastore API performance, in particular for big datasets. This change requires a cold upgrade of any existing dataset: this process is handled for you along with the steps mentioned above. The upgrade starts Cassandra and Zookeeper (used by the datastore and for metadata persistence), and upgrades their data to the latest supported format.
As usual, data safety comes first, so please take a snapshot or a backup before attempting the upgrade. After that it should be as simple as running
on your head node. Depending on the amount of data, this process may take time.
As of now, you cannot perform an upgrade on a deployment that is started in what we call cloud mode: the distinction between cluster and cloud deployments will soon go away, but let’s leave this for a future post.
Enjoy your freshly upgraded deployment and we encourage you to share your feedback with us.