The Infrastructure Access Layer, or IAL for short is a simple concept, nothing new, in-fact you have all been using something similar for years when programming against your databases. I have just expanded the concept to the cloud (and the ability to create “cloud ready” applications).
Infrastructure Access Layer (IAL)
The Infrastructure Access Layer is simply a way to abstract away your underlying infrastructure from your business logic or processing. This means that I can easily change how my applications interact with the infrastructure just by changing a method within the IAL and the business logic would be none the wiser.
Lets take a simple example, I may be developing an applications that takes work items and processes them. I create a method in the IAL called GetWorkItem which will return to my business logic the work item to be processed. This method can then call out to Azure Queues to get a work item, or maybe in the future you will want to switch out where we are getting the work item from, maybe we want to use a web service to call another location, use blob storage to store large work items or listen for a work item to be passed onto a service bus. This can all be dealt with in a single place.
All the business logic knows and cares about is that it is going to call the GetWorkItem method and get a work item back, not where it came from or how it received it it.
Cloud Ready…
Even with more and more people are moving toward the cloud, there are still companies that aren't quite ready to make the jump, but realise that in the near future may have to and want to know how to create applications that will be able to transition easily to the cloud when they are ready.
By programming against the Infrastructure Access Layer companies will be able to make this move a lot smoother, by just replacing the needed classes so that they interact with the cloud rather than the old infrastructure.
A great example of this would be using a messaging system such as MSMQ as part of your on premise application, and then being able to easily switch this out for Windows Azure Queues or the App Fabric Service Bus when moving into the cloud. Having to make minimal if any changes to your business logic.
Keeping the cloud contained
As I talked about in my last post the cloud can end up getting everywhere and you can soon end up breaking the principle of DRY (Don’t Repeat Yourself).
With the IAL you can easily keep the cloud contained, letting a minimal number of project have access to the cloud, making SDK upgrades and maintenance easier.
Is that it?
It is indeed. As I said at the start, the IAL is a simple concept that allows you to abstract away your underlying infrastructure from your business logic and also help create cloud ready applications for when people are ready to make that push to the cloud.
