The Cloud: Platform as a Service

This is part two in a series of posts about The Cloud; for an overview see the original article.

There is also a discussion of SaaS.

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.

Platform-as-a-Service Big-egg-in-the-carton
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,, and even VMware.

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

With Platform as a Service, even little guys can build big apps by using PaaS services as application building-blocks.
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.

There are lots of examples of this:

  • Google App-Engine is a big example of this type of PaaS play,
  • Cloud Foundry is an example of a smaller player providing host-your-app service.  “Focus on your code, not Infrastructure” states their homepage.
  • Engine Yard hosts only Ruby, Node.JS and PHP applications.
  • Heroku hosts Ruby, Node.js, Python and Java application.

PaaS type 2:  Platform building services (the cool type)

The second type of PaaS are the component-style web-services available from the bigger vendors, and the “PaaS App stores”.

For example, Amazon and Azure provide the following types of services (and many more) for building applications:

  • Push notification capabilities to support mobile applications
  • On-demand media trans-coding
  • Storage of data blocks with fast look-up
  • Cheap “cold” storage of data with slow look-up (excellent for backup software)
  • E-mail services (which is actually much harder than it sounds to correctly configure MX records and avoid being labelled SPAM)
  • Identity and Access Management – user authentication through Facebook, Google, or Microsoft accounts, or private cloud-scaled Active Directory for authorization; even multi-factor authentication is supported.
  • Advanced workflow services
  • Limitless data queues for ordered processing of data
  • Business Intelligence – Reporting and analytics solutions in the cloud such as Hadoop and Microsoft SQL Server Reporting Services or SQL Server Analytics Services.
  • Cloud DNS, Load balancers, Monitoring, Virtual Private Networks (VPN) capabilities, regular scheduled data transfers, etc.

Heroku has a page dedicated to “Heroku Add-ons“.  They’ve got all the basics, and then advanced things like:

  • Scalable machine learning and data mining; this is incredible!
  • Time series data storage with built-in analysis, monitoring and predictions
  • “Urban Airship” – Deliver customer and location targeted cross platform push messages
  • Full-text search services with auto-complete, query, result management and analytics
  • All sorts of powerful queues, monitoring, logging, caching, and analytics capabilities
  • Media capabilities, document management, PDF and Excel file creation and manipulation
  • Website security and scanning
  • Payments

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!


The Cloud: Software as a service (SaaS)

This is part one in a series of posts about The Cloud; for an overview see the previous article.

There are several different layers to the cloud, and to understand “The cloud” we need to examine the different types of cloud offerings provided by vendors.

The following diagram will be the basis for our discussion, although we won’t tackle it in order.
The Cloud Hierarchy - SaaS - Software as a Service is in the middle.

Instead, we’ll start our discussion with SaaS, because historically that’s where I started with “The Cloud”, so I’m completely biased to thinking that SaaS makes a good starting point. Continue reading The Cloud: Software as a service (SaaS)

What is “The Cloud”?

iStock_000000231918XSmall---cloud-questionmark-smallWhat 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).

But it won’t vanish.  The Cloud is amazing.  Continue reading What is “The Cloud”?

Domain Driven Design over Test Driven Development

I believe that software development is design, either informed design or accidental design.

As a programmer is writing code, they are constantly and continuously making design decisions.  For example, consider the questions a developer asks herself when writing a simple method: Continue reading Domain Driven Design over Test Driven Development

Application design considerations

For some time now I’ve been meaning to write down rough list of things I consider in my role as enterprise architect for a project on either a new or existing system.  Often in the early stages of a project I will be the project architect, and then in the later stages of the project I will transition to become the lead developer. Thus, I have included a high-level application design consideration list and a more detailed lower level application design consideration list.  In my experience, being aware of the lower-level design considerations has always helped inform the high-level solution design considerations. Continue reading Application design considerations

Leaky Data Access Layer Encapsulation

I’m doing a code review right now of some domain logic layer code. Unfortunately, sprinkled throughout the domain logic layer are properties such as:

This is definitely the database implementation leaking into the domain logic layer. I’m not going to comment (yet?) on whether a string column in the database with “Y” and “N” values is a good idea, but it’s definitely a bad idea in the domain logic layer. Furthermore, notice that the setter doesn’t even check that the value is actually ‘Y’ or ‘N’ (and are ‘y’ and ‘n’ okay too, or are they “right out”?). The convenient use of automatic properties is handy, but in this case completely inappropriate because I could set “Negatory!” – and I probably won’t notice until the database blows up (hopefully). Additionally, because this is a string property I’m forcing all the code that wants to use this property to manually check the value:

Sadly, this further propagates how the database is storing its values, and provides lots and lots of code duplication anywhere this property needs to be used. (Notice also that this would fail if somebody had set the property to “Yes” or “1”).

Therefore, MUCH better is the following, normal .NET code:

By changing the domain logic layer property to be a Boolean property we don’t need to document what the “appropriate” string values are, and we also don’t need to check that the appropriate value is being set. This also makes all use of the property obvious and easy, and unaware of the underlying database implementation:

Notice that this change does not impose any change on the database – the Database Access Layer (DAL) should completely encapsulate how the database actually stores this particular property, and there is no ambiguity in the domain logic layer code and all the higher level layers that use it. This is also the first step towards refactoring the database to store our Boolean property as something other than a VARCHAR…

Part 2: Another leaky encapsulation

Another leaky encapsulation of the database implementation is properties such as:

This of course shares all the same flaws as the previous leaky encapsulation, but also, what the hell are “Inir” and “Inna“?!

MUCH better is to provide a public enumeration in the domain logic layer:

And then change the property to use the enumeration:

Again, the database access layer should be completely and strongly encapsulating the strange codes that the database designers chose to use for the various values.


Be very aware of how database implementation details can leak into the domain logic layer and beyond, and put a stop to it if you can help it! Your code will be much better off, easier to understand and much easier to maintain and improve over time.

Separation of concerns: Application layers: The Utilities Layer

It is well-known that separation-of-concerns and proper application layering lead to a clean design, and improves application maintenance. In my July 2010 MSDN article, “Problems and Solutions with Model-View-ViewModel” I provided a standardized and layered high-level component diagram for virtually every software application I have had the pleasure to work on: Continue reading Separation of concerns: Application layers: The Utilities Layer