August 30, 2012 by rnoowcc
Coming from a Unix, Lotus Notes and Java world I have always realised that there are more considerations when writing software to just your code. Software does not operate in a vacuum of dependencies to hardware, networks and other systems. From the early days of Unix where poor code could render a multi-user environment unusable to the Lotus Notes world, where I ensured that I had both Application Development and Administration Principal certification from all versions from R3 to R8 (one of handful globally), it was always incredibly beneficial to understand how the other half lived. Software solutions would work better, would be more reliable, require less maintenance , could be deployed and forgotten about if you understood the server, administration and the challenges other IT professionals experience. Issues would often only surface due to a hardware problem (weblogs being a recent case in point). I now find myself in a world where Cloud Platform providers, give the deploy and forget fix for no perceived outlay – what does it matter to you whether your buggy code takes out half of the Amazon East Coast EC2, when you’re hosted in Ireland?
However a recent piece of work has made me realise as developers, exclusively, we are missing out on or having to make adjustments that would not be necessary if we had a better understanding of the administrative and systems side. The work revolves around Google Authentication for a Ruby on Rails internal application. Using Devise and OAuth2, the authentication portion was a breeze and my user was authenticating within a morning of Googlifying the RoR app. The process involves a little bit of tooing and froing with the user being sent to Google, with a list of actions your application would like to carry out, and the user having to login (through Google) and authorise my apps actions. Once authenticated and authorised you are sent back to my application. That sounds perfect. Where’s the issue?
Well, after logging in, my attempt to call Google Web Services on behalf of the user, for simple actions such as finding out which Google Groups he was a member of, lead to authorisation errors. How strange I thought, I can see those groups in my list of Google Groups from a browser as that user. Rooting around in the dark, I happened upon a screenshot showing the Google administration console which specified permissions and roles, and thought where is that? Unfortunately, that was limited to Super Administrators and not mere developers. Following a few phone calls, I managed to get myself bumped to that level, temporarily, and voila the web service worked immediately. Obviously this could not be applied in the real world, so I needed a different approach.
Some more arm twising and bending, I find myself now on the WCC Google Test domain, with full admin access and Google’s application development approach has finally become apparent. Our approach to developing, deploying, maintaining and deploying applications if looked through a Google prism can be very different. If an in-house application has been developed using Google’s checklist and deployed with a complete manifest of what it wants to do, it can be deployed directly by the Administrators for the domain. This includes which users have access to the Application, whether the application is live or not. You can choose whether you want in-house applications to appear within the Google Marketplace list of applications (we probably wouldn’t) and the world of Google Gadgets now opens up, where we can write custom Gmail code to be triggered at will. Should I even heretically propose that we even consider hosting on Google’s App Engine, we would have our administrators looking after our critical systems and developed apps, in a single console upon which to gauge our corporate offerings and their stati. Whereas currently we seem to be the last to know either from another user’s Tweet that EC2 is down or that Heroku, as a platform, is unreachable. Maybe I’m a moth, but that Google light does seem more consistent and stronger than the flashes of the penlight we’ve been getting with our cloud providers to date.
Following on from this, my eyes have certainly opened up to how we can better approach application development practices given that marrying development knowledge with systems and platform architectures always gives the best results.