Cloud Foundry API Documentation

Today I was pleased to kick off a project that has been in my head for a while now. Have unveiled the Cloud Foundry API Documentation project, which will work to document all the API endpoints and messages that go across the message bus.

Since we've been working extensively in Cloud Foundry, and extending it quite a bit, one of the areas we've been sensitive to is discovering what data is already being passed around, and how we can add and extend the data types while still ensureing compatiblity.

The API documentation project is open sourced with the site on GitHub and accepting contributions.

Our hope is that with Cloud Foundry's growing ecosystem, we'll find more developers adding new service types, creating different plug-in components, or making drop in replacements for some of the core components.

Thursday, March 29, 2012

Runtime Upgrades

We put a lot of care into the runtimes we've deployed, both in terms of optimizing them for the platform and ensuring they're up to date with the most useful features and fixes.

One of the ways we do this is by building custom packages for each of the runtimes. Instead of using the standard packages with the operating system, we build our own for many of the components in our infrastructure. We can more efficiently keep them up to date, ensure we can install and support multiple versions at the same time, and track/tune the performance over time.

When we first began testing PHP support, we were using the standard package which was only 5.3.2 and wasn't really at the same level in terms of attention to detail as the others.

That is why I'm pleased to announce that we've updated our PHP runtime and added a new one.

We're running running on PHP 5.3.10, and have also added support for PHP 5.4.0. If you are creating an application through the dashboard, you'll now see a Runtime dropdown appear where you can pick which one to use, from the command line you can add --runtime php54 to the paasio create command. All existing PHP applications are automatically on 5.3.10.

We've updated our Ruby 1.9.3 runtime from 1.9.3-p0 to 1.9.3-p125. This was primary to roll out a fix for a Ruby OpenSSL related security bug.

You can find a list of our currently supported runtime versions and a list of past versions on our Developer Portal.

Wednesday, March 07, 2012

Cloud Foundry Open Tour San Francisco

VMware is kicking off its Cloud Foundry Open Tour this month, and being users of it and big time fans, we'll be attending the San Francsico stop of the tour on March 30th.

The purpose of the Open Tour is to help people (developers and non-developers) to learn about Cloud Foundry and Platform-as-a-Service as a whole. There will be several talks about Cloud Foundry high level as well as some details on using the different runtimes and services.

If you are in or around San Francisco and interested in PaaS, be sure to check it out. Register before March 15th to get early bird pricing too! If you're attending, be sure to seek out our founder, Ken Robertson.

If you aren't near San Francsico, the Open Tour has several worldwide stops including Portland, Austin, Washington, London, Moscow, Beijing, and more.

Stay tuned here as it gets closer to the San Francsico event for more about what we'll be doing there.

Friday, March 02, 2012

PHP and Haskell Runtimes in Beta

Excited to have two new runtimes in beta testing: PHP and Haskell.

PHP is arguably one of the most prominent languages on the web, so we are very glad to have support for it in testing. PHP is powered through Apache, so any common rewrite rules you've been used to through your .htaccess file are supported.

Haskell support is new to Cloud Foundry as a whole. Haskell had piqued my personal interest through a friend who had introduced me to it. One thing I am very pleased with the Haskell support is that it has full support for Cabal, Haskell's package management system. When you deploy, it will install any necessary dependencies and build the application into a binary. With this, you can use any of Haskell's web frameworks, whether its Snap, Happstack, Yesod, or anything.

This brings our list of runtimes up to:

• Ruby 1.8.7
• Ruby 1.9.3
• Node 0.6.9
• PHP 5.3
• Haskell 2011.4.0 / GHC 7.0.4

If you'd like to beta either of these runtimes, please shoot a message over to help@paas.io to get added.

Wednesday, February 29, 2012

Pricing Details

We've been starting to send out batches of invites and wanted to take a few moments to post some information about our pricing.

One thing to point out first is that currently all new signups have a 30 day trial, where the service is free to use. We do place limits on what you can initially provision, though. Default account limits are:

• Up to 2 applications
• Up to 512mb RAM between your application instances
• Up to 2 database services provisioned

Getting more than that is as simple as filing a support request. This is primarily a safeguard to prevent abuse.

Application Instances

• $0.03/hour per instance
• 256mb RAM per instance

With this, you can have 4 application instances with 256mb RAM each for $0.12/hour, or you can have 2 instances with 512mb RAM each for $0.12/hour. The flexibility in RAM allows you to get more memory per instance if you have a more memory intensive application.

One thing we are instrumenting is where you can deploy the simple Caldecott application for free. Caldecott is a simple application that is deployed when you use the paasio tunnel command to let you directly connect to your database services. We will be configuring it so if you have that application deployed, it will be locked to just one intance and 64mb of memory, and not be billed for it or have it against your limits.

Custom Domains

Custom domains are free. There is no charge to link your own domain names to your applications.

SSL

• Free on *.paas.io subdomain
• $5/month for SNI SSL
• $25/month for dedicated IP SSL

By default, SSL is enabled on any application running on a subdomain under *.paas.io.

SNI SSL is available for $5/month. This option uses a more recent approach to SSL which allows the use of multiple certificates on a single IP address. However, it is not supported by every browser. In particular, IE, Chrome, and Safari on Windows XP do not support it.

To use SSL on a dedicated IP address is $25/month. With this, you get your own dedicated IP address attached to our load balancers and configured with your SSL certificate. This will work with all browsers and on any hostname, whether the root domain or not.

Databases

Databases are priced at a flat fee per month, but will be prorated based on if you create/delete or upgrade/downgrade mid-month. Pricing between similar types of database engines will be kept very close, for instance MySQL and MongoDB are generally more similar than something like Redis or Memcached.

We're looking at keeping pricing tiers between database types very close in order to keep them more consistent.

One important aspect of all of our database services is that they are configured fault tolerant and transparent to your applications. Each database is present on at least two servers with fail over handled automatically.

MySQL/MongoDB Pricing

Pricing for MySQL and MongoDB will be tied to how much disk storage is needed, as well as number of simultaneous connections. However, number of connections will be more of a soft limit.

Redis Pricing

Pricing for Redis will correspond to how much memory is used. The pricing tiers will also be tied with number of application instances it can support, howver the specific limits we still aren't set on, but it will also be a soft limit.

The Obvious Comparison

When talking about pricing, there will be the obvious comparison against Heroku. So, lets just come out and address it. You can find some here.

One point is that many of the database services available through Heroku are not offered directly by Heroku, but instead through third-parties with their addons. As a result, the pricing isn't set by Heroku and reliability isn't controlled by them either.

Some direct comparisons:

There are some distinct differences, however overall in terms if what you will be actually using, we think it works out well. For instance, they're counting on you not actually having a 20gb database. And if you do, be aware of the expectation of performance for only $15/month.

Additionally, most of the services available through Heroku are hosted directly on Amazon Web Services, while we run all of ours on our own dedicated servers within our own network. We've posted before about performance on AWS still being linked to 2007 technology. We use our own hardware configured specifically to each type of workload.

For some other addon database types offered by third-parties it is even more different. It can be difficult to compare apples to apples, as all of our options are fully redundant with, for instance, MongoDB running as a replica set pair.

Tuesday, February 14, 2012

Presenting at NodePDX Feb 11-12th

PaaS.io's founder, Ken Robertson, will be presenting next week at NodePDX in Portland, Oregon, going on February 11-12th.

The presentation will be on BattleBots in the Clouds with Node.js. Remember the old TV show BattleBots? It featured teams building robots and pitting them against each other in a battle royale. What would happen if we took that concept to the cloud? What if we built applications and unleashed them on each other, testing the scalability and resiliency of the cloud as well as tactics.

Ken will be talking about building such a "bot" using Node.js, walking thorugh the concept, code, and actually deploying and running some matches.

Want more? Hopefully you can make it out to NodePDX and join me on Sunday at 11am for the presentation. Will also be talking some about PaaS.io and demonstrating the concept running on our platform. Will also be handing out some invites...

Friday, February 03, 2012

Demoing Git Deploys

We've been hard at work and thought I'd take a quick moment to show just a little piece of what has been in the works.

We've chosen to adapt Cloud Foundry's default deployment strategy to be wrapped around source control tools. In particular, we're allowing the use of Git and Mercurial repositories for the flexibility that they offer. You can have your main development happen somewhere else and simply push your code to PaaS.io when you want to trigger a deploy. With this, deploying is an easy extension of your development process.

However, the convenience of Cloud Foundry's default deployment is sometimes a big win. By default, applications are uploaded manually with Cloud Foundry's command line tool, VMC. VMC compares the local files to the ones on the remote server and simply uploads the changes. With this, you can easily roll out quick one-off changes without the need to commit and push code. How many times have you seen a commit message saying "maybe this will work"?

One draw back to the default strategy is when developing on a team where multiple people have deploy access. If someone deployed some code before you and you haven't pulled the latest commits, you may actually be inadvertently reverting changes.

To help ease this, we've extended VMC's default update command in our command line tool, paasio, with the upload command. The upload command will ensure the commits from the most recent source control based deploy are present locally and warn you if they aren't.

Watch the video for a quick demonstration and then head over to paas.io to get on our beta list. We are slowly opening up more slots and expecting much more very soon.

Tuesday, January 24, 2012

It's All About The Pentiums

(Props if you got the reference and began humming along.)

We've been hard at work putting together a solid system and one way we're doing that is by starting from the bottom up and looking closely at the hardware we'll be running on. We're building out our own infrastructure rather than building out on a public cloud like Amazon EC2 or the Rackspace Cloud. Those public cloud options are certainly attractive for the ease of provisioning, however we can get much better performance on our own hardware than leveraging others. It all boils down to control. Control is key and has benefits through the entire stack in terms of how you lay out your network, size CPU, memory, and storage, and allocate resources within the system.

Storage. This is the weakest point of almost all public IaaS services is that storage will end up being your bottleneck. The providers build fairly fixed hardware configurations designed around accommodating their set machine sizes, however different applications have very different storage requirements. The transfer rate is rarely problem, its normally the rate for individual operations (iops, Input/Output Operations Per Second).

For instance, a database like MySQL or MongoDB can be I/O intensive, while memcached is all in memory and redis only saves to disk in the background. You want to load up MySQL/MongoDB will many disks, while memcached and redis don't really need all that power. Webservers do moderate I/O, but often more read heavy and easily cached by the operating system.

With our own hardware, we're able to ensure we tailor to individual workloads and have the ability to revise our configuration over time to continually maximize performance.

CPU and memory are another factor, but the important control aspect comes with resource limits on them. Moore's Law has existed for more than 30 years. Quite simply, Moore's Law says the amount of transistors that can be placed in a circuit will double every 2 years. This loosely translates to computers can double in speed and memory capacity every 2 years.

Amazon EC2 though has been defying Moore's Law for 4 years. Amazon allocates a fixed amount of processor power, called Compute Units, for each instance type. The Compute Units are still based on CPU specs from 2007.

EC2 Compute Unit (ECU) – One EC2 Compute Unit (ECU) provides the equivalent CPU capacity of a 1.0-1.2 GHz 2007 Opteron or 2007 Xeon processor.

EC2 has almost been around for 2 iterations of Moore's Law, but their allocations have stayed the same. Am m1.large today probably is a little faster than an m1.large 4 years ago, since there are other factors (memory speed, bus speed, etc), but it won't be an evolutionary leap. On today's hardware, Amazon can do 4x what it could do in 2007. Based on past experiences of moving workloads from the cloud to raw hardware, it is very eye opening what you can do when you have real CPU power.

Last but certainly not least, the network is core to everything. Without the network, nobody can talk. By controlling the network, we can ensure your web app is connected to the same switch as your database server. We can ensure close proximity of servers and maintain lower latency. Amazon isn't very detailed on their datacenter configuration, but simply based on their scale it is definitely advanced. However your web app and database might be at completely opposite ends of the building without knowing or being able to control it. Network latency within EC2 can often times be prone to hotspots that are difficult to diagnose or prevent.

All this means that by building our own infrastructure, we will be able to offer a higher level of performance. We can tailor configurations to their individual workloads. And we can cycle in new hardware as it becomes available to continually keep our infrastructure current.

Thursday, January 12, 2012