Recommended
More Related Content
What's hot
What's hot (20)
Similar to From COBOL to Kubernetes: A 250 Year Old Bank's Cloud Native Journey
Similar to From COBOL to Kubernetes: A 250 Year Old Bank's Cloud Native Journey (20)
Recently uploaded
Recently uploaded (20)
From COBOL to Kubernetes: A 250 Year Old Bank's Cloud Native Journey
- 1. ABN AMRO Bank Laura Rehorst & Ferhat Yildiz From COBOL to Kubernetes #teqnation2019
- 2. Ferhat Yildiz Turing Technology Services DevOps Consultant Laura Rehorst ABN AMRO Product Owner
- 3. ABN AMRO BANK Financial sector Enterprising bank Amsterdam Headquarter Agile organization DevOps / Hybrid cloud Total number of employees 20,000 Development Teams 400+ Applications 3,000+
- 4. MOVING TOWARDSCONTAINERS • Increased development speed • Flexibility • Unified environment • Cost efficient • Supplier software in containers
- 6. What we need: • Clearguidance • Thebest cloud features easily consumable • A uniformway of working • Shareknowledge and best practices
- 7. Stratus “low-level clouds characterized by horizontal layering with a uniform base.”
- 8. to enable development teams to quicklydeliver secure and highquality software by providing them with: STRATUS’MISSION Easy-to-use Platforms Re-usablesoftware components Portabilityacrossclouds onenterpriselevel Security
- 10. PLATFORM ORCHESTRATION INFRA PROVISIONING RUNTIME SECURITY MONITOR&LOGGING APPLICATION Level Docker RegistryAutomation& Config App definition& Image build CI/CD Persistentstorage NetworkContainerruntime Secrets Management Scanning …Azure AKS To be determined Azure DevOps
- 11. ROADMAP Q4 2018 Stratus team created Define mission & vision Define capabilities of platform Q1 2019 Minimum Viable Product #1 Managed Container Platform on AWS (EKS) Twistlock build implementation Docker Image Pipeline Hardened and secure base images Q2 2019 Minimum Viable Product #2 Improve platform governance Training & Education Positioning Infrastructure as Code Positioning Compliance as Code Metrics / Telemetry Twistlock runtime implementation Onboard applications
- 12. COMPLIANCE How do wemakesure that we adhereto compliance controls? Timely mitigation Mitigating measures need to be implemented within a certain amount of time. Open Policy Agent (OPA) Policy engine (OPA) integrated with Kubernetes. Versioning Versioning enables immutability and traceability. Trust Trust but verify approach. CIS benchmarking Use best practices for secure configuration, hardening and monitoring. Monitoring & alerting Compliance related logs sent to CloudWatch and Splunk.
- 13. COMPLIANCEASCODE Defining yourcompliance requirements in a human- andmachine-readable language. Configurations can be automatically deployed, tested, monitored andreported on across your entire IT estate. AutomationIncreased speed Shift left
- 14. USE CASE – SMILE TEAM
- 15. USE CASE:SMILE TEAM The SMILEteam is developing containerized microservices in Java.These microservices are deployed totheir EKScluster on AWS. • Stratus heavily collaborates with them in a Lean fashion • Helm is being used forpackaging androllingupdates • Cloudbees Jenkins Enterprise is used for CI • Standardized Docker image pipeline forCI • Twistlock is included within the pipeline forcontainer security • AWS CodePipeline is being used for CD
- 16. Keep focus on your Minimum Viable Product (avoid the squirrel effect). Focus Don’t only focus on the technical aspects, but also create clear governance. Automate as much as possible. Start small and iterate in a lean fashion with actual customers. Think in terms of platform capabilities rather than tooling. Holistic approach Automation Iteration Platform Capabilities LESSONS LEARNED What did we learn from our journey up until now?
- 17. DEMO Compliance as Code with Open Policy Agent
- 18. Questions?
- 19. #teqnation2019 Thanks for your attention and don’t forget to rate us in the TEQNATION APP!
Editor's Notes
- Active in financial sector > Strictly regulated, highly competitive. Work according to agile principles and implementing DevOps across the organization. Quite far with CI/CD and strategy for hybrid cloud. > Agile organization 400+ dev teams 3000 applicaties
- Why is ABN moving towards containers? Because of Devops transformation - What prompted the start of the containerization journey, and where do we want to be? - The desire for containerization was bottom-up – developers want to use containers for efficiency/reliability/etc. Deliver to azure and aws, containers. Strategic decision for formalize the containerization strategy to avoid redundant expenditure, uniform quality of containerization components External influence > suppliers deliver software in containers. When starting with containers on cloud, you will have a lot of choice in the cloud native landscape…
- Guidance – otherwise all teams will create their own solutions and multiple licenses Select the best cloud features and make them available according to the ABN AMRO standards and rules. Best fit-for-purpose tooling Uniform way of working > easier to control Share knowledge/best practices: prevent re-inventing the wheel. Cloud-native landscape can be overwhelming. What do you actually need? When do you need it?
- The team responsible for delivering this managed container platform is called ‘Stratus’. To determine the direction of this team and the journey towards containers, we have defined a mission. Stratus: investigates the needed capabilities, experiments with tooling, implements and integrates best-fit-for-purpose-tooling, supports teams that are already moving forward with containers, kubernetes, and microservices, writes standards, guidelines, and best practices. “Stratus clouds are low-level clouds characterized by horizontal layering with a uniform base.” - https://en.wikipedia.org/wiki/Stratus_cloud
- Create easy-to-use platforms, so teams can easily deploy their software. Security is top priority. With new techniques, new vulnerabilities and risks pop-up. We needed to create specific security measures for working with containers. delivers re-usable components e.g. base images and infra-structure-as-code, so teams can re-use and don’t need to re-invent. We practice inner-sourcing. Teams that are pioneering adoption of containers contribute to shared modules. Teams with less DevOps maturity can benefit from the work of these teams. Modular approach – Lego for DevOps We offer Infra as Code modules for setting up Kubernetes clusters and worker nodes We offer modules for pipelines for building containers, delivering Helm Charts to shared repositories, delivering applications to Kubernetes, etc. We offer Helm Charts for common components such as EFS provisioner for persistent storage, ALB ingress with External DNS, etc. We practice inner-sourcing. Teams that are pioneering adoption of containers contribute to shared modules. Teams with less DevOps maturity can benefit from the work of these teams (standing on the shoulders of giants) Portability across clouds > less dependent on the cloud provider if you use cloud agnostic tools. Helps you with exit strategy.
- - Platform = technique - In a large enterprise it is not simply implementing a tool; governance is important. Collaborate with other teams, e.g. security and compliance departments. But also collaborate with cloud platform teams. We needed to define the responsibilities and shared responsibilities, so we can work more effective and prevent gaps. Pipelines help us to automate process. We for example have a Docker image pipeline that enables teams to create their own Docker images. In these pipeline certain steps are integrated that check the quality and security of the image that you are creating. If critical issues are find, the build will break and you will need to fix your image. Helps us to speed up, but also to control and add security steps in the process. This all together is the managed container platform. Teams will onboard their applications and can go to PROD with it. We use semantic versioning for compliance rules Compliance changes are software changes – we get all the benefits software development: CICD, code review, etc. As new regulations or advisories come into affect, we can release new versions of our compliance policies Compliance teams get an easy overview of who is using which sets of rules Developers get an easy upgrade path – just bump the version number in the policy applied to their clusters and they are compliant again
- - Helm - package management at k8s level - Jenkins/Azure DevOps - Twistlock - runtime and build time security scans, policy enforcement Vault - secrets management, secret zero provisioning Open Policy Agent - policy enforcement. Compliance as Code. - Docker - CNI - container networking, container storage. We haven’t locked down a decision on these components yet. Still evaluating. - Splunk/Prometheus - ABN has invested heavily in our Splunk infrastructure, and we wanted a way to reuse as much as possible. Terraform - infrastructure provisioning. Splunk/Prometheus metrics - AWS EKS/Azure AKS - managed kubernetes. I do not want my team woken up in the middle of the night because of an issue with etcd or another under-the-hood component. Just give me an API that spawns Kubernetes clusters, and we’ll take it from there
- Highly regulated especially with regards to workloads on the public cloud. Banks are expected to be ‘in control’. How do we make sure that we adhere to compliance controls?
- High speed automated compliance checks Real evidence can be delivered to regulators instead of Excel-sheets Automated compliance checks can be traced back to compliance controls. Compliance triggers can be aggregated into a log aggregation system Compliance reports can be generated automatically Shift Left for Compliance. CaC pipelines can give quick feedback to developers