Bleeding edge has its price, there’s no doubt. I can’t help wondering if that isn’t the case right at the moment when it comes to "proper" solutions for managing your systems, for deploying solutions.
The premise is that you break apart your solution and put the different parts where they are best supported. In the case of SQL Server, for example, one of the pieces you’ll hear me complain about not being available on many cloud solutions is encryption. In this case, to support a solution that works then, many providers will suggest you use virtual machines for data that must be encrypted, then use cloud SQL services for the rest of the data support.
I realize things are changing, moving forward, being updated. I am sure this will get addressed (really, it has to be addressed). But right now, it seems like a Band-Aid.
There are a few different things like this that pertain specifically to how you deploy your solutions when you’re looking at the cloud. Pieces here, pieces there – it makes you re-architect your solution and it forces development and admin resources to work around the shortcomings.
But there is another side to this too, and that is using an optimized tool as the best tool for the job. In the case of encryption (sorry to beat this to death), it may be that moving data to a separate system is actually a better idea. If you consider that that layer of abstraction/removal adds another level to the access controls, it could be a benefit. Just because a potential hacker gets in your DB, they might still be prevented from getting protected data since it would be a layer removed.
My question is whether you would consider deploying to production a system based on this type of split configuration/architecture? Is it something you would go through the process of implementing or is this something reserved, at least thus far, for "no other choice" solutions?
Shoot me a note, swynk@sswug.org – let me know what you think.