Bladewatch.com

I was having a conversation with one of the application teams about migrating their application to be compatible with one of the grid application tools. There was concern that this might affect the control that the application team have over the application, that by using ‘the grid’, they have to work within their constraints, the rules of deploying a new application, of making sure that their code is adequately tested etc. Their argument was that outside of the grid, they controlled the data source, they controlled the calls they made within the application code, and they (the support team) dictated when new application releases were released, when infrastructure could be taken down or not. That IT could take down so many blades during the day for maintenance and not tell the application team, reducing performance and resilience.

Let us step back just two steps. The reason we’re looking at something like DataSynapse, Platform or any of the others is hardware abstraction. Although you might have ownership of the infrastructure and the application, this doesn’t really change within the grid environment, all that changes is that we have a more industrial strength solution, a bit more control and transparent way of doing business.

You want to deploy new code to the grid? Not an issue, raise the relevant service request or change request, and submit it for deployment to the grid. Consider that it is not in IT’s interest to have servers not in the grid, both in terms of resilience and ‘branding’. Branding sounds such PR’ish, (if that’s a word), but what I mean by branding is end user perception, of managing user expectation and service delivery. We can anyway overcome such issues by giving application support teams read/view rights of the grid middleware, or access to the grid logs etc. What we want is ideally a transparent infrastructure, a common shared infrastructure with the right optimizations for the applications running on it, in an approved configuration so that the grid team can co-exist, can do the grid support, ensure that grid is available for applications to submit workload to the grid on demand.

The grid team in effect should be infrastructure based, should be the connector between the application support teams and production. They should manage the expectations of the user groups, the stakeholders and the teams that support the underlying infrastructure, working in line with (or as close to) the ITIL processes, with a clear understanding that grid is in an on demand world, where the processes should reflect this.  I’m all for process, you want a change made to grid to fix a problem on the staging grid, we’ll do it in five minutes, but can you log a service request, so that we can log the setting changes in the system and maybe note the changes on our intranet site (one of those collaboration tool, even a blog).

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.