- Developer Tools
Brent Smithurst, November 15, 2012SHARE THIS:
Since Stackato's GA (general availability) release in February, many of our customers and prospective customers have expressed their concern about vendor lock-in: They don't want to write applications that are specific to a single vendor's cloud infrastructure.
After all, cloud computing and particularly Platform-as-a-service (PaaS) technologies are relatively new concepts. The market has already seen some vendors go out of business, drop legacy(!) products after a very short time, or be acquired by former competitors. Understandably, nobody wants to deal with the fallout from that.
If I'm in charge of an organization's development or IT, I don't want to be the person who recommends and implements a product that soon ceases to exist. Aside from the impact on my own credibility, what would happen to my organization's apps, data, and (now sunk) investments in time spent developing for a defunct platform? Similarly, I may face the same problems if I just wanted to change suppliers at a later date.
At ActiveState, we address this fear in a number of different ways:
- Stackato's infrastructure-agnostic capabilities help you avoid vendor lock-in with any infrastructure or cloud provider.
- Stackato's polyglot support allows developers to write applications using any standard language and frameworks they choose. (Stackato doesn't mandate proprietary languages like some cloud competitors do.)
- You can export all data from Stackato at any time in standard formats. (Same holds true for importing data into Stackato.)
- Stackato is meant to be deployed on your organization's private cloud, so you're not impacted by a third-party's ability to run a service.
- ActiveState is an upstart, not a startup. We've been around since 1997, have a history of providing mission-critical software to enterprise customers of all sizes (including many very large and well known ones), are profitable, are not beholden to potentially fickle VC investment, and will continue to be around tomorrow.
- Stackato is built on top of various proven open-source components, including VMware's Cloud Foundry. In Stackato, we maintain API compatibility with Cloud Foundry.
Speaking of Cloud Foundry, the new Cloud Foundry Core program was launched on Tuesday with some fanfare. The Cloud Foundry about page explains the program: promoting cloud portability across different instances of Cloud Foundry. We think that's a noble intention.
As a longtime Cloud Foundry partner (and the community lead for Python), ActiveState's Stackato users and customers were surprised to see that we weren't included on the list of compatible products. To be completely honest, so were we. It turns out that the purpose of the program is to list public PaaS providers who share the common Cloud Foundry core. Because Stackato is not a public PaaS service (we put the "P" in PaaS but your organization's IT department or a service provider provides the "S"), we weren't included.
That makes sense, however our users and customers immediately asked us, "Hey, I thought Stackato was Core-compatible". The answer is, "Of course we are, that is one of our key Stackato design tenets." Stackato does have a public PaaS service of sorts -- the Stackato sandbox, which anyone can sign up for and try for free. Entering api.stacka.to into the Cloud Foundry Core "Test Endpoint" box was giving an error and we weren't sure why. After all, we know for a fact that Stackato is compatible with Cloud Foundry...
James Watters of the Cloud Foundry team was kind enough to point us in the right direction: a two month old Cloud Foundry commit with an innocuous description that turned out to be the secret sauce we needed.
One of our rockstar devs (recently christened "DFD") implemented the commit, applied to both cloud controllers that the sandbox uses, and we were in business.
Suddenly, entering api.stacka.to into "Test Endpoint" no longer returned an error! Even better, it credited us with two out of five checkmarks under Services! We were initially a little stumped as to why the other three Services remained unchecked.
Runtimes remained entirely blank of checkmarks, slightly stumping us further. Then, our superhuman intern Steven told DFD about a further upstream commit that provided information on those. Minutes later, DFD had implemented the new code on both sandbox cloud controllers, we refreshed the Cloud Foundry Core page, and we had some more checkmarks. Success!
What about the missing checkmarks? And why do the vendors in Cloud Foundry Core list have these other runtimes and services that are marked "Extra" while we don't? Well, that goes back to the Cloud Foundry Core definition. It turns out that a checkmark is granted only if the runtime or framework matches the specific version that Cloud Foundry Core Definition expects. (There is a note saying that they will introduce a system to show different versions in deprecated, current, and next columns.)
So, Stackato is missing checkmarks because our included versions of node.js, Java, Ruby 1.9.x, MySQL, PostgreSQL, and Redis differ from the Cloud Foundry Core baseline. In most cases, this is because our versions are newer. None of the additional runtimes, frameworks, and services provided by Stackato are listed at all (e.g. memcached, filesystem, Perl, Python, PHP, Erlang, and more). Furthermore, Stackato's support for extensible frameworks via Heroku Buildpacks are not considered either.
(You might be interested to check out our previous blog posts about Buildpack support using Java and Jekyll examples. Plus, this being ActiveState, we have complete documentation for Buildpacks as well.)
We plan to work at getting in sync with the Cloud Foundry Core baseline moving forward. This means that we may add some older versions of certain runtimes and frameworks, though we would keep the newer ones as well. Hopefully that will eliminate any confusion in the market around the Core definition by ensuring that Stackato meets the baseline (plus more).
All in all, we think that the Cloud Foundry Core program is an excellent step in the right direction. It should further help assure users that the Cloud Foundry ecosystem helps with application portability and eliminates vendor lock-in by default. It's true that all Cloud Foundry partners will tend to differ on exact runtime and service versions, and that the broader feature sets (and market focus) diverge as well. But at the end of the day, you can generally be assured that an application deployed to Cloud Foundry itself can also be deployed to one of its partners.
Trackback URL for this post: