Chris Riley writes that when an organization is considering the cloud, it has to consider its approach as well. The cloud was built on the principles of initiating things fast, and only what you need when you need it. The cloud was not built for people who follow the mantras of “set it and forget it” and “plan for everything ahead of time.”
When the cloud hit the masses in the mid-2000s, the immediate effort and implementations were all production grade. Cloud computing was regarded by companies as the answer to many challenges and seemed to be the future of computing. The concept of agility passed everyone by, however, and the comfortable process of picking enterprise-level technology kicked in. Organizations did not consider how they could embrace a cloud solution with little or no effort, and instead they treated it like deploying a completely new IT infrastructure. As a result, the cloud lost its gusto. There were long sales cycles to purchase cloud products, long planning required to deploy it, and as a result poor adoption, not a lot was accomplished with the spirit of the cloud.
You have to think that this is quite ironic; this is new technology but we are using the old habits of adoption. When considering the cloud, organizations have to consider their approach as well. The cloud was built on the principles of initiating things fast, and only what you need when you need it. The cloud was not built for people who follow the mantras of “set it and forget it” and “plan for everything ahead of time.” For configuration management professionals, the cloud presents new challenges in terms of provisioning servers. It’s a paradigm shift that does not fit the mold of typical infrastructure acquisition processes. It may not even be the configuration management people who control the provisioning at the end of the day. It also provides new capabilities that highlight the value of automated deployment frameworks. The ability to have only the number of machines you need, when you need them. The ability to scale in minutes with no approval cycles or hardware considerations.
The dominance of production-level cloud solutions can muddy the waters for developers working in day-to-day operations that do not involve the production-level line-of-business applications that most people talk about. In a developers mind, production is something much different. This is where they work. Production for a developer is a place to code, build, test, and repeat. This process is actually volatile and has peaks and valleys of activity.
The cloud’s core tenants are accessible from anywhere; you have access to instant scalability and you can avoid any capital expense. Scalability used to imply that you could add infrastructure, but you don’t typically take anything away. With the cloud ,you can scale up and down in hours, not weeks. You can remove the fear of breaking servers, because replacing a corrupt environment is a trivial task.
The concept of fail fast is near and dear to my heart. I’ve noticed over the years in IT a lot of projects never see the light of day for the simple reason organizations are too afraid. They are afraid of the restarts if something goes wrong midstream. They are fearful of the learning curve. Fail fast means you have none of these concerns. In fact you encourage encountering roadblocks sooner rather than later, discovering issues, and thus reaching their solution sooner. This allows organizations to try more and do more with advance technologies. When I step out of the production mindset, the cloud becomes the place where I can break things, start over fast, sandbox all elements of an enterprise application deployment, and forget about talking to IT.
I’m reminded of conversations with my family who are unfamiliar with the technicalities of development; to them, IT encompasses anyone capable of doing more than checking Facebook and sending an email. But let’s face it, developers and IT managers are not the same people and