- Get Stackato
- Why a Private PaaS?
- Features & Benefits
- Stackato by Language
- Compare Editions
- Stackato & Cloud Foundry
- Developer Tools
- Professional Services
- Commercial Support
- Code Recipes
Diane Mueller, February 17, 2012
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.
Subscribe to ActiveState Blogs by Email
Share this post: