With the advent of platform as a service (Azure and paradigms like it) it isn’t enough to simply write the same code patterns as we have in the past. To be sure, those patterns will still function in Azure, but we are not taking full advantage of the paradigm if we don’t exercise it more fully.
I’ve been reading Neal Stephenson’s “Snow Crash” again for the first time in a long time, and the old adage holds true – today’s science fiction is tomorrows science fact. In this story there are interesting paradigms in code – a strange mixture of “the sims” or second-life and the Internet. There is also the idea of telecommuting, remote meetings and classes, which develop into a real second economy.
Developers will bring in something similar using cloud technologies. Data marketplaces such as the one we recently released will become the norm, and the App store model from Apple will bubble down – not up – into code fragments that will allow other developers and non-developers alike stitch together entirely new applications.
So what steps do you need to take now to get your skills and code up to speed? My recommendation is to modularize your code logic – not the code itself, but the thoughts behind it – in a more Service Oriented Architecture way. From the outset, think of the public and private methods the code provides, and most importantly, divorce it from the processing of the rest of the system as much as possible. And – this is the important part – keep the presentation layer separate.
Again, that concept isn’t new. Lots of folks thought of this a long time ago. As software engineers we’re always supposed to do that, but over and over again I find the code inextricably tied between the two. If you keep them separate, however, there is something else I propose you do: implement functional contracts between your front end and the presentation handler code. Let me explain.
I suggest you create three levels of code – all of them separate – one handling the processing of data, numerics a-la SOA, the second handling multiple rendering properties such as text, HTML, polygons, vectors and so on, and the third for each front end you plan to address. That’s right, multiple front ends. I know this antithetical to a platform independent approach, but I think it is necessary. When I view an app designed for a win7 phone, an iPad and a web page, it is rubbish. Sorry, but there it is. Each platform has it’s own strengths, and you should Code to those.
Keeping a three-level architecture with contracts allows you to only rewrite front ends as needed, which of course need updating often anyway.
So there you have it – not necessarily a revolutionary concept or an original one, but something to keep in mind for programming against a Platform as a Service like Windows Azure.