With this post we’re going to explore the Cloud from a Platform as a Service perspective. Platform as a Service allows you to purchase software middleware services just like you purchase electricity, water or internet service to your home.Middleware sold as a service over the internet.

It’s easy to be the biggest egg in the carton; with PaaS your application can easily scale.

So while SaaS provided pre-built software for end-users, PaaS provides software developers with the tools needed to build their own software applications running in the cloud – and likely offer it as a SaaS solution.

PaaS is very exciting for developers and businesses looking to build software, because PaaS eliminates infrastructure and middleware maintenance issues. Like reusable VB components in the ’90s or reusable .NET components in the ’00, PaaS offers developers powerful pre-built services that can be leveraged to accelerate application development and enable massive scaleability.

Of course – just like SaaS – the cloud PaaS provider makes sure the underlying operating system is maintained and patched, the database is distributed properly, etc.

Two types of PaaS

There are a lot of PaaS capabilities available from vendors, and several vendors are offering “PaaS App Stores” where developers can offer up their PaaS service for other developers to consume. Of course the big players such as Amazon, Google, and Microsoft have PaaS offerings, but so do “smaller” players such as Red Hat, Salesforce.com, and even VMware.

But the two types of Platform as a Service seem very different.

With PaaS, even little guys can build big apps by using PaaS services as application building-blocks.

PaaS type 1: Application platform as a service (the boring type)

The more basic PaaS – it’s almost Infrastructure as a Service – simply provide a hosting environment to run your existing applications. So a basic Java PaaS might simply provide WebSphere or JBoss hosting in the cloud, allowing the developer to deploy their EAR/WAR in isolation without worrying about setting up and maintaining the Java container. To me this is a rather boring vision for PaaS that misses the richness of what is available. However, for a Java shop with access to the huge variety of Java open-source technologies and simply looking for an easier way to deploy their application on the internet this might be ideal.

This is amazing stuff, and the developer only pays for what they use. Previously developers and businesses would either try and build all this themselves, do without, or buy big solutions and then pay, host and maintain it themselves.

Of course, just like SaaS there downsides.

The downsides of PaaS

As you can probably imagine, building your application in a PaaS environment is a very different development experience than traditional software development.

Your cloud application will probably be designed to run with core application on either Type-1 PaaS or IaaS – scaled across multiple machines/instances – and then leveraging different services running on completely different servers in different data centres. This is not your father’s application where you just call into Java JARs or .NET DLLs running locally. Large parts of your application will be calling into remote services, so it becomes essential that your application is highly asynchronous (which is hard).

Additionally, you need to be ready for failure of any one of these components. Not just the “it failed so we’ll log it and have our support guy look-at it” either type of “dealing with failure”.

The cloud runs on commodity hardware; so it’s not that the cloud doesn’t fail – it fails all the time – but cloud applications are designed for failure.

So if any one component fails how will your application react? If you’re using the search and auto-complete capabilities of some Heroku add-on service how does your application work when it goes down? What if your image or video processing service goes down, what then? You don’t want it to bring your entire application down, so you need to design appropriately and recover automatically and transparently. Probably your application should keep queuing requests and then automatically scale up the video-processing servers when they become available.

It’s also very possible that your cloud-based application is dealing with enormous amounts of data (or you’re hoping it will if your start-up venture is successful). So you need to make your application highly scalable. Traditional applications – ironically, especially in the enterprise – are typically not scalable at all and are instead highly dependant on session-state. So “scalability” is achieved by using sticky-sessions and increasing the number of servers hosting the application. But this means that if one server goes down all the users on that server loose their work. This kind of all-or-nothing behaviour is not what we’re trying to build in the cloud.

So development of a cloud application is a very different thing than traditional development. There are great rewards to be had if you can adapt your design/development/test life-cycle: faster time to market, amazing capabilities, incredible scalability, and all for reduced operational costs. Should be quite the adventure!

What is “The Cloud?” In the last few years “The Cloud” buzz-word has become ubiquitous in tech circles, and applied to many things. Vendors all seem to want a piece of the cloud, calling just about anything “Cloud enabled”, or “Something as a Service”. So it would be understandable if you’d just shrugged it off as another over-hyped marketing keyword and decided to wait a few years before researching it (hoping that it might have vanished by then).

Today my cousin asked for my advice about getting a new computing device for her daughter who is going off to university. Her daughter wisely wanted something lightweight, probably figuring that she’d be carrying it with her all the time.

Also in the security vein, ZDNet has a very nice article on password complexity and password reuse.

And, in completely miscellaneous news, I spent the last two days discovering that Microsoft’s .NET SerialPort implementation has a nasty memory leak when using the SerialPort.DataReceived event. Problem now solved!

C#

In the “The Visual Studio Documentary” C# designer Anders Hejlsberg talks about simplicity and productivity; he talks about how he C# designed C# specifically to simply C++ and eliminate entire classes of bugs that C++ developers spend inordinate amounts of time solving. He talks specifically about how “C# is a great language because it makes you very productive”, and how developer productivity is paramount to the .NET ecosystem. It’s a pragmatic developer’s dream. Continue reading You’re married to your technology choices