I'm sure everyone is aware of the recent volcanic eruption in Iceland and the cloud of ash that has been spewed out and more importantly the knock on effects this ash cloud has had on not just Europe but the whole world.
Clouds can Spread …
The ash cloud started out in Iceland where it eventually moved and spread out to cover the UK and Europe, even some reports say that it got as far as Canada. Grounding planes and crippling transport for a number of weeks.
This got me thinking, not all clouds are nice white clouds, some are evil volcanic clouds that actually do more harm than good especially when not contained to where we want them to be. (the ash cloud would have been fine if it had not strayed into European airspace).
The same is true in your applications, when developing for the cloud you can find that the cloud can end up spreading throughout your applications and if your not careful touching every section of code you write.
This can then be a real problem when the underlying SDK to interact with the cloud changes and you have to go through all of your application looking where to refractor and make changes.
Contain Your Cloud
To combat this I contain any code that will access the cloud within few specialised “cloud” projects within my application.
This means that throughout the application if I want to access the Azure message queue, I call a single method from one of my cloud project that will return me a message, meaning that no other part of you application needs to know how to deal with the cloud.
Added Benefits
Containing your cloud not only allows you to keep to the DRY principles and code re-use it, makes maintenance of your application easier and can reduce code smells. One of the biggest benefits is that it also allows you to easier test your applications without having to rely on the cloud or developer fabric, as you can create your cloud methods in a mock-able way.
