Selecting an AWS Workload that fits AppScale

Characteristics that make your AWS workloads a great fit for AppScale

AppScale exposes API endpoints just like all AWS regions do, so tools or workloads which use the core AWS services can be redirected to any AppScale deployment. Like AWS regions (Example: China or GovCloud), AppScale deployments only expose the APIs that have a corresponding service. Each AppScale deployment defaults to using the AWS CLI tools as the main client tool: using named profiles, multiple AppScale deployments and AWS regions can be used with the same installed AWS CLI tools. An easy-to-use GUI console is also provided: similarly, it can be used for AppScale deployments and/or AWS regions.

Workload Characteristics

A workload consists of a subset of cloud resources working in cooperation. Simple workloads could be fully defined for example in a cloud formation template, while larger workloads may span multiple accounts, templates, and other resources as well. A small business might have only a few workloads while a large enterprise might have thousands. Although any workload can run on AppScale, there are certain characteristics that make it a better fit, or an easier first step to implement a hybrid cloud strategy. Some characteristics or requirements align the workload easily with the platform: for example requirements of off-the-grid or intermittently connected operations, makes AppScale the best platform, while extremely variable workloads may align better with hyperscalers. AppScale deployments' performance and capabilities are dependent on the underlying hardware infrastructure: this customization is the secret for our excellent performance per dollar ratio. Hyperscalers own or lease DCs, corresponding network links, and they provide a uniform performance characteristic allowing workload mobility across their infrastructure. Hence workloads relying on specific infrastructure characteristics may be harder to move around.

Characteristic Description
High-Cost Sensitivity For organizations sensitive to the cost of public clouds, AppScale can provide savings of 30-60% and preserve all the investment in the AWS infrastructure (training, and workloads).
The requirement for Data Control Workloads or policies may require or desire specific data treatment or storage locations (intranet policy, or poor connectivity -- disconnected operations --, or regulatory compliance). AppScale accommodates all these needs.
Low Workload Variability AppScale deployments are typically created with a certain overhead %, to accommodate for workload load variance. The typical overhead of 30%-50% is factored in the cost estimations. Workloads with much higher variance will require bigger clusters to accommodate them, decreasing the saving margins.
Low CDN Requirements AppScale’s reliance on third parties infrastructure for clusters and networks means that specific CDN solutions are used in conjunction with each deployment.
A requirement for Vendor Independence For organizations concerned about AWS dependency, AppScale provides a route that doesn’t require the rewrite of all workloads and retraining of the workforce.
APIs & Services used Not all AWS APIs and Services are implemented in AppScale: some are experimental, some have alternatives, and some do not quite make sense on AppScale deployments. Hence AppScale focuses on the core APIs, the ones that are virtually used by any workloads, and the ones needed to implement higher-level APIs (EC2, IAM, Auto Scaling, EBS, S3, etc…).
Independent AZs AppScale allows for multi AZs configuration, but the network requirements amongst AZs, the power as well as the failure independence of the AZs needs to be built-in.

Matching Workload Patterns

Workloads are designed to meet a mix of technical, regulatory, and business requirements. Although they have their own characteristics and specific requirements that need to be evaluated each time, we have observed generic patterns in the workloads that align particularly well with AppScale.

Workload repatriation

Workloads that have been running on AWS for a long time but have become too expensive, are not any longer compliant with newly imposed data regulations or policies or go together with increased uneasiness independence on Amazon.

Air gap workloads

Workloads that need to run when a disconnected operation (air gap) is either a requirement or a situational factor (e.g. poorly connected areas).

Test & Development workloads

QA and development around specific workloads can comprise up to 40% of the related AWS cost. QA and development teams are also the aptest to adapt, react and modify the workloads making dev/test workloads the best target to deploy on AppScale

Workload Analysis & Cluster Sizing

Determine the right node size and cluster topology for your AWS workload on AppScale

Cluster Sizing