In his The Case for Hybrids blog post Mat Mathews described the Hotel California effect of public clouds as: “One of the most oft mentioned issues with public cloud is the difficulty in getting out.” Once you start relying on cloud provider APIs to provide DNS, load balancing, CDN, content hosting, security groups, and a plethora of other services, it’s impossible to get out.
Interestingly, the side effects of public cloud deployments extend into the realm of application programming, as I was surprised to find out during one of my Expert Express engagements.
I was talking with an engineer who was tasked with setting up networking infrastructure for a private cloud that would allow his company to migrate the workloads from a too-expensive public cloud into a more cost-controllable private environment.
It looked to be an easy engagement focusing on designing the networking infrastructure for maximum scalability – after all, the programmers deploying cloud applications usually know a bit about scale-out architectures and resiliency – and I got a real shock when encountering the stretched subnets needed to support live long-distance VM mobility in a list of requirements.
It turned out that while the programmers understood everything about application resiliency, the redundant database service offered by AWS lulled them into complacency – they never thought about the database redundancy, and because writing database connect strings straight into source code seems to make sense to some people, they got stuck with an application stack relying on a single database instance that had to be constantly nurtured and carefully migrated to another data center during disaster avoidance process (all other virtual machines could be shut down and restarted on the other end, but the database remained an untouchable holy cow).
Fixing the application stack was (as always) out of question, resulting in another case of brownish substance flowing downwards until it creates expensive complexities in the network layer.