This is the first article in a series describing an opinionated architecture for running web applications on Amazon Web Services (AWS). This design forms the basis of Cuju, Fullback Systems toolkit for building production ready infrastructure. Cuju is designed to help small to medium organisations who may not have a dedicated operations team get their applications up and running quickly in the Cloud.

The sorts of applications Cuju targets typically consist of one or more back-end services and possibly a front-end component accessed via a web browser. Some of these services are publicly accessible over HTTPS. Services may communicate with each other using HTTP. The application may utilise various data stores such as key value stores, object storage and relational databases.

What is an opinionated architecture ?

AWS provides primitives in the form of services that must be glued together to form a working infrastructure. This approach while flexible, leaves much of the decision making and complexity in the hands of the implementer.

An ‘opinionated’ architecture like Cuju is one in which most of decisions have been made for you. It attempts to accommodate the most common use cases and provide a balance between security, usability and cost.

If you have additional requirements not covered by the architecture we are happy to discuss providing additional customisation for you.

Architecture overview

Cuju assumes a Container based approach to deploying and running applications. Elastic Container Service (ECS) is used to manage the Container life cycle. Container images are stored in Elastic Container Registry (ECR) repository and deployed to the ECS service.

Fargate is described by Amazon as a “serverless compute engine for containers”. Traditionally you would need to deploy and manage the underlying compute instances to run your container workloads. By using the Fargate ECS launch type the need to need to provision and manage worker nodes is removed as Amazon takes responsibility for deploying and managing these for you.

Each environment consists of a Virtual Private Cloud (VPC) in which a number of subnets are spread across availability zones. Fargate instances are deployed into these subnets. An Application Load Balancer (ALB) is used to route requests from your users to some or all of these services as well as providing TLS termination.

Cloud Map gives your deployed services the ability to discover each other using DNS host names which you define, without having to add additional code to the service.

CloudWatch is used to collect application logs and metrics as well as trigger alerts. Metrics such as CPU and memory usage as well as application specific metrics can be used to trigger alarms for example when CPU usage for a service goes above a certain threshold for a period of time. Cuju configures some default metrics and alarms for you as well as providing helpers to define your own application specific ones.

CloudFront is used for delivering static content such as images, style sheets and front-end code to your users web browser.

The main components of the architecture are show in the following high level diagram. Missing from this are the optional back-end data stores.

Environments and tooling

Cuju uses “Infrastructure as Code” to provide a declarative description of the infrastructure which can be consistently applied to multiple environments with varying parameters.

Along with the primary production environment we recommend creating the following environments:

• Development: For testing infrastructure changes
• Staging: For performing QA before deploying to production

Ideally each environment should be deployed into separate AWS accounts in order to limit risk when deploying applications and creating or upgrading infrastructure.

Availability

Cuju is currently in development with early access starting soon. If you have specific infrastructure or needs you would like to discuss please feel free to contact me directly at anthony@fullbacksystems.com