We work tirelessly here at AppFog HQ to provide the absolute best service possible for all of our users. But over time, our generous free offering has led to abuse by bitcoin miners, facebook spammers, phishing sites, porn sites, and more, rendering the service unusable for a number of our legitimate users. While we’ve made every effort to track this abuse down and bring an end to it, it has ultimately slowed down our development of new features and improved performance.

So in order to curb this abuse, we’ve recently had to make the difficult decision to impose some limitations on our free plan. While this has by no means been an easy choice, it was absolutely necessary in order to provide a reliable service for our customers. See the updated plan details here: https://www.appfog.com/pricing/.

We understand that $50 can be a lot of money for a new application that has not yet gained the traction needed to justify such an investment. So we’re also introducing a lower-cost, entry-level plan.

For only $20 per month, in addition to 2GB RAM and 8 MySQL, PostgreSQL, MongoDB, Redis or RabbitMQ instances, you get:

• Custom domains
• Ticket-based support
• More storage for MySQL and PostgreSQL databases
• Group collaboration
• Higher monthly bandwidth cap
• Higher requests-per-second allowance

Check out the full details at https://www.appfog.com/pricing/.

We hope you understand the difficult choices we’ve had to make in order to provide a reliable, sustainable service for many years to come.

So, we asked developers to create an app that helps us choose the beers that will be served at Happy Hour. The app that ended up generating the most total votes would win the grand prize: an iPad with Retina Display.

Success in this contest ending up coming down to how effective the viral spread of the apps were, and we worked to scrub the few anomalies from the final results. In the end, racking up those votes came down to really great promotion of the apps.

We had great entries overall, so thanks to everyone who entered, created an app and promoted it to capture votes.

So let’s unveil the winners!

The Winning Beer: Sierra Nevada Pale Ale

A long-time favorite of Bay Area developers, this clean and well-hopped session beer goes perfectly with your hackathon. The perfect beer for when you’re having more than one.

Here is the final ranking for the beers:

• Sierra Nevada Pale Ale
• Guinness Stout
• Newcastle Brown Ale
• Widmer Hefeweisen
• Lagunitas IPA
• Stella Artois

Grand Prize Winner

Runners Up

Low introductory prices made it easy for developers and executives to adopt PaaS as their platform; and everyone enthusiastically embraced the agility and velocity they realized through PaaS. Even corporate IT executives saw the upside of PaaS: faster application development reflects well on them. But they saw a downside, too, especially as business units went off the reservation for PaaS suppliers. The lack of central control complicated management of corporate system and created potentially serious liabilities because the integration points were unclear and complicated. The first PaaS providers ignored all of these concerns, even claiming that incumbent systems “didn’t exist” because they weren’t focused on enterprises.

But these days, early PaaS success is making the enterprise adoption problem even more pronounced. Not only is adoption slow to arrive, the push to the cloud is also increasingly splintering development within enterprises, pushing “cloud sprawl” to its limits and making Enterprise IT even more resistant to PaaS.

There are various underlying causes for this state of affairs.

First, early PaaS providers priced their services to make them irresistible to start-ups and hackers – so that spinning up a couple of instances for an application was cheap. But the economics of early PaaS providers were not designed for scale. If an application was successful and went into production, the price of operating it went up much faster than with traditional infrastructure. It didn’t make sense for successful businesses to stay with PaaS, or for large enterprises to bet on PaaS. As a result, many developed a practice of using PaaS for dev/test only and then migrated off to go to full production deployments. And though early PaaS providers realized that they needed to make their services stickier with third-party and proprietary services, most haven’t made much progress on this front.

The second obstacle to PaaS growth in the enterprise is that platforms are typically confined to the public cloud, while most enterprises want the flexibility to move between public and private in a hybrid model. For example, an enterprise might deploy a short-lived marketing promotion application on the public cloud, but want to capture customer data from the promotion and store it in an on-premise database.

A new generation of PaaS is solving for this.

Simply put, enterprises are willing to wait on PaaS adoption until providers can resolve these issues. But a new generation of PaaS is rising up to meet their needs while simultaneously serving startups. The modern PaaS infrastructure is designed from the outset to handle large-scale deployments, rather than just a few apps or instances per customer. As a result, it can scale up to large-scale production deployments cost effectively.

The modern PaaS provider understands that big customers want multiple options without the burden of managing multiple providers. Today’s enterprise CIOs demand platforms that deliver agility and velocity and which work just as well in the public cloud as on-premise, providing the same insight, tooling, and control and governance. They want to enable and encourage their developers to dev/test in the public cloud and deploy production on-premise. They want a single PaaS provider that works as well in Ruby as it does in Java or Node or PHP or Ruby. And they want consolidated analytics and insight into all their PaaS activities. This set of requirements is the antidote to “cloud sprawl”.

Responding to these demands, the modern PaaS platform enables something akin to Java for the cloud: enterprise developers can write code once and run it anywhere, so migrations are fast and easy, even in the case of pulling deployments in-house. The benefits now open to enterprises via modern PaaS are enormous: physical servers can be placed in a customer’s data center and managed remotely; IT staff can be enabled to stand up platforms on dedicated hardware or on dedicated virtual machines within the enterprise’s architecture; enterprise IT can give developers in business units the same agility and velocity that drove those developers to the public cloud in the first place.

So, how can you distinguish modern PaaS from early PaaS?

To determine if a PaaS is modern or early, you can ask yourself the following questions:

• Does it run just as well in the public cloud as it does in the private cloud?
• Can you choose to run it behind your firewall or run it in your existing public clouds?
• Can you migrate apps between public clouds (or from private to public or vice versa)?

If the answer these these questions is a resounding “yes,” you’re looking at a modern PaaS.

Where early PaaS delivered the benefits of the cloud—agility, velocity, governance, security, provisioning, dev/test—solely to developers, modern PaaS delivers all these benefits to developers, small startups, and large enterprises alike. Modern PaaS platforms close the gap, making the cloud just as powerful for the CIO as it has been for the developer. By bringing agility and velocity into public and private clouds, modern PaaS brings back control and governance, ultimately mending the problems of “cloud sprawl” for everyone in the organization and finally delivering the initial promise of PaaS: making developers lives easier.

Rackspace and AppFog are throwing a Happy Hour on Thursday, February 7 at AppsWorld in San Francisco, and we’re asking developers to create an app that helps us choose the beers that will be served at the party. Because, you know…. beer.

Of course, we wouldn’t ask for your help without turning it into a contest! So we’re also teaming up with our friends at Rackspace to launch the Rackspace/AppFog Apps and Beer Contest. (US Citizens only – sorry, pesky legal details restrict us on that front)

All you have to do is register for the contest, create an app (deployed on AppFog and Rackspace of course) that allows people to vote for which beers will be served at the happy hour, and then get people to use it and vote.  The app that generates the most total unique votes will be the Grand Prize winner of the iPad.

Get all the details for the app creation, and enter the contest here.

Remember, this is about getting the most total votes via your app, so you need to pimp it and get people to use it to vote for their favorite beer!

What’s the easiest way to do this? Why…. Social Media of course! So promote your app via whatever social network or site or service that you like the most. For maximum impact we suggest creating a custom tweet with a link to your app. Here’s a suggested tweet: ” I created a beer-voting app for the @Rackspace @AppFog Apps & Beers Contest: [your app's short URL]. Enter contest: http://bit.ly/WOvPJ5 ”

We’ll announce the winning beer at the happy hour as well as the winning app & developer, so this contest ends at 4:00pm PST on Friday, February 7, 2013, right before the happy hour gets underway. The sooner you enter and create your app, the better chance you have! (We won’t be extending this contest end date and time…nor any future contest end dates for that matter…just in case you were wondering.)

Oh… and if you’re going to be at AppsWorld or in San Francisco on Feb 7-8 you should come by the Rackspace booth and hit up the party, but please RSVP as space is limited!

But then a few weeks ago, a number of trusted friends and colleagues began raving about AngularJS. Curious about what the fuss was about, I began doing some exploring, looking at sample apps, reading the API docs, and watching a few videos, and it became abundantly clear that Angular is an almost shockingly powerful library. I was surprised by the kinds of heavy lifting that can be accomplished with little effort. And so I set out to see how concisely I could re-implement my Backbone project in Angular.

I was quite pleased with the result.

Getting started

The first thing you need to do is specify within your <html> tag itself–I know, crazy, right?–that your HTML page is going to be staging an Angular app. Instead of the typical <html> tag, you need to insert a <html ng-app> tag instead. As you’ll see over the course of this tutorial, you’ll be embedding a surprising amount of basic application logic in HTML tags themselves when you’re using Angular.

Now, I need to specify my document head:

<head>
  <title>AngularJS Blog Engine</title>
  <script src="http://ajax.googleapis.com/ajax/libs/angularjs/1.0.3/angular.min.js"></script>
  <script src="http://stevenlevithan.com/assets/misc/date.format.js"></script>
  <script src="blog.js"></script>
  <link rel="stylesheet" href="style.css">
</head>

Notice that AngularJS has zero dependencies (not even jQuery or Underscore), which is pretty impressive in itself. I’ll also be importing the DateFormat library for making the timestamps on my blog posts look nice. The blog.js file will harbor my application logic.

Setting up a controller

When I was putting together my Backbone blog engine, I didn’t have anything resembling a controller. That was okay because all of my controller-style logic was placed elsewhere, namely in my views, models, and overarching collection. Like Backbone, Angular doesn’t force you to specify a controller, but there are cases where I would highly recommend implementing one. In my case, I have a well-specified resource (blog posts) that have methods attached, which makes a controller a very nice thing to have.

Here’s what my controller (in my blog.js file) looks like:

function BlogController($scope) {
  $scope.posts = [];
  $scope.addPost = function() {
    var now = new Date();
    var time = dateFormat(now, "dddd, mmmm dS, yyyy, h:MM TT Z");
  $scope.posts.push({ title: $scope.postTitle,
                      content: $scope.postContent,
                      time: time,
                      backgroundColor: $scope.backgroundColor });
  }
}

So, let us take stock of what’s going on here. The most important thing to be aware of is the $scope variable. This variable acts as a kind pub/sub store for everything involving our controller. I will store specific blog posts (as hashes/objects) in this $scope.posts variable. When I add a post new with the addPost() function, I’ll snatch the current time with the var now = new Date(); expression and then push a new post to the (currently empty) $scope.posts array.

Each post will consist of four key/value pairs, specifying a title, content, formatted timestamp, and background color. We’ll see in a minute how those values will be passed into the controller, as that logic will take place in our HTML file.

Wiring our HTML to let the Angular goodness flow through

Like I said before, part of the magic of Angular is that it relies on logic embedded within HTML tags (as in KnockoutJS). One of the things that I love about Angular is that I can attach a controller to a specific DOM element and restrict its scope to that element alone. I’ll do that by inserting a <div ng-controller="BlogController"> tag into my document. Everything I do in this tutorial will transpire within that div element, although an app could easily have multiple controllers attached to their own respective DOM elements. Angular is built for this.

Within my new div element, hotwired to sync up with my BlogController, I’ll start with an unordered list for displaying my posts:

<ul>
  <li style="background-color: {{ post.backgroundColor }};" ng-repeat="post in posts">
    <h2>{{ post.title }}</h2>
    <p>{{ post.content }}>/p>
    <p>{{ post.time }}</p>
  </li>
</ul>

The ng-repeat="post in posts" in the <li> tag means that a new list item will be produced for every post in the posts array within my controller. The background color, title, content, and time will be inserted into this template automatically. There is simply no way to do this so concisely in Backbone, where you would need to hook up each post view to a template in your HTML file and then pass it into a collection that is then rendered (correct me in the comments if I’m wrong!).

For good measure, I also want to display how many posts have been made to the blog thus far. This can also be done incredibly neatly:

<h5>Total posts: <strong>{{ posts.length }}</strong></h5>

This kind of syntax should be familiar to anyone who has used Mustache. The most important thing to remember here is that if we placed this <h5> tag outside of the div element tied to our Angular controller, the {{ posts.length }} variable would come up empty-handed. It simply wouldn’t know where to look for this value.

Time to input some data and close the loop

So far, we can’t do much because we can’t input data. Our posts array is empty and there’s not much we can do about that. So let’s create a form and get to work:

<form ng-submit="addPost()">
  <input type="text" ng-model="postTitle" placeholder="Post title"><br />
  <input type="text" ng-model="postContent" placeholder="Post content">
  <select ng-model="backgroundColor">
    <option value="teal">Teal</option>
    <option value="beige">Beige</option>
    <option value="white">White</option>
  </select>
  <input type="submit" value="Submit post">
</form>

The ng-submit="addPost()" embedded in the <form> tag specifies that the addPost() function from our BlogController will be fired upon commit. Remember from our controller that the values for new posts are tied to variables in our div. When we insert an ng-model snippet into an HTML element, that ties the input value to our $scope variable and allows that input to be passed through our controller. I find this to be a much more elegant way of doing things than the standard jQuery $('#element').val(), which is required in Backbone and other libraries.

And that’s it. Everything that was on offer in my Backbone blog engine is on offer here, and all of it implemented in shockingly few lines of code. I invite you to have a look at how I did it in Backbone (have a look in particular at the blog.js file…it’s not pretty).

Thoughts about Angular and Backbone

As much as I still like Backbone and think that it was a crucial stepping stone toward other libraries, I can’t help but think that its days in the sun might soon come to an end. If the maintainers of Backbone can’t find a way to make client-side code this concise, then we might be looking at a gradual sea change in the direction of frameworks like AngularJS.

If this sounds like an overly bold statement, Dear Reader, please do not be bashful in the comments!

From the standpoint of tech geeks like myself, the IT operation behind Obama for America was extremely impressive. Why? Because the operation managed to be all of the following at the same time: 100% cloud-based, deeply polyglot, poly-framework, poly-DB, and, perhaps most importantly, unbelievably agile and time- and resource-constrained. And when you consider that they were passing around terabytes of data across over 100 applications… Yeah, this was inspiring.

There have been a variety of articles on Obama’s IT operation, many of them very engaging and informative, but none of them, I feel, have covered some of thing things I want to know: what is the broader significance of an operation like this? What does it tell us about the cloud and the promise it offers (not to mention the potential pitfalls)? About polyglot programming? About the state of web development going into 2013?

So I decided to do some digging to answer my own questions and share my thoughts with all of you.

The Obama stack: a (more or less) merry medley of components

Obama for America’s web dev stack, according to CTO and minor celebrity Harper Reed, consisted of over 100 different apps performing a bewildering array of different functions. I won’t list all of these apps here, of course, but I will shine some light on some of the more important components of the Obama team’s tech arsenal.

I’ll begin with social media. Now, any politician with a brain nowadays has a Facebook page and probably a Twitter account and maybe even a presence on a handful of other platforms. This is simply de rigeur.

But the Obama team did something pretty impressive in their social media tactics: they simply built their own social media platform, Dashboard. This platform acted as a sort of decentralized online field office, complete with message boards and other communication channels for local organizing. Users could organize their own teams, invite people to sign up, upload pictures and customize their Facebook-esque home pages, and so on. And the Call Tool built into Dashboard gave people (semi-)randomized phone numbers to call before and on Election Day. The interface was clean and aesthetically pleasing. Dashboard was a real triumph.

A presence in the social media space is essential to modern campaigns, and now crowdsourcing has to be considered standard as well. The Obama team built a crowdsourcing platform to act as a “voter incident tracker” on Election Day which enabled volunteers to report incidents such as illegal electioneering or improper ballot handling. The team opted to use Ushahidi (written in PHP), originally built to work seamlessly across Facebook, Twitter, email, SMS, etc., as the basis for their platform.

Alongside Dashboard and the Ushahidi crowdsourcing tool were a vast variety of other apps, for example Dreamcatcher, which helped target voters on the basis of sentiments expressed on a variety of platforms. For the sake of brevity I won’t describe all of them here, because it’s far more important that I introduce the most important element of the entire Obama tech stack: the Narwhal data layer.

Narwhal: demonstrating the power of abstraction

Narwhal is probably the most impressive piece of the puzzle. It is a tool charged with “linking separate depositories of information to build a more complete picture of the potential voter” and then exposing that information via API to the more than 100 applications built by the team. Basically, it acted the way that the Twitter, Facebook, Twilio, and other APIs operate with respect to the app ecosystems built around them.

The primary goal of Narwhal was essentially to secure the scalability of the entire system depending on it. If you’re managing a system of 100+ apps, having an ultra-reliable, API-driven Single Point of Truth tying the loose strands together is simply beyond necessary. Narwhal clearly rose to the challenge. The end result is that services like the Dashboard (and all the others) never spoke to any database whatsoever. They never made SQL queries or put key/value pairs in a NoSQL database. The 100+ apps in the stack only ever spoke to the Narwhal API.

Well executed APIs are such a powerful thing because they enable the construction of “aggregated organic” systems of this sort. They provide a kind of lingua franca within a system that enables all kinds of “citizens” to seamlessly interact. With a RESTful API-driven platform as solid as Narwhal, suddenly Ushahidi and Rails and Node.js and Java and many others can play quite nicely with one another. Apps can be scaled one by one, in isolation from one another and from the data layer, which constitutes a major agility win.

Another impressive aspect of Narwhal is that it relied on a variety of database systems. The team began with a SQL-based data retrieval system that was to be used by all applications. But they ultimately decided to separated applications and data with a single, common abstraction layer. The bulk of the team’s database needs were filled by Amazon RDS. RDS’s “snapshot” feature enabled the team to perform large data dumps into Amazon’s S3 file store.

According to multiple articles, if the campaign had gone on longer, the team would have had to switch to their own large EC2 instances running MySQL. From the beginning, they really strained the limits of RDS. But staying on RDS meant significant cost savings, as hiring database administrators to manage such a huge and complex transition was safely avoided.

The team also relied on Amazon’s SQS (Simple Queue Service) as the basis for distributed systems-style architecting. Narwhal pulled in streams of data from a variety of sources and passed the data along to a vast constellation of worker applications. Quite often, that data was then passed into SQS queues for further processing, to be made available via a variety of APIs. SQS was also used to process emails in conjunction with RDS and S3 storage. The team even experimented with Amazon’s DynamoDB when it was introduced. It ended up being used in some of the campaign’s get-out-the-vote efforts. It will indeed be interesting to see if key/value stores will become core technological components in future campaign operations.

With all of these elements tied together, the team had assembled a powerful anchor for the campaign’s digital effort. While Narwhal entailed a lot of work up front (not least of all because of the sheer quantity of data that the designers knew the system would ultimately have to be able to manage), the payoff in terms of agility, according to multiple members of the campaign, was enormous. At its inception, the idea of having a single interface and shared data store for everything probably seemed like a promising but frightening approach. But it paid off because it made every bit of the campaign’s terabytes of data more valuable.

Against all odds, the campaign managed to do all of this with only 30 minutes of downtime over the entire course of the campaign. The whole stack was even architected to resist catastrophic infrastructure failure (which we know to be an all-too-real phenomenon). That’s exactly what happened on October 21st, when AWS-US-East went down due to Hurricane Sandy, just days before the election. Fortunately, the team had a failover plan in place to move everything to AWS-US-West in case precisely that scenario transpired.

In the digital landscape as we know it today, this kind of approach–polyglot, distributed, fault-tolerant, cloud-based–is the Holy Grail. Monoglots beware.

Polyglot by necessity

The Obama IT team could have opted to go monoglot from the outset. They could have chosen Ruby or Python or PHP or whatever and made their entire technology stack conform to that principle. Database clients, API proxies, crowdsourcing tools, social media platforms, etc., all in one language. In the abstract, there really is something compelling about a vision like that. The people you hire don’t have to be as flexible; getting things to play nicely in the same sandbox is easier.

But knowing what we know about the operation, a monoglot approach would have been absolute MADNESS. By going polyglot, the team was able to capture what I would call comparative advantage gains. If you survey the entire web dev space, you see a bewildering array of tools, each with their own strengths and weaknesses. Most of the time, picking the absolute best tool for a specific task means drawing upon multiple runtime communities. The Ruby community simply hasn’t come up with a crowdsourcing tool as powerful as Ushahidi. Ruby on Rails, however, strikes me as the best possible way to build a platform like Dashboard in a short period of time. This is to give one example among many.

Going polyglot means never being forced to say “no” just because something–or someone–lies outside of the walled garden of a language community. And so yet another important advantage for the Obama team of building a deeply polyglot architecture is that the team was able to reap personnel gains. Team members came from a vast variety of tech companies, from Twitter to Google to Facebook to Quora to Orbitz to small startups and beyond. When you’re simply looking for the best and brightest, you often don’t have a lot of latitude to simply say “we’re using X, so get used to it.”

Note: I relied on articles from Mother Jones, Ars Technica (this article as well as this one), The Atlantic, and Current for almost of the information contained here.

Nowadays, a variety of tools exist to make group collaboration easier and more natural than ever. From distributed version control tools like Git and Mercurial to social media-style hubs like BitBucket, GitHub, and CoderWall to cloud IDEs like Exo and Cloud9, collaborating with others across runtimes, organizations, and vast geographical distances has become something that we take for granted.

At AppFog, we feel strongly that these kinds of capabilities need to be introduced into the world of PaaS as well. And so we’re happy to announce that AppFog Teams is now in public beta and ready for you to test-drive.

Please note: The Teams feature is currently available only to users on paid plans.

So what is this Teams thing?

AppFog’s Teams feature enables you to invite other AppFog users to collaborate on app management. All you have to do is email them an invitation to your Team, and if they accept they’re on board. Now, multiple users with different email addresses can sign into an account, even simultaneously, and manage the same set of applications and services, be it in the console or in the command line.

What actions can Teams collaborators perform?

With this Teams release, if you invite someone into your AppFog account, they can do almost anything that the original user can do: they can run almost any command in the CLI, from af update to af delete to af clone, and thus perform any and all app management tasks. There are only two things that invited users cannot do: they cannot change the account password, and they cannot invite or exclude users. For any given team, only users with the password for the team account can perform those actions.

How to use the Teams feature in the console and in the command line

In the console, using the Teams feature is as easy and intuitive as all of our other console tools, from managing environment variables to managing domain names. You simply click on the Teams tab in the console, which is located in the main toolbar:

 
Once you do that, you’ll be taken to the Teams page, where you can see which users are currently a member of your Team, which invitations are pending, which users have been excluded, and so on:

 
From there, you can invite new users into the fold (you can give it a shot with Matt Damon, but we can’t make any guarantee that he’ll accept) as well as keep tabs on who’s in the group, as well as a few pieces of information, including email address. Individual users can even select a picture for themselves (let’s hope your pic turns out better than this).

If you’re using the AppFog command line tool, things are similarly straightforward. Let’s say that you’re a member of an AppFog group (under the email address me@irule.com) and you want to update an app called better-together. The only thing that you would need to do differently is to specify in the command line which user you are:

$ af -u me@irule.com update better-together

If you’ve accepted the group’s invitation, you have an AppFog account (which are free), you’re signed into AppFog, then you’re set to go. This was just one example among many. You could also start apps, restart apps, add services, modify environment variables, etc. If you run af help, all of the commands that you see–with the exception of af passwd–will be available to you. It really is that simple.

Teams feature roadmap

As we said, this feature is still in its relative infancy. But you know us: if we’ve built something that we think developers will find useful, we’re really bad at keeping it under wraps. Even if it’s in an early stage (as this feature is) we want to let it out into the world. We’re always open to feedback, so check out the AppFog Google group and let us know if there are features you’d like to see or any kinks that remain to be worked out.

In the future, we plan on iterating on the Teams feature quite a bit and adding the following:

• Specified roles. Right now, anyone in a group can perform any and all AppFog-related tasks except changing passwords and inviting members to a group. In the future, we’ll enable much more fine-tuned role specification than this, including roles such as “admin,” “auditor,” and more.
• Spaces. Within larger organizations, it is very often the case that some apps and projects are running in production, others are in testing/QA, and yet others are making baby steps in development. With the Teams feature, we seek to eventually enable AppFog groups to group projects into spaces along these lines. This would mean that the dev/engineering team for OmniCorp.org could have multiple apps and/or services grouped into spaces of their choosing. This allows for a far more streamlined workflow in larger groups.
• Full console support. At the moment, there is little Teams-related functionality in the console, but we will have much more comprehensive support in the future. We want to enable users to, for example, be able to sign into multiple groups in different consoles at the same time, to customize certain aesthetic aspects of the console, and so on.

So if you’re on an AppFog paid plan, give the Teams feature a shot. We’d love to see what you end up building with it, and we are always more than open to any and all feedback. Come together, developers. And be in touch.

And of course, a big shout out to our contest sponsor Cloud Foundry!

We’ve had a chance to review all of your smart and funny resolutions, and have selected the six winners of the GoPro HD Hero Naked cameras.

So, in no particular order, here are the winning new year cloud resolutions:

“In 2013 I will provide a cloud with capacity of 2000. http://www.youtube.com/v/9ntPxdWAWq8&hl=en_US&fs=1&”
– submitted by Mike Y.  (Note: Mike, we think you can get to 4000)

“My resolution is to properly learn how to use capistrano to properly deploy code to multiple servers in the cloud or to convince more people that Oregon is the worst place to host stuff in the cloud because all the rain, and terrible weather makes the servers in the sky not work… the latter seems easier.”
– submitted by Jason B.  (Note: Jason, with all the clouds in Oregon, it seems the perfect place to utilize Capistrano)

“My resolution is to not tune out /ignore my two screaming children when I’m in the cloud or on AppFog Mommy, mommy, mommy, mommy, mommy “What!?” “Nothing”"
– submitted by Lesly C. (Note: Maybe teach them Node.js? Indoctrinate ‘em early we always say.)

“My resolution is to preach the dangers of vendor lock-in to my clients and to spread the good will of the public cloud where ever I can. Oh, and to drink more milk; it does the body good.”
– submitted by Zachary Q. (Note: Dairy-as-a-Service?)

“My resolution is to write my first true deploy script that does not depend on Git post-receive hooks!”
– submitted by Chris M. (Note: And share on Github!)

“My goal is to get my distributed event bus for Cloud Foundry production ready and deployed in our private cloud.”
– submitted by Mike H. (Note: We’d love to see this ourselves….)

Congratulations again, winners. Your cameras are on the way! And cheers to an amazingly successful 2013 for developers in the cloud!

Are you building your cloud application directly on the Infrastructure-as-a-Service (IaaS) provider vs. using a Platform-as-a-Service (PaaS)? In recent conversations with dozens of cloud application developers I’ve found many developers are still choosing to build their application using services offered by the IaaS (Infrastructure-as-a-Service) provider, e.g., Amazon (AWS), Rackspace or other IaaS providers vs. using a PaaS between the application and the infrastructure. In nearly every instance I find the primary reason for selecting an IaaS first was that the development team didn’t fully understand the benefits of a PaaS or didn’t know how to evaluate one.

We recommend to our clients that they select their PaaS first and then select the IaaS provider that best supports their selected PaaS. By developing your application using a PaaS, you can lower the total cost of ownership of your application by 30% or more. With the right PaaS, you also gain the freedom to change cloud infrastructure providers over-time and avoid infrastructure vendor lock-in by making your application portable to any IaaS provider.

We see five primary reasons for using a PaaS:

Reduced Operations Cost – we generally find that 30% or greater of development time can be consumed in DevOps functions. A PaaS will nearly eliminate the DevOps function and reduce it to simple user administration and resource allocation functions. AppFog, a leading PaaS provider, has a great infographic on this topic and our experience validates their claim that almost all DevOps functions can be eliminated by developing and deploying cloud applications using a PaaS.

Reduced Development Cost – An IaaS provides network, compute and storage scalability; but it doesn’t automatically provide application scalability. Application scalability is not only an operations issue but it is a development issue as well. A significant amount of development time is spent repeatedly building such functions as application health checks and reporting, but a PaaS provides these functions out of the box. A PaaS provides application runtimes, data and messaging services that are cloud aware. As adoption of the PaaS layer increases, the leading providers are investing time and energy, in providing tools to increase development productivity and the development productivity gains of using a PaaS will continue to increase.

Application Portability- It is a bad idea to develop on-premise applications specific to a hardware vendor, so why would it be a good idea to write cloud applications specific to the hardware vendors of the cloud, i.e., IaaS providers? Your PaaS offers developers a set of services that are independent of the infrastructure, ensuring that the application and operational tools you integrate into your application are agnostic of any cloud infrastructure. By leveraging application development runtime environments, data and application management services within an open PaaS you can deploy to your application to any IaaS, without changing a line of code.

More Deployment Alternatives – Open and portable PaaS offerings, like Cloud Foundry,  can be deployed to public or private cloud configurations giving you the most flexible deployment alternatives. For instance, the Cloud Foundry ecosystem includes multiple public cloud providers including AppFog and Cloudfoundry.com. Additionally, the PaaS bundle is available from CloudFoundry.org for private cloud deployments to your data center, or public clouds such as Amazon Web Services, Rackspace and Hosting.com.

More Development Services – We find that a PaaS such as Cloud Foundry has a wider range of run time and data services available than do most IaaS providers. Cloud Foundry for example supports Java, Ruby and Node.js application run-times, as well as PostgreSQL and MongoDB data services. Also, a vibrant ecosystem of partners have extended the available runtimes to include PHP, .Net, and added data services for MySQL, Microsoft SQLServer and Hadoop.

Are you considering a PaaS for your next cloud application development project? What are the primary reasons?

This week we welcome two of our developers’ favorite Add-On Partners — Logentries and Xeround.

With the addition of these two fantastic partners, we believe we are starting to realize the promise of this ecosystem – and the full platform delivery of this ecosystem to developers. Developers’ lives keep on getting easier!

Logentries

Logging-as-a-service is a vital part of any distributed cloud-based application. And Logentires has proven to be a fantastic solution for your logging needs.

Logging is a critical part of any app development, management, and iteration process. For cloud-based apps––especially those that rely upon multiple services––logging is absolutely critical. Logentries gives AppFog users a way to easily manage, store, search and analyse their log data. Logentries essentially turns your raw log data into extremely useful actionable data – which you can use for debugging issues, finding performance bottlenecks or for simply understanding how your users are interacting with the applications you develop. Logentries supports the full AppFog stack (PHP, Java, Node.js, Python and Ruby) so you can get access to your logs regardless of what language you prefer to build your applications in.

Xeround

Mysql is, obviously, the default SQL database for internet development. While AppFog offers a shared Mysql DB service – for many production use-cases, customers will need a dedicated DB or services and functionality that our shared DB service doesn’t offer. In these cases, Xeround’s robust, simple DB-as-a-Service solution is a fantastic option.

With support for elastic auto-scaling, failover and advanced clustering, Xeround provides a HA database for your demanding production workloads.

If you are considering building out your own cloud-based database for your app do to concerns about performance and scalability – you should seriously consider Xeround instead. It’s going to be easier and less painful.