Unicorn Pursuit: Architecture
Unicorn Architecture
Unicorn Project has a single objective: to help you become a Cloud Ninja, or improve your Ninja Skills. Cloud Ninja may mean Cloud Developer, Cloud Engineer or a Cloud Architect. In accordance with this, we are building on the up-and-coming technology stack. These are the skills that will be in the highest demand within the next 5 to 10 years. Most of the architectural components have been chosen precisely because of this.
Architecture will be Serverless, as it best meets technical requirements.
Cloud Provider - Amazon Web Services.
Source Code Management - GitHub. All code (both application and infrastructure) will be stored in a public unicorn repository.
Web Application - Golang, with Gin-Gonic web framework.
Architecture Deep Dive
Unicorn Pursuit Cloud Architecture is shown in the diagram below.
- AWS CDK (Cloud Development Kit) with Python has been chosen for IaC (Infrastructure as Code). This means that all AWS resources (everything you see on the diagram) is provisioned using AWS CDK only.
- Cognito is used for User Authentication. Users Phone Numbers will be verified using OTP. e-mail address will serve as username, and users won’t be able to vote or create projects unless their email is verified.
- S3 is used for static content (images, for example). When submitting a new project, users will have an option to upload an image. The image will be stored in S3, and image URL will be stored in DynamoDB along with other project details in a single Item representing a Project, which makes project viewing later easier.
- KMS will be used for Encryption Key Management.
- SSM (Systems Manager) will be used for storing the encrypted Key/Value pairs. This way we won’t have to expose our sentitive info in the code.
- Two DynamoDB are used for Projects and Users Voting info. First one is used as Project Table (stores all project info, including current Votes) and User Votes Table (stores the information on how each user has voted. Since each user can vote for 5 projects, assigning 1 to 5 points to each, this database will be used for control, so that users cannot “cheat”).
- ECS Fargate is where our Docker container runs. ECS is a managed container orchestration platform. Unicorn Pursuit is a web application written in Go, containerized, and Docker Image is pushed to ECR (Container Registry), which is where Fargate will reach to create a Service. Docker Image is pushed to ECR from GitHub. Application Load Balancer stands “in front of Fargate”, and exposes an Application to the public.
- CloudFront as Content Delivery Network. ALB is configured as an Origin.
- Route53 for Domain management and DNS. unicornpursuit hosted zone is where our web domain A and C records are configured.
- Certification Manager is where our SSL is. Don’t forget that even though our App is in Ireland - SSL needs to be in “Global”, otherwise we won’t be able to use it from CloudFront, which is also a “global service” (not linked to any AWS Region).
- IAM is used to give Fargate the right permissions. Service Role is created, to be assumed by Fargate Task, and all the required policies are fine tuned into this Role.
- CloudWatch is used for individual service monitoring and logs.
Keep reading to understand why each element and technology was chosen.
Why AWS
There are 3 hyper-scalers, that really managed to build decent Cloud Platforms, where a Serverless web application could be hosted. Each one can be described with what their priorities are:
- AWS: Customer First
- Google Cloud: Technology First
- Azure: Profit First
This is why for us most of the times it’s AWS vs GCP. At this particular occasion, AWS has been chosen for two reasons:
- AWS skills are in more demand by the Workshop participants (Twitter survey).
- Due to recent launch of AWS CDK, a real differentiator when it comes to deploying Cloud infrastructure.
Yes, depending on the demand, there will probably be a Google Cloud version of a Unicorn Pursuit. If you want to see something like this soon, please contact us.
Why AWS CDK
CDK is a Cloud Development Kit. It allows us to programmatically define our infrastructure, and luckily - Python is one of the options. AWS CDK will allow us to write our infrastructure in Python, and it will manage CloudFormation Template creation and stack deployment for us.
AWS CDK was chosen because it combines the best of indicative and declarative programming. I mean… let’s face it, it’s a far better option then typing YAMLs on a keyboard.
Why Cognito
Cognito is a managed AAA (Authentication, Authorization and kinda Accounting). It integrates easily with SAML, or any Identity Provider like Facebook, Google etc. If we’re using AWS - it’s the way to go.
Why Dynamo DB
Performance and Scalability. Voting apps tend to require high performance and low latency.
Why CloudFront
CloudFront is pretty cheap, and since we’re doing an open source app that might serve users all over the globe - CDN can only help our performance.
Why Lambda & Python
Lambda is AWS FaaS, and it integrates quite well will most AWS Services. AWS SDK for Python has a big community, which will help us do great stuff with little effort.
Why GO
Go shows great performance, it’s easy to write and read, and ideal for modern apps that require multi tenancy and micro services. It’s the programming language most developers want to learn, based on the recent surveys.
Using Templates and Routes, Go let’s us develop the Web and APIs. This means we can integrate HTML with Backend, and we don’t require an additional API Gateway.
AWS SDK for Go will be used for all interactions with AWS Infrastructure.
Why Gin Gonic
Go is awesome, but a framework allows you to significantly simplify your code, and when you use Go Routes - it makes the code more performant, and more readable.
Feedback
Was this page helpful?
Awesome! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.