Cloud Computing: Cloud Application Deployment: 10 Deadly Sins to Avoid

 
 
By Chris Preimesberger  |  Posted 2011-09-27
 
 
 

Sin No. 1: Building an Infrastructure Cloud Rather Than an Application Cloud

Applications are the driving force behind cloud systems. While a focus on infrastructure may be important for a software development environment, business outcomes are built on applications. Application delivery, not infrastructure, has become a new bottleneck. To avoid this, ensure that computing, storage, network and application resources all get the same weight.

Sin No. 1: Building an Infrastructure Cloud Rather Than an Application Cloud

Sin No 2: Treating Automation as an Afterthought

For those who think scripted, preconfigured stack assembly is sufficient, decide whether you want deployments and updates that are reliable or fast. In a cloud world, there is a trade-off between the two, even in a virtual environment. Without true automation, there's no chance at efficiency at cloud scale. The business needs applications (and there are many), not servers.

Sin No 2: Treating Automation as an Afterthought

Sin No. 3: Not Controlling Golden Images

At cloud scale, the rate of change is great with new software and data images deployed daily. Golden (master) images can be massive, and changes are slow and hard to script. Not only that, but self-service environments require visibility for security and governance. Minimize image degradation and provide visibility with version-controlled "blueprints" of your system model that can be changed and deployed at the push of a button.

Sin No. 3: Not Controlling Golden Images

Sin No. 4: Failing to Avoid Vendor Lock-In

Scripting your own cloud system automation is a direct road to a dead-end destination: vendor lock-in. Also beware of platform as a service (PaaS); this is architecture lock-in. Making changes to a "locked" solution requires time, cost and risk. Not to mention that there are still multiple vendors at each layer in the cloud stack vying for market position, and it's too early to see who's going to come out on top. Agility via an open cloud architecture is the key to private cloud success.

Sin No.  4: Failing to Avoid Vendor Lock-In

Sin No. 5: Using a Manual Approach to Process and Change Management

The manual road in any case is time-consuming and fraught with human error, especially when new services and applications are emerging all the time. This constantly evolving environment makes manual efforts to keep up with process and change in a cloud environment virtually impossible. Push-button, repeatable change management is a much better answer.

Sin No. 5: Using a Manual Approach to Process and Change Management

Sin No. 6: Building a Cloud Without a Self-Service Portal

Trouble tickets are a thing of the past; your customer base wants service on demand. That's why implementing a self-service portal as a core ingredient in your private cloud strategy is critical. Customers need access to what they want, when they need it.

Sin No. 6: Building a Cloud Without a Self-Service Portal

Sin No. 7: Not Utilizing Versioning Control

Without visibility into your infrastructure, there is a high probability that you will make the same mistakes over and over again. There is also the added challenge of ensuring compliance when you don't know which version of which application was installed where. Whats the solution? Provide access to a complete history of all of your systems and applications. It's all about versioning. Centralized version control helps you learn from the past, manage today and plan for the future.

Sin No. 7: Not Utilizing Versioning Control

Sin No. 8: Scattering Software Resources

Because resources are scattered across a network, trying to track down and solve an error is often next to impossible. In a cloud world, your customers want it to work right and right now. That's why you must adjust your approach; instead of assembling the image, you must pre-inspect coordination of all of the pieces stored in a trusted central repository. Visibility into exactly what your infrastructure consists of helps you reduce errors, streamline updates and rollouts, and keep organizations in compliance.

Sin No. 8: Scattering Software Resources

Sin No. 9: Relying on Manual Rollbacks

Manual rollbacks (using system snapshots to go back before a problem occurred) have many shortcomings: They are time-intensive, risky and can compromise reliability. As a result, IT is hesitant and frequently slow to make changes. Automated (push-button) rollbacks with multi-tenancy offer you a way to partition your customer base and meet unique requirements of a particular segment—all without compromising consistency, reliability or speed.

Sin No. 9: Relying on Manual Rollbacks

Sin No. 10: Automating Provisioning Without Automating Updates

Looking to sidestep the update problem by making all your applications stateless???íThis is not reality. Cloud-based applications need automated updates.

Sin No. 10: Automating Provisioning Without Automating Updates

Rocket Fuel