Is PaaS Tech Still Around? Maybe Containers Will Kill it or Bring it?

Recently a post from @Gigabarb popped up on the ole’ Twitter that started a micro-storm of twitter responses.

This got me thinking about a number of things and I started to write her an email specifically, but realized I should really just blog it. After all, the topic is actually part of what should be the public conversation. It’s about the changing world of technology, which we’re all part of…

First Topic: Usage of PaaS

Barb, just shortly after the tweet above was posted, this other tweet altered what information I might provide her. @TheSteve0 had responded with some items, which @GigaBarb then responded with

Now, not to pick on OpenShift & Red Hat (the effort @TheSteve0 is working with), because they have a great open source effort going on around this PaaS Technology, but Barb had a point. If Cloud Foundry responded with something like this, she’d still have a point. The only companies that continually sign up new companies is AWS & Beanstalk (ok, so they don’t call it PaaS, it gets you to the same place – arguably better than most of the others), a little bit at Windows Azure and a few companies pop up every once in a long while that might take Cloud Foundry or OpenShift and run with it. Most of the early adopters are already on board and most that might get on board are still mostly just waiting in the sidelines.

This fact is frustrating for those

in the space that want to see more penetration, but for those that arent’ technically in the space, it seems kind of like ASP. Oh wait, I should add context now, ASPs as in Application Service Providers. The technology from the beginning of the 21st century similar in many ways to what is dubbed SaaS now. At the time it could have been revolutionary. However at the time nobody picked it up either. This is similar to what PaaS is seeing. However…

A Hypothesis of What Will Happen to PaaS Tech

I have a theory of what will happen to PaaS Tech, it is similar to ASP Tech. PaaS will keep plundering along in odd ways, and eventually one day, it will become a mainstream tech. Right now however it will remain limited. In that same turn, by the time it becomes a common tech, it’ll be called something else.

Here’s a few reasons. One, is that many developers see PaaS and their response, especially if they’re seasoned developers with more than a few years under their belt, is to respond will immediate apprehension to the tech. It removes key elements of what they want to control. It hides things they can’t actually get to and it abstracts in ways that don’t always make sense. The result is that many senior devs stay away from pure PaaS offerings and instead use it only for prototyping, but production gets something totally different. I’ve been there more than a few times myself.

However, the result of what most senior devs end up with, when they get their continuous integration and development environments running at full tilt, is exactly what PaaS is attempting to promise. There are some companies, with senior devs, and extremely intelligent members that have taken PaaS and effectively implemented it into their continuous integration and delivery environment giving them strengths that most companies can only imagine to have.

One of those companies is lucky and smart enough to have Jonathan Murray @adamalthus heading up efforts. On his team he also has Dave McCrory @mccrory and Brian McClain @brianmmclain. To boot, they are close to the Cloud Foundry team (and @wattersjames, who cuts a path when there are issues) and keep a solid effort going working with key partners such as @Tier3 (now part of CenturyLink)  and other companies that help bring together one of the most strategically and tactically relevant PaaS deployments to date.

Other PaaS deployments are questionable for various reasons, they’re trying, but they aren’t there. At least not the types of companies and efforts that Barb was looking for. So really, if there is another out there that’s hiding, but wants serious street cred. A boost to hiring serious A grade talent, and to push forward past competitors, please let us know. Let me know, let Barb know and let’s hear about what you’re doing. If a company is hiding their implementation and doesn’t want to be part of the community, then fine, they can stay hidden and not gain the benefit of the community that presses forward beyond them. But I would love to hear from those that I might have missed, that want to push forward, so ping me. Ping Barb, we’ll get word out there and get developers checking out and making sure your company is getting it done! 😉

Second Topic: PaaS on PaaS and Start Docker

PaaS is nice. If your company can get it deployed and use it effectively, the you’re going to push forward fast in many regards. Deployments, savings, code cleanliness, effective separation of concerns and abstraction at a systems level are some of the things you can expect from a good PaaS implementation. Sometimes however, as the senior devs I mentioned pointed out, you give up control and certain levels of abstraction. However almost all senior devs understand that they want the ability to abstract at the levels that PaaS enables. They want to break apart the app cleanly at the system level from the software level. No reason for an app to know where or what a hard drive is doing right? That’s a rhetorical question, onward with the topic…

Docker has entered the market with a BOOM, part of the abstraction level that enables PaaS tooling in the first place. This tool enables a team to jump into the code or to just deploy the tool to abstract at a PaaS level, but to build the elements that they need specifically. The components are able to be brought together in a composite way that provides all the advantages of PaaS, while put together specifically for the problem space that the team is attacking. For environments that don’t make cookie cutter apps that fit perfectly to PaaS tooling as it is, that needs that little bit extra control of the environment, Docker is the perfect tool to bring those pieces together.

So really, is Docker and containerization that new word (from a technically old tech! lolz), that new tech, that’s going to bring PaaS into the mainstream as the standard implementation? Is it going to make PaaS become containerization when we developers talk about it? It could very well be the next big step. It could be that last mile coverage that devs want to push environments into a PaaS Tech ecosystem and make full use of hardware, software and move to the next stage of application development. Could it? Will it?

Personally I’m ready for the next stage of the whole PaaS thing, are you?

Next up on other thought patterns, WTF are people using Oracle for still when mariadb and postgres mean their freedom to innovate, move forward and surpass their competition.

Red Hat, OpenShift PaaS and Cartridges for Riak

Today I participated in the OpenShift Community Day here in Portland at the Doubletree Hotel. One of the things I wanted to research was the possibility of putting together a OpenShift Origin Cartridge for Riak. As with most PaaS Systems this isn’t the most straight forward process. The reason is simple, OpenShift and CloudFoundry have a deployment model based around certain conventions that don’t fit with the multi-node deployment of a distributed database. But there are ways around this and my intent was to create or come up with a plan for a Cartridge to commit these work-arounds.

After reading the “New OpenShift Cartridge Format – Part 1” by Mike McGrath @Michael_Mcgrath I set out to get a Red Hat Enterprise Linux image up and running. The quickest route to that was to spool up an AWS EC2 instance. 30 seconds later I had exactly that up and running. The next goal was to get Riak installed and running on this instance. I wasn’t going to actually build a cluster right off, but I wanted at least a single running Riak node to use for trying this out.

In the article “New OpenShift Cartridge Format – Part 1” Mike skips the specifics of the cartridge and focuses on getting a service up and running that will be turned into a Cartridge. As Mike writes,

What do we really need to do to create an new cartridge? Step one is to pick something to create a cartridge for.

…to which my answer is, “alright, creating a Cartridge for Riak!”  😉

However, even though I have the RHEL instance up and running already, with Riak installed, I decided I’d follow along with his exactly example too. So I dove in with

[sourcecode language=”bash”]
sudo yum install httpd
[/sourcecode]

to install Apache. With that done I now have Riak & Apache installed on the RHEL EC2 instance. The goal with both of these services is to get them running as the regular local Unix user in a home directory.

With both Riak and Apache installed, time to create a local user directory for each of the respective tools. However, before that, with this version of Linux on AWS we’ll need to create a local user account.

[sourcecode language=”bash”]
useradd -c "Adron Hall" adron
passwd adron

Changing password for user adron.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.
[/sourcecode]

Next I switched to the user I created ‘su adron’ and created the following directories in the home path for attempting to get Apache and Riak up and running locally like this. I reviewed the rest of the steps in making the Cartridge w/ Apache and then immediately started running into a few issues with getting Riak setup just like I need it to be able to build a cartridge around it. At least, with my first idea of how I should build a cartridge.

At this point I decided we need to have a conversation around the strategy here. So Bill Decoste, Ryan and some of the other Red Hat team on hand today. After a discussion with Bill it sounds like there are some possibilities to get Riak running via the OpenShift Origin Cartridges.

The Strategy

The plan now is to get a cartridge setup so that the cartridge can launch a single Riak instance. That instance, then with post-launch scripts can then join itself to the overall Riak cluster. The routing can be done via the internal routing and some other capabilities that are inherent to what is in OpenShift itself. It sounds like it’ll take a little more tweaking, but the possibility is there for the near future.

At this point I sat down and read up on the Cartridge a little more before taking off for the day. Overall a good start and interesting to get an overview of the latest around OpenShift.

Thanks to the Red Hat Team, have a great time at the OpenStack Conference and I’ll be hacking on this Cartridge strategy!

References

OSCON 2012 => Monday Ignited, Tuesday OpenShift Session ++

OSCON 2012 Opening Doors
OSCON 2012 Opening Doors

Today kicked off with a monster Reggie Biscuit from Pine State Biscuits. If you live in Portland or are visiting just for the conference and like soul food of the tastiest nature, check it out.

My first day ended up not as planned. Instead of attending sessions I ended up meeting a number of people and discussing the future of Cloud Foundry, where it is headed and in general, the direction of PaaS Technologies. I met Andy Piper (@andypiper) and Raja Rao (@rajaraodv) and discussed Node.js and Cloud Foundry specifically. We then dove into trying out some of the CLI features in the latest VMC builds.

After that I met Mark Atwood for a brief few moments. As always, Mark’s a friendly guy, and might I add pretty smart too. I’ve enjoyed our conversations in the past during the AWS Meetups in Seattle too. He’s always got interesting thoughts and perspectives on open source, linux and now on PaaS Technology too. Ya see, Mark has become the Red Hat OpenShift Advocate. It’s a perfect fit, as Mark loves this stuff!

Ignite!  ….or Bailey’s for more tech talk and #nodejs discussions.

After all of this I almost, and had planned, to attend the Ignite Presentations after OSCON, but instead ended up heading over to talk with some Node.js & JavaScript Coders about some of our latest efforts around getting concrete performance benchmarks for Node.js and some of the various libraries in use.

That brings us to Tuesday…

Tuesday brought forth a super busy, exciting and educational day. I headed straight to OSCON for the OpenShift Workshop with Mark Atwood & Krishna Raman (Mark’s Twitter is @fallenpegasus). The session was great and they hit on a lot of hugely important topics. Let’s go through each of these real quick, as this is where more than just the tech bits were involved.

OpenShift is Truly Open Source Software

Mark & Krishna made a strong point to outline and show how and why OpenShift is open source. For instance, they are following the original precepts of a particular guy named Stallman (http://stallman.org/ if you’re unfamiliar with Richard, he’s the guy who got GNU happening and a major originating advocate of open source software). Mark pointed out that Red Hat is open to keeping the governance of the project completely open, would even cede it to another governance entity when it grows beyond just Red Hat, and they intend to keep all the communication very open and public, as intended with open source projects.

Another thing that Mark and Krishna pointed out, was that the software is on github, and not just in a psuedo “read-only” state, but in an actively useful way, with interactions and tracking on github. The point being that there is no hidden processing of the code or private repositories of code. What you see is what you get in this regard. In addition all of the code that is available, is the exact code that Red Hat is using to actually host the OpenShift PaaS that they provide for testing and demoes. Simply, it is all there available in a completely open, contribution based, interactive, and publicly accessible way.

So far this is even more evident if you do a google search or even trace the twitter activity. They definitely have the search engines working in their favor with all of that searchable content publicly available.

Cloud Foundry & OpenShift

I’m still a huge Cloud Foundry fan, the team and effort and product is getting to be in pretty solid shape. However OpenShift is definitely here to provide some competitive interest. In the end, I’m a fan of PaaS Technology and what it can do for software developers and what we’re trying to achieve on a daily basis. The potential of PaaS to improve, dramatically, the software development lifecycle while reducing the overhead cost is pretty huge. The key is, people have to be aware of and start utilizing the technology well. Just implementing it and saying “I have PaaS” is one thing, but improving your software development process to use PaaS technologies well is where the seriously powerful advantage is.

I’m looking forward to seeing the market unfold and start making progress with these technologies. On that note, day #1 and #2 are finished for me. Cheers!

Day #1 => Cloud Expo & Cloud Bootcamp

Thanks to Larry Carvalho and Krishnan Subramanian for lining me up to speak at the kick off bootcamp keynote and for a PaaS Session at the Cloud Expo Boot Camp. I had a great time and was able to cover some great material with the audience. It was great to hear a number of companies and people diving into PaaS Technology and learning about what this technology can do.

The audience, above all was very open to the idea of openness with technologies that are open. See the theme there? 😉 There were a few resounding themes to things people would like to see added to the Open Source PaaS Solutions such as Cloud Foundry, Iron Foundry and Open Shift. Here are a couple of these;

  • People want to have continuous deployment or continuous integration features added to the PaaS Capabilities so that the PaaS doesn’t just deploy code blindly. The two companies that came up that have some capabilities around continuous deployment and integration are AppHarbor and CloudBees. But the stronger ask from the audience was for there to be some type of integration with one of the open offerings like Cloud Foundry or Open Shift. Some discussion also followed around these capabilities being a default “service” within a PaaS or even IaaS offering.
  • The other thing that brought up a lot of questions was the architecture behind the various PaaS Solutions. I walked the audience through a description based on what I wrote up in “Cloud Foundry Architecture – Removing the Operating System Barriers with PaaS Part 4“. It generally tends to fit similar architectures in the PaaS realm and most of the audience liked the idea of how PaaS operations are working.
If you attended either of my talks and want to check out the PaaS Providers that came up during questions and discussions, here’s the one’s I can remember:
  • Tier 3 – Enterprise grade IaaS and PaaS w/ the Web Fabric Product. This company I currently work for, they’re doing a rock solid job with the offering.
  • AppFog – Very application focused and IaaS autonomous, i.e. you can pick AWS, HP Cloud, or Azure with more options to come in the future. I’ve worked with these guys also and they too kick ass!
  • AppHarbor – .NET focused PaaS running atop AWS, provides a free tier and continuous integration and rollback features. I haven’t worked for these guys, but I’ve met everyone on the team and they’re all top notch. Props guys! 🙂
  • CloudBees – Java focused PaaS with Enterprise focused CI/CD capabilities with Jenkins.
  • Heroku – These are the guys who kicked off the whole PaaS thing a few years ago. They started Ruby on Rails focused but also cover Java and Node.js too.
  • EngineYard – A solid PaaS offering running primarily atop AWS with some IaaS style features available too.
  • Windows Azure – Microsoft’s cloud offering, with a lot of updates around Node.js lately. They’ve traditionally focused on .NET, but lately have put as much or more focus on Node.js. Looks like things are improving in the Azure Camp.

More to come tomorrow with DeployCon at the Cloud Expo.  Until then, cheers.

PaaS Help! Know any PaaS Providers?

I’ve been diligent and started a search of Platform as a Service Providers, so far my list includes:

  • EngineYard
  • Heroku
  • AWS Beanstalk
  • Windows Azure
  • AppFog
  • Tier3
  • CloudFoundry
  • OpenShift
  • IBM PaaS
  • Google App Engine
  • CloudBees

Who else is there? Help me out in creating a list of every possible offering we can find!  Cheers! Please leave a comment or three below with any I’ve missed.  Thanks!