How Docker EE is Finnish Railway’s Ticket to App Modernization
0 likes895 views
The document discusses how the Finnish Railways modernized its application platform using Docker, enhancing operational efficiency with a focus on DevOps practices and microservices. It outlines the drivers for the change, the implementation of the Docker Enterprise Edition, and the management of diverse workloads across a unified architecture. Key achievements include improved development processes, operational visibility, and the establishment of a consistent deployment experience.
![Public
As VR’s next-gen application platform, this was a great
opportunity to provide teams with a modern, state of the art
experience
[pvm] [Aihe, Tekijä]6
Consistent
Provide a runtime,
development and operation
experience with zero
surprises
Unified
Common underlying
components, regardless
of technology or
framework
Automated
Enable as much as possible
with zero human
intervention](https://image.slidesharecdn.com/qahnwcipsreedp8top0x-signature-09fc6dbf2184074a7078a9031bd8b57b41165735df4bd03a54f4d484bf6ba757-poli-171025005512/85/How-Docker-EE-is-Finnish-Railway-s-Ticket-to-App-Modernization-6-320.jpg)
How Docker EE is Finnish Railway’s Ticket to App Modernization
- 1. Public How Docker is Finnish Railway’s Ticket to App Modernization Markus Niskanen Oscar Renalias 18.10.2017
- 2. Public Net sales 1 186.7 million euros 82.1 million train journeys 35.8 million bus journeys 36.1 Million tons of goods transported by rail 5.1 Million tons of goods transported by road 7 898 workers Train Operations Maintenance
- 3. PublicPublic • 300+ different applications • 100s of integrations • 10s of different vendors • 6 different local datacenters • 90%+ of development outsourced to partners Managing Diversity – By The Numbers
- 4. Public BUSINESS DRIVERS • Bang for the buck • Quality • Time to market IT DRIVERS • Common application platform • Unified architecture • Open Source based solutions • Microservices • DevOps approach Drivers For Change – Why Did We Start The Modernization
- 5. Public Migration Business Case DevOps Platform Analysing Architechture Options IaC Implementation Commuter Services Go-Live Migrations Starts Implementing Docker Platform Migrating Pilot Applications Reservation System Go-Live Pilot Apps Go Live AWS Architecture 2015 2017 20182016 What Has Been Done - Timeline
- 6. Public As VR’s next-gen application platform, this was a great opportunity to provide teams with a modern, state of the art experience [pvm] [Aihe, Tekijä]6 Consistent Provide a runtime, development and operation experience with zero surprises Unified Common underlying components, regardless of technology or framework Automated Enable as much as possible with zero human intervention
- 7. Public Docker EE Additional components DOCKER ENTERPRISE EDITION Infrastructure Runtime Services Administration Host OS Container OS Container Engine Container Tooling Orchestration Resource Management Service Discovery PersistenceNetworking Browser Application Integrations Containers Data Registry Storage (Images) Monitoring DevOps Logging Image Build Access Control Log aggregation Metrics aggregation Monitoring, alerting Secrets Management Stacks Swarm Overlays Sysdig Docker Overlays Convoy DTR S3 Docker Docker CLI RHEL RHEL Jenkins Docker EE ELK Sysdig Sysdig Docker EE Storage (Volumes)EFS
- 8. Public Docker EE allows Finnish Rail to run mixed workloads on a common, consistent platform DOCKER ENTERPRISE EDITION Legacy WorkloadsMicroservices & APIsNon-production
- 9. Public Docker EE runs great on AWS
- 10. Public Development Laying out Docker EE on multiple standalone environments while still achieving the efficiencies of containers required some thinking Production A Production B Test Promote Promote Promote Failover if necessary
- 11. Public Docker EE provides robust multi-tenancy capabilities for a multi- tenant application platform • One org per project with at least one technical user for deployment, integrated with Active Directory; no cross team resource access • Separate HRM routes per project • Teams manage their own resources: stacks, services, networks, bundles using standardized naming conventions • Engine labels to separate worker nodes per business group – soon to be replaced with Node RBAC • Secrets management to simplify configuration management
- 12. Public Docker Trusted Registry greatly simplifies the process of managing a large number of images • One DTR organization per team, with multiple repositories as needed • Each team is responsible for managing their own repositories • Immutable repositories to prevent overwriting labels • Image scanning and signing is in the roadmap, has not been enabled yet
- 13. Public Enabling development Manual/user guide: naming conventions (stacks, HRM, images, networks), secrets, load balancing Common base images: CentOS, JDK, JBoss Reference patterns and cookbook: load balancing, reverse proxy, application configuration, multiple application versions, file shares, and others Reference applications and pipelines
- 14. Public BUILD TEST PUBLISH DEPLOY (non-prod) DEPLOY (prod) Promote DTR (non-prod) Non- prod Clusters Prod cluster Build Nodes Enabling a consistently, automated and unified deployment experience with containers DTR (prod)
- 15. Public Achieving operational visibility across the platform with containers and container-native processes DOCKER ENTERPRISE EDITION Logging Monitoring Metrics Resource Management
- 16. Public What Did We Achieve
- 17. Public • Trust that you are on the right track – Technology works • This is not just a technology change – the whole organization is affected • Containers are largely developer driven • Docker is evolving really fast – make sure your organization and infastructure can deal with it Lessons learned