Using AWS to Build a Large Scale Dockerized Microservices Architecture Dr. Oliver Wahlen moovel Group GmbH Frankfurt, 30. Juni 2016
The moovel Group GmbH Our vision is an ecosystem that simplifies mobility now solves the mobility challenges of the future
Mobility as a Service Urban areas will become more crowded: Today 54% of people live in cities In 2050 there will be 66% More people on less space Driving and parking will become more regulated High demand for new transportation concepts Autonomous driving will become reality: Taxi and car sharing business will change completely Cost efficiency similar to public transport but faster Owning a car becomes less relevant The future will be Mobility as a Service
moovel Entwicklung Technology 3: Autonomes Fahren We are building apps, widgets and services that integrate existing transportation providers Benefits for the user: Only one registration: no need to remember passwords or provide payment data several times Transparency on mobility alternatives Intermodal routing Benefits for the partners: Get new users from other mobility providers Get new users from different geographic regions Wir verändern die Art, wie wir uns fortbewegen.
Design Entwicklung Goals 3: of Autonomes Our System Fahren Architecture Scalability up to millions of users Future prove: Easy to modify components and update technologies Usable on global scale Minimal operational effort Teams can develop independently Wir verändern die Art, wie wir uns fortbewegen.
Avoid Entwicklung Vendor 3: Lock-In Autonomes vs. Reduced Fahren Operational Effort Services currently used by moovel Wir verändern die Art, wie wir uns fortbewegen.
What Entwicklung and Why 3: Autonomes Docker? Fahren Docker Containers Provide application(s) with a virtual operating system Isolate applications from the host OS and other docker containers (e.g. Files, Network) Are self contained run on any machine without other installs Are simple to build images reference a base image Docker Registry Stores docker images produced by the build system Provides access control and maintenance of tags Dockerhub (Docker Inc.) vs. Amazon EC2 Container Registry
What Entwicklung and Why 3: Autonomes EC2 Container Fahren Service (ECS)? ECS is a highly scalable, fast, container management service that makes it easy to run, stop, and manage Docker containers on a cluster of Amazon EC2 instances. AWS documentation Technology similar to Kubernetes on Google Container Engine but tailored for AWS and fully managed Terminology ECS cluster: Group of EC2 instances that allow docker execution ECS container instance: EC2 instance with ECS container agent ECS task: The running docker container on an instance ECS task definition: docker image, CPU, mem, port requirements, ECS service: number of parallel tasks, scalability, health checks,
What Entwicklung and Why 3: Autonomes Microservices? Fahren Web Service Docker Task = ECS Task EC2 Instance Services independently deployable Continuous Deployment Scalable on service level Specific to service needs: CPU, memory Services have firm boundary allows for: different languages per service different teams per service group evolution of logic and technology ECS Cluster http://martinfowler.com/articles/microservices.html
Conway s Entwicklung Law 3: And Autonomes Microservices: FahrenA Good Fit Organizations which design systems [...] are constrained to produce designs which are copies of the communication structures of these organizations Product Owner Search Squad Book Squad User Squad Pay Squad Melvin Conway 1967 App-Developers Backend-Devs moovel product dev is organized in squads (feature teams): with a long term business vision ability to build and modularize mobile apps / componets build their own set of microservices choose the technology that best fits their needs
Continuous EntwicklungIntegration 3: Autonomes with Fahren Docker and AWS Build Path code push to triggers dockerfile.tgz Developer Version Control SaaS Build System S3 Bucket Deployment Path Deployment triggers: develop branch: automatic master branch: manually docker image push to start update update docker SaaS Build System Dockerhub Cloudformation Elastic Container Services: dev/prod
moovel Entwicklung System 3: Autonomes ArchitectureFahren Client App moovel VPC Consul service discovery client load balancing service configuration External ELB TLS termination Kong API Gateway reverse proxying LUA plugins logging Kinesis ELK Stack synchronous REST call asynchronously publish changes ECS microservice SNS Topic SQS Queue
Limitations Entwicklung of 3: Existing Autonomes Solution Fahren Difficult to realize dynamic port allocation Currently each service has a fixed port Two levels of scaling introduce additional complexity: Cluster nodes = No. of EC2 instances ECS Tasks = No. of running Docker containers for a service had to introduced a custom metric taskless instance count Service discovery with Consul: Automates node and service registry Provides hierarchical key value store with ACL for configuration Consul is a very critical component Must be operated and maintained Kong API gateway: Extremely flexible and powerful nginx based reverse proxy Requires cassandra DB Must be operated and maintained Elasticsearch Logstash Kibana (ELK): Do not use it for long term data storage!
Check-up Entwicklung of Design 3: Autonomes Goals Fahren Scalability moovel runs 80 services on 21 ECS clusters (dev+prod) Future prove Exchanging microservice technology is easy We have microservices in Java, Node.js, Python, Kotlin, Global Scale The world is currently operated from eu-west-1 Pub/Sub is good starting point for multi region deployment Minimal Operational Effort Technology is operated by 10 squads Currently no DevOps team needed: squads build it and run Deployments are easy, frequently done and without downtime Teams can develop independently Technology is operated by 10 squads Microservices, REST and Pub/Sub are a good basis UI decomposition in app is difficult: modularization ongoing
Thank You