You heard the buzzwords and drunk the kool-aid and now you want to move to the cloud, how do you do this? This has been the a fairly interesting question on the VMware Communities Podcast yesterday, when the vCloud team showed up to talk about the current reference architecture. Yet almost all the questions were about going to the cloud and not about the architecture. Does this mean people do not understand what is required to go to the cloud? I think so. So to take a few elements from the podcast and put them in writing is the goal of this article. The Simple Steps to move to the cloud.
So what at the simple steps?
- Define your Requirements (Requirements Gathering)
- Review/Update your Processes, Policies, and Procedures (Architecture)
- Plan, Plan, Plan, and then Plan some more (Design)
- Define and Train your Cloud and Virtualization Teams (Training)
- Implement your Cloud (Implementation)
Yes, there are 5 simple steps to move to the Cloud, but they are not all that simple of steps. In most cases you may need a little help from others. But let’s discuss each in detail.
Define your Requirements
This is the area where you decide what are the reasons for moving to the cloud. As a C-level type or lower level administrator do you want to move to the cloud to improve IT Agility? Have IT Pay for Itself? or Even make IT a Profit Center? Or are you moving to the Cloud because of Cost issues with buying more and more hardware, licenses, etc. is eating away at what budget you do have? In either case, you need to know the requirements and the goals for going to the cloud. Here is where you start to look at the benefits of IT as a Service and service catalogs, but before you define such elements there are two basic steps that must be taken.
- Define who are the Cloud Users? Are they the System and Application Administrators, Developers, Quality Assurance, Executive Assistants, Non-Technical users, etc. Or a combination of the above.
- Once you define who will use the Cloud, sit down with those Users and determine what they do on a day to day basis. You will need this information to further define your requirements, architecture, and design. An example of this could be Application Administrators who want to dynamically increase the number of web services during peak loads and decrease them when they do not need them anymore.
This is a critical yet overlooked phase.
Review/Update your Processes, Policies, and Procedures
This is probably the most complex part of going to the Cloud. In this stage you take the defined requirements and goals, and determine what processes, procedures, and policies need to be created, updated, or dropped completely. This is the architecture stage where all aspects of the environment are reviewed. Outside of Requirements this will define your Cloud in more solid terms. Since the Cloud is based off of having a well defined service catalog that contains applications, operating systems, service level agreements, compliance, security, charge-back/show-back, life-cycle, and many other aspects within a IT infrastructure, it is incredibly important to create the proper procedures based on the use model you have discovered.
What processes should be reviewed or changed?
- Golden Image Build procedures
- Capacity Planning Process
- Patch Process
- NOC Procedures
- Management Procedures
- Monitoring Processes
- Trouble Shooting/Debug Procedures
- Security Policies
- Incident Response
- Network Management Processes
- Life Cycle Procedures
- Regulatory Compliance
- Disaster Recover, Disaster Avoidance, and Business Continuity Policies and Procedures
- etc.
Yes, that is quite a list, but any one of these could cause you issues when you move to a self-service environment where your IT Staff has been cut-down or re-allocated to different tasks. Your service catalog needs to be developed in some way that will meet the organizations current and future procedures, policies, and processes. There is a need to have well-defined owners and procedures for handling security and compliance incidents, disaster recovery and avoidance, as well as the necessary steps to maintain the contents of the service catalog and the elements already deployed from it.
On top of this, the Architecture phase is the best place to determine what aspect of the cloud you need to use (IaaS, PaaS, SaaS, etc.) and whether you will want to take advantage of a local private cloud or include in your architecture the process and procedures that would allow you to make use of external clouds such as Terremark, Verizon, Savvis, etc. Also, in which cases this would be allowed.
Architecture must include groups from Networking, Storage, System Management, Virtualization, Security, NOC, and all other aspects of your IT infrastructure.
Plan, Plan, Plan, and then Plan some more
The design stage is where you get to choose the products that will comprise your Cloud. This could be VMware vCloud Director with VBlock, or some other combination of tools from rPath, Embotics, Platform Computing, etc. However, you go, you need to Plan, Plan, Plan, and then Plan some more. Ensure, you involve all aspects of the IT infrastructure in the review of anything that comes out of design. Design needs to address everything that comes out of Requirements and Architecture.
The most important step is to review, review, and review. You may want to include a small proof of concept to validate any design as well. You may pick great products but find they do not fit your needs. Design is the area where you get to play with the technology before you fully choose what you will use.
Ensure you include all Compliance and Security components that will be necessary to meet your regulatory compliance. Overlooking any aspect of the Architecture at this stage could waste quite a bit of time.
Hence, the mantra: Plan, Plan, Plan, and then Plan some more.
Define and Train your Teams
After you have a design it is time to train those who will make up the Cloud team which will include people from networking, storage, security, application management, system management, and virtualization management as well as any other aspects of your IT staff that need to be part of these teams. Once the teams are trained, then you need to train your Users of the Cloud. Training of the Users will most likely wait til after the Cloud is implemented, but training the administrators is critical. They need to understand the products in detail before going forward. Do not overlook how to troubleshoot your environment.
Training your users and administration staff will be paramount.
Implement your Cloud
Now you have all the pieces to implement your Cloud. The key here is to start small and grow as you need. Start by taking the proof-of-concept you started during the design phase and duplicate it within your production environment applying all the procedures and policies that make up a production environment. But not only that you need to have a separate QA environment that is identical to the productions environment but perhaps with less hardware, but all the same hardware regardless. QA is where you will test your brand new Service Catalog before putting it out into production. The steps of production are:
- Put together the Cloud Components within a QA environment
- Start to define your service catalog, golden images, etc. within QA
- Put together the Cloud Components within a Production environment
- After QA of your service catalog, move it to production.
- Test, test, test.
The key to this stage is to test everything in QA and then test once more in Production. Test your backup procedures, disaster avoidance, and recover procedures, incident response procedures, auditing and compliance policies, etc.
Once the test is completed, your implementation will be ready for prime-time use. The QA environment is where you will handle testing of patches and new features to be added to your cloud as they become available as well as develop new Service Catalog entities.
Conclusion
The steps to moving to a Cloud within your Organization are listed above, but these same steps will be necessary when making use of Cloud Providers. The only real difference is during the implementation stage. Implementation in this way requires you to work closely with the Cloud Provider administrators to ensure your implementation works as expected, can be audited, and and provides the agility required.
If you do not have process and procedures in writing for all aspects of your current infrastructure, going to the cloud will aggravate your existing problems caused by lack of such documentation. If the documentation is incorrect, the Cloud will show you where in short order. Making use of the Cloud is not a ‘shoot from the hip’ type of implementation but requires careful planning and understanding of your requirements, a proper architecture, design, training, and implementation.
Comments are closed.