Nothing lasts forever. Whether they’ve been supplanted by newer offerings or simply outlived their usefulness, these cloud services on AWS, Azure and GCP are ready to be retired.

Many of us have a stash of obsolete equipment that we keep around just in case. IT vendors tend to be more ruthless about jettisoning old products — sales figures and order backlogs don’t lie. However, even the most rigorously run operation can succumb to portfolio bloat by letting products live on past their utility.

Cloud services are particularly susceptible to this, given the marginal cost to keep old services alive and the desire to placate long-time customers resistant to migrating to an updated replacement. And since companies like AWS, Microsoft, and Google must prioritize their limited resources, some services are left with lagging support and stale technology.

Of course, the phrase “one person’s junk is another person’s treasure” is certainly true in the tech industry, where the rate of change often seems gratuitously excessive. However, it’s in an IT shop’s best interest to upgrade to a superior offering when the time is right. So, at the risk of offending those still loyal to aging offerings, here are some cloud services that might be ready for retirement.

Potential AWS services to retire

AWS isn’t just the oldest and largest cloud vendor, it also has the broadest portfolio with roughly 175 services and counting. While many Amazon cloud offerings, like EC2 and S3, have received regular updates for more than a decade, others have been supplanted by newer products with better features and technology. When AWS decides to house clean, here’s where it should start to cut.

Classic Load Balancer. AWS offers three variants from its Elastic Load Balancing service: Application, Network, and Classic. The Application Load Balancer is a Layer 7 service designed for applications with web HTTP/HTTPS interfaces, while Network and Classic are traditional Layer 3 and Layer 4 network routing services. Since Network Load Balancer includes every useful feature offered by the Classic Load Balancer, there is no reason to use the old version unless you have an existing deployment that you don’t want to migrate.

CloudSearch. In 2012, Amazon rolled out this service as a way to add search features to applications and websites. Elasticsearch, an open-source alternative, emerged at about the same time. Elasticsearch became wildly popular with developers for systems management when paired with Logstash for logging and data collection and Kibana for data analysis and visualization — the ELK stack.

AWS added an Elasticsearch managed service in 2015 called Amazon Elasticsearch Service (Amazon ES). CloudSearch is arguably more convenient, with built-in cluster scaling and automatic software updates. But Amazon ES is more customizable and compatible with Elasticsearch deployments on other environments. Amazon ES is a better choice than CloudSearch for most users.

Data Pipeline. Data Pipeline is an extract, transform, and load (ETL) service also launched in 2012. IT teams use this service to transform data pulled from on-premises or AWS sources, before transferring it to another AWS service like DynamoDB or Elastic MapReduce (EMR).

AWS added another ETL service, AWS Glue, in 2017 that provides more features, uses standard Scala or Python syntax, and works with AWS Athena to analyze unstructured data in S3. AWS Glue is a serverless product while Data Pipeline jobs run on EC2 or EMR clusters. Given its features and flexibility, users should opt for Glue rather than Data Pipeline for their AWS ETL needs.

ElastiCache for Memcached. AWS offers two variants of in-memory data caching service, both based on open source software. Much like its search services, the variant released first, based on Memcached, was supplanted by a more feature-filled and popular alternative based on Redis.

In comparing the two, AWS notes that the feature unique to Memcached is its multithreaded design and more efficient use of multicore CPUs. In contrast, Redis offers seven features that are not available on Memcached, such as snapshots, replication, and atomic transaction. Given its maturity and feature set, it’s no surprise that Redis is the most popular in-memory cache and the engine underlying the caching services on both Azure and Google Cloud Platform (GCP).

SimpleDB. AWS also has two variants of a NoSQL table key-value store — SimpleDB, released in 2007, and DynamoDB, released in 2012. Once again, the successor service is the superior product. While SimpleDB is easier to use for small applications and less sophisticated developers, DynamoDB is faster and more scalable. SimpleDB is no longer listed on the AWS database product pages, so it appears to be a service on autopilot.  

ECS. Elastic Container Service (ECS) isn’t necessarily ready for retirement, but it’s getting close. ECS has an esteemed place in AWS history as it was the first cluster management service offered by a major cloud provider. Although not obsolete, ECS’ core capability has been superseded in popularity by Kubernetes.

Kubernetes was open-sourced by Google only a few months before ECS was announced, and it has since become the de facto standard for cluster management and container orchestration. This makes it difficult to justify any alternative, particularly when improved workload portability between clouds is a primary driver for organizations to adopt containers.

AWS customers still launch millions of containers every hour on ECS. However, there is less need for the service now that AWS has its own managed Kubernetes service, Amazon Elastic Kubernetes Service (EKS). EKS works with user-provisioned nodes on EC2 and container instances from Fargate.

ECS does provide tighter integration with other Amazon cloud services and is simpler to use. However, expect AWS to close the usability gap via future enhancements to EKS. Given that EKS workloads are compatible with other container services, there seems little reason for users to choose ECS.

Azure and GCP services fit for retirement

Microsoft Azure and GCP do not have the history or accumulated inventory of offerings that AWS has, so there are less apparent services ready for retirement. However, each of these platforms has a few redundancies to consider.

Azure management interfaces are prime examples. There is confusion around whether to manage Azure resources with Azure Resource Manager (ARM) or the classic deployment portal. ARM offers more features and support, so there is no reason other than procrastination for anyone to use the classic portal. Microsoft says 90% of its customers use ARM and the classic interface will be retired on March 1, 2023. Azure users should move on from the classic deployment interface as soon as possible.

Database services are another area where Azure should do some pruning. The Azure database portfolio is confusing and full of redundancies, with four SQL products and three NoSQL services. Anyone building new applications on Azure would be advised to stick with the Microsoft native products, namely Azure SQL Database for SQL Server, Cosmos NoSQL database, and Table Storage, a key-value store.

As for GCP, most of its services are too recent to have outlived their usefulness. That said, GCP’s product portfolio could use some simplification through consolidation. For example, GCP offers separate versions of storage, database, monitoring, and serverless products for Firebase that duplicate functionality elsewhere. Another example is GCP’s network services, where there are several opportunities to combine services, such as:

• Google Virtual Private Cloud and Cloud Network Address Translation;
• Network Intelligence Center and Network Telemetry; and
• Cloud Load Balancing and Cloud Armor.

Undoubtedly, like Azure and GCP mature and introduce new services that supersede existing ones, the list of retirement candidates will grow. But for now, AWS is most in need of some spring cleaning.