Add a Private PaaS to any Cloud and Avoid Cloud Host Lock-in

From a developer’s perspective, cloud computing started out quite simple: you gave Amazon your credit card, picked a pre-built instance template with a description closest to your application’s stack requirements, spun up an EC2 AMI, added any missing modules or frameworks, installed your application, instantiated your database, configured everything, and let Amazon do all the scaling.

This approach was familiar territory – It felt just like booting up a server and installing all of the supporting software. While it still left the burden of maintaining the software stack up to you, you gained elasticity and you didn’t have to wait weeks or months for your IT department to respond to your service ticket for a new server.

Granted , do-it-yourself AMIs weren’t and aren’t fun to maintain, and they get stale when new patches or upgrades are released, but if you had some half-decent DevOps skills, the accelerated time-to-market benefits alone out-weighed the extra effort, vendor lock-in, and data-security risks.

Along came Public PaaS, and cloud application deployment got even easier.

Then public PaaS offerings (like Heroku, EngineYard, and many others) emerged on the scene The vendors automated deployment, helped with resource allocation and scaling, then, configured everything for you. Plus, many of them hosted on Amazon as well. Just give them your credit card and those vendors did all the heavy Ops lifting for you. Someone other than you took on the responsibility of creating and maintaining services (data, mail, monitoring, etc), making sure the right web servers were in place, and that all the appropriate languages, frameworks, and modules were available when you deployed. And, one would hope, they handled security patches for you.

Convenience comes at price – more vendor lock-in.

In that public model, once your app is in the cloud, it’s locked into the vendor’s proprietary operating model. You’re paying a little extra for data storage and computing cycles, but the automated deployment and service provisioning seems so convenient.

When does convenience become too costly?

Your production apps run smoothly for a few months. You get a few more customers, App usage spikes a little. And then you get the monthly service bill. And the buyer’s remorse kicks in. What happened? The ROI was supposed to be so much better! So you start analyzing, looking at other infrastructure providers. You compare prices, zone availability, service-level agreements, and wonder if you are getting the best deal.

More importantly, what it would take to move to a new cloud?

Deploy your own PaaS and make any Cloud your Cloud

Today with Stackato, you can easily deploy your own private PaaS to any cloud, keeping the convenience of lower-overhead services while enjoying the added security of a private cloud.

Oh, and forget all about cloud host lock-in. Stackato plays well with everyone, so you can always move the whole cluster to a different vendor, or even a different hypervisor

Deploying a private PaaS is easy with Stackato

Major cloud-hosting vendors have tools that allow you to import virtual machine images as ready-to-use instances. To use Stackato with your hosting provider, simply import a Stackato Micro Cloud VM (get it here, clone the Stackato micro cloud, then assign the machine instances to various roles to make a Stackato.

Role assignment is easily done using the stackato-admin utility. The cloning process will vary by hypervisor. Stackato VMs can take on one or more roles such as Router, Cloud Controller, or DEA (Droplet Execution Agents, or worker nodes), or become a data service such as mysql, postgresql, redis, or mongodb.

For example, a typical Stackato cluster deployment might include one controller and router VM, ten DEA VMs, one data-service VM. (Set up the controller VM first, so all other components can connect to it.)  For all but the largest deployments, the router can be run on the same VM as the controller to minimize complexity.

You just set up your own private PaaS. And the best part is you can share it with your fellow developers to deploy. Securely.

Don’t worry—Your organization can still claim to be “NoOps.” Corporate IT will still pay the bills and they’ll probably claim credit for ensuring compliance with business practices.

Cut out the public PaaS vendor middleman!

Why so are you paying so much to Public PaaS middlemen, when you can deploy your own private PaaS on any Cloud-Hosting Provider on any hypervisor? If you are looking for flexible bursting from private to public clouds, add Stackato to any cloud and you can retarget you application with a single command.

Avoid locking in to one cloud only. Switch cloud hosts if you find a better deal on computing cycles or need a safe-harbor data center in a new jurisdiction.

With Stackato, ActiveState provides all the technical support you need, gives you an SLA, and even throws in a great web management console and application performance monitoring.

Get off on the right cloud, avoid vendor lock-in

Stackato lets you deploy your own PaaS to any cloud hosting provider (Amazon to Rackspace) running on any hypervisor. Still want to pay the high bills for public PaaS vendor service? Are you addicted to an inflexible commitment to a proprietary platform?

Try ActiveState Stackato. Deploy it to your favorite cloud hosting provider. Just once. You’ll see the difference with your own private PaaS.

<!–

–>

In this new whitepaper, USA Patriot Act and Data Privacy Concerns for the Cloud, we explore some of the concerns that today's enterprises are faced with when contemplating data in the cloud.

Corporations are thinking long and hard about the legal and regulatory implications of cloud computing. When it comes to actual corporate data–no matter what the efficiency gains are–legal departments are often directing IT departments to steer clear of any service that eliminates their ability to keep potential sensitive information out of the hands of federal prosecutors. Organizations with any information that they want to keep private–or need to keep private for other regulatory considerations, are looking looking to private PaaS as a way to keep that data private. From employee HR records to healthcare organizations and financial/banking organizations, knowing who accesses your data and when is of the utmost priority.

Despite all the hype about every application moving into the cloud, some practical patterns are starting to emerge in the types of data corporations are willing to move to the cloud. Learn how to create a secure, compliant, private platform and cloud for developing, distributing and managing enterprise applications.

<!–

–>

In this new whitepaper, USA Patriot Act and Data Privacy Concerns for the Cloud, we explore some of the concerns that today's enterprises are faced with when contemplating data in the cloud.

Corporations are thinking long and hard about the legal and regulatory implications of cloud computing. When it comes to actual corporate data–no matter what the efficiency gains are–legal departments are often directing IT departments to steer clear of any service that eliminates their ability to keep potential sensitive information out of the hands of federal prosecutors. Organizations with any information that they want to keep private–or need to keep private for other regulatory considerations, are looking looking to private PaaS as a way to keep that data private. From employee HR records to healthcare organizations and financial/banking organizations, knowing who accesses your data and when is of the utmost priority.

Despite all the hype about every application moving into the cloud, some practical patterns are starting to emerge in the types of data corporations are willing to move to the cloud. Learn how to create a secure, compliant, private platform and cloud for developing, distributing and managing enterprise applications.

<!–

–>

Komodo has always been adept at working with multiple languages. When we realized that multi-language templating systems were becoming more common, we made it easier to create new colorizers for them. But until now, Komodo wasn’t very flexible at checking the syntax of these documents.

For example, Komodo has always supported running HTML documents through HTML Tidy, which can be quite draconian in its requirements. Unfortunately, HTML Tidy skips embedded CSS style and JavaScript script elements, so those have to be checked manually at runtime. And as most web developers know too well, most browsers respond to errors in CSS and JavaScript with the silent treatment. You have to test by looking for what’s missing, always a recipe for frustration.

Checking Parts

Komodo 7 now identifies the different parts of a document, and hands each part over to a particular syntax checker. It then collects any error or warning messages from the different checkers, weaves them back together, and presents them all in one shot. We even integrated the Syntax Checking Status panel from Davide Ficano’s KLint extension, so now you can see all the highlighted parts of a document in one view. Figure 1 shows a typical snapshot with the classic Komodo HTML sample file with some errors introduced.

The syntax checker also looks at JavaScript and CSS fragments in HTML code as well — these are the contents of event-handling and “style” attributes. Figure 2 shows Komodo complaining about a missing quote in a handler.

Multiple Choices

Since the syntax checking internals were redesigned to handle multiple languages, we also made it easier to select different checkers for a particular language. Perl programmers had this option in earlier versions, where they could install Perl-Critic and choose which of its levels to use to examine Perl code. Now we’ve expanded this choice to several other languages.

JavaScript programmers can select jslint (or the more recent jshint), configure it, and have their JS code checked for problems other than missing return statements. We also found not one but two Perl modules, HTML-Tidy and HTML-Lint, that have different takes on checking HTML code. You’ll need to install these modules in your local Perl library to access them.

Similarly, we’ve added support for three other Python syntax checkers: pylint, pyflakes, and pychecker. My personal preference is for the annoyingly picky pylint, but other people swear by pyflakes. If you’re looking for a higher degree of accuracy, pychecker can supply that. Note that if you select it, Komodo will give a warning that pychecker actually loads and executes your editor’s code as part of its operation. I prefer the safety of static checking, but if you know that your code isn’t going near the file system or manipulating database connections, pychecker might do it for you. Figure 3 shows the new Syntax Checking page in Preferences, where all languages can be found. You can also tweak the Syntax Checking prefs on a per-file and per-project basis as well.

CSS Checking is Back

Before version 6, Komodo relied on a CSS syntax-checking component buried deep in the Mozilla codebase. Then we upgraded, lost the checker, and couldn’t find a suitable third-party CSS checker anywhere. In fact, the only ones we could find were online. Meanwhile, new wrappers for CSS have emerged. One thing they all have in common is an attempt to reduce the duplication and complexity that tend to worm their way into all too many real-world stylesheets. Here’s the rundown on the most common variants:

• Sass: an indentation-driven variant from the creators of Haml
• SCSS: essentially Sass with braces rather than whitespace
• Less: another brace-based wrapper, with some overlap with SCSS

Komodo now supports SCSS and Less, and offers syntax-checking for them as well. It turns out that Sass is syntactically so different from SCSS that separate coding efforts are needed to support it.

Up Next: Hopping on the Brave New World of Syntax Checkers

The new syntax checking system is full of extensibility points. The next article will cover the following topics:

• Writing a checker (aka “linter”) for your own new language
• Writing a new linter for a current language, like a better jslint
• Tapping into existing templating languages
• Supporting a new templating language.

Try it yourself

If you’d like to test out these new syntax checking capabilities, you can download a 21-day free trial of Komodo IDE 7.

Komodo IDE 7 is currently on sale, starting at $245 ($295) until March 15th.

<!–

–>

Komodo IDE 7 has just been released! It offers groundbreaking new technologies and innovative enhancements. Here’s an introduction to the most prominent features it includes.

• Code Collaboration is one of the coolest things to use in a team development environment. You can easily share your files and collaborate in real time with your colleagues and friends. Peer reviews and pair programming become a much more intuitive and interactive experience with Komodo’s collaboration tools.

  
  
  

• 

  For those that use multiple machines, Komodo’s Synchronization feature gives you the ability to copy your Komodo settings (remote server accounts, toolbox, file templates…) between all the Komodo instances. So you can customize Komodo in one place and have the same setup appear in another!

• The cloud is a new and exciting playground for developers. Komodo’s Stackato interface provides the ability to quickly deploy web based applications onto cloud infrastructure – you can have your application running on the cloud within minutes! A slew of languages and frameworks are supported – such as Python, Django, Ruby, Rails, PHP, Drupal, Perl, Mojolicious, Node.js and even Java!

  
  
  

• Node.js support – Komodo IDE brings in debugging, code intelligence, editor and syntax checking support for Node applications. As well as this, Komodo IDE 7 provides additional support for web and template languages like CoffeeScript, LESS, SCSS, EJS and Mojolicious.

  
  
  
  

• With the ability to Code Profile your application – you can now find out why that PHP or Python code is taking so long to run! Komodo shows a graphical representation of the methods and calls made by your program, as well as outlining the CPU time spent executing your code. Automatic time sorting makes it easy to see the code hot-spots at a single glance.

  
  
  

• Now, with every major Komodo IDE release we’ve aimed to make things work smarter and faster than they were working before. Komodo IDE 7 is no exception to this rule and you’ll notice a lot snappier Komodo startup time, lower CPU utilization – particularly when idle, and lower memory usage for large projects. Additionally, tools like the fast-find bar make it even quicker to do the common things you use the most.

  

There are way more features in Komodo IDE 7 than I can outline in a single blog post, so check out the full release notes to see other great enhancements like multi-language syntax checking, HTML end-tag completions, moveable side panes and much more.

If you’d like to test out these features yourself, you can download a 21-day free trial of Komodo IDE 7.

It’s also currently on sale, starting at $245 (reg. $295) until March 15th. Visit our store to purchase today.

A special thanks goes out to all the testing feedback provided by the Komodo 7 beta users during the Komodo 7 development process – you all rock!

We hope you enjoy Komodo IDE 7!

<!–

–>

We have a number of Stackato deployments here at ActiveState, some larger than others, but one stands out as enticingly quick to get setup and scaling with little effort.

Our Stackato vSphere cluster serves as one of our primary testing platforms and at any given time. It’s running at least 25 Stackato nodes, one ‘cloud controller’ and the rest mostly ‘DEA‘ nodes.

In a real elastic cloud you wouldn’t want to waste the resources or expense of running these DEA’s perpetually, you would want them only when there is a current or trending resource demand for them. We mainly idle these VMs for QA testing and benchmarking, so we are ready to instantly scale up or down.

Elasticity should be no stranger to those of us working on PaaS or IaaS products, and if you’re not already familiar with our Stackato Sandbox, it runs on Amazon EC2 with EBS backed storage. To meet user demand at any point in time, we can have the cloud controller automatically spin up new DEA instances taking into account projected load on resources and use the EC2 API to spin up a new DEA.

vSphere can also serve your own privately managed cloud in this exact manner, and I’ll be giving a short summary on how we did this on our own vSphere setup.

Taming the vSphere API

It should come as no surprise to more experienced vSphere users that to achieve scaling we made use of the vSphere API. As Cloud Foundry itself was conceived in Ruby, we choose to use RbVmomi, an open source Ruby interface to the vSphere API. If you’ve had previous dealings with the vSphere API, fear not – this Ruby interface actually makes the coalescence of the two a breeze.

For the connecting vCenter user, I recommend creating a new user with the permissions to create, start, stop and deploy new VMs, and access to any of resource pools it might need.

Diving into the Cloud Controller

I reused existing modifications to the health monitor component from our EC2 (Sandbox) scaling code, to incorporate the ‘events’ necessary to trigger a scaling activity.

These previous modifications to the health monitor are designed to probe all the available DEAs at runtime intervals and check their current resource capabilities and limits, including the DEA’s current RAM metrics. This, of course, can also include the condition when there are simply no DEAs available for deployment due to failure or full capacity.

Using a small analysis of past, current and projected app deployments, a ‘scale up’ event will be triggered and passed along the NATS message bus, which is the default PubSub messaging mechanism used by Cloud Foundry.

At the point of receiving the event message, the process flow follows something like this:

• The Health Monitor component keeps track of the health of any deployed apps and the availability of DEAs
• If under load, the ‘scale up’ event is triggered from the Health Monitor to the cloud controller via NATS
• The cloud controller will load up the vCenter YAML configuration (more on this later) and connect to vCenter via the API
• It will round-robin all hypervisor hosts currently available for deployment, so no single one becomes overloaded.
• Upon finding an available host, the DEA is deployed from the template to the host and it’s corresponding resource pool and datastore.
• The MRU index of the last deployed to host is kept in the cloud controllers database.
• When the DEA starts up, it is already configured to register with your cloud controller and is instantly ready to start receiving new app deployments.

Scaling from a pre-built template

On the ‘subscribing’ end of these event messages is the cloud controller itself, which upon receiving a ‘scaleup’ operation, will proceed to connect to vCenter, and deploy a new DEA from a pre-defined template. To make the template, we take a new Stackato VM and run:

  stackato-admin become dea -m <cloud_controller_ip> -e <api_url> 

This is the same step you would take when setting up a cluster manually. Once you’ve run this, you can shut that VM down, then right click ‘Save as template’. Once converted into a template, it as available for instant deployment across all your ESXi’s / vHosts.

Balancing the VM load on your ESXi’s

Checking the hosts status

A useful feature of the vSphere API is the ability to probe your hosts for their runtime metrics, so you can make an informed decision about where the next VM should be deployed to. We make use of the vSphere API’s HostSystem() object to get some information about which hosts are available, and which hosts are in good health.

Using the API makes it easy to locate a new host to deploy to. You don’t need to supply any host configurations, the cloud controller will take care of keeping tabs of hosts in the CC Database. The scaling code automatically chooses the next available vSphere host at runtime, so you don’t need to manually specify your hosts in a config file.

Wrapping it up in a configuration file

To ease maintenance and provide flexibility, the scale-up control settings are in a simple YAML configuration file that you upload to the stackato user’s $HOME directory, which is then parsed by the cloud controller. This configuration contains parameters like vCenter server, authentication details and template information. It is quite straight forward:

---
  server: vcenter.domain.com
  user: username
  password: password
  https: true
  port: 443
  insecure: true
  path: /sdk
  datacenter: DataCenter
  template: "Your-Template-Name"

We use SSL to connect to vCenter (recommended), but I’m also connecting with ‘insecure’ set to true. That simply means we are using self-signed SSL certificates, and forces RbvMomi to accept them.

Expanding the featureset

With the abundance of documentation on the vSphere API we could take the scaling process even further when working with different setups of datastores architecture.

Some items for consideration could be:

• Limiting the maximum number of VMs on any single host
• Allowing deployments from multiple/different templates
• Allowing multiple vCenters in the configuration

If you have any thoughts or questions about how this could apply to your own vSphere setup please let us know, we’d love to hear them!

<!–

–>

The ever-expanding OpenStack ecosystem now has an enterprise-ready PaaS. Stackato, built on Cloud Foundry and hardened for the enterprise, now supports vSphere, Amazon/AMI, HP Cloud Services, OpenStack, Citrix XenServer, and KVM infrastructure models.

ActiveState joined the OpenStack community in 2011, and committed publicly to making PaaS a reality for OpenStack deployments. As showcased with  Stackato’s successful deployment to HP’s OpenStack-based cloud, we’ve made good on this commitment, and are now pleased to offer OpenStack-ready Stackato for download with our latest release of Stackato.

Stackato—ActiveState’s commercial-ready, secure, multi-tenant platform for creating a private PaaS—is now the linchpin connecting Cloud Foundry and OpenStack.  Stackato’s enterprise-ready OpenStack support ensures that these two important ecosystems can be securely deployed together.

With Stackato, customers can deploy applications to either a private internal cloud (like ones powered by vSphere, XenServer, KVM, or OpenStack) or one hosted with a third-party cloud-hosting provider (like those powered by Amazon, RackSpace, or HP Cloud Services).

Stackato also now has SSH support, so you can have a secure interactive shell in any of your application instances. (Personally, this is my favorite new feature in this latest Stackato release.) This is possible (and safe) because each application instance runs in it's own para-virtualized container using LXC, providing more secure multi-tenancy.

In addition to OpenStack deployment and ssh support, Stackato has a new Management Console that replaces the Admin Dashboard with a new, improved user interface:

The Management Console offers deep visibility into the activity and events in a private cloud to help administrators better manage usage. This view includes showing activities of developers who deployed an application, number of instances deployed, memory usage, data services deployed, and languages used.

And there’s more: Additional updates in this latest release include improved application lifecycle management, improved Perl deployment speed, and new pre-staging setup hooks.

Take a test drive with Stackato on a microcloud (VM) on your own desktop or deploy directly to the Stackato Sandbox today!

<!–

–>

Last week, SD Times contributor Alex Handy published an interesting article titled The PaaS market accelerates. The piece was noteworthy not just for its insight into the burgeoning PaaS market space and introduction to the major players, but for some bizarrely unfounded assertions made by one of the article's subjects.

Really, Adam?

In his January 6^th SD Times article, Handy writes (emphases mine):

… Adam Wiggins, CTO of Heroku, said that PaaS is about the public cloud only. Although he used harsher language to describe the private cloud and PaaS market, he indicated that he and Heroku believe the private cloud to be entirely vapor.

"My opinion—and this is not a widely held opinion—is that private cloud is total BS. If you make it private it is no longer cloud. You destroy all the value you get from cloud by making it something you have to run yourself. Anyone pursuing that path is advocating a false trail," said Wiggins.

(At this point, the Enterprise IT Leads all do a spit take. I'm just curious to know what the unmentioned "harsher language" was.)

Really, Adam? "BS"? "Vapor"? Really? Is that the best you can do for FUD? Your comments are at best puerile, and at worst naïve. Let's focus on the naïve…

Save me, public cloud!

What Heroku's Wiggins is desperately trying to obscure is that in the real world, the enterprise demands private cloud and Private PaaS. Fortunately, he is correct in observing that his is "not a widely held opinion."

Wiggins suggests that customers derive value from the self-service nature of the public cloud, and that making the cloud "something that you have to run yourself" defeats its purpose. Hmm. Do I really want control over my own platform? My data is probably safe, I mean, it's in the cloud. And do I really want to deal with all that pesky provisioning and applications management and infrastructure administration and oh, I'm overwhelmed-Save me, simple public cloud!

If only it were that simple. As my colleague ActiveState VP of Engineering Jeff Hobbs noted in Handy's article, Public PaaS can lift the burden of cloud-management responsibility, lightening IT load. And public clouds also deliver benefits like shared-resource efficiencies, utility computing, and scalability. But let's be honest here: Every Public-PaaS developer promotes those same supposed advantages, and whee! The race towards commoditization is on. Indistinguishable public-cloud services foster desperate competition, which drives down price, which ultimately benefits the consumer…at least the one looking for the cheap solution.

Public PaaS: Slumlord of the cloud's low-rent district

In contrast with Private PaaS, the very nature of the Public PaaS' shared-services model enforces a lowest-common-denominator architectural approach. You're entering the low-rent district: You get what you pay for with public cloud ("First month free!"), and that means the same setup as the tenant sharing your virtual apartment building. ("Matching floor plans!") Does your company have unique data needs? Public PaaS may impose restrictive limitations on the way you manage your data. ("No pets!") Prefer a cookie-cutter approach, okay with limiting application portability, and don't mind sharing a multi-tenant virtual hallway? ("It's just like a hostel!") Then Public PaaS-at least as Adam Wiggins envisions it-might be right for you.

The real world demands Private PaaS

Recall those Enterprise IT leads? (I hope they've regained their composure.) They are the ones who are investing in private cloud and Private PaaS because it provides better security, better control, and-believe it or not, Adam-greater flexibility than public-cloud alternatives. Oh, and with the right technology, those Enterprise IT Leads can also realize those public-cloudy benefits like shared-resource efficiencies, utility computing, scalability, and even multi-tenancy.

But don't take my word for it. The U.S. Army recently invested a quarter billion dollars in private-cloud technology. Sure, you could argue that the military has special security needs that would never be well served by a public cloud. But so do very-much-not-like-the-military companies such as Federal Express. The package-delivery logistics giant has leveraged a private-cloud architecture in its newest data center, and even retrofitted an old data center to match. Even SD Times contributor Alex Handy noted in a November 2011 blog post that-despite Heroku's contention that private cloud is just "a myth and snake oil"-he could "entirely understand the need for an internal private cloud inside the major retailers [on Black Friday and Cyber Monday]."

Thanks Adam!

Don't get me wrong-I have long admired Heroku's accomplishments (particularly its carefully cultivated developer community), and Wiggins and team have produced some great technology. Let's face it, there will always be market segments that can settle for implementing a public-cloud solution. (Small business and municipal public sector are just two that immediately come to mind.) But ultimately, Wiggins' comments ignore (and even denigrate) the needs and priorities of the vast majority of the enterprise cloud market.

But you know what, the more I think about it, maybe that's not so bad. Who knows? Maybe Wiggins is right. Not that Heroku and Wiggins need my validation, but it's okay with me if they want to believe there's no future in private cloud and Private PaaS. Adam, you and Heroku can go play in your public-cloud-only sandbox. The rest of us will be just fine over here providing solutions for the real world.

###

About the Author

Originally published Tuesday, January 17, 2012 7:16 AM by David Marshallon VMBlog.

<!–

–>

Built on VMWare's Cloud Foundry Open Source project and hardened for the enterprise, ActiveState Stackato works on vSphere, Amazon EC2, and OpenStack, and will also support other infrastructure platforms.

While some PaaS offerings are content to rely on user-based Unix security, but ActiveState’s Stackato takes security a big step further, and is the first PaaS to bring lxc-based containerization to the HP Cloud, creating a more-trusted, commercial-grade level of security to private PaaS deployments.

So what’s the big deal about deploying a secure multi-tenant PaaS on HPCS, rather than on one that relies on Unix-based user level security, or one that shares resources amongst its tenants?

Why does multi-tenancy matter? (Hint: It’s more efficient.)

True multi-tenancy enables your organization to squeeze efficiencies out of a shared IaaS-level resource pool by running multiple applications on the same cloud servers. Multi-tenancy is what distinguishes PaaS offerings from Orchestration tools that do not manage multiple guest applications, but rather act as simple installers onto bare IaaS instances.

While multi-tenancy allows you to maximize usage of your allotment of cloud servers, having multiple applications running on the same server can be tricky (if not impractical) to secure.

Playing well with others in the PaaS playground

When you deploy a Platform as a Service, you provide a shared “playground” for a number of guest applications (tenants). The resource pool is presented as a single logical layer to those guest applications–The PaaS manages pools of OS resources and co-habits applications on shared instances.. Those guest apps should not have to be aware of the details of components that lie beneath the PaaS at the infrastructure level, nor should they have to be designed to play nicely with others. The PaaS layer should insulate both infrastructure and application from each other, and ensure that guest applications are not forced to be aware of other guest applications running on the same resource pool.

Some PaaS offerings manage the boundary between infrastructure and the application, But most do not, and PaaS solutions that offer only Unix user-level security leave openings for untrusted applications or users to exploit, and do not provide adequate security guarantees for the enterprise.

Securing the PaaS

Early on in the development of Stackato, ActiveState made the decision to extend Cloud Foundry, and take advantage of Linux technologies to provide better security. ActiveState's Stackato creates isolated, lightweight containers known as “lxc containers,”, Virtual Private Servers (VPS), or Jails. Conceptually, the containers are built atop several Linux technologies which provide each guest-application container with a segregated file system with web and ssh services.

The containers are protected from each other: a guest application in one container cannot read files owned by another container, or kill its tasks. With the Stackato-container approach, the outside world can still reach web servers and ssh servers on the containers and, more importantly, the hosting PaaS can protect its key files from guest applications and users in the containers.

The containers effectively allow Stackato to partition the resources into isolated groups to better balance conflicting demands on resource usage between the isolated groups. Stackato's innovative containerization approach has the dual benefits of running applications on a seemingly separate machine while still leveraging many of the underlying resources. As far as the guest application is aware, the PaaS has provided a private Playground. The architecture makes Private Cloud even more "private." For enterprises, the operational and security advantages of sharing these resources while isolating the guest applications can also lead to significantly lower overhead than true virtualization.

Implications for the HP Cloud Services platform

Adding support for HP Cloud Services to Stackato reinforces ActiveState’s commitment to providing the best-of-breed secure Private PaaS layer in the cloud that runs on HP's world-class hardware and software on OpenStack™ technology – giving your organization a clear alternative to Amazon Web Services.

The end result is a highly flexible, secure, multi-tenant PaaS layer that can be run in any environment (on-premises or in the cloud) helping your organization deliver a knock-out punch when if comes to securing your Cloud.

Stackato is a private PaaS that enables deployment, scaling, and management of Java, Python, Ruby, PHP, Perl, Node.js, Scala, and Clojure applications to any cloud. Stackato delivers the power of PaaS on-premise with the security, privacy, and control behind a corporate firewall. With Stackato, customers can deploy an application to either a private internal cloud (like one powered by VMWare vSphere™, Citrix XenServer, Linux KVM, or OpenStack™) or one hosted by a third-party cloud-hosting provider (such as Amazon or HP Cloud Services).

To see Stackato working with HP Cloud Services, we've provided this short screencast.
 

Developers and cloud administrators can download Stackato, currently in open beta including the free Stackato Micro Cloud, at: http://www.activestate.com/cloud.

<!–

–>

We had the opportunity to take HP Cloud Services (currently Beta) for a spin and get a Stackato cluster running there.

We were happy to take advantage of the computing horsepower HP made available to us to put Stackato through it’s paces and to try out a build running on Ubuntu 11.04, and we’re equally happy to report that it worked just as well as it did on EC2 and our internal VSphere testing cluster.

The video shows me deploying WordPress, as I did the recent Komodo video, but also talks a bit about how we got Bugzilla running in the cloud.

<!–

–>