Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am a freelancer and plan to work with other freelancers in the coming time. Since I would be owning the project(s), I want to own the development environment as well. We all will be working out of our respective locations. I have been contemplating using Amazon's EC2 service for the purpose of erecting a development environment and giving desired access to the others involved.

With the above in mind, I have several queries:

  1. Is this a good idea in the first place? Is it better to have VMs created and distributed (physically) to the members of the team? Of course I lose control in this case and data is vulnerable.
  2. Should I just buy a Large instance, install all desired tools, create users and provide them access as per role?
  3. Should I just buy a Large / Extra Large instance, build VMs inside the instance, one each for every role and instantiate instances per user? I am not sure right now how the access would work out. How one would be able to directly access a VM instance running inside the EC2 instance.
  4. There are tools that help in managing the EC2 instances w.r.t. the EC2 APIs. However, w.r.t. what I have explained above (specially point # 3), are there tools that can help in the management / monitoring of instances and VMs within?

There may be many more complexities that I cannot think of at this point. Will appreciate inputs / directions in case someone has been through this already.

share|improve this question

1 Answer 1

Option 2 requires having an instance up and running 24/7 (or at least during the union of everyone's work schedule). This may not matter to you.

I'm not sure if option 3 is possible. Are you asking about installing Xen (or something) inside your EC2 instance and then creating your own "sub-virtual" machines?

Another option is to create an EC2 image (AMI) with the development environment set up, and then allow each developer to launch an instance of this AMI whenever they want to work.

Benefits:

  • Developers do not compete for computing resources (e.g. CPU) on a shared machine. This may not matter to you.
  • You can modify the image (e.g. an operating system update) and release a new "version" without requiring downtime for all developers.
  • Potential savings since you don't need an instance up 24/7.

Drawbacks:

  • Potential increased cost since you might have 5 instances running (i.e. 5 developers working at once) instead of 1.
  • Requires each developer to have access to an AWS account.

If you think this is right for you, then the AWS account problem can be addressed in several ways:

  • Each developer uses your AWS account. This is the easiest option, but requires that you trust them.
  • Each developer creates their own account and forwards the bill to you. This causes more "paperwork" but allows you to reject bills if you think the developer is not being legit.
  • Each developer creates their own account and you use AWS Consolidated Billing to pay them all using the same credit card.

I believe you can grant launch access to an AMI without necessarily giving the person root access once the instance is up and running. But you would want to double-check this, since it sounds like you are concerned about security.

Finally, this would obviously require some central source code repository which is running 24/7. One more reason why this may not be the right solution for you.

share|improve this answer
    
Well, at this point, I will keep this option with a lesser priority. Clearly this will be an expensive proposition, but surely is an option. –  Kabeer Feb 22 '10 at 19:03
    
Matt, I already have a central source code repository (@ assembla) thankfully. So I guess this is not a challenge. –  Kabeer Feb 22 '10 at 19:17

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.