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? Running multiple customer-facing application in Fargate! Nils Rhode | Haufe.Group | AWS Community Day Hamburg 2019 v 1.0

Haufe.Group - 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 Talent Managemen t T eam R ecruiting M y O nboarding I nstant F eedback M arketplace ….

Haufe Instant Feedback • 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 Agile Hats • 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.

From self-hosted applications to cloud-native applications

Haufe Haufe Instant Feedback Agile Hats 2017 2018 IF 1.0 developed as native app based on a backend, hosted at AzureDE* Start of development of Agile Hats as web application following a microservice approach 2018 Backend reengineering 2019 (better multitenancy, Orchestration, new features) Move to AWS 2019 Hybride App approach with fmutter Move to AWS

Haufe Instant Feedback Backend V 1.0 Reengineerin Move to AWS g V 2.0 (Kubernetes, Docker)

Haufe Instant Feedback Backend V 1.0 Reengineerin Move to AWS g on-prem to cloud native

Haufe Agile Hats Start of Move to AWS Development

Haufe Agile Hats Start of Move to AWS Development on-prem to cloud native

AWS Architecture based on EKS

Move to AWS - Overview Amazon CloudWatch AWS CloudT rail Amazon API Gateway AWS Systems Manager Amazon SQS AWS T rusted Advisor Amazon CloudFront Amazon Pinpoint Amazon Route 53 Amazon Pinpoint AWS T ransit Gateway Amazon GuardDuty Amazon Aurora Amazon Cognito AWS Certifjcate AWS Lambda Manager (Moible) data processing done via AWS Lambda instead of K8s containers AWS WAF

AWS Architecture based on Fargate EKS to Fargate

AWS Architecture based on Fargate Amazon API Gateway VPC Link NLB RBAC Pods Seamless integration Containers DeamonSets into AWS services T ask Deployments RDS Service ConfjgMaps AWS Fargate AWS Lambda S3 IAM s t e r c e ParameterStore S AutoScaler ELB / ALB / WAF PV / PVC N a m e s p a c e s ReplicaSet Role-based access Ingress following S e r v i c e s least privileges Amazon Aurora K8s Updates

AWS Architecture Conclusion - 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 one 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

Architectural Deep Dive

Architectural Overview Deep dive

Architectural Overview Separation on product level AWS CLOUD VPC IN EU-CENTRAL 1 Availability Zone 1-3 Product IF Product AH Product *

Architectural Overview Container Orchestration AWS CLOUD VPC IN EU-CENTRAL 1 Availability Zone 1 WWW Container Service T ask Availability Zone 2 Container Service T ask Availability Zone 3 Container Service T ask

Fargate Cluster Availability Zone 1 Availability Zone 2 Availability Zone 3

Fargate Cluster Availability Zone 1 Container Availability Zone 2 Container Availability Zone 3 Container

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

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

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

Architectural Overview Security - 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 - …

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 AWS DEV ACCOUNT - Difgerent accounts per environment/workspace AWS INT ACCOUNT AWS PROD ACCOUNT - Gitlab Runner based on EC2 to deploy infrastructure (deployment happens from inside the AWS account) AWS Cloud PRODUCT VPC RUNNER VPC HAUFE Amazon EC2 AWS Direct Connect

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 AWS Cloud RUNNER VPC PRODUCT VPC HAUFE 1. test 2. build (6.)Rollback if required ECR 3. deploy 4. int-test 5. check Fargate

Conclusion

Benefjts of going cloud native - 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

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.