Scalability

A quick look at the AppScale architecture quickly reveals that the solution's developers understand and have internalized the principle of scalability. Instances can be added and removed virtually arbitrarily at the individual levels of the design, but especially on the compute node side. However, this feature in itself does not differentiate AppScale from other solutions – OpenStack also does seamless scalability.

The key asset is Amazon compatibility, which I'll get to in detail later. The developers consider their deployment mechanism to be at least as important, because the solution comes with its own installation tool. The initial environment setup in particular is a headache, and OpenStack has only managed to establish standardized tools and processes to a limited extent thus far. The potential to establish unique selling points is great compared with competitors, and AppScale is trying hard to leverage it.

The developers deliver their environment with their own tool that is based on Ansible and other automation tools, and it completes the entire deployment process in a relatively short time. The administrator's only task is to associate individual physical nodes with their roles in the AppScale context. This step ultimately tells the installation routine which services to run on which hosts. The deployment process itself runs smoothly afterward. If you later want to extend the setup, you simply use the same tools, which are basically designed to achieve idempotency. If in doubt, simply set up more compute systems to grow the environment.

AWS Compatibility

AppScale's main promise is compatibility with AWS. This goal is not surprising because the predecessor, Eucalyptus, already claimed that it was compatible with several AWS APIs. According to AppScale, compatibility opens up several possibilities for customers, one of which is the complete migration from the public to a private cloud. The promise is that existing workflow implementations can be reused, as can any existing tooling. On the one hand, migration facilitates the deployment of new resources in the environment, and for AppScale this also means facilitating processes such as monitoring, alerting, and trending.

What is almost more important from a vendor perspective is the hybrid workload option. If the AWS cloud and your own private cloud use the same APIs, all deployment and workflow tools can be applied to both. Users can then dynamically decide on an ad hoc basis whether to roll out new workloads from their existing deployment chain to AWS, to the private AppScale cloud, or as hybrid workloads with parts on both targets. For this to work well and reliably, you need a high degree of AWS compatibility, which depends on the individual use case.

Because AWS is not an open standard, the APIs are all proprietary. All functionality in AppScale is based on classic reverse engineering. The developers themselves admit that they do not support all calls from all APIs to AWS services. However, they also claim that this is not necessary for the majority of users. In most cases, people only need the most important API commands anyway, they say. AppScale says that it supports such commands fully and well. One is reminded of the Pareto principle: 20 percent of all functionality is sufficient to satisfy 80 percent of all users.

In practice, though, how compatible is AppScale really? The previously cited list of supported services sheds light on the issue. Of course, EC2 for virtual instances, EBS for dynamic block storage devices, and S3 as object storage are must-haves in the portfolio. AppScale also offers virtual networks, the counterpart to virtual private clouds. Users can also use the CloudFormation cloud orchestrator in combination with compatible templates. Things become a little more complicated with advanced AWS services. AppScale supports CloudWatch (i.e., AWS monitoring), as well as the Auto Scaling feature that is particularly popular with AWS customers (Figure  2). This feature accesses data from CloudWatch and ramps VMs up or shuts them down depending on the workload.

Figure 2: Old acquaintances: The AppScale dashboard is unmistakably similar to Eucalyptus but also offers services like CloudWatch and Auto Scaling.© AppScale

The bundle also includes ELB and provides the Route 53 global DNS service, which is also very popular with AWS customers but currently is still a Technical Preview. To ensure that customers have a uniform regime in terms of authorization and authentication, the developers have also replicated the AWS IAM service. The Simple Queue Service (SQS) is also available as a Technical Preview. Database as a service replicates AppScale as a relational database in the form of the Amazon Relational Database Service (RDS). Although the service is no longer a Technical Preview, it offers far less choice than the original in terms of functionality.

AppScale is still working on a few services at the moment. They include ElastiCache (i.e., managed Redis and Memcached) and Elastic MapReduce (EMR), which is a kind of Hadoop as a Service. AppScale also plans to deliver a message bus and workflow manager soon as counterparts to Amazon Simple Notification Service (SNS) and Simple Workflow Service (SWF).

Missing Services

AppScale is also looking to replicate some other services, but not in a way that will be compatible with AWS. Kubernetes, for example, which is almost indispensable in modern IT operations, will be implemented in the form of Rancher with K3s and CloudFormation templates. This feature differs significantly compared with Amazon Elastic Kubernetes Service (EKS) and is indicative of a larger problem behind the scenes.

These AWS as-a-service options add value for many users of the platform. Databases such as Aurora or RedShift, for example, make it far easier for users to use AWS. Hyperscalers have always tended to rely more on services like this because they reinforce the lock-in effect like no other group of applications. If you only run IaaS in AWS, you have a genuine opportunity – given some migration work and large amounts of time – to migrate your workloads to a different provider. However, fully orienting your own application on services such as RedShift or DynamoDB would tie you to a vendor, and you would be facing a complete rebuild in leaving AWS, which would be a mammoth task for which many companies quite simply lack the monetary resources.

The crux of the matter is that AWS has a virtually unlimited workforce, so they have many developers capable of implementing arbitrary services. By its very nature, though, AppScale is different. Implementing a service compatible with DynamoDB would likely take a small development team months, if not years, of work, which is undoubtedly better spent doing other things. One thing is patently obvious: Although AWS now offers a huge number of specialist services, only a relatively small percentage of users take advantage of them. The Pareto principle once again rears its head to point to the economic facts of life at AppScale.