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.

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.

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.

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.

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.

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.

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.

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.

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.

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