Cicada's High-Level AWS Service Architecture

This is Cicada Note #2 . For a background on Cicada and Cicada Notes, read Introducing Cicada.

In the previous Cicada Note I introduced Cicada’s architecture with respect to the interfaces between Cicada’s cloud-hosted application; third-party APIs; and the user’s browser. In this note I descend one level to start looking at the primary AWS Services that Cicada uses, and the interactions between them.

The services and interactions I describe in this article are those most closely related to Cicada’s user experience. Cicada uses many other AWS services beyond those described here, for areas including security, deployment, and operations.

Stepping down one level

This is the architecture diagram I introduced in the previous Cicada Note :

I can expand the big “Cicada” bubble by one level to get this:

All of the new boxes I show in this version of the diagram represent the use of services within AWS - Amazon Web Services. In this article I list those services and a brief description of how Cicada uses them, but first there are a couple of things I can say about the philosophy of Cicada’s implementation approach based solely on this diagram.

“AWS Native” Architecture

Over the last decade or so a popular architectural approach has emerged called cloud native. Cloud native is about the idea of knowing that you are deploying an application to a cloud environment, instead of to an “on premise” environment, and using the differences and opportunities that come from the cloud in designing your system. These cloud capabilities are things like highly elastic scaling through use of third-party managed, shared, hardware.

Cloud native systems sometimes don’t rely on any one cloud vendor in their design, and can run on different cloud platforms. For such systems there’s typically a benefit to be able to run on multiple clouds.

The tradeoff with “multi cloud” cloud native designs is that they don’t fully embrace the capabilities of one cloud. This typically requires using abstractions to form a “cloud abstraction layer”, or not using vendor-specific functionality at all.

The alternative to this multi cloud approach is to build for one cloud platform. Cicada is only built for one platform - AWS. In this regard Cicada doesn’t just use cloud native architecture, but AWS native architecture. In other words my design primitives are those specifically provided by AWS, which I attempt to use to the fullest.

Whether to use a “multi cloud” or “vendor native” version of cloud native architecture is often a tricky question, involving many tradeoffs.

Unfortunately “cloud native” has become co-opted as a term in some parts of the world to just describe the architecture of systems built using Kubernetes as a cloud-abstraction layer. I have nothing against Kubernetes, but I’m disappointed by the narrative from some that cloud native requires Kubernetes. It doesn’t, and I see AWS-native (or GCP-native, or Azure-native) as subsets of the larger idea of cloud native architecture.

Serverless Architecture

The next immediate architecture choice that is apparent from the second diagram is that Cicada embraces serverless architecture. All of the AWS services that Cicada uses are serverless ones - those that are fully elastic based on load, have minimal idle costs, and don’t require me to manage any server hosts.

The use of AWS Lambda is the most obvious aspect of a serverless design but all of the services shown here are also serverless.

Primary AWS services used by Cicada

In the rest of this article I briefly describe the services referenced in the second diagram above, and what Cicada uses those services for.

CloudFront

CloudFront is Amazon’s HTTP hosting service, and CDN (content delivery network). CloudFront provides an HTTP host over “static” web content stored somewhere else, and provides caching as part of that service.

CloudFront can also proxy any other HTTP “origins” though, and it can use multiple origins for one client-facing host, choosing between them based on details of an HTTP request. That means that dynamic content and static content can both be accessed via the same hostname.

Use in Cicada

Cicada uses CloudFront to provide both web hosting of static content in S3, and also provide a single host over that content and other endpoints, which are themselves served by API Gateway.

API Gateway

API Gateway is another HTTP hosting service, but instead of “origins” like CloudFront it instead integrates directly with other AWS services. Like CloudFront, API Gateway can be configured to integrate with multiple services, and different instances of those services, and routes to the correct service instance based upon the contents of an HTTP request.

API Gateway is, historically, the most common service to use with Lambda to provide a serverless HTTP application.

API Gateway, despite the name, doesn’t only work for “API requests” - it can satisfy any HTTP request, including those that return HTML responses.

Use in Cicada

In Cicada API Gateway is primarily used to provide an HTTP integration layer with Lambda Functions. However it also directly integrates with S3 to store webhook events published from GitHub.

S3

S3, or Simple Storage Service, is one of Amazon’s oldest services. It provides mass “object storage”. Such objects are often treated as files, but S3 isn’t a fully fledged file system.

Use in Cicada

Cicada uses S3 to store static web content hosted via CloudFront.

Cicada also stores the webhook events posted by GitHub in S3, and when such webhook events are saved then an event is automatically generated in EventBridge to trigger subsequent processing. Webhook events stored in S3 are read by code running in Lambda.

Lambda

Lambda is AWS’ Function as a Service, or FaaS, platform. Lambda allows AWS customers to upload custom code and have that code run in a particular Function according to events and triggers. Lambda automatically scales up and down - when Lambda Functions aren’t running then an AWS customer isn’t (typically) charged anything for their use.

Lambda Functions can be invoked by many other AWS services, and Lambda Functions can also be invoked directly from code via the AWS API / SDK.

Code run in Lambda by default has full access to the public internet, and in such a case can call third party external services.

Use in Cicada

Lambda is Cicada’s cloud-side code hosting environment, and so it is used for many types of behavior, including:

• Responding to API and Web requests (requiring dynamic responses) from the user’s browser (invoked from API Gateway).
• Processing new GitHub Webhook events by reading those events from S3 (triggered by notification events from EventBridge, which themselves are published by S3).
• Asynchronous processing of “internal” events, e.g. when publishing web push notifications by calling a web push service API (triggered by events from EventBridge, which themselves are published by other Lambda Functions)
• Scheduled processing, e.g. daily crawls of GitHub objects involving calling the GitHub API (triggered by a CloudWatch Scheduled Event)

EventBridge

EventBridge is AWS’ most simple topic-based (“pub-sub”) asynchronous messaging system. EventBridge can be used without deploying any resources, i.e. you don’t need to create topics or queues.

Components interacting with EventBridge can be either or both of publishers, or subscribers. Many AWS services are themselves publishers and/or subscribers, and custom code (in Lambda Functions, and elsewhere) can also be of either or both types.

Use in Cicada

• A Lambda Function is triggered by EventBridge whenever a new GitHub webhook event has been received and stored in S3 (S3 is publisher, Cicada Lambda Function is subscriber)
• Allow asynchronous and decoupled behavior between different parts of Cicada itself (Cicada Lambda Functions are both publishers and subscribers)

DynamoDB

DynamoDB is a NoSQL database. Like Lambda it is serverless, and so there is usually zero or trivial cost for using it apart from during actual activity (when used in “on-demand” mode) , and further it can scale according to load.

Use in Cicada

Cicada uses a number of DynamoDB tables to store various type of records, including users, GitHub account configuration, and GitHub activity.

Summing up

In this Cicada Note I showed the high-level architecture of how Cicada uses AWS services. I discussed a couple of important themes of Cicada’s architecture. Finally I listed the primary services used by Cicada, and briefly described how Cicada uses them.

Feedback

I value hearing what people think about how I’ve built Cicada, and also my writing in Cicada Notes. If there ends up being enough interest I’ll start some kind of discussion forum, but for now please either email me at mike@symphonia.io, or if you’re on Mastodon then please kick off a discussion there - my user is @mikebroberts@hachyderm.io .