Recycling is a good strategy for the physical world and also for your AWS resources. When you have an automated process to deploy parts of your application, you can often use that same automation to rebuild broken pieces rather than troubleshooting the failure. Naturally, there are parts of your applications that cannot simply be destroyed and replaced; there is always valuable persistent data somewhere. The design skill separates that data from the rest of your application components and handles the persistent and disposable parts differently. Later I will look at using managed services for that persistent data; now, we will look at the disposable portion.
The classic disposable resource on AWS is an EC2 instance that is part of an AutoScaling Group (ASG). The ASG has instructions for creating a new EC2 and rules about creating new and destroying existing instances. These instances were intended from the start to be disposable and replaceable. At the small end of the size scale is Lambda, event-driven programming where a Lambda function is the compute unit and cannot run for more than 15 minutes. Every Lambda invocation is disposable. The middle ground is a container, an immutable application image that behaves the same wherever and whenever it is launched. All three provide disposable compute resources and are building blocks for your application. There are many other options of disposable building blocks that on-premises you might expect to be more persistent.
Everything on AWS is an API; we can deploy and destroy all types of resources as disposable. The difference between persistent and disposable elements is our choice of how we use the service. For example, you might use an S3 bucket as a destination for permanent records from your application, but you might also use an S3 bucket to hold temporary data used by your application that doesn’t need to be retained. That temporary S3 bucket might only be required for days or weeks, created when needed and removed when the task is complete. You might use a DynamoDB table in the same ways, as a permanent record or as a transient store. AWS makes it very simple to create temporary resources and dispose of those resources when they are no longer required. Remember that you pay for the resources you are using on AWS, so linking value delivered to cost paid is essential, and disposing of valueless resources is good cost control.
There is always a risk of accumulating leftovers with long-lived resources, such as temporary files that fill up EC2 instance drives or older application binaries with security vulnerabilities. When we use disposable resources, our upgrade process is to deploy a brand-new resource and delete the older resource. This way, every resource is built new every time, and there is no accumulated risk from upgrades in place. Disposable resources are also easier to replicate in development and testing environments to improve the quality of changes deployed into production.
Abstraction is an essential part of using disposable resources; you usually need a persistent access point or way of discovering the current temporary location, such as this week’s temporary DynamoDB table. Services such as the Elastic Load Balancer, Simple Queue Service, and Route 53 DNS service are suited to providing consistent services over transient resources. The Systems Manager Parameter Store is another place to store the location of a temporary resource, or your application may. You might also use an app mesh for discovery and reliability with your disposable services.
There is a common theme in a lot of these design principles, make it simple to create and recreate as much of your application and infrastructure as possible. Understand what parts must be persisted and protected, and what parts do not need the same care and feeding.
© 2021, Alastair. All rights reserved.
RSS - Posts