This document discusses the concepts of cloud native and why it is important. It defines cloud native as utilizing containers, dynamic management of infrastructure and applications, and building applications as microservices. The document provides examples of companies like the Financial Times and Gigaset that improved reliability, deployment velocity, and efficiency by moving to a cloud native approach using containers and microservices. It also discusses how cloud native relates to existing DevOps practices and the history and evolution of concepts like containers, orchestration, and microservices.

1. What is Cloud Native
and why should I care?
Tomasz Tarczyński, Gigaset
@ttarczynski

2. @ttarczynski
Cloud Native

3. Gigaset elements
@ttarczynski

4. Gigaset elements
@ttarczynski

5. Gigaset elements
@ttarczynski

6. Requirements of IoT Backend
1. Reliability
@ttarczynski

7. Requirements of IoT Backend
1. Reliability
2. Velocity
@ttarczynski

8. Evolution of IoT Backend
1. Containers
@ttarczynski

9. Evolution of IoT Backend
1. Containers
2. Microservices
@ttarczynski

10. Evolution of IoT Backend
1. Containers
2. Microservices
3. Automation
@ttarczynski

11. Evolution of IoT Backend
1. Growing number of apps
@ttarczynski

12. Evolution of IoT Backend
1. Growing number of apps
2. Automation with puppet
@ttarczynski

13. Evolution of IoT Backend
1. Growing number of apps
2. Automation with puppet
3. Puppet is host-centric
@ttarczynski

14. Alternative
Need for orchestration
@ttarczynski

16. How is it defined?

17. WHY Cloud Native?

18. Case Studies

19. Case study: Financial Times
https://container-solutions.com/study-tech-transformation-financial-times/

20. Case study: Financial Times
Before After Change
Rollback ratio 20% 0.1% 200x
Lead time
Deployment
frequency
https://container-solutions.com/study-tech-transformation-financial-times/

21. Case study: Financial Times
Before After Change
Rollback ratio 20% 0.1% 200x
Lead time 120 days 15 min 4000x
Deployment
frequency
https://container-solutions.com/study-tech-transformation-financial-times/

22. Case study: Financial Times
Before After Change
Rollback ratio 20% 0.1% 200x
Lead time 120 days 15 min 4000x
Deployment
frequency
12 /
year
2000 /
year
170x
https://container-solutions.com/study-tech-transformation-financial-times/

23. Case study: Financial Times
https://kccnceu18.sched.com/speaker/sarah.wells1

24. Case study: Gigaset
Before After Change
Rollback ratio 40% 1% 40x
MTTR
Lead time
@ttarczynski

25. Case study: Gigaset
Before After Change
Rollback ratio 40% 1% 40x
MTTR 8 hours 15 min 32x
Lead time
@ttarczynski

26. Case study: Gigaset
Before After Change
Rollback ratio 40% 1% 40x
MTTR 8 hours 15 min 32x
Lead time 60 days 2 hours 240x
@ttarczynski

27. 2018 State of DevOps Report
https://cloudplatformonline.com/2018-state-of-devops.html

28. WHY Cloud Native?
@ttarczynski
1. Reliability

29. WHY Cloud Native?
@ttarczynski
1. Reliability
2. Velocity

30. https://www.slideshare.net/AmazonWebServices/dmg206

31. WHY Cloud Native?
@ttarczynski
1. Reliability
2. Velocity
3. Efficiency

32. HOW?

33. Containers

34. Dynamic Management

35. Microservices

36. Cloud Native:
A Technological Paradigm
1. Containers
2. Dynamic Management
3. Microservices
@ttarczynski

37. 12 Factor Apps
https://12factor.net/
# Factor
I Codebase One codebase in version control, many deploys
II Dependencies Explicitly declare and isolate dependencies
III Config Store configuration in the environment
IV Backing services Treat backing services as attached resources
V Build, release, run Strictly separate build and run stages
VI Processes One or more stateless processes

38. 12 Factor Apps
https://12factor.net/
# Factor
VII Port binding Export services via port binding
VIII Concurrency Scale out via the process model
IX Disposability Fast startup and graceful shutdown
X Dev/Prod parity Dev / stg / prod as similar as possible
XI Logs Treat logs as event streams
XII Admin Processes Admin tasks as one-off processes

40. Cloud Native: Infrastructure
Useful Abstractions
@ttarczynski

41. Cloud Native: Infrastructure
Infrastructure
Managed by Software
@ttarczynski

42. Cloud Native: Applications
Applications
Managed by Software
@ttarczynski

43. Cloud Native and DevOps
Should we forget about DevOps?
@ttarczynski

44. Cloud Native and DevOps
DevOps
“A cultural and professional movement”
“Focused on high velocity”
Adam Jacob: https://chef.github.io/devops-kungfu/

45. Cloud Native and DevOps
Coulture
Automation
Measurement
Sharing
John Willis: http://itrevolution.com/devops-culture-part-1/

46. Coulture
Automation
Measurement
Sharing
Cloud Native and DevOps
John Willis: http://itrevolution.com/devops-culture-part-1/

47. Cloud Native
Is this all new?
@ttarczynski

48. Cloud Native: History
@ttarczynski
Containers:
2006 – cgroups started at Google
2008 – cgroups in Linux kernel mainline (v2.6.24)
2008 – LXC (Linux Containers)
2013 – Docker

49. Cloud Native: History
@ttarczynski
Orchestration:
200X – Google Borg
2009 – Mesos project started
2010 – Twitter using Mesos
2014 – Kubernetes release

50. Cloud Native: History
@ttarczynski
Cloud / Microservices:
2006 – AWS with: S3, SQS, EC2
2006 –“You build it, you run it” – Werner Vogels
2010 – Amazon moves all retail to AWS
2010 – Netflix moved to AWS
2010 – Netflix OSS started
2011 – 12 Factor apps

51. Cloud Native: Today
@ttarczynski

52. Thanks!