Choosing Compute Options

One of the most common questions AWS Solutions Architects get asked by startups is, “What compute environment should I use for my application? Is it better for me to run it on virtual machines, containerize, or go fully serverless?” AWS provides a wide breadth of services and features for customers to run virtually any kind of workload. In this article, we cover these options and equip you with the knowledge to make the right choice.

At the heart of this decision is recognizing that when you’re first building your application, the best choice of architecture is typically whatever allows you to move fast and focus on your core business value. The goal at this point is to get your product to market as fast as possible so you can test market fit, acquire customers, and generate revenue. Focus on using the programming languages, frameworks, tools, and services that enable your specific team to build your product as quickly as possible, and not on whether those are the same choices somebody else would make. You certainly want to consider how your solution would scale, but it is unlikely to be the most important factor for your team at this early a stage.

With that perspective in mind, let us walk through a few common situations for you to see which one your team aligns with most closely. The scenarios we cover include a team starting from scratch, a team that is either already containerized or has specific compute needs, and a team that has an existing monolithic web application or likes having full control over a server. For each situation, we make a recommendation on which compute environment you’ll have the most success with.

Greenfield Project

The first team is one starting from scratch and comfortable breaking its code into small pieces of business logic. It would rather focus the bulk of its effort on its business and data processing logic than on figuring out infrastructure concerns like load balancing, elastic scaling, networking, or writing plumbing code such as for user authentication, logging, catching exceptions, and so on.

If your startup falls into this category, go with a serverless architecture, expressing logic in AWS Lambda functions and relying on services such as Amazon S3, Amazon CloudFront, Amazon API Gateway, AWS Step Functions, Amazon Cognito, and AWS AppSync to provide infrastructure that is fully managed by AWS.

In this scenario, there are no servers to manage. They scale automatically on a per request basis and virtually eliminate the need to write plumbing-style code. It’s easy to get started by taking a look at current business and data processing logic and redefining it as Lambda functions. You can then use the AWS Serverless Application Model, or SAM, to define when and how these functions should be invoked - for example, via an API call, on a schedule, in response to an event. It may take some time to adjust to this architecture initially, but long term, it allows your team to quickly build highly scalable applications with significantly less overhead. 

Docker Containers

The second team is a startup already working with Docker containers. It might also have a workload which does not fit within the constraints of a Lambda function, such as a single job which is highly compute intensive or requiring longer than 15 minutes to execute. It also may need to span across the cloud and another environment, such as a genomics lab or a factory floor. If your team aligns with this one, AWS provides either Amazon Elastic Container Service (Amazon ECS) or the Amazon Elastic Kubernetes Service (Amazon EKS). If you are building your workload entirely within AWS and prefer the familiarity of EC2-like constructs such as security groups and IAM Roles, then ECS will work well for you. If you already have existing skills and preference towards Kubernetes, then EKS will be the right choice.

In either case, run your underlying fleet on AWS Fargate, which allows AWS to fully manage the provisioning and scaling of the virtual machines upon which your containers will run. This means the only thing you need to worry about is defining the CPU and RAM needs of your various tasks and services, not if you have enough underlying compute to run them all.

Monolith Application

The final team is one with an existing monolithic web application looking for the simplest way to deploy on AWS. It might be using a web framework such as Ruby on Rails, Python Django, or PHP Laravel. The team is also familiar with common web server technologies like Apache Tomcat, IIS, or nginx, and more comfortable having full access to the underlying infrastructure for operations like diagnostics and tuning. If your team falls into this category, you will get a lot of benefit out of AWS Elastic Beanstalk, which accelerates standing up a web application on EC2 by helping with deployment and provisioning resources such as load balancing, auto scaling, and health monitoring while still allowing it to retain control over the infrastructure.

This doesn’t mean that you have to sacrifice one option for another. In fact, as your team grows, we find a high percentage use both containers and functions to build successful workloads. We recommend you evaluate this decision for each workload.

Conclusion

Ultimately, startups on AWS are successful leveraging any one of these three approaches. The key is to align your approach to the specific strengths of your team. You can continue using the technologies with which you’re familiar and accelerate their deployment and management using the corresponding AWS services. No matter which approach you take, you can rest easy knowing that whether your architecture remains the same or continues to evolve, the underlying AWS services will always meet the scaling needs of your business.

Have fun, and build on!