Built for operations (update 1)
We’ve previously touched on the trend of operations having an impact on application architecture. Up to this point, the shift towards being “built for operations” manifested itself as subtle organic changes that differed from organization to organization. If you stood back far enough, you can see it as an unmistakable trend but there hasn’t been a common driving force.
The rise of Amazon Web Services, specifically EC2, is a remarkable force that could result in a sea change in the average developer’s assumptions. For example, why do you need persistent local storage on any one machine? In EC2, if you shut off a machine you lose everything on it that isn’t part of the template image used to instantiate it. I can’t get that instance back but I can instantly launch a dozen clones from the same “birth state”. Whoooah… that’s just a little bit different now, isn’t it?
Local writes are lost? Servers are completely built from templates? Launch fully operational clones with the push of a button? The implications of these three simple concepts alone are enough to blow a lot of people’s mental gaskets.
Everyone gives Amazon props for cheap on-demand infrastructure hosting. Perhaps Amazon should get a bit more credit for pushing the art of systems architecture and management forward in a very public and massively appealing way.