Running multiple customer-facing application in Fargate! Nils Rhode - - PowerPoint PPT Presentation

Running multiple customer-facing application in Fargate!

Nils Rhode | Haufe.Group | 09.09.2019

Community Day 2019 Sponsors

Does it always have to be K8s?

v 1.0

Running multiple customer-facing application in Fargate!

Nils Rhode | Haufe.Group | AWS Community Day Hamburg 2019

• 1934 founded as family company
• 407 Mio € revenue 2019
• 2.000 employees worldwide

distributed over ~20 difgerent locations like Freiburg, Barcelona, Timisoara, St. Gallen

• All DAX 30 Companies rely on our expertise
• We are leading companies in terms of

transformation to digitization

Haufe.Group

Haufe Talent Managemen t

Team Recruiting Instant Feedback Marketplace My Onboarding

….

• Mobile App with

Administration Backend for Managers

• … with a few clicks, employees can

request feedback on their own behavior or provide feedback on a person, meeting or survey — at any time.

Haufe Instant Feedback

• Web Application

for employee and Manager

• … helps organizations to establish an

agile, self-organized and motivating

• culture. Give employees access to

new work opportunities and help them achieve their career goals, unlock their potential and expand their professional network.

Haufe Agile Hats

From self-hosted applications to cloud-native applications

2017

IF 1.0 developed as native app based on a backend, hosted at AzureDE*

2018

Backend reengineering (better multitenancy, Orchestration, new features)

2019

Hybride App approach with fmutter Move to AWS

Haufe Instant Feedback Haufe Agile Hats

2018

Start of development of Agile Hats as web application following a microservice approach

2019

Move to AWS

V 1.0 Backend Reengineerin g Move to AWS

Haufe Instant Feedback

V 2.0 (Kubernetes, Docker)

V 1.0 Backend Reengineerin g Move to AWS

Haufe Instant Feedback

• n-prem to

cloud native

Start of Development Move to AWS

Haufe Agile Hats

Start of Development Move to AWS

Haufe Agile Hats

• n-prem to

cloud native

AWS Architecture

based on EKS

Move to AWS - Overview

Amazon Pinpoint Amazon Aurora Amazon SQS Amazon API Gateway AWS Lambda

(Moible) data processing done via AWS Lambda instead of K8s containers

Amazon CloudWatch AWS CloudT rail AWS Systems Manager AWS T rusted Advisor Amazon CloudFront Amazon Route 53 AWS T ransit Gateway Amazon GuardDuty Amazon Cognito AWS Certifjcate Manager AWS WAF Amazon Pinpoint

AWS Architecture

based on Fargate

EKS to Fargate

AWS Architecture

based on Fargate

RBAC DeamonSets Pods ConfjgMaps Deployments S e c r e t s AutoScaler PV / PVC N a m e s p a c e s ReplicaSet Ingress S e r v i c e s Seamless integration into AWS services RDS IAM ParameterStore ELB / ALB / WAF K8s Updates

AWS Fargate Amazon API Gateway AWS Lambda Amazon Aurora NLB VPC Link

Containers T ask Service

Role-based access following least privileges S3

• K8s for hybrid-cluster over multiple cloud provider

Not the right fjt for our cloud-native applications/approaches

• Fargate serves better and easier integration in AWS

Services

• ne abstraction layer less and usage of triggers and seamless integration

(role-based access for Pods following least privileges in K8s is a mess)

• Fargate reduces a lot of overhead

like scaling, RBAC, namespaces, Updates & Security of K8s by using managed services

• It is cheaper and better scalable

AWS Architecture

Conclusion

Architectural Deep Dive

Architectural Overview

Deep dive

Architectural Overview

Separation on product level

VPC IN EU-CENTRAL 1 Availability Zone 1-3 Product IF Product AH AWS CLOUD Product *

Architectural Overview

Container Orchestration

VPC IN EU-CENTRAL 1 Availability Zone 1 AWS CLOUD Availability Zone 2 Availability Zone 3

WWW

Container T ask Service Container T ask Service Container T ask Service

Fargate Cluster

Availability Zone 1 Availability Zone 2 Availability Zone 3

Fargate Cluster

Availability Zone 1 Availability Zone 2 Availability Zone 3 Container Container Container

Fargate Cluster

Availability Zone 1 Availability Zone 2 Availability Zone 3 Container T ask Container T ask Container T ask

Fargate Cluster

Availability Zone 1 Availability Zone 2 Availability Zone 3 Container T ask Service Container T ask Service Container T ask Service

Network Load Balancer

Availability Zone 1 Availability Zone 2 Availability Zone 3

API Gateway with VPC Link

Availability Zone 1 Availability Zone 2 Availability Zone 3

API Gateway with VPC Link

Availability Zone 1 Availability Zone 2 Availability Zone 3

• Least privileges on each container and service
• No IAM users needed at all (deployment via EC2, Login via SSO)
• No jump host or “open” port 22 => Transit Gateway in private

Subnet

• Nothing is deployed in public subnet (except NAT Gateway)
• Everything is encrypted (RDS, S3, EFS, Backups, HTTPS-traffjc)
• Credentials to RDS shared via Parameter Store
• CloudTrail with S3 and Athena
• Security Hub with integration of GuardDuty, Inspector and some

more tools

• …

Architectural Overview

Security

Quick Journey: environment deployment for multiple production applications

Architectural Overview

Setup of Infrastructure

• Everything is done by terraform
• Workspaces used to split between Dev, Int and Prod

environment and also with var-fjles

• Difgerent accounts per environment/workspace
• Gitlab Runner based on EC2 to deploy infrastructure

(deployment happens from inside the AWS account)

PRODUCT VPC

AWS Cloud RUNNER VPC

HAUFE

Amazon EC2

AWS Direct Connect

AWS DEV ACCOUNT AWS INT ACCOUNT AWS PROD ACCOUNT

Architectural Overview

Setup of Infrastructure - Baseline

Architectural Overview

Setup of Infrastructure - Instant Feedback

Architectural Overview

Setup of Infrastructure - Agile Hats

Architectural Overview

Setup of Infrastructure

Base infrastructure to serve

• VPC (Network)
• Security
• Backup
• SES (setup)
• Security

Application specifjc infrastructure to serve application services like

• API Gateways
• Fargate
• S3
• Elasticache
• Cloudfront
• ….

Architectural Overview

Setup of Infrastructure - CI/CD Push to feature/bug branch => terraform validate … => merge request to develop => terraform plan … => merged into develop => terraform apply to dev environment … => merge request to master => terraform validate => terraform plan => terraform apply to new AWS account (int) => backup from prod into new AWS account (int) => testing… … => merge to master => terraform apply to prod env

Architectural Overview

Setup of Infrastructure - CI/CD

• Gitlab (own branch) with validate => request =>

validate, plan => merge => deploy in dev infra

• Gitlab (dev) to master request => validate, plan,

deploy to INT => check/test => merge => deploy to master

Architectural Overview

Setup of Infrastructure - CI/CD

validate plan apply

Architectural Overview

CI/CD for our products

PRODUCT VPC

AWS Cloud RUNNER VPC

HAUFE ECR

• 1. test 2. build

Fargate

• 3. deploy 4. int-test 5. check

(6.)Rollback if required

Conclusion

• Make use of services and reduce maintenance efgort

(Backups, DR, Scalability, Monitoring/Logging)

• Reduce development overhead by making use of services

(e.g. Lambda instead of own docker)

• Handling and applying high security standards
• K8s has a difgerent purpose than cloud native – don’t

depend on both

• Outlook: AWS App Mesh

Benefjts of going cloud native

The big difgerence for cloud native applications is really how they are built, delivered and operated.

If you are going cloud native:

Rethink your architecture and avoid a lift and shift.