Tips To Help With Your Cloud Computing Project
By Dan Morrill
Just finishing up the final touches on my first big cloud computing project, and there was much to learn here, some pitfalls and some promises in the cloud that might help you with your cloud computing project.
As I wind down the infrastructure part of my first big cloud computing project, there are some rewards and risks, along with some pitfalls to cloud computing that you might encounter when you do your big project. Here is what I have learned.
User Management - not so easy, if you stick with the Amazon Web Services console, you are simply down to one person logging into the system. Using shared credentials is a big no no when it comes to providing security and accountability with your project. I did not find a software or product that would allow me to make multiple administrator accounts that would work for me. There are software programs that exist, but I found most of them lacking what I was looking for leaving me with the AWS console and access to the computer being shared by multiple people and one login. If anyone has a great tool that will provide the ability to audit, report, and provide multiple account support for multiple AWS images, then I would love to hear about it.
Updates - if you want to make sure your system is updated, then I would highly suggest you make your own AMI on a fully supported operating system (regardless of flavor). One of my biggest issues was finding out that YUM on Fedora would not update on the Amazon AMI, and kept on coming up with out of mirror errors. Fedora needs to step up to the plate and provide a fully functioning mirror, or better yet you should make your own AMI for AWS that provides the support you need for what you are trying to do. There is nothing more dangerous on the internet than an Operating System that cannot be patched or software that cannot be updated. If you are using a Windows AMI, make sure that everything is installed or that you have an I386 directory, there is nothing more amusing than being prompted to provide the installation disk when your OS is in the clouds.
Socialization of the product - Cloud computing is scary for many people, because it puts everything you have in someone else's data center. For some the concept must be killed now, for others they see it as a way to save money. Regardless of what your approach is, you have to make sure you have full executive support and buy in for what you are doing; otherwise your project will languish for weeks if not months waiting for people to grab onto the concept. You should be prepared to deal with fear, FUD, and other undesirable business ways of killing off the cloud computing project.
Failure is going to happen - make sure you snap shot your Cloud Computing system before you start tinkering with it. While backups are always a good idea, it is also an excellent idea to simply snapshot what you are doing before you make huge changes to the system. This is often easier than trying to back out a pile of changes and you have no idea which change broke what.
Never ever hit "Terminate Instance" - if you hit terminate instance, it is gone, gone for good, and you cannot get it back, pray you made a snapshot before you "turn the computer off" for the night. Otherwise you get to start from scratch on the whole thing. This will cause amusing chuckles from your co-workers, and bemused responses from your Project Manager. It might also set you back unless you made a snapshot.
Logging - make sure you have a nice way of getting logs back to the company, or that you are going to be able to process logs on the cloud computers. You will want this for compliance, and to know if someone is doing something unusual with your system. Syslog over the internet is not a great way to get logs off the cloud back to the company. You want to use a VPN to make this happen, and it is easy to set up regardless of chosen operating system.
Documentation - you want to make your own documentation on the project you are working on, do not rely on AWS documentation to help you, often the AWS documentation is difficult to follow, understand, or read. The approach to documentation is make your own, and do it in such a way that anyone can follow what you did, how you did it, and what they need to duplicate your processes. Like any good system design or development, cloud computing systems should be documented just like any other internal project.
Make sure you have a good ROI - make sure that if you go into the cloud that there are obvious measurable cost savings in the offering. Some setups make no sense economically, while for some companies they do. Make sure you do not overspend on your project.
Continue reading this article.
About the Author:
Dan Morrill has been in the information security field for 18 years, both civilian and military, and is currently working on his Doctor of Management. Dan shares his insights on the important security issues of today through his blog, Managing Intellectual Property & IT Security, and is an active participant in the ITtoolbox blogging community.
NetworkNewzis an iEntry, Inc. publication --
iEntry, Inc. 2549 Richmond Rd. Lexington KY, 40509
archives | advertising info | news headlines | newsletters | comments/feedback | submit article