Learn how to Leverage Kubernetes to Support 12 Factor for Enterprise Apps
5 likes1,145 views
Brad Topol & Michael Elder, IBM “12 Factor” is a software methodology for building scalable microservice applications that provides best practices designed to enable applications to be built with portability, resilience, and scalability when deployed to the web. In this talk we provide an overview of the 12 Factor methodology and describe how the core constructs provided by Kubernetes can be leveraged to support the 12 factors for scalable web apps. In this talk we will provide live demonstrations of how Kubernetes can support 12 Factor for not only newer cloud native applications, but also for legacy enterprise middleware applications that include stateful and transactional workloads.
Ad
More Related Content
What's hot (20)
Similar to Learn how to Leverage Kubernetes to Support 12 Factor for Enterprise Apps (20)
Ad
More from Michael Elder (20)
Ad
Recently uploaded (20)
![PRTG Network Monitor Crack Latest Version & Serial Key 2025 [100% Working]](https://cdn.slidesharecdn.com/ss_thumbnails/revolutionizingresidentialwi-fi-250422112639-60fb726f-250504182022-6534c7c0-thumbnail.jpg?width=560&fit=bounds)
Learn how to Leverage Kubernetes to Support 12 Factor for Enterprise Apps
- 1. Learn how to Leverage Kubernetes to Support 12 Factor for Enterprise Apps Dr. Brad Topol IBM Distinguished Engineer @bradtopol Michael Elder IBM Distinguished Engineer @mdelder
- 2. Let’s deploy our apps on the cloud! 2© 2019 IBM Corporation
- 3. Why? 3© 2019 IBM Corporation 1.Cloud has evolved as a strategy for disruption driven by continuous delivery. 2.Cloud elasticity enables microservices architectures to scale out quickly, but also roll new updates out at immense speeds. 3.Data becomes the fuel for business innovation. 4.AI becomes the catalyst to turn data into brilliant user experiences. 5.Profit! Or really, reduce overall cost.
- 4. 4 What is a 12-factor app? https://12factor.net/ • “12-Factor” is a software methodology for building scalable microservice applications • Originally created by Heroku • Best practices designed to enable applications to be built with portability, resilience, and scalability when deployed to the web
- 5. 5 I. Codebase One codebase tracked in revision control,manydeploys II. Dependencies Explicitlydeclare and isolate dependencies III. Config Store config in the environment IV. Backing services Treat backing services as attached resources V. Build, release, run Strictlyseparate build and run stages VI. Processes Execute the app as one or more stateless processes VII. Port binding Export services via port binding VIII. Concurrency Scale out via the process model IX. Disposability Maximize robustness with fast startup and graceful shutdown X. Dev/prod parity Keep development, staging,and production as similar as possible XI. Logs Treat logs as event streams XII. Admin processes Run admin/management tasks as one-off processes Why 12 factor apps? https://12factor.net/ • Make it easier to run, scale, and deploy applications • Keep parity between development and production • Provide strict separation between build, release, and run stages
- 6. I. Codebase One codebase tracked in revision control, many deploys II. Dependencies Explicitly declare and isolate dependencies III. Config Store config in the environment IV. Backing services Treat backing services as attached resources V. Build, release, run Strictly separate build and run stages VI. Processes Execute the app as one or more stateless processes VII. Port binding Export services via port binding VIII. Concurrency Scale out via the process model IX. Disposability Maximize robustness with fast startup and graceful shutdown X. Parity between dev & prod Keep development, staging, and production as similar as possible XI. Logs Treat logs as event streams XII. Admin processes Run admin/management tasks as one-off processes Code Deploy Operate
- 7. 7 I. Codebase One codebase tracked in revision control, many deploys V. Build, release, run Strictly separate build and run stages X. Parity between dev & prod Keep development, staging, and production as similar as possible Code Factors Mapped to Kubernetes Container images built from Dockerfiles + Kubernetes Declarative YAML based deployment Using same container images and Kubernetes YAML objects in both dev and production Continuous Delivery and leveraging Kubernetes support for deploying updates
- 8. 8 II. Dependencies Explicitly declare and isolate dependencies III. Config Store config in the environment IV. Backing services Treat backing services as attached resources VI. Processes Execute the app as one or more stateless processes VII. Port binding Export services via port binding Deploy Factors Mapped to Kubernetes Container Secret Service ConfigMap Persistent Volume Pod
- 9. IX. Disposability (Pods) Maximize robustness with fast startup and graceful shutdown Common Services (logging, monitoring, audit, etc) VIII. Concurrency Scale out via the process model XI. Logs Treat logs as event streams XII. Admin processes Run admin/management tasks as one-off processes Operate Factors Mapped to Kubernetes Deployment (ReplicaSet) Stateles s Stateless StatefulSet Stateful Job Batch DaemonSet System Job Batch
- 11. Code factors for our app 11 # Application to deploy apiVersion: extensions/v1beta1 kind: Deployment metadata: name: watson-conversation-app spec: replicas: 2 # tells deployment to run 2 pods matching the template template: # create pods using pod definition in this template metadata: labels: app: watson-conversation-app tier: frontend spec: containers: - name: watson-conversation-app image: mycluster.icp:8500/default/conversation- simple:alt resources: requests: cpu: 100m memory: 100Mi env: - name: WORKSPACE_ID valueFrom: configMapKeyRef: name: car-dashboard-config key: workspace_id - name: CONVERSATION_SERVICE_CAR valueFrom: secretKeyRef: name: binding-conversation-service-car key: binding 1.Container Images are built from Dockerfiles. Kubernetes Deployments, etc are managed as YAML (Factor #I) 2.Having a strong artifact-driven model makes it easier to follow a Continuous Delivery lifecycle (Factor #V) 3.Using the same images and YAML objects make it easier for dev teams to match what’s running in production (Factor #X)
- 12. Deploy factors for our app 12 1.ConfigMaps and Secrets can be managed in source repositories or built dynamically via commands (Factor #III) 2.Our container image runs as a container process in a Pod with other containers (Factor #VI) 3.A collection of Pods can expose or consume Services via port bindings (Factor #IV & Factor #VII) Pod (SingleIP Address) Volume Volume container container container Volume Secret ConfigMap
- 13. Operate factors for our app 1.A Deployment includes a ReplicaSet which declares the desired availability policy(Factor #VIII) 2.If a Pod fails, Kubernetes will attempt to recover it via restarting the Pod or scheduling it to a new node (Factor #IX) 3.Running our app as a container makes it possible to capture all logs, metrics, and other management functions in a consistent way (Factor #XII)
- 14. Great, but 95% of my workloads do not fit 12- factor! 14
- 15. Code factors for middleware 15 1.Helm Charts are an open way to package 12-factor apps, but also middleware like IBM MQ Series (F#I) 2.Providing a catalog of Helm Charts either from the community or your internal teams makes it easier to build production-like environments (F#V) 3.Just like apps, build these into Continuous Delivery pipelines for canary testing your upgrades of critical supporting services • IBM MQ Series is a leading provider of messaging services for enterprise apps; • Great example of a critical component that isn’t 12-factor
- 16. Deploy factors for middleware 16 1.Secrets used to configure credentials and TLS certificates (F#III) 2.MQ built as a container image that runs as a container process in a Pod (F#VI) 3.Admin console, app messaging ports, and metrics ports exposed via Services with port bindings (F#IV & F#VII) MQ (SingleIP Address) Volume mq Secret Service
- 17. Operate factors for middleware 1.A StatefulSetthat declares the desired availability policyfor MQ; a database might scale out replicas or prepare primary/secondary failover (F#VIII) 2.Recovered Pods re-mount the same PersistentVolumes (F#IX) 3.All Pods can have logs, metrics, or other management details captured automatically by your Kubernetes provider (F#XII)
- 18. Continuous Integration & Delivery 18 1.Exposing all of your datacenter via container images with a Kubernetes orchestrator will take time for full maturity 2.Potential to dramaticallysimplify delivery of services and ongoing operations with built-in control planes for running containers 3.Start NOW to leverage these same features designed for 12-factor apps to expose more production-like environments (F#V) for your devs/LOBs
- 20. Leverage the IBM Cloud Garage Method to change how you work. 20 Provides an in-depth collectionof practices, tutorials, and architectures to help you on this journey. Completely open forum for learning at your own pace. We offer hands-onguidance and services, if needed. Defined Practices Business Benefits Technical Benefits ibm.com/cloud/garage>
- 21. Find IBM Cloud Garages worldwide 21 AUSTIN COPENHAGEN DUBAI LONDON MELBOURNE MUNICH NEW YORK NICE SANFRANCISCO SÃOPAULO SINGAPORE TOKYO TORONTO
- 22. Get your hands in the code 22 developer.ibm.com/patterns>
- 23. 232323 Free Community Edition Try Kubernetes with IBM Cloud Private ibm.biz/Try-IBMCloudPrivate>
- 24. 24 Learn more in our new book! Now available online compliments of IBM (see above)! Come see us to get it signed! ibm.biz/BdYA4i>
- 26. 26