We get asked occasionally about Stackato support for .NET. It’s clearly an important enterprise application platform today, but there are some technical challenges to supporting it on a Linux-based PaaS system.

Stackato, like the Cloud Foundry code base it’s built upon, has a modular design that can be extended to provide application hosting on any operating system – including Windows.

Tier 3′s Iron Foundry project does just that by providing a Windows-based DEA (Droplet Execution Agent) that works with Stackato.

Stackato & Iron Foundry Micro VM combo

The Iron Foundry and Stackato development teams have been working together to ensure smooth integration of our VMs. To add .NET support to a Stackato instance, you need to run a separate Iron Foundry Micro Cloud which handles .NET application hosting (the Iron Foundry DEA) and provides a MS-SQL database service. You can run the VMs side-by-side on the same hypervisor host, or host them separately. You just need to make sure they can see each other (e.g. by running in bridged mode). With the two VMs connected as per the setup instructions, you’re ready to push applications that use the .NET framework.

Get the VMs

To try this pairing out for yourself, you’ll need to download VMs to run on your local hypervisor:

• Stackato VM
• Iron Foundry VM

The Stackato forums and Iron Foundry Forums are there for you if you have any questions. Let us know what you think!

<!–

–>

One thing about Java applications is that you need to generate byte code
to execute it, and every Java developer knows that you should never commit
your byte code to source control because of the size (for pet-clinic, 500KB of sources become 40MB of compiled jars/wars). For this reason, with Stackato demo applications we generally recommend that Java developers do the extra step of compiling the bytecode before deployment.

With the preliminary support of Heroku Buildpacks in Stackato 1.2,
there’s now a way to make compilation happen as part of the app deployment.

So let’s explain both methods of deploying Java to Stackato.

Building it locally

The first way is to build the application before pushing to Stackato. This
method has been available all along in Stackato when using the ‘java_web’ and
‘spring’ frameworks:

1. Install Maven on your local system if you don’t have it

2. Build the application

   mvn clean package

3. Push it to Stackato

   stackato push -n

That’s all.

However, if your application uses a database like pet-clinic does, and if there are maven tests on this database, you will need to set up a local database to pass these tests. You could use the ‘-Dmaven.test.skip‘ argument to skip tests, but this is not recommended.

maven clean package -Dmaven.test.skip=true

It would be nice to run these tests against the actual database we’ll be using. We can do that using the ‘buildpack’ framework.

Using a Java Buildpack

Heroku Buildpack support is new in Stackato 1.2. Heroku introduced this system as a way for users to add custom frameworks to their PaaS. Stackato has other ways of customizing the application environment, but buildpacks have become popular, so we decided to emulate them in the Stackato environment.

In the case of our demo Java application, the Java buildpack allows the application bytecode to be built on Stackato instead of on your local machine. The Java buildpack also includes OpenJDK if you want to run a simple java application.

For the pet-clinic application for example, we need a Java-based server to run the application. To do that, we will use Jetty. Jetty is a light Java application server. It includes a Jetty Runner. The good thing about Jetty is that you can run your Java web application with a simple command just by providing the war file:

java -jar jetty-runner.jar application.war

Advantages of using the buildpack framework?

• You don’t need Maven on your local machine
• The application builds on the PaaS instead of on your machine
• You don’t have to push all the byte code
• You don’t need to set up a special environment for tests.

How does it work with Stackato?

It is really easy! You only need to modify three files.

First, in ‘stackato.yml’ you will need to define the framework type and to
provide the buildpack url. Here is the pet-clinic stackato.yml:

name: pet-clinic
mem: 512M
framework:
    type: buildpack
env:
    BUILDPACK_URL: https://github.com/heroku/heroku-buildpack-java.git
services:
    mysql-spring: mysql

As it is a buildpack application, you also need to create a Procfile in
which you declare how you want your application to be executed. Here is the one
from pet-clinic.

web:    java $JAVA_OPTS -jar target/dependency/jetty-runner.jar --port $PORT target/*.war

And finally, add the jetty dependency in your pom.xml
in order to run your application.

<build>
    ...
    <plugins>
        ...
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-dependency-plugin</artifactId>
            <version>2.3</version>
            <executions>
                <execution>
                    <phase>package</phase>
                    <goals><goal>copy</goal></goals>
                    <configuration>
                        <artifactItems>
                            <artifactItem>
                                <groupId>org.mortbay.jetty</groupId>
                                <artifactId>jetty-runner</artifactId>
                                <version>7.5.4.v20111024</version>
                                <destFileName>jetty-runner.jar</destFileName>
                            </artifactItem>
                        </artifactItems>
                    </configuration>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

And that’s it! Target your Stackato server/cluster with the client, login, and push your application.

So there you have it – more ways to get your applications working in Stackato. You choose the one that fits your development style.

<!–

–>

Release of new, more powerful Stackato Private PaaS Solution Coincides with HP Cloud Services Public Beta

I’m pleased to announce that ActiveState and HP Cloud Services have formed an extended partnership, ensuring support for Stackato 1.2 running on HP Cloud Services. Stackato is the application platform for creating a private Platform-as-a-Service (PaaS), and its industry-leading cloud application security, data privacy, and control are now available on the HP Cloud Services infrastructure.

This announcement coincides with the upcoming HP Cloud Services move to public beta. It follows on the heels of the successful launch of Stackato version 1.2, a major upgrade that delivers several new features, including persistent file system services (and associated Drupal compatibility), enhanced app store functionality, integrated debugging support with Komodo IDE, Heroku build-pack support, and configurable user/group permissions and quotas.

HP Cloud Services (HPCS) is based on HP’s world class hardware and software, with key elements of HP Converged Infrastructure combined with a developer-friendly integration of OpenStack™ technology. Available soon in public beta, HPCS offerings include HP Cloud Compute, HP Cloud Object Storage, and the HP Cloud Content Delivery Network.

With this integration, developers and enterprises can quickly and seamlessly create a private PaaS in HP Cloud Services without having to download a virtual machine.

Stackato 1.2 on HPCS infrastructure provides a secure middleware layer to complement HPCS’ unique hybrid delivery solution for private, managed, and public cloud deployments. Stackato’s support for HP Cloud Services gives enterprise developers more options and flexibility when choosing their cloud infrastructure services, while offering all the benefits of a private PaaS to deploy, scale, and manage applications.

“ActiveState enjoys a mutually-beneficial partnership with HPCS,” says Bart Copeland, ActiveState CEO. “Stackato’s support for HP Cloud Services reinforces our vision of delivering ‘cloud control’ to support any underlying infrastructure, benefitting enterprise developers and IT/DevOps with the flexibility and deployment options they demand.”

<!–

–>

Platform-as-a-Service is the future for deploying and managing Internet applications. It promises to provide an environment that abstracts the hard stuff (operating system, web server, programming language environment, databases, etc) and leaves you with the joy of just saying “Run this app, please”. With ActiveState’s Stackato, not only can you do that, but you own the entire PaaS system, and you run it wherever you wish.

How easy is it to install a complete Stackato PaaS? Very. It’s just a download and a few clicks. How about deploying popular applications like Drupal or Bugzilla to your new Stackato PaaS? Even simpler. The Stackato App Store makes them a click away. What if you want to install your favorite apps that are not yet in the store? No problem. You can create your own App Store and it’s amazingly easy to do.

In this article, I(ngy döt Net) will teach you how to do all three of the simple and exciting exercises above. Let’s get started…

Installing Stackato

Stackato can be installed as an enterprise cluster of 1000+ nodes running on Amazon EC2, vSphere, or OpenStack, but it will also run as a single virtual machine (VM) on your laptop. Since deploying Stackato as a single node (we call it Micro Cloud licensing) is completely free of charge (forever), let’s do the the latter.

The first thing you’ll need to do is download a copy of the Stackato VM. This free download is available here. In a nutshell, Stackato is just a VM image that is ready to boot up as a server. It is packed full of all the system software needed to get your apps running immediately. Stackato VM images are prepared for a bunch of different virtualization hypervisors. Since you are on a laptop, you’ll probably want to use VMware Fusion/Player or VirtualBox, which have free versions. Download the Stackato image that matches your hypervisor software.

Note: The Stackato image is 1.2GB, so now is a good time to get a cup of
coffee (or a good night’s sleep), depending on your bandwidth.

Pro Tip: Start the download now, and hopefully it will be done by the
time you finish reading this.

After you unzip the Stackato download, you’ll want to get the image into your hypervisor. For VMware you can just “open” and “play” the .vmx file. For VirtualBox, you’ll need to “import” and “start” the .ovf file (and also adjust the Network Settings). In either case, you should see a Linux VM booting up in a window. Your Stackato is coming to life…

When the Stackato VM has booted, you will see a URL to a unique local domain. Just type that URL into a web browser. This is where the real fun begins. The (now running) Stackato serves up a web based Stackato Management Console (SMC), which you can use to do most of the common Stackato operations (and all the operations discussed here). For instance you can install apps, stop and start and launch them, view their logs, see pretty system graphs, and many many other things that I encourage you to explore on your own.

The first thing the SMC wants you to do is enter your email address and a password. Your email will be your Stackato id. You are now the administrator of this Stackato. That means you have full control of everything. The password you’ve entered, is also now the password of the stackato Unix user, should you want to ssh into the actual Stackato VM. This is a real live server, it’s yours, and you have the keys to the castle, if you want to dive deep. But let’s get back to the fun stuff!

Note: The above process will work on a laptop that is running Mac, Linux or Windows, but with some caveats. For instance, you’ll need sufficient RAM, 64-bit capabilites and some network tweaks on Windows. If you have any problems, see the rich Stackato documentation.

The Stackato App Store

If you look at the left side of your SMC, you’ll see a link to the App Store. Click it! You’ll be presented with a cornucopia of applications written in many programming languages. If you wanted to run all these by setting up your own server, it would likely take you days. With the Stackato app store, it’s just a few clicks.

Try it. Click “Install” on an interesting app. You’ll be prompted with some basic setup info. Usually the defaults are just fine, so click the “Install App” button. In a few seconds your app will be installed. You should now see your “Applications” page. From here you can start your app. Once it is fully started, you’ll see a launch button. This will take you to your brand new running app. Viola!

So what is the App Store exactly? It’s not a store in the sense that you have to buy anything. The App Store is simply a collection of links to software that is ready to run on Stackato. Currently these applications are all hosted as GitHub repositories. In fact, the link to “More Information” on each App Store app, points to the GitHub page for that app. Click it to read the app’s documentation and instructions. If you are a developer, you can clone the repo, change the source code, and push it to your Stackato VM using the Stackato command line interface.

You can think of the Stackato App Store as the rabbit hole to a PaaS wonderland. The folks at ActiveState are adding new apps to the App Store every day. You may just end up using Stackato to host your favorite off-the-shelf apps, but Stackato strives to be the deployment platform of choice for application developers.

Creating Your Own App Store

I’m not certain that I’ve conveyed just how ridiculously simple a Stackato App Store is. I said was a collection of links, but let’s take a closer look.

If you click on “Settings” in the SMC, you’ll see a set of tabs. Click on the Stores tab. You should see a list of URLs hosted by ActiveState. The URLs are links to JSON files. For instance, look at this one. If you understand JSON (which is about as simple as it gets) it’s pretty easy to see what’s going on. These JSON files just contain meta-data about application sources. The App Store fetches this JSON info and presents it to you in a graphical and interactive manner.

With Stackato 1.2, you can change the JSON sources to whatever URLs you want, as long as they return the proper content. In other words, all you need to do is host a static JSON file, and tell the SMC about it. We call this the “App Store 2.0″ and it’s a great example of how open ActiveState is making the entire Stackato platorm.

There are many ways to host static files, but here is a really simple and free way to test it out. Go to the link above, and copy the JSON text, then go to https://gist.github.com and paste it into the text box. Make a small change to the JSON text (possibly change an app desc value) and then click the “Create Public Gist” button. Next, find the “raw” link on the page and click that. Now you’ll have a hosted static raw JSON file on the Internet! Copy the URL to the SMC’s Setting’s list of App Store URLs. That’s everything. If you go into the App Store now, you’ll see your own App Store data.

Conclusion

I started by asserting that PaaS is the future of computer application deployment. Stackato is polishing that future at every level. I hope this gives you a glimpse of the future, and that you try it out today.

<!–

–>

Deploy Drupal where you want

Stackato lets you run Drupal, the popular content management system, on public clouds such as AWS and Rackspace, or on private clouds powered by VMWare, CloudStack or OpenStack. With Stackato, you choose the cloud hosting provider that best fits your organization’s requirements.
 With one ‘stackato push’ command or one click in the Management console, you can make Drupal available on any Stackato PaaS deployment.

Here at ActiveState, we’ve been huge fans of Drupal for years. Both the ActiveState corporate and community sites are powered by Drupal, so it was only natural for us to want to get it working nicely on Stackato.

Scaling Drupal in the Cloud isn't trivial

With Al Jazeera, Time Inc, Turner, World Economic Forum, Stanford University, New York Senate, and NPR all running their extensive web properties on Drupal, we know that Drupal can scale. It’s not easy though – not because Drupal can’t scale, but because replicating multiple instances of Drupal and its software stack in the cloud takes a fair amount of skill and requires a way to share user-contributed files between those instances.

Cloud application instances in Stackato—and in most other PaaS solutions—are ephemeral, and the storage on those instances is ephemeral as well. If the instance is shut down, the data on it goes away. That’s not a very desirable configuration if you are deploying an application such as Drupal that expects (and requires) a persistent file system.

To solve this problem, Stackato offers a file system service that can be shared between application instances. Just like the data and messaging services, this service can be created using the ‘stackato create-service’ command or specified in a YAML config file to automatically set up the service for an application.

You can link this file system to Drupal’s ‘sites/default’ directory, and even specify multiple file system services to share themes and modules between multiple Drupal sites.

Deploying Drupal: Insanely simple with Stackato

Stackato automates deploying, managing, and scaling a Drupal application-appropriate stack and makes it insanely simple to deploy Drupal on your private cloud:
1.    Download the Stackato VM, request access to the AMI, or sign up for the Sandbox.
2.    Go to Github and get ActiveState’s ready-to-run Drupal branch, which is ready to run.
3.    Target Stackato and enter 'stackato push -n' from the ‘drupal’ directory.

Deploying from the App Store is even easier!

Drupal is now featured in the Stackato App Store

Just launch Stackato's Management Console, navigate to the App Store, browse to the Drupal item  and click ‘Install’. You can even import data from existing Drupal deployments using Stackato’s ‘tunnel’ and ‘ssh’ commands.

Why Drupal on a Private PaaS? Manage & Scale multiple web properties with ease

Today’s real-world enterprise maintains more than just a single web property. Stackato enables corporate IT to easily manage and distribute multiple Drupal-powered sites across an enterprise to produce a consistent experience, while centralizing the administration, security, and control of key IT activities.

Stackato can scale Drupal when your organization needs access to elastic capacity to meet traffic surges. An enterprise can easily manage the secure deployment of multiple Drupal instances while securely encapsulating each web property.

Content can be managed locally while web site deployments are coordinated centrally. By deploying a private PaaS, an enterprise can rapidly develop a consistent web experience, easily redistribute it to various web properties, and continue to manage and evolve the underlying IT infrastructure.

For a quick overview of Stackato and a walk-thru deploying Drupal, watch this YouTube video.

Test drive Drupal today on a Stackato Micro Cloud, with on Amazon EC2 or on our Private Stackato Sandbox Service today!
 

<!–

–>

It’s getting harder and harder to give short Stackato demos. We’ve been adding so many cool features that it’s hard to cover everything. With the release of 1.0.6, we needed an updated demo screencast to show off the Management Console and the App Store, but that leaves less time for explaining the core workflow.

So, with this demo I gloss over some things that are covered in previous screencasts. To get the full picture, feel free to supplement the information in the new screencast with some of the previous material:

• Stackato Demo – Micro Cloud to Private PaaS: This is the first screencast we made for a beta version of Stackato. It goes into a lot more detail on the initial setup of the VM and the client, so if you get stuck setting up your own Stackato micro cloud, have a look at this one.
• Komodo IDE and Stackato: Yes, there’s integration with Komodo too! This video shows how to push applications from Komodo IDE and use its Database Explorer to view and modify the automatically provisioned database services.
• Stackato on HP Cloud Services: Though this demo was made to show Stackato running on HPCS, it also deals with a very important part of Stackato’s security model – the use Linux containers (LXC) for isolating the hosted applications. This allows Stackato to offer SSH access into the user’s application containers for running remote commands.

You may get sick of hearing me say “Hi, my name is Troy Topnik” but hopfully there’s enough information here to get you started setting up your own Stackato VM, or taking it for a spin in our developer sandbox. There’s are active forums on the Community site if you run into any difficulties and the #stackato IRC channel on freenode. Come join the discussion.

<!–

–>

Deploying and configuring your own single instance private PaaS on EC2 with Stackato is almost as easy as downloading a micro cloud virtual machine (VM) to your desktop. The ActiveState team has created an Amazon Machine Image (AMI) with Stackato installed that is ready to run on EC2, with a few minor configuration tweaks that even a Newbie to the cloud can figure out. The Stackato AMI is available for free subject to the terms and conditions of the Stackato Micro Cloud License Agreement.

How simple is it?

To get Stackato up and running on EC2, all you need to do is launch an EC2 AMI, configure an IP address and domain name, SSH into the instance, perform a few simple stackato-admin commands, and then launch the Stackato Web Management Console to complete your setup and configuration. Download the Stackato Client and you’ll be able to push your applications directly to the cloud from your desktop.

Getting Access

Before you can get started, you must first have valid AWS credentials so that you can use Amazon’s web services. You can either sign up for a new AWS account or use your existing AWS credentials. If you’re creating a new Amazon account, you will need to provide a credit card to complete the sign-up process. At the end of each month, Amazon will charge your credit card for the cloud-related usage costs associated with your AWS account.

You’ll also need to send an email request to the ActiveState Stackato Support team with your AWS Account Number (shown in the upper-right corner of the AWS “Manage Your Account” page).

Once you have received your email confirmation from ActiveState that you’ve been granted access – you can spin up your own private PaaS on a small EC2 instance in a few quick steps.

1. Launch an AWS Instance of Stackato




2. Associate your Domain Name with your Stackato Instance’s Elastic IP Address




3. Log in to your Stackato Instance with SSH/PuTTY




4. Adding your domain to /etc/hosts




5. Use the “stackato-admin” Command Basics




6. Sign in to the Stackato Web Management Console

Step 1: Launch an AWS Instance of Stackato

The AWS Management Console provides a web interface for Amazon Web Services. You can start and stop EC2 instances, view and perform actions on running instances, set configurations (e.g. security groups, key pairs, and Elastic IPs) and modify them using interactive controls.

Log in using your AWS account name and password. Navigate to the “Amazon EC2 Console Dashboard” and click on the “Launch Instance”. This will launch the “Request Instances Wizard” for you.

From your AWS console, search the Amazon “Private Images” catalog for the latest Stackato AMI using the string “stackato“. Select the Stackato AMI ID.

Choose the Instance Type “(m1.small, 1.7 GB)”. This is the least expensive option and a good one for testing purposes. For a production environment, you will need to deploy a cluster of instances and assign different roles to each of them to spread the workload more efficiently. The Stackato AMI is currently only available for use in the “us-east-1a” EC2 Availability Zone, so select that zone at this point.

Click on “Continue” and accept all the defaults on the Advanced Instance Options for now.

Next, give your AMI a user-friendly name or “key”. This makes it easy to identify later if you deploy more than one instance.

There is a default password for the Stackato AMI. You will be prompted to change it when you launch the Stackato Web Management Console for the first time. Click “Continue” on the “Create Key Pair” page and go directly to “Configure Firewall” to set up a Security Group.

Using the “Create a new rule” drop-down list, select each of the following rules: SSH, HTTP, HTTPS and DNS. This security configuration will allow you to securely shell into your instance using SSH/PuTTY and configure your instance so that it can be accessed using a domain name of your choice.

Review your choices and hit “Launch”. Be patient as it may take a few minutes for Amazon to fulfill your request. When the instance is available it will appear in your AWS Console as a “running instance” with the name you chose earlier.

You have a live Stackato Instance. Now you just have to make it “yours” by mappng your domain name to the instance.

Step 2: Associate your Domain Name with your Stackato Instance’s Elastic IP Address

The Public DNS and your Private IP Address assigned automatically by AWS are ephemeral. They do not persist when an instance is restarted.

To map a DNS entry to Stackato, you need a persistent IP address. Amazon EC2 provides Elastic IP addresses, which do persist through reboots. Any Elastic IP addresses that you associate with your account remain associated with your account until you explicitly release them.

To allocate a new Elastic IP address for use with your PaaS

1. Click Elastic IPs in the Navigation pane. The console displays a list of Elastic IP addresses assigned to your account.
2. Click Allocate New Address.
3. In the confirmation dialog box, ensure the value for EIP used in is set to EC2, and click Yes, Allocate.

To associate the Elastic IP address with an instance

1. Click Instances in the Navigation pane. The console displays a list of instances.
2. Write down the instance ID to associate with the Elastic IP address.
3. Click Elastic IPs in the Navigation pane. The console displays a list of Elastic IP addresses assigned to your account.
4. Select an address and click Associate Address.
5. In the Associate Address dialog box, select the instance from the Instance list box and click Yes, Associate.

For this example, I registered the domain “gorilla-mgmt.com” through Dreamhost.com, so I use Dreamhost’s domain management console to make the DNS changes to point to the AWS instance. In this example, I am using a subdomain called “paas” to associate with the Stackato PaaS running on the AWS instance.

Type in your “AWS Elastic IP” in to the “Value” field of the CNAME Record. You’ll need to add add a “.” at the end and then save your changes. Depending on your domain hosting provider, it may take awhile for this change to take effect.

Step 3: Log in to your Stackato Instance with SSH/PuTTY

You need to tell Stackato about your instance’s “Private IP address” and your chosen domain name.

Log in to your machine via ssh as user “stackato” with default password “stackato”. Note: Do not change the unix user password in this step – it will happen in a later step.

While Secure Shell or “ssh” may sound daunting, it really is just a secure way to log into a remote computer as an authenticated user. If you’re using Linux or Mac OS X, use the ‘ssh’ client that comes with the OS, if you’re using Windows get a copy of PuTTY.

Launch PuTTY from your desktop and type in your AWS Public DNS address in the Host field, then click “Open”.

Click the “Open” button and you’ll be prompted to login to your instance for the first time.

This first time, you’ll login as the user “stackato” using the default password which is also “stackato”. Do not change the password yet, this will be done in a later step.

Step 4: Adding your domain to /etc/hosts

You’ll need to add a line in the ‘/etc/hosts’ file to resolve the domain name added above to localhost via the 127.0.0.1 loopback address.

To make these edits, you’ll need to use a console text editor like “Vim”, which is already installed on your EC2 instance (if you don’t know how to use it, here’s a useful cheatsheet).

To edit the /etc/hosts files, you’ll have to run vim with the “sudo” command – which allows you to run programs and commands with the security privileges of another user (in this case, the superuser, or root):

$ sudo vim /etc/hosts

You’ll need to add one line to the top of the /etc/hosts file, substituting your domain name for the one used in this example.

127.0.0.1 localhost stackato paas.gorilla-mgmt.com api api.paas.gorilla-mgmt.com

When you save the file, you may get an error message such as the following: “unable to resolve host stackato-xxxx”. This message can be ignored.

When you are finished editing your /etc/hosts file should look something like this:

Step 5: Becoming Stackato: the “stackato-admin” command basics

While still logged in with PuTTY to your instance, you’ll need to type in the final configuration using a few stackato-admin commands and then reboot your instance.

The email address used in this step should be the same as for the user who will become the first admin user of the system in Step 6.

The “private instance IP” is the one noted as Private IP Address for your EC2 instance.

From the command line, type in the following stackato-admin commands substituting your domain information :

$ stackato-admin admin grant admin1@gorilla-mgmt.com
$ stackato-admin become all -m 10.110.201.176 -e api.paas.gorilla-mgmt.com -h paas --domain paas.gorilla-mgmt.com

Now reboot so all the changes take effect.

$ sudo reboot

When you do the “reboot” from PuTTY, your session will automatically end and disconnect.

Step 6: Sign in to the Stackato Web Management Console

Direct your browser to https://api.<Fully Qualified Domain Name>/. In this example, you would go to https://api.paas.gorilla-mgmt.com.

This will take you to the initial console setup welcome page. Use the same email address here that was granted admin permission in the previous step. The password that you provide here will also become the stackato system password, replacing the default password that you used to do your first login.

After that, you are ready to deploy apps to Stackato, your own single instance personal Private Paas on EC2!

To learn more about deploying applications to Stackato and navigating the Stackato Web Management console, watch this short YouTube video.

Thinking about setting-up a cluster for to scale for production use? Be sure to contact our sales team to learn how Stackato Enterprise can help your business.

<!–

–>

With this move, Citrix has elevated CloudStack's "open-sourciness," but hasn't changed CloudStack's fundamental operating model: Citrix will continue to offer a commercial CloudStack infrastructure solution, but it will now be built upon a much-more-widely supported open-source framework. The Apache relationship gives CloudStack instant newfound clout with developers, and promises new potential for customers of all shapes and sizes developing cloud services.

At ActiveState, we've long recognized the power of open source to drive innovation within the enterprise. Stackato, the application platform for creating a private PaaS, is based on the open-source Cloud Foundry framework. Stackato already provides full support for the CloudStack infrastructure platform, and today's announcement represents a validation—of open source, of CloudStack, and of Stackato's enterprise-ready model. The CloudStack/Apache marriage offers great opportunities for a broader community of developers and partners to build commercial-grade extensions upon CloudStack. And that can deliver on the promise of enterprise cloud success.

"CloudStack's evolution means greater visibility, flexibility, innovation, and opportunity," says ActiveState CEO Bart Copeland. "It provides greater visibility for both CloudStack and ActiveState's Stackato, more choices for customers, and opportunities for development innovation. I look forward to seeing the exciting ways CloudStack will be extended in the future."

"Stackato's private-PaaS middleware solution complements CloudStack," notes Sheng Liang, CTO of the Citrix Cloud Platforms Group. "And with its open-source heritage, ActiveState bridges two leading open cloud communities—open source Cloudstack at an infrastructure layer, and the open source Cloud Foundry at the PaaS layer."

Since its introduction in 2011, ActiveState's Stackato has supported Citrix Xen and XenServer infrastructure, and by extension, CloudStack. Being part of the market-leading Apache development community will raise CloudStack's visibility, and can only help drive cloud-computing adoption. When Stackato is paired with CloudStack, enterprise customers can deploy an open source-based private cloud with the assurance of enterprise technical support from both Citrix and ActiveState, and the full collaborative support of the Apache open source community. And that's an enterprise model that benefits from the best of both the open source and commercial development worlds.

<!–

–>

I’ve been using the Internet since the pre-browser times… circa the Gopher protocol. Admittedly, not the earliest of adopters, but still before at least one of my current coworkers was born. I’ve been active in writing and promoting Open Source since 2000. In that year I went North to help a little Canadian dot-com company who embraced everything Open. I left after less than a year, but ActiveState survived the bust, stabilized into a solid company supporting Open in the Enterprise, and more recently has raised its voice in the Cloud Computing arena.

Dark, Cloudy Skies

I’ve been watching the Cloud movement for a few years, and to be honest I’m not liking it overall. The Internet was designed to be a decentralized network of peers, where a little glitch (like say a nuclear war on continent X) could be routed around in a few microseconds. It held the promise of connecting every human to all shared knowledge. In those Gopher days (and for years after) monetization was not even on the table. If you have any hopes of the Internet remaining Free, watch this inspiring speech by Eben Moglen.

Cloud computing smacks of power grab. Offer the shiny candy of deployment-in-seconds, and build the biggest centralized user base that you can. Now you have a wealth of information and wallets to tap into. Not only that, so does anyone who attacks your systems. Oops. Not possible on your system? BS. Any server cluster on the Internet can be cracked, and bigger clusters make bigger targets. Anyone who tells you differently is selling something. Even more disturbing, thanks to the Patriot Act, any server under American jurisdiction can be accessed (by subpoena) through the front door. We live in scary times.

PaaS it On

Last Summer I ran into an old ActiveState coworker from my past. He gave a short talk on what ActiveState was doing in the Cloud. I tuned out. I was annoyed. ActiveState always did the right things. Why the Cloud nonsense? I found him later in the hallway and tried to poke fun at him for ActiveState jumping on the Cloud bandwagon. When he showed me that they were doing Private PaaS, I saw the light. Decentralized Shiny Candy! I was on-board. I got myself hired back by the end of the day.

Oxymorons (minus the Oxy)

Since returning to ActiveState I have worked hard to help get a solid Enterprise-ready Private PaaS solution out the door. It’s called Stackato, and it went 1.0 last month. Yes, you can deploy apps in all the popular languages and frameworks in seconds. The difference is that it can live anywhere you see fit: your laptop, your data center, EC2… It’s up to you.

What if you could have all of, say, Heroku running behind your own firewalls and under the control of your own IT dept? That’s Stackato. Your company’s developers all have the same instant gratification of deployment, but your CTO has the peace of mind that nothing has left the building. This is the future, and I actually want to live in it!

In recent months there has been vocal opposition (albeit without much substance) to Private PaaS. "If it’s private then it’s not up in the Cloud". Given that "Cloud" seems to mean about anything people want it to, this could be a valid argument, or it could be total BS. Let’s try both:

• If Cloud means that the Internet needs to be hosted in very large, centralized server locations, then sure, Private PaaS is an Oxymoron.

• If Cloud means the clean abstraction of modern computing into IaaS and PaaS, then asserting that those abstractions must be conflated is simply Moronic.

Now your IT department can click 2 buttons: which PaaS to use and which IaaS it lives on. IT can happily give their users the convenience they deserve, without throwing away every other concern into the vapor.

<!–

–>

We’ve been remiss in making screencasts for all the new features in Komodo IDE 7. To remedy that, Todd Whiteman has made this short video showing off Komodo Collaboration. You can share buffers (existing files or new documents) with other Komodo IDE users in real time and see everyone’s changes highlighted and tracked. This is similar to the functionality available in online tools like Google Docs or Etherpad lite, but with all of the editing and code intelligence features available in Komodo.

This new feature gives you:

• real time editing
• the ability to share with individual users and/or limit access to individual files
• visual indicators for where people are editing and the text they have highlighted
• secure HTTPS/SSL connections – only authorized users can see the code you share
• full Komodo editing support – commands, code coloring, syntax highlighting, etc…
• unlimited collaborators – how many friends ya got?

Pair programming

When ActiveState was a part of Sophos, the PureMessage team made the big jump to adopting the Agile methodology and using pair programming. This involved a big change in the office layout to accommodate pairing stations, where developers could sit side-by-side and work on code collaboratively. Each station needed two keyboards, two mice, two chairs, and the corresponding desk real-estate. That would be an unfeasible change for a team that just wants to experiment with pair programming or use it only sporadically.

With Komodo Collaboration, you can get some of the benefits of pair programming without having to rearrange your furniture. You can still grab your laptop and go sit with your colleague, but you don’t have to fight about who’s key-bindings are going to be used (the Vim vs. Emacs issue for example) or give up any editor customizations you’ve made (theme, macros, snippets, etc.).

Distributed development teams

Most distributed teams of remote developers become adept at communicating via email or IRC and using pastebins to pass code back and forth, but working together in the same buffer is much more efficient. With code collaboration in the editor, pair programming suddenly becomes a possibility. With Komodo, a headset, and Skype, you get pretty much the full pairing experience without having to put on pants.

How it works

Behind the scenes, here’s how collaboration in Komodo IDE communicates with the central server hosted in ActiveState’s network:

• Komodo IDE connects to the ActiveState server over HTTPS
• Users are authenticated using their ActiveState single sign-on account
• Shared files are stored on the ActiveState server.
• Changes made by users are propagated to the ActiveState server
• The ActiveState server then re-propogates those changes to other authenticated users accessing that file

So try it out and let us know what you think.

If you like what you see, note that Komodo IDE is on sale till March 31.

<!–

–>