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 are often not even friends with each other. Infrastructure is a necessary evil for developers to accomplish what they need to do and it presents a hurdle to overcome.
What this all means is. Infrastructure is not just for production anymore. Take all the benefits of the cloud and embrace it as the optimum pre-production environment for sandboxed development, testing new technologies, and exploring evolutions of your organizations production environment. This point of view has been difficult for me to explain, due to the habits of IT to focus only on production. But once people understood, they really got it. This approach enables developers to control the infrastructure and if something breaks it can be repaired with snapshots allowing an easy restart. There also are no more long requests for virtual machines or concerns about security. Additionally, you can ensure that developers stay out of production, which is business and regulatory requirement for many firms. Let IT focus on production and not have a second thought about what the developers need.
Companies that have not yet adopted the cloud should set aside a place for it in pre-production. All things that are volatile and often considered a cost center can be re-positioned and become predictable in cost. You can also remove unsightly development boxes under peoples desks. DevOps fits naturally into this approach. The transient nature of development tasks, the high risk of complications, the need for flexibility are all reasons DevOps should be exclusively in the cloud. In the cloud DevOps has a predictable cost, is in the control of the developers who use it, and provides the greatest level of flexibility. It also gives developers the chance to test things they would otherwise shy away from.
The reality is that not all cloud solutions are built for pre-production. There are some questions you need to ask yourself when looking for a cloud provider.
How predictable are the costs? Does the cloud provider give you a pricing model that keeps the costs of using the service very predicable? If not, then it’s a cloud provider that tailors only to solutions where the production is always on. As a developer, it’s very hard for you to know what bandwidth, memory runtime, and hard drive runtime you will use; you should not have to care.
What type of cloud service do you need? Do you need Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), or Software-as-a-Service (SaaS), or some sort of combination? Being a developer of large enterprise applications, I need a good deal of resources, a robust Development Environment (IDE) and administrator-level access to virtual machines. I need an IaaS cloud provider with a nice SaaS user interface. But more specifically I need an IaaS that supports the saving of states.
When I develop, I develop in short bursts, and I can’t rely on a strict process of check-in and release. I need the ability to pickup on an environment exactly how I last left it—in the recycling bin, mid-compile, or in another state. This refers more to IaaS, but for a developer, it’s necessary to have the ability to suspend environments and pick up where one left off. Most cloud providers give you two options for your virtual machines: off or on. This, for a developer, is painful. You must wait for reboots, and you have to close applications and shutdown your environment every time you walk away from it. For me, I really need to be able to suspend my environment and pick up where I left off the next day while its suspended pay a reduce cost.
Additionally, you must have the ability to share with your customers and end-users what you are working on without confusing them with the cloud and the concepts that come with it. If you are unable to share with your customers, you need to be able to share with other developers or transition all your environments to them. Several cloud solutions offer this ability via web access to cloud environments avoiding the VM level access or the ability to share whole VMs.
You must have the ability to backup and regular snapshots of complete environments. This is the key to failing fast. Snapshots are the tool that saves you when something goes wrong. Even when you are rebuilding multi-tier web applications in the cloud with sever web front ends and a backend, you need to be able to take snapshot of the whole environment and revert it back to previous versions, just as you would from a source repository.
Finally, the best way to evaluate and pick a cloud solution is to try one out. If you don’t have a way to try a cloud solution, then it’s not a vendor for you. Keep in mind, all of us nerds like to tinker, but tinkering and configuring things are really just barriers to productivity. You need to make sure during your evaluation that you quantify how long it takes you to get up running and coding.
It’s not rocket science, but it can be a paradigm shift. The cloud for pre-production seems such an obvious way to bring many of the cloud’s benefits, including fully-sandboxed environments and the ability to both fail fast and remove volatile no-production activities from production-level solutions.
The next time someone who has no experience with the cloud talks to you about how they are thinking about investing hundreds of thousands of dollars into a production-level cloud solution, remember this article.
