This document discusses moving two customer-facing applications, Haufe Instant Feedback and Haufe Agile Hats, from self-hosted to cloud-native architectures on AWS. It provides an overview of the architectures, which include separating the applications by product at the VPC level and using AWS Fargate for container orchestration without Kubernetes. The document outlines the security measures taken and continuous integration/delivery pipeline used to deploy updates from development to production environments on AWS.

1. Does it always have to be K8s?
v 1.0
Running multiple customer-facing application in Fargate!
Nils Rhode | Mission 1 @ umantis | Haufe TEC Day

2. Haufe Talent
Management
Team
Recruiting
Instant
Feedback
Marketplace
My
Onboarding
….

3. • 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

4. • 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

5. From
self-hosted applications
to
cloud-native applications

6. 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 flutter
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

7. V 1.0
Backend
Reengineering
Move to AWS
Haufe Instant Feedback
V 2.0 (Kubernetes, Docker)

8. V 1.0
Backend
Reengineering
Move to AWS
Haufe Instant Feedback
on-prem to
cloud native

9. Start of
Development
Move to AWSHaufe Agile Hats

10. Start of
Development
Move to AWSHaufe Agile Hats
on-prem
to cloud
native

11. AWS Architecture
based on EKS

12. 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 CloudTrail
AWS Systems Manager
AWS Trusted Advisor
Amazon CloudFront
Amazon Route 53
AWS Transit Gateway
Amazon GuardDuty
Amazon Cognito
AWS Certificate
Manager
AWS WAF
Amazon Pinpoint

13. AWS Architecture
based on Fargate
EKS to Fargate

14. AWS Architecture
based on Fargate
DeamonSets
Pods
ConfigMaps
AutoScaler
PV / PVC
ReplicaSet
Ingress
Seamless integration
into AWS services
IAM
ParameterStore
K8s Updates
AWS Fargate
Amazon API Gateway
AWS Lambda
Amazon Aurora
NLB
VPC Link
Containers
Task
Service
Role-based access
following
least privileges

15. - K8s for hybrid-cluster over multiple cloud provider
Not the right fit 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
AWS Architecture
Conclusion

16. Architectural Deep Dive

17. Architectural Overview
Deep dive

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

19. Architectural Overview
Container Orchestration
VPC IN EU-CENTRAL 1
Availability Zone 1
AWS CLOUD
Availability Zone 2
Availability Zone 3
WWW Container
Task Service
Container Task Service
Container Task Service

20. Fargate Cluster
Availability Zone 1
Availability Zone 2
Availability Zone 3

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

22. Fargate Cluster
Availability Zone 1
Availability Zone 2
Availability Zone 3
Container Task
Container Task
Container Task

23. Fargate Cluster
Availability Zone 1
Availability Zone 2
Availability Zone 3
Container Task Service
Container Task Service
Container Task Service

24. Network
Load Balancer
Availability Zone 1
Availability Zone 2
Availability Zone 3

25. API Gateway with
VPC Link
Availability Zone 1
Availability Zone 2
Availability Zone 3

26. API Gateway with
VPC Link
Availability Zone 1
Availability Zone 2
Availability Zone 3

27. - 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-traffic)
- 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

28. Quick Journey:
environment deployment
for
multiple production applications

29. Architectural Overview
Setup of Infrastructure
- Everything is done by terraform
- Workspaces used to split between Dev, Int and Prod
environment and also with var-files
- Different accounts per environment/workspace
- Gitlab Runner based on EC2 to deploy infrastructure
(deployment happens from inside the AWS account)
PRODUCT VPC
AWS Cloud
RUNNER VPCHAUFE
Amazon EC2
AWS Direct Connect
AWS DEV ACCOUNT
AWS INT ACCOUNT
AWS PROD ACCOUNT

30. Architectural Overview
Setup of Infrastructure - Baseline

31. Architectural Overview
Setup of Infrastructure - Instant Feedback

32. Architectural Overview
Setup of Infrastructure - Agile Hats

33. Architectural Overview
Setup of Infrastructure
Base infrastructure to serve
• VPC (Network)
• Security
• Backup
• SES (setup)
• Security
Application specific infrastructure to serve
application services like
• API Gateways
• Fargate
• S3
• Elasticache
• Cloudfront
• ….

34. 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

35. 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

36. Architectural Overview
Setup of Infrastructure - CI/CD
validate
plan
apply

37. Architectural Overview
CI/CD for our products
PRODUCT VPC
AWS Cloud
RUNNER VPCHAUFE
ECR
1. test 2. build
Fargate
3. deploy 4. int-test 5. check
(6.)Rollback if required

38. Conclusion

39. - Make use of services and reduce maintenance effort
(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 different purpose than cloud native – don’t depend on both
- Outlook: AWS App Mesh
Benefits of going cloud native

40. The big difference 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.