ActiveBlog

Stackato 2.4 Released: PM Perspective
by Brent Smithurst

Brent Smithurst, November 2, 2012

Stackato 2.4 shirt I'll start this post with the usual, "ActiveState is excited to announce the release of Stackato 2.4. It's the best version of Stackato yet!"

I have no problem saying that, because it's totally true. We are excited. It is the best version yet. And we know that you'll be excited too. Meanwhile, over at our Stackato forum, Jeff is merely "pleased" about the announcement. (I guess it takes a lot to excite a CTO.) But I digress...

If you simply want to see the complete list of changes, Jeff's forum post and the release notes have everything covered. Of course, our marketing team put out a really nice press release too.

I'm taking this opportunity to talk about this release from a product management perspective. I'll tell you about a few of the new features and capabilities in Stackato 2.4, but I'll also inject some commentary about how some of those feature requests came to be, how they might benefit you, and a bit about how our development process works.

Themeable (Easy for OEM partners to re-brand/re-theme the console and CLI)

Stackato is different than other PaaS (Platform as a Service) solutions. Some say that Stackato itself is not a PaaS until somebody deploys it (i.e. Stackato is a Platform, but there is no Service component offered by ActiveState). As soon as "ABC Organization" deploys Stackato, it becomes a PaaS, because now the Service component is enabled. In other words, Stackato is the P in PaaS and "ABC Organization's" IT department offers the S (to their internal customers). This is what private PaaS is all about.

We've got lots of enterprise customers using Stackato on their private cloud in interesting and innovative ways, including ExactTarget. But we also have several cloud hosting (IaaS) providers of varying sizes who are interested in offering their customers a PaaS. Some of them want to re-theme Stackato's web console and offer "ABC PaaS" instead of Stackato. This new feature makes it easy for them to do so (it does require an OEM license).

Of course, it was always possible for us to re-theme the console for a partner; it just required a lot of manual effort that needed to be re-done every time a new version of Stackato was released. The point of this new feature is that it is now very simple to do; once done, the theme can be transfered to a new Stackato release with minimal (next to no) effort. So, the time invested to implement this feature will be paid back many times over in the future.

Centralized logging and log forwarding with Logyard

Troy wrote a blog post earlier this week that explains Logyard in great detail. What's kind of cool about it is that I had an existing customer and multiple prospects (one of whom is now a paying customer) ask me about log aggregating and/or forwarding within a week of the development effort beginning. A few people had inquired about log forwarding earlier this summer, and that's why it was in the feature backlog in the first place. But then nobody asked again until a few days after we started working on it. The serendipitous timing proved that we were onto something important!

But what's really cool about Logyard is how our dev team starting working on it. As I said above, we maintain a feature backlog (using the amazing Trello). Items are pulled out of the backlog and assigned to the current development version plus one or two future versions, and are ranked in order of priority. One of our incredible developers saw the third-party logging feature in the backlog and asked a couple of questions about it (it was very sparsely spec'd by yours truly; in fact, it wasn't within 50 yards of the word "spec"). I answered his questions and didn't think twice about it.

A few weeks later, he grabbed Jeff and I and was diagramming his thoughts on a whiteboard. Part 1 of his plan was log aggregation; that would enable new capabilities for developers and IT administrators. It would also enable Part 2: log forwarding to third-party services. Until that session, I hadn't truly understood the problem that was being solved. All of a sudden a lightbulb went off and I couldn't believe that I had been letting this languish in the backlog. He was confident that he could deliver the feature for v2.4, so we added Logyard to the 2.4 column in Trello. Done!

It's a perfect example of what makes the development team at ActiveState so great. The developer wasn't a cowboy just cherry-picking something from the backlog for the heck of it. Instead, he saw an item in the backlog, thought about its usefulness, thought about how to implement it, then brought a more or less completely fleshed out solution forward, convinced us that it should be higher priority than other items, and then actually delivered it on time in a very compressed schedule. How rare is that at other companies? How cool is that?

Web Console Improvements

I'll end with a grab bag of improvements that add up to more than the sum of their parts. There is little doubt that Stackato already has the industry leading web management console. We also have some major feature additions coming in the near future. But for 2.4, we focused on tackling a bunch of niggling issues that, for lack of a better term, just bugged us and our users.

Which DEA does my app live on? So many users asked this question that I almost lost count. One of the assumptions of our architecture is that you shouldn't really care or need to know this. Your app gets deployed to the best available DEA (algorithmically determined) and if it requires more instances, it gets deployed to additional DEAs. So, who cares which particular DEA your app is on? Well, it turns out that there are times you really need to know. One simple example is if you need to take down a particular piece of hardware for whatever reason (power supply swap, RAM upgrade, etc.). You know which DEAs live on that piece of hardware, but you don't know which apps will be affected if those DEAs go down. I know, I know -- if your app's DEA goes down, another instance will spin up when needed. But, assuming your app only had a single instance originally, that will result in a couple of minutes of downtime and an unpredictable loss of control for the administrator. So, in the app details, we now show the DEAs that each app is on.

Auto-start apps when pushed from App Store. In previous versions of Stackato, you'd push an app from the App Store and then go to the Application Details screen where you had to click the start button. Perhaps not the biggest problem in the world, but it consistently led to confusion for new users. They naturally assumed that something had gone wrong. This turned out to be a universal perception amongst a focus group a short time ago. They'd push an app and almost instantly say, "My app seemed to push okay, but it didn't start! What did I do wrong? What happened?" We'd answer, "Nothing went wrong; you just have to start the app now." And they'd say, "That's stupid! Why didn't it start itself?" Now, there legitimately are cases where you don't want an app to start automatically after deployment. However, these users had a good point so we added a button to Start app after installation when deploying from the App Store. Confusion removed and case closed.

Activate or de-activate App Stores without deleting them. The Stackato App Store is often misunderstood. Yes, you can use the apps that are in there as-is. But there are at least two other great reasons to check it out. First, you can use it to view the source of the apps that are in it. Read the ReadMe and view the stackato.yml file for each app to see how easy it was for us to move it to Stackato (just click the More Information link in the App Store). Second, you can completely customize the App Store with your own apps. If you wanted to remove ours, you've always been able to do so by deleting the entries in Settings > System. But, there was no way to get those entries back (other than finding out what they were and typing them back in). So we added a checkbox that enables or disables an App Store without deleting it. Simple, yes? And suprisingly effective! Bonus tip: to remove the App Store entirely for your users, simply uncheck all of the App Store listings and the App Store itself will magically disappear from the left-hand navigation.

I hope you found this useful, interesting, or both. Just remember that this is not the exhaustive new features list. More than anything, I hope it encourages you to let us know what you'd like to see added to Stackato. What problems are you having that Stackato isn't currently solving? How can we make your life easier? Please let me know -- on Twitter, brents+feedback [at] activestate [dot] com (subject: Stackato%20feedback) (email), or our Stackato discussion forum.

Subscribe to ActiveState Blogs by Email

Share this post:

About the Author: RSS

Brent is ActiveState's Vice President of Product Management & Marketing. He's interested in helping enterprise IT departments and developers work together more effectively. Prior to joining ActiveState, he held leadership positions in software product management, IT, operations, and marketing for organizations in security/computer management, motion picture/television, food services, and hardware retail/online industries. But you already knew that after checking him out on LinkedIn, didn't you?