ActiveState has created a Private PaaS  that supports Perl and Python as well as Java, and is based on the Open Source CloudFoundry distribution, packaged and distributed in a VM image, or installed to a wide range of IaaS platforms (public or private).

ActiveState is well known in Open Source communities as packaging/distribution vendor for dynamic languages – Perl, Python and Tcl.  A sort of Red Hat for dynamic development languages.  It also has a Komodo IDE for these languages, and a strong pedigree in contributing back into the Open Source projects which it packages. Stackato is also essentially a packaging of these and other Open Source technologies. It’s an interesting take on the PaaS space – PaaS becomes a packaging problem – just like the Linux Distro. For the customer, the choice of PaaS/Distro is partly about the  breadth in the package and partly the mix of pricing, support and warranty offered by the PaaS/Distro.

Dynamic languages such as Perl and Python and web frameworks built upon them have been adopted in certain enterprise sectors, often to drive quick ROI. In some cases the application was always expected to go into production, in other cases it was originally a throw-away prototype that ultimately ended up in production. There is thus an opportunity in moving customer’s investments in applications and skills using these languages and  platforms to the cloud, and the Open Source CloudFoundry platform that VMware has instituted offers a “Meta-Platform as a Service (MPaaS)” on which Perl and Python can be accommodated.  By integrating with existing support for Java, Spring etc. on CloudFoundry, ActiveState is able to deliver a packaged PaaS with the breadth to appeal to an enterprise which uses both Java-based/derived languages and other dynamic languages (or wishes to do so in the future).

The way to think about a PaaS built this way is that it is like a menu built on a menu-board. The Meta-PaaS (in this case CloudFoundry) provides the menu board, and then the PaaS provider populates the menu with the services it wishes to support. With the addition of all the dynamic languages, Activestate ends up with a very big menu – big enough to cater for the diverse requirements of a large enterprise, although of course ActiveState is required to support that entire menu.

ActiveState is very specifically taking this forward as a Private PaaS. It believes volume enterprise adoption of PaaS will be private, because regulatory and security concerns will ultimately dominate, and IT will need to maintain control. ActiveState also suggests that the cost of private PaaS will be lower. ActiveState offer Stackato in a simple VM for single developer use for free.  They also offer a 45-day sandbox on Amazon where you can try it out. This is definitely not a Public PaaS – your application is wiped out after 45 days.  In private PaaS, deploying and managing a PaaS becomes an IT function.  There are even options in deploying a private PaaS over a public IaaS, which offers an intermediate level of security assurance.  ActiveState also expects to partner with service providers who will offer public clouds on Stackato, possibly as a layer over an Amazon or Rackspace IaaS.

In some ways every PaaS vendor is going to market on a false premise. The standard PaaS ‘story’ of Developers deploying directly to Production is total lunacy. I suspect even the most freedom-loving developer would understand that his healthcare provider or bank, or the IRS, should adopt some kind of change management process and maybe a wee bit of testing – functional, security, performance etc.

Use of a private PaaS rather than a public PaaS allows configurations that map more directly onto these lifecycle processes as mandated within the business and/or by the regulator.  However, the inherent simplicity of the PaaS proposition – one-button deployment from the IDE or script – is eroded by the realities of enterprise application lifecycle management (ALM), and indeed IT has to get involved in layering ALM processes around the PaaS platform. In my personal view it is the story around lifecycle that the PaaS vendors need to get sorted – they need  easy-to-deploy support for a broad range of workflows, and a menu of ALM technology just like they have for infrastructure.  Otherwise the value proposition  isn’t there for enterprise usage, the PaaS layer simply obfuscates the underlying processes and makes IT’s job harder.

ActiveState is packaging a lot of third-party technology, particularly from VMware. Wouldn’t customers prefer simply to go with VMware?  There is, however a precedent for a smaller company building a better Distro – Eclipse distributions are dominated not by IBM, who originated most of the technology, but by MyEclipse – a small company in Texas who innovate faster, and offer a better matrix of support/cost options.

The determining factor for ActiveState may be the relationship between Private PaaS and Public PaaS, and which one ultimately drives adoption.  ActiveState is betting that the majority of enterprises will go Private PaaS first, in which case it is well placed.  If the enterprise goes Public PaaS first and then migrates back to Private PaaS, ActiveState will have a lot of incumbent competitors to deal with.

Share this Article:

Share Button
Mike Norman (104 Posts)

Dr Mike Norman, is the Analyst at The Virtualization Practice for Open Source Cloud Computing. He covers PaaS, IaaS and associated services such as Database as a Service from an open source development and DevOps perspective. He has hands-on experience in many open source cloud technologies, and an extensive background in application lifecycle tooling; automated testing - functional, non-functional and security; digital business and latterly DevOps.

Connect with Mike Norman:


Related Posts:

Leave a Reply

Your email address will not be published. Required fields are marked *


3 × = twelve