AWS Compute - Part 5: How to choose compute service

TL;DR

Key Compute Options

• Amazon EC2 offers granular control, various instance types, and flexibility for managing infrastructure
• Containers provide lightweight, portable, and consistent application deployment across environments
• Serverless computing abstracts infrastructure management, allowing focus on code and rapid development

When to Choose Each Option

• Use EC2 for compute-intensive applications, long-running stateful apps, or when full OS control is needed
• Choose containers for compute-intensive workloads, large monolithic applications, or when quick scaling is required
• Opt for serverless (Lambda) for short-lived applications (under 15 minutes), event-driven architectures, or when automatic scaling is desired

Considerations

• EC2 is versatile and suitable for a wide range of applications, offering various pricing models
• Containers are ideal for microservices architecture but may not be optimal for apps with complex persistent storage or networking requirements
• Serverless is best for small, simple applications that integrate multiple AWS services and don't require long execution times

I. Advantages of each compute type

1. Amazon EC2

Amazon EC2 offers granular control for managing your infrastructure. It gives you the choice of over 500 instance types, with the latest processors, storage, OSs, and networking. An EC2 instance is a virtualized server running in the cloud. Whatever options you customize for a physical server can also be customized for EC2 instances. Amazon EC2 also offers instances that are optimized for certain performance needs or workload functions. Therefore, your applications can start on an instance built to accommodate that workload type.

One advantage of using virtual servers is that you can build and deploy an instance in minutes. You can spin up an instance, test your application, and then delete the instance when you are done. Instances also offer you the flexibility to increase or decrease resources as your workload demands change, without affecting your application.

When you choose to use EC2 instances, here is a list of benefits that you gain:

• With Amazon EC2, you can quickly build and start a new server: You don't need to rack the server, run cable, and update hardware drivers as you would do with a traditional server.
• You can scale capacity as needed, both up and down. This means that if you need more memory, processing, or storage, you can add it.
• Instances offer at least 99.99% (four nines) of availability. For more information on AWS and availability, see Amazon Compute Service Level Agreement.
• Amazon EC2 offers instances that are optimized for specific types of workloads, including memory optimized, compute optimized, storage optimized, accelerated computing, and general purpose.
• Various instance types are available with different pricing options, so you can choose the best option to fit your business requirements. These options include On-Demand Instances, Reserved Instances, and Spot Instances.
• Amazon EC2 gives you complete control over the instance, down to the root level. You can manage the instance as you would manage a physical server.
• You can use instances for long-running applications, especially those with state information and long-running computation cycles.

2. Containers

Containers provide a standard way to package your application's code, configurations, and dependencies into a single object. Containers share an OS installed on the server and run as resource-isolated processes, for quick, reliable, and consistent deployments, regardless of environment.

Containers are lightweight, efficient, fast, and highly portable. Because the container holds all the files it needs to run, you can ensure a consistent performance from your application, regardless of the underlying components. This encapsulated application approach also caters for rapid deployment, patching, and scaling when needed. Because you don't need to worry about OS patches or security enhancements that might affect your applications, containers lend themselves nicely toward improved and accelerated development cycles.

Here are some of the key features of the AWS container services:

• The application is packaged so that you control the application and all associated resources, such as policies, security, and deployment.
• Containers are portable and can be moved to different OS or hardware platforms, and through different environments such as development, testing/staging, pre-production, and production.
• There are no time-out limits when running. This is useful for applications that run longer than 15 minutes or that need to initiate instantly when called.
• Containers run without the startup latency of Lambda or Amazon EC2.
• Containers have no size limit. They can be as large or as small as you need them to be.
• Containers are useful when taking a large traditional application and breaking it down into small parts, or microservices, to make the application more scaleable and resilient.

3. Serverless

One of the major benefits of cloud computing is its ability to abstract (hide) the infrastructure layer. Therefore, you don't need to manually manage the underlying physical hardware. In a serverless environment, the abstraction is one layer higher. Not only is the physical infrastructure abstracted, but the instances and the operating systems on which AWS Lambda is running, are also abstracted. With this higher level abstraction in place, you can focus on the code for your applications without spending time building, maintaining, and patching the underlying infrastructure, hosts, and operating systems.

With serverless applications, there are never instances, OSs, or servers to manage. AWS handles everything required to run and scale your application.

By building serverless applications, your developers can focus on the code that makes your business unique.

If you are considering putting your workload into a serverless environment but aren't sure, the following list has some considerations when deciding on a serverless architecture.

To learn more about reasons to choose a serverless solution for your application, expand each of the following six categories.

• Fast development
  You might need to develop applications quickly and might not have the time to build and maintain the underlying infrastructure.

  Using a serverless solution, you and your developers can focus on building and refining your applications without spending time managing and maintaining servers.

• Pay for value

  You only pay for the time that your application runs. This model helps keep costs down so that you aren't paying for time when your application is idle.

  The AWS Lambda free tier includes one million free requests per month and 400,000 GB-seconds of compute time per month

• Short-lived applications
  Lambda is a suitable choice for any short-lived application that can finish running in under 15 minutes.

  If an application needs to run longer than 15 minutes, it's no longer cost effective to use Lambda. Instead, consider other solutions.

• Event-driven applications
  You might need event-initiated, or event-driven, stateless applications that need quick response times.

  An event-driven architecture uses events to initiate actions and communication between decoupled services. An event is a change in state, a user request, or an update, such as an item being placed in a shopping cart in an ecommerce website. When an event occurs, the information is published for other services to consume it.

• Automatic scaling
  If you do not want, or need, to managing resource scaling, a serverless architecture is something to consider.

  When you use Lambda, the service is responsible for all the resources required to run your application. If your application suddenly needs more resources, Lamdba adjusts your resource consumption up or down to maintain consistent application performance during peak utilization and off-hour timeframes.

• Redundancy and resilience
  The AWS Global Infrastructure is built around AWS Regions and Availability Zones. Regions provide multiple physically separated and isolated Availability Zones, which are connected with low-latency, high-throughput, and highly redundant networking.

  Lambda runs your function in multiple Availability Zones to ensure that it is available to process events in case of a service interruption in a single zone.

  Lambda also provides additional resilience features such as versioning, reserved resources, retries, and the previously mentioned automatic scaling capability.

II. Choosing a Compute Option for your Workload

1. Amazon EC2 considerations

With Amazon EC2, you have complete control of your computing resources. Amazon EC2 reduces the time required to obtain and start new server instances to minutes. Therefore, you can quickly scale capacity up or down as your computing requirements change.

Because EC2 instances are virtualized servers in the cloud, they lend themselves to support a large variety of applications. Anything you can run on a physical server can be run on Amazon EC2. Whether you need a small instance type or a robust instance type with multiple processors, and extra memory, Amazon EC2 is a versatile platform for all of your application needs.

Here are some application characteristics that lend themselves to run best when using Amazon EC2.

• When you have compute-intensive or memory-intensive applications, consider the following:
  • You can select a specific instance type based on the requirements of the application or software that you plan to run on your instance.
    • Amazon EC2 provides each instance with a consistent and predictable amount of CPU capacity, regardless of its underlying hardware.
  • Amazon EC2 gives you the choice of OSs and software packages. You can select a configuration of memory, CPU, instance storage, and a boot partition size that is optimal for your choice of OS and application.
  • You have access to the underlying files of the instance to customize or update as needed.
• Amazon EC2 works with other AWS services to provide a complete solution for computing, query processing, and storage across a wide range of applications.
  • From a performance perspective, you can use instances for long-running, stateful applications.
  • You can determine the type and size or your storage, whether to use block or file storage.
  • Amazon EC2 can support workloads where complex networking, security, and storage is required, in addition to applications and workloads with heavy computational requirements.
• EC2 instances are optimized for use cases such as compute optimized, storage optimized, general purpose, or accelerated computing.
• Amazon EC2 is versatile and reliable. You can run a simple website or you can run a vast, complex, custom-built application, and when necessary, replacement instances can be rapidly and predictably deployed.
• Pricing is pay for what you use. There are also different types of pricing models so you can select the type of instance and the pricing model that fits your budget.

2. Considerations for containers

Some application characteristics lend themselves to run optimally in a containerized environment. Here are some factors to consider for your application to see if containers are appropriate.

When to consider containers

• For compute-intensive workloads
  • Applications that are compute intensive run better in a container environment. If you have a small application that runs under in 15 minutes but is compute intensive, consider using a container. Lambda is not the best fit for a heavily compute-intensive piece of code.
• For large monolithic applications
  • These are appropriate candidates to move to containers. Large monoliths that have many parts are very suitable applications to consider moving to containers.
  • You can break apart applications and run them as independent components, called microservices, using containers to isolate processes.
    • By using microservices, you can break large applications into smaller, self-contained pieces.
    • Segmenting a larger application means that updates can be applied on only specific parts. Because each part of the larger application resides in its own container, an update that might have affected files used by a different piece of the application is isolated to its own container.
    • With containers, you can do frequent updates by pushing out new containers, without the concern that one set of updates might break another part of the application. If you detect any issues, you have the flexibility to undo the change quickly.
• When you need to scale quickly
  • Containers can be built and taken down quickly, which means fast application deployment and scaling.
• When you need to move your large application to the cloud without altering the code
  • With containers, you can package entire applications and move them to the cloud without the need to make any code changes.
  • Your application can be as large as you need it to be and can run as long as you require it to run.

When not to use containers

• When applications need persistent data storage
  • Containers can absolutely support persistent storage; however, it tends to be easier to containerize applications that don't require persistent storage. Persistent storage requirements increase the security and storage complexity and also make the containers less portable. If the container is moved, the storage needs to be reconfigured and secured.Applications that have no state information and don't require complex persistent storage would be better candidates for using a container solution than an application with complex storage needs.
• When applications have complex networking, routing, or security requirements
  • Containers are portable and can be moved through different environments (testing, staging, production). If the application requires a complex configuration for networking, routing, storage, and so on, the containers are much more challenging to move.

3. Considerations for serverless applications

Consider the characteristics of applications that lend themselves to run optimally in a serverless environment:

• Are you building, testing, and deploying applications frequently and want to focus only on your code and not on infrastructure?
• Are your applications less compute intensive?
• Are the applications that you are running or building small, simple, or modular?
  • Simple applications, such as chatbots or to-do lists that people can use to modify a list of things that they need to do, are good choices to move to serverless.
• Will you be using multiple AWS services where one service might need to call another service?
  • For example, if someone uploads a file to Amazon Simple Storage Service (Amazon S3), will you then need to invoke other workflows to log the update or convert the file to HTML? Serverless is a very appropriate fit when you need one action to invoke other workflows within AWS.
• Do your applications finish quickly?
  • Serverless is most suitable for applications that don't run longer than 15 minutes.
  • Large, long-running, workloads, are expensive to run on serverless and not an optimal fit for this compute type.

4. Putting it all together

John is confident that he can now distinguish between the AWS Compute types and explain which types use Amazon EC2 instances and which types are run serverlessly. Sofia wants to make sure he grasps the nuances of the services. She asks him how he would summarize the three options, he shows her his notes which read:

• Amazon EC2 are virtual server instances in the cloud.
• Amazon ECS, Amazon EKS: Container management services that can run containers on either customer managed Amazon EC2 instances OR as an AWS managed serverless offering running containers on AWS Fargate.
• AWS Lambda is Serverless compute for running stateless code in response to triggers.

John took a moment to draw an image depicting the abstraction of the compute services from the instance based compute to the serverless solutions.