- Get Stackato
- Why a Private PaaS?
- Features & Benefits
- Stackato by Language
- Compare Editions
- Stackato & Cloud Foundry
- Developer Tools
- Professional Services
- Commercial Support
- Code Recipes
Troy Topnik, October 18, 2011
By executing '
We love Cloud Foundry. It's the right architecture for a cloud application platform. Without this open source project to build on we wouldn't have Stackato in it's current form. We're excited to be a part of this growing community, and proud to have been chosen as a community partner.
But aside from the fact that Cloud Foundry is an open source project, and Stackato is a commercially supported private PaaS offering, there are some notable technical differences between Cloud Foundry and Stackato.
The stackato client
Cloud Foundry uses a ruby program called vmc for client-side operations. We thought that making Ruby a prerequisite for all users was a bit presumptuous (not everyone uses Ruby), so we rewrote vmc...
At first glance that seems to replace one prerequisite with an arguably more obscure one, but we happen to have the tool at hand (TclApp) to make a stand-alone executable out of the Tcl program. So there are no language interpreter prerequisites for using Stackato, other than those you might want to have on hand for your own development. You just download the executable (single file, no dependencies) and go.
The Stackato client maintains API compatibility with Cloud Foundry and can be used interchangably with vmc in most cases. You can target api.cloudfoundry.com with it, push applications and run all the same commands you can with vmc.
But the Stackato client has some extra commands, features that we felt were necessary for a successful PaaS client:
Cloud Foundry has a data service provisioning system which lets you create database engines or messaging services to use with your applications. It doesn't, however, give you any way to interact with that database directly. You can do so programmatically from your application, but sometimes you need direct access to the database shell, so we added that.
stackato dbshell <appname>' command opens a connection between the data service running on Stackato and your local system, then spawns the appropriate database client. Alternatively, you can use the '--json' option to return the connection information and credentials so you can connect with a database administration tool (like Komodo IDE's Database Explorer).
Some frameworks and applications obviously didn't have the cloud in mind when they were built. Part of the process of getting them in a functioning state may require running commands in the console. We hit this first when we ran into Django's requirement for the 'manage.py syncdb' and 'manage.py migrate' steps when setting up the database. Running these programatically from the application itself is theoretically possible, but very inconvenient, especially for one-off operations. We added a 'run' command to make this easier.
By executing '
stackato run <appname> ...' you can run arbitrary non-interactive commands in the application space (and only in that space, more on that later). These can be scripts within the application directory or common Linux commands.
The process of pushing an application with vmc requires a number of interactions to set the application name, reserve memory, create and name a data servce, etc. We added a config file so this can be automated. Stackato looks for a 'stackato.yml' file in the current directory when you push an application. The client uses the following keys to determine values that are otherwise passed by the user as arguments or as answers to prompts. For example, our django-gtd sample has something like this:
name: gtd mem: 64M env: DJANGO_SETTINGS_MODULE: settings services: postgresql: postgresql-gtd hooks: post-staging: - python manage.py syncdb --noinput - python manage.py migrate --noinput ignores: - .git - dev.db
The application name is specified, memory is reserved, an environment variable is set, a PostgreSQL data service is created, and some commands are run on the first application instance (thanks to the aformentioned 'run' command).
It's one of the most powerful and popular languages for the web. A true multi-language PaaS has to support Perl, so we added it.
Perl applications in Stackato are run on ActivePerl, connected to Nginx via PSGI.
PPM, PyPM and NPM
We used our binary package managers to make Perl and Python module installation as fast and simple as possible. For cases where a module might not be available from the ActiveState repositories, application staging falls back to using pip and mcpan respectively.
We found that Cloud Foundry did not have any server-side module provisioning for Node.js. This becomes a barrier if you're developing Node applications with compiled modules (unless your laptop or workstation happens to be running Ubuntu x86_64), so we added npm support too.
Amongst other finishing touches is a a reverse caching proxy to keep recently fetched packages handy for quicker staging.
We're building Stackato integration into Komodo 7. The current Alpha of Komodo IDE has a Stackato toolbox, which allows you to run most of the command line operations right from the IDE. The upcoming Beta release will have an even more rich dashboard for managing running applications and services.
As with Stackato's command line client, you can use this with cloudfoundry.com and other Cloud Foundry based PaaS providers, though Perl and the two additional commands mentioned above will not work.
Conversely, you could also use the Cloud Foundry plugin for Eclipse or STS to connect to Stackato.
Added Security: application isolation with Linux Containers
Cloud Foundry relies on Linux user permissions to prevent tennants and their applications from messing with each other. We felt this didn't provide enough security for a true multi-tenant system, so we made some core changes to put applications in their own Linux containers using LXC. LXC is implemented at the kernel level, and adds isolation in a similar way to Solaris Zones or BSD jails.
With this in place, we're much more confident that user applications are safely separated from each other, and that the hosting systems have better protection from malicious or accidentally dangerous code.
You can install Cloud Foundry from source using their install script, but it's a complex and error-prone process. We've prepared ready-to-run VM images of Stackato for VMware Player/Fusion, vSphere (OVF), and VirtualBox. Just boot the VM and start using it as a micro cloud, or clone that same VM and link the instances together in different roles using the 'stackato-admin' tool.
Cloud Foundry was designed with application portability in mind. Applications deployed to any Cloud Foundry system can be moved easily to any other, including compatible ones like Stackato.
We've taken the next step and made the platform itself more portable, so that you'll be able to run Stackato on the hypervisor of your choice. In addition to vSphere and EC2 which are already supported, we'll be working to make sure Stackato runs just as well on XenServer, Xen, KVM and others.
Cloud Foundry is open source software. Stackato is commercial software.
Stackato is technically a fork of the Cloud Foundry codebase, but we contribute changes back to the upstream project and we strive to maintain API compatibility between the two (e.g. using the 'stackato' client with other Cloud Foundry servers).
Our biggest contribution to the public project so far has been Python support. It's now available in the Cloud Foundry repository, and the code we contributed uses core CPython and pip instead of ActivePython and PyPM, so there's no reliance on ActiveState builds. We are proud to be the Cloud Foundry Community Lead for Python, and will be continuing to help with Python support in Cloud Foundry.
So if you're interested in running your own PaaS, either for your own or organization's use or as a service for your customers, check out Stackato and see the differences for yourself!
Subscribe to ActiveState Blogs by Email
Share this post: