Question

For the first time I am developing an app that requires quite a bit of scaling, I have never had an application need to run on multiple instances before.

How is this normally achieved? Do I cluster SQL servers then mirror the programming across all servers and use load balancing?

Or do I separate out the functionality to run some on one server some on another?

Also how do I push out code to all my EC2 windows instances?

Answer 1

Disclaimer – I’m not going to mention any Windows specifics because I have always worked on Unix machines. These guidelines are fairly generic.

This is a subjective question and everyone would tailor one’s own system in a unique style. Here are a few guidelines I follow.

If it’s a web application, separate the presentation (front-end), middleware (APIs) and database layers. A sliced architecture scales the best as compared to a monolithic application.

1. Database – Amazon provides excellent and highly available services (unless you are on us-east availability zone) for SQL and NoSQL data stores. You might want to check out RDS for Relational databases and DynamoDb for NoSQL. Both scale well and you need not worry about managing and load sharding/clustering your data stores once you launch them.
2. Middleware APIs – This is a crucial part. It is important to have a set of APIs (preferably REST, but you could pretty much use anything here) which expose your back-end functionality as a service. A service oriented architecture can be scaled very easily to cater multiple front-facing clients such as web, mobile, desktop, third-party widgets, etc. Middleware APIs should typically NOT be where your business logic is processed, most of it (or all of it) should be translated to database lookups/queries for higher performance. These services could be load balanced for high availability. Amazon’s Elastic Load Balancers (ELB) are good for starters. If you want to get into some more customization like blocking traffic for certain set of IP addresses, performing Blue/Green deployments, then maybe you should consider HAProxy load balancers deployed to separate instances.
3. Front-end – This is where your presentation layer should reside. It should avoid any direct database queries except for the ones which are limited to the scope of the front-end e.g.: a simple Redis call to get the latest cache keys for front-end fragments. Here is where you could pretty much perform a lot of caching, right from the service calls to the front-end fragments. You could use AWS CloudFront for static assets delivery and AWS ElastiCache for your cache store. ElastiCache is nothing but a managed memcached cluster. You should even consider load balancing the front-end nodes behind an ELB.

All this can be bundled and deployed with AutoScaling using AWS Elastic Beanstalk. It currently supports ASP .NET, PHP, Python, Java and Ruby containers. AWS Elastic Beanstalk still has it’s own limitations but is a very cool way to manage your infrastructure with the least hassle for monitoring, scaling and load balancing.

Tip: Identifying the read and write intensive areas of your application helps a lot. You could then go ahead and slice your infrastructure accordingly and perform required optimizations with a read or write focus at a time.

To sum it all, Amazon AWS has pretty much everything you could possibly use to craft your server topology. It’s upon you to choose components.

Hope this helps!