Eight things worth considering before building your first private cloud (Part 3 of 3)

Read Part 1 and Part 2 of this series.

In this three-part series, we look at what to consider in the early phases of a private cloud project. We already talked about virtualization, automation, self-service, and chargeback. In this last part, we will see how important it is to keep in mind subjects such as monitoring, compliance, backup, and security too.

5. Monitoring (and help desk)

In a cloud environment, not only administrators but cloud users too will want to monitor what’s going on. This means that the monitoring solution (for instance, IBM Tivoli Monitoring) should not only work with the cloud, but also be integrated within the self-service portal so that everyone can follow the health of their virtual machines.

If you plan on supporting the cloud environment through a help desk, you will probably need to feed your corporate Configuration Management Database (CMDB) after every single change (creation, modification, or suppression) of virtual machines. This interface should be planned carefully. This way the help desk will “know” about the actual state of your cloud environment. If you are to host production workloads on your cloud, this step becomes mandatory.

6. Compliance (and patch management)

You have to decide with all the actors, from security to end users, what will be the policy in terms of compliancy checks and patch management with software such as IBM Tivoli Endpoint Manager:

  • Do you need compliance checks?

Whether it is wanted or not, some people are susceptible to violating corporate rules. This is why compliancy checks must be run on a regular basis. These tests need to be defined before implementing the cloud, to show what is possible and what is not from the beginning. And do not forget to plan for a mechanism to alert the virtual machine users!

  • Do you need to enforce policies?

The problem is that, when it comes to patch management, owners of virtual machines will probably be reluctant to apply patches that could break their software. One relatively good compromise is to allow each user to choose between either managing patches themselves or leaving patch management to the cloud administrators, with a different cost for each service, of course.

7. Backup (and recovery)

This is a vast subject because you need to worry about:

  • Backing up your cloud management platform

The same way you back up any virtual machine in your traditional IT is the way you should back up your cloud management platform and have a tested procedure to restore it.

  • Backing up your cloud virtual machines

Provide your users a way to back up and restore themselves virtual machines. This should be a self-service offering, and because storage has a cost, you should see that this space is charged.

Decide what your policy is if you lose a virtual machine: Will you recover it from a virtual machine’s backup? I suggest you make this a manual process (or scripted) because this scenario should not be too frequent.

  • Being able to recover from the major crash of a whole data center

Last but not least is the case of a major crash of the whole data center. In this situation, you will need a clear strategy and carefully plan for it during the early phases of the project. Third-party site recovery tools, depending on the way you plan to use those, might or might not be compatible with all the pieces of your cloud solution.

If you have not already read it, I suggest you look at “Considerations for backup and recovery in cloud” from David Kwock.

8. Security

Last but not least is security: The key words here are “best practices.”

  • Physical security

Even if we are talking about virtual environments, the physical security at the data center level has to be dealt with. I’m not an expert here, but it really is crucial to have good physical security before you start worrying too much about virtual and cloud security.

  • Cloud security

You need to secure your network and the management software that is being used. Here some basic best practices are:

  • Authenticate all people.
  • Keep it simple (that is, remove the unnecessary components and, in the design phase of your cloud, try to minimize its complexity)
  • Encrypt all data that is exchanged or stored in public locations.
  • Monitor activity to detect threats.
  • Be prepared for anything. For instance, in case of a contaminated system in the cloud, what will be your policy? Will you quarantine or simply destroy the system?

Security demands careful planning and needs to be challenged during each phase of the project.

All in all, it’s very important to remember that all of those topics, from virtualization to security need to be thought of at the beginning of your cloud project. Maybe you will not implement everything at first, but at least you will have a roadmap of what to implement and when. Good anticipation and careful planning are keys to success.

Share this post:

Share on LinkedIn

Add Comment
No Comments

Leave a Reply

Your email address will not be published.Required fields are marked *

More Archive Stories

Tips for customizing your environment with IBM Bluemix

Co-authored by Burak Cakil IBM Bluemix is an amazing deployment environment that allows you to mix and match runtimes, services and add-ons to suit your specific needs. For example, a given application can only use a single runtime, but typically uses multiple services and add-ons. We would like to provide some useful tips for customizing […]

Demo or die!

When Nicholas Negroponte started the MIT Media Lab, he told students to focus less on writing papers and more on proving by doing. “Demo, demo, demo!” he said. In agile software development practices, the developers focus on producing demo-able code at the end of every sprint. By following IBM Design Thinking you can go even […]

Using the Cloudant database service in an IBM Bluemix application

As a cloud solution architect, I am keen to understand the capabilities of the new IBM platform as a service (PaaS) offering, IBM Bluemix. In particular, I’ve come to realize that preserving a state in an inherently stateless architecture is key, so I decided to investigate how to use the IBM Cloudant database with an […]