Going production with AppScale

Posted by Meni Vaitsi on 3/2/16 8:04 AM

Find me on:

I frequently get asked what the ideal setup is for a production AppScale deployment. There’s no one-size-fits-all approach and that’s how flexible AppScale is and how easily it can accommodate your needs. You can mix and match to save up on cloud computing costs without making compromises when it comes to having your app up and running at all times. However, there’s a trade-off in cost reduction versus high availability. If you’re using or want to use AppScale to cut down operational costs you might have to consider limiting the size and number of servers used, while if you’re aiming for high availability, server redundancy is fundamental. Typically, monitoring the behavior of the application on the new platform can provide all the information needed to help you make the right decisions.

So you played with AppScale, you test-drove your app and now you want to go production. Let’s look at a couple examples to help you get started.

 

Example #1: Internal Enterprise Application

Take a BI application for example. Here is a list of stats for this application:

  • 1-10 reqs/sec
  • 100-200 active users monthly
  • 100-500 GB of mission-critical data

To host this application on AppScale it takes roughly 6 AppScale-ready servers on the infrastructure of your choice. Specifically:

  • 1 head/load balancing server
  • 3 database servers (replication factor of 3) for high availability and fault tolerance; it’s recommended to set those up with disks of at least twice the dataset size they’ll be hosting to facilitate Cassandra grooming operations
  • 2 appengine servers that will be serving the incoming application requests; it’s always a good idea to have appengine server replicas that will keep your app from experiencing downtime if one server goes down
  • Each machine would need 2-4 cores and 8-15 gigs of memory depending on how the app utilizes computing resources. You can find what that translates to on popular public clouds below:
    • recommended Amazon EC2 instance types: m4.large, m4.xlarge, c4.xlarge
    • recommended Google Compute Engine machine types: n1-standard-2, n1-standard-4, n1-highmem-2, n1-highcpu-8

 

Example #2: Popular Gaming Application

Let’s look at another example, a gaming application backend with:

  • 1500 req/sec
  • 25 million downloads
  • 10-20 TB of data

In this case, you’ll need:

  • 1 head/load balancing server
  • 20 database nodes (replication factor of 3) that will hold 1-2 TB of data each; once again, it’s recommended to set those up with disks of at least twice the dataset size they’ll be hosting to facilitate Cassandra grooming operations
  • 10 appengine nodes that will be serving the incoming application requests
  • Each machine would need 4-8 cores and 8-15 gigs of memory depending on how the app utilizes computing resources. That translates to:
    • recommended Amazon EC2 instance types: m4.xlarge, c4.xlarge, c4.2xlarge
    • recommended Google Compute Engine machine types: n1-standard-4, n1-highmem-2, n1-highcpu-8, n1-highcpu-16

These are just two application examples we see users running on AppScale. Already running your app in production on AppScale? Tell us about it in the comments!


You can find out more about recommended AppScale deployments and the AppScale architecture on our website and on GitHub.

Find out why our customers are so happy. Click below to read our Case Studies.

Case Studies

Topics: Best Practices

Subscribe to Email Updates