on perimeters, clouds, database outsourcing, security

I’ve long been somewhat anti-anti-perimeter. I understand the reason why groups of professionals will say there is no more perimeter, and I agree with most of their observations, I don’t really buy their conclusion that the perimeter is dead. I still feel there is a perimeter and there will continue to be a perimeter. It’s just not as hard and physical a stop as it used to be.

But, finally, the first real crack in the perimeter issue (at least to me) is coming from “cloud” services, like this Amazon RDS service. Basically, you want a database hosted by someone else? There you go, a MySQL instance at a third-party. Really, this is outsourcing your IT infrastructure piece by piece. This is like hooking me up to an external plasma or blood machine, and having it a critical part of my circulatory system. You’ll make me extremely nervous every time you get close to those delicate tubes and the power switch next to my bed! At least when it was inside my body, I certainly knew when something was wrong.

While I think this is a horrible approach for security (in light of our ever-increasing sensitivity to data flow, transmission, storage), I do recognize that it continues the destruction of “the perimeter.” Pretty soon we’ll have these golems out on the web where the web front-end is hosted at X, the database hosted at Y, with API calls to A-thru-M, and built with no security in mind. The silver lining? Continues the push for encryption when you’re outside the traditional perimeter. Is this bad? Who knows, maybe this will evolve into something awesome, but for now my initial feelings are quite cynical (if I were a web developer, I’d probably think the opposite!).

And like most outsourcing endeavors, I really think this will be a cool, trendy cost-saver in the very short term, but all the issues that come with “cloud” and outsourcing and trying to make a customized service into a one-size-fits-all product (study business strategy and economics to see why I make such a fuss about those two categories of product) are going to challenge this deeply beyond the next 12 months. At least with offering something narrow like a “database instance” you could maybe get away with calling this less a customized service and more a standard product. It’s definitely much better than saying something vague like, “we’ll massage data if you send it to us”. But still, it’s a very narrow piece that must rely on something else, and it is the stringing of those sorts of connections across untrusted networks that is sketchy.