Lambda, EC2 or Fargate?

A Simple Approach to Choosing AWS Compute for Enterprise Workloads

Image by Katerina Limpitsouni from
  1. Help everyone to understand and buy in to technology decisions
  2. Keep meetings focused, efficient and effective

Factors that Matter Most

  1. Direct business value. Don’t invest in building or maintaining anything that has already become a commodity. Building anything that takes time but does not directly yield unique business value is a burden, a cost and a debt that has to be paid off in the future. If you are in the business of selling motor insurance but have teams of people maintaining networks, clusters and other supporting infrastructure, ask how you can improve and re-focus the team on motor insurance products and features.
  2. Simplicity. The geek in us wants to build things from scratch. We are drawn to solutions with lots of configuration options — elaborate frameworks that we can own and hold up as monuments to both our cleverness and our firefighting skills. In the end, the smartest option is always the simplest. The simplest solution is when you have to configure nothing and write as little code as possible.
  3. Scalability. Most technology options these days claim scalability but that can mean any of a number of things. Ask yourself these questions: How much scalability do we need? Only spend effort on this factor if it matters. Many workloads are predictable and limited so don’t overthink scalability where it doesn’t apply. How fast and how often should it scale up and down? How does scaling work in production compare to in development? The responsiveness of scaling in production is sometimes paradoxically less important than in development where you are iterating frequently and speed is important. If you are waiting minutes for a cluster to rejig itself to host your single-line code change, you might have a problem.
  4. Cost of maintenance. This is closely related to simplicity but there are subtle differences. Some technology is simple to adopt but more costly to maintain as time goes on. This factor should reflect how easy it is to deploy software, to iterate on change. It should also include the cost of maintaining the infrastructure itself, including the maintenance of aspects like security, network and storage.
  5. Evolvability. How comfortable are you with changing or adapting your decision shortly after you have made it? What if things just don’t turn out as well in practice when the production workload kicks in or when users’ needs change? The term Evolvability was used by Werner Vogels last year to describe how AWS build their own products. For your system to be evolvable, the mindset of your organisation, the architecture and the technologies you use must all be amenable to change. Data-driven decision-making only works if you measure effectiveness afterwards and have the potential to switch. Switching is made easier if you go for the simplest option first as you don’t have to worry about the sunk cost of complex infrastructure.

Simplicity is the Trend

This image shows the evolution of commodity computing in the context of AWS. The axes, value and evolution, are borrowed from Wardley Maps.

The evolution of commodity computing

Factors that Matter Less

Avoid the risk of introducing phantom factors into the equation. Things that often fall into this category are cost, vendor lock-in and skills. The way to eliminate these factors by addressing them up front and measuring whether they matter or not.

  1. Vendor lock-in is similar. All technology choices involve lock-in to something — a framework, programming language or some database. If this is a real concern, assess the risk and the potential cost of moving vendors. Then, include this in your data-driven decision process. In the vast majority of cases, the risk is so low that you can ignore it.
  2. Skills suitability. Don’t underestimate the ability of your organisation to adopt new technologies and skills. Sure, it takes time and there is always a learning curve. In general, when the case is made clear and people are given the opportunity to learn, they will grab it with both hands. If your company’s technology is driven by input from the teams leading to data-backed decisions, people will accept it and be driven to make it happen.

The Methodology

Measuring simplicity isn’t an exact science. Further down, I’ll provide a guide to AWS services with a number for simplicity based on our own knowledge and experience. The important thing is that you can start to put numbers on these factors and rank them. The numbers can always be adapted as more information becomes available. These rankings allow you to make quick, clear decisions using the following flow.

A process for choosing compute services

Scoring AWS Compute Services

By using a simple scoring system, decision-making becomes faster and much less controversial. It protects against the effects of loud voices, personal opinions and bike-shedding. In our scoring system, we include scaling characteristics, important limits and unique features. Each of the compute options in AWS comes with a large amount of documentation on features, quotas, limits and options. Here, we present the essentials to enable quick decisions so you can deploy quickly, measure, learn and adapt. The full table is available as a downloadable PDF here.

A scoring comparison table for AWS compute services

Start with Simple

The message here can be reduced to one principle with a major impact on the ability for you to deliver repeatedly on business outcomes — start with simple. The decision-making process can itself be simplified by reducing factors to an uncomplicated scoring system to facilitate clear choices everyone can understand. It is also designed to work well in organisations that value a learning approach, measuring and adjusting as part of a continuous improvement process. Can you make this process work in your organisation? What’s holding you back? How will you adapt it to foster quick, clear decisions?

CTO @fourtheorem; Co-Author of AI as a Service