Enabling Bare-Metal Performance for Today’s Clouds

Mobile connectivity, social-media, digital streaming, the Internet-of-Things, big data, and many other taxing use-cases are spawning new classes of computing transaction and analytic requirements. As a result, IT organizations are looking for every possible way to stay abreast, if not ahead, of their workload performance goals within ever-tightening budgets.

Some feel the choices are between dedicated, bare-metal infrastructure over virtualized, shared resources. Others argue that virtualized infrastructures best address today’s challenging IT realities. Fortunately, if you are running your applications and other workloads in a public cloud, like Amazon Web Services or Microsoft Azure, you can have the best of both worlds. You can provide bare-metal performance from your virtualized environment, and you can do so without provisioning expensive, individually dedicated cloud resources.

Many IT organizations are delivering the performance of bare-metal within virtualized clouds by leveraging in-memory computing and caching technologies offered by their cloud providers. Admittedly, some of these options are not for the faint-of-heart. They require developers who understand how to apply caching and in-memory technologies and techniques to their applications and workloads. But others are much easier, and can be deployed by SysAdmins and DevOps.

Using Amazon Web Services (AWS) as an example, here’s how one might optimize workload performance using in-memory and caching services provided by AWS.

Those familiar with AWS will likely know of, and may even be utilizing, AWS ElastiCache. ElastiCache is a service that manages the work involved in setting up an in-memory cache for workloads running in AWS. It uses Memcached and Redis (your choice), and is based on deploying one or more cache clusters across your application workloads. ElastiCache integrates with other Amazon web services like Elastic Compute Cloud (EC2) and Relational Database Service (RDS). It also can be used with distributed applications and other relational and NoSQL databases as well.

On the surface, Memcached and Redis seem similar since they both use in-memory key-stores, but they are actually quite different in practice. For instance, Memcached is a pure, object caching solution with no data persistence, whereas Redis has data persistence built in. ElastiCache, therefore, utilizes Redis like a relational database with its clusters managed as stateful entities that include failover. Memcached, on the other hand, is managed by ElastiCache as a node-pool that can grow and shrink similar to an EC2 Auto Scaling group. Because Memcached is multi-threaded, it makes good use of larger EC2 instances. Redis is single-threaded, but it supports more advanced data structures such as sorted sets, hashes, and lists.

Amazon has extensive documentation regarding how developers leverage ElastiCache; its best-practice use-cases, when to apply Memcached versus Redis, and how to code such choices into workloads; all of which you can find here. In a nutshell, here are a few things to consider when deciding between them:

  • Use Memcached if the primary goal of your workload is object caching.
  • Use Memcached if a simple caching model is all that is needed.
  • Use Memcached if the workload requires large cache nodes, requiring multithreaded performance using multiple cores.
  • Use Memcached if the ability to scale horizontally is required for growth.
  • Use Redis if the workload requires advanced data types.
  • Use Redis if the workload requires pub/sub capabilities.
  • Use Redis if the workload requires its key value store to persist beyond RAM cache.
  • Use Redis if high-availability and failover is required for the workload.

An excellent article about the differences between Memcached and Redis can be found at InfoWorld.

A nice feature of ElastiCache is that it automatically detects and replaces failed cache-nodes. This reduces system administration oversight and provides a resilient in-memory system. Other benefits include:

  1. Applications can be sharded to scale in-memory-cache with up to 20 nodes using Memcached.
  2. Applications using Redis can be clustered with up to 15 shards forming a single in-memory key-value store of up to 3.55 TiB, plus up to five read-replicas per shard. Additionally, multiple AWS Availability Zones can be provisioned to scale beyond single node capacity constraints, and to gain availability.

As with many of Amazon Web Services’ resources, ElastiCache is priced by the hour. It is billed based on the amount of memory/compute capacity used in addition to the other AWS infrastructure provisioned with ElastiCache. The specifics of ElastiCache pricing and cost calculator can be found here.

Getting started with AWS ElastiCache is fairly straight forward. In fact, Amazon’s 400+ page ElastiCache User Guide provides all the details developers, SysAdmins, and DevOps could ever need. So, if the simple, in-memory solutions referenced earlier don’t fit your AWS workloads, some time and effort with ElastiCache may provide the bare-metal performance benefits you are looking for.