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 have a kind a complex architecture involving 5 differents applications:

  • 1 API
  • 1 Frontboard
  • 1 Dashboard
  • 1 Administration Panel
  • 1 Public File hosting app

All these apps are actually hosted on a single dedicated server and running in Node.js

I want to push my architecture in the Amazon AWS cloud but I'm still questioning myself about the new architecture I want to set-up.

Do I need to split my apps and run one EC2 instance for each app (and possibly 1 load balancer for each application group) or can I run all my apps in one single instance and use a single load balancer on top of it.

I wish I could be more precise, but I'm not used to scaling techniques.

Hugo.

share|improve this question
    
So putting a single box behind LB is not of any use , atleast put more than one box behind LB so that you can scale your app , and put each instance in different zone so that you will get redundant architecture. –  Abhishek Anand Amralkar Oct 1 '13 at 10:05
    
I think I wasn't clear enough: I don't want to LB one instance. My question is: do I put all my listed applications in one single instance, or do I split them in several different instances (one EC2 isntance per project). Load Balancing will come after when I'll have multiple instances of my projects. –  gogson Oct 1 '13 at 12:16
    
It depends upon how busy your each app is? If you have a low traffic app than yes you can go for single instance but my concern with this is you are in cloud and at higher risk of getting some technical glitch , what you can do is benchmark your apps with single instance and also with splitting them on multiple instances. –  Abhishek Anand Amralkar Oct 1 '13 at 12:45

2 Answers 2

up vote 2 down vote accepted

Assuming you're not concerned with high availability, If one instance can handle the load, then put them all on one instance. That said, I would put some monitoring around those particular services so that you know when its time for them to have their own host(s). You might find that different services are going to need to scale out at different rates. The only good way to keep an eye on that is with good monitoring and instrumentation.

You can save yourself a lot of headache later by introducing some abstraction between services. For example, make sure that when one service is calling the API, it calls it by some name (DNS is great for this). Something like api.myapp.com will be fine. Maybe initially, all the names point to the same host. But in the future, when you need to scale, you can point that name to an Elastic Load Balancer with a bunch of instances behind it, and nothing in your application needs to change to talk to the new instances.

If you are concerned with high availability, you need more than one box. full stop.

share|improve this answer
    
Indeed, high availability isn't our first goal. Our first goal is easing our architecture maintenance. I want my CEO to be able to deploy our entire architecture in a few minutes if a server crash occures. We actually can't because of an outdated server and no resource to spend on doing sysops/devops. But maybe pushing my architecture on a single EC2 instance isn't the best solution neither. Thanks for all your answers guys. –  gogson Oct 2 '13 at 13:29

Given the information you've provided above, I'd recommend compartmentalisation or abstraction of services from each other if you are going to keep them on one box. As a sysadmin, I'm loath to recommend relying on a single box for your entire architecture, but if you are not concerned with high availability and you have a suitable backup solution in place for any data that you wish to retain in the case of failure, then go ahead (even if you are distributing your architecture one box per service, you should still be backing up your data and configs!)

If however you are willing to spread your services over multiple EC2 instances - which will aid with scalability later - remember to use DNS names or EC2 elastic IP addresses, as the internal IP addresses of the boxes can change. Because traffic between the internal IP addresses is cheaper though, you might want to investigate using these and dynamic DNS if you are going to have a lot of inter-component traffic.

Remember too that if you will need to scale beyond a single instance per service at some stage, your design should take into consideration the possible future use of AWS' Elastic Load Balancers and Auto Scaling.

If you need your CEO to be able to spin up a new stack quickly in case of issues, I'd recommend investigating AWS' Cloud Formation service. This allows you to use JSON configuration files to define a stack comprised of multiple AWS resources, and launch and terminate your service with minimal interaction.

share|improve this answer

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.