PWS is Pivotal’s public Platform-as-a-Service offering. PaaS systems let you host apps by pushing them to a service rather than having to configure and maintain separate installations of web servers, load balancers and so on. PWS is a hosted installation of the open-source Cloud Foundry project, to which Pivotal is a primary contributor.
You may be familiar with Heroku, one of the first cloud application platforms. PWS (or ‘p-dubz’, as it’s affectionately known at Pivotal) occupies the same space as Heroku, and as such is a competitor.
Although earlier in its development than Heroku, PWS is a very stable, viable alternative. It has several advantages over Heroku, but also has a few disadvantages, which the team are working hard to eradicate in the near future.
A decoupled CLI
Because it’s a Cloud Foundry installation, the PWS command line interface isn’t coupled to a version control system, as Heroku’s is to Git. I could, for example, start a quick project without version control and have it publicly available on the web using PWS in a few minutes.
This is a big advantage for teams using other version control systems. It’s also great for trying things out without committing them to version control. I shouldn’t have to change history in order to tidy up some commits that were only created to test the waters of my cloud platform.
Portable to the private cloud
If your organization is considering installing a private Cloud Foundry installation, such as Pivotal CF, then you can apply your knowledge of interacting with PWS to that system too. It’s simply a case of targeting a different API:
cf api https://my.internal.cloud/
…and then pushing your app again:
PWS charges by memory used by apps over time, and per month for any services used in the marketplace. You can try the system out for free for 60 days, after which apps are pay-as-you-go.
One advantage PWS has over Heroku in this area is that you can determine exactly how much memory to allocate, and therefore pay, for a given app. Whereas Heroku requires its users to allocate chunks of 512MB, on PWS I could choose to allocate 5309 megabytes to my app if I so wished.
We have a dedicated Cloud Ops team who maintain the system, so you don’t have to be up in the middle of the night when a server gets upset. In addition, we have a highly knowledgeable support team, known to get customers out of pickles entirely unrelated to PWS. There’s also an active forum.
Cloud Foundry has a plethora of docs ranging from guides to reducing downtime with blue-green deployments to sequence diagrams of the internals. We have a large and growing dedicated documentation team that is constantly reviewing and improving our written material.
The future: one-off tasks
One-off tasks such as database migrations on PWS aren’t quite as slick as you may be used to on services like Heroku. Whereas on Heroku you can:
heroku run rake db:migrate
On PWS the traditional workaround for a lack of support for one-off tasks is to run migrations on one instance as part of the app’s startup command. Details of this and other techniques are on the Cloud Foundry database migrations documentation.
The future: more services
Heroku boasts many more add-ons than PWS. If you can’t wait for more vendors to join, however, you can easily create your own service that bridges the gap between any SaaS provider and PWS.
If you’re on the lookout for an easier, cheaper, or more compatible way to deploy and maintain your apps, signing up for PWS is painless. It’s also a skill worth acquiring: as more companies adopt Cloud Foundry as their platform of choice, your experience with PWS will stand you in good stead for pushing apps to those internal platforms.
If you have any questions about the service, feel free to add a comment to this post.