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