Remember when the internet was pure and unspoiled? In our innocence we saw the promise of renewal of the world through connecting, sharing, and creating online. We became developers and hackers because we wanted to understand how things work, to take them apart, and build quirky (and sometimes useful) things just for the pleasure of it. In the earliest decades of the Internet Epoch the Internet was a playground. We happily coded directly on production systems. And it was fine, as many Great Things were created. But the Internet has matured, and has now become Big Business. Developers have matured too, and good thing they did! So many people now rely on what we’ve built, for security, for privacy, for the paycheck at the end of the month. We matter. Maturity has come at a price though, and deploying well tested code into complex applications with polyglot teams working with heterogeneous stacks, all while maintaining compliance with GDPR, HIPAA, PCI, etc. has taken all of the childhood innocence out of the web. Now even the simplest website seems like Hard Work. In this talk I will show how we can, and should, regain our joyful demeanor, how we can use the maturity of the most innovative tools around us to start hacking like crazy again. Without regressing on agility, testing, compliance, scalability or robustness. I use the metaphor of childhood innocence to explain how the complexity of modern cloud computing, in combination with increasing quality expectations and compliancy, has curtailed the creative freedom of developers, and as a whole, organisational motivation. Together with a lack of resources and idea time, this leads to lower and slower product innovation. We are, however, at the brink of a paradigm shift in cloud computing that will give developers and hackers their mojo again. This talk will zoom into the key elements of this paradigm shift, and provide an overview of the basic concepts and operational practices of the new age of developer innocence. https://drupalcampkyiv.org/node/81

1. Platform.sh, Kiev, May 25, 2019
DevOps & the Death and Rebirth of
Childhood Innocence
Erik Evrard, Manager Northern/Eastern Europe, Platform.sh
@erikevrard
erik@platform.sh

2. Erik’s First Law of Coder Dynamics

3. Problem

4. Solution?

5. Solution?
Logic path
{

6. Solution?

7. Safe zone
Danger zone

8. DOWNLOAD
ALL THE
THINGS!

10. Part I: Developers

11. In the beginning…

12. In the beginning… computers were toys.

13. We played with them.

18. https://www.behance.net/gallery/3923327/Internet-History-Infographic

20. In the beginning…

21. In the beginning… deploying code was fun.

24. 4 kilobytes of RAM
8088 CPU
8087 Math Co-Processor

27. My first SC/MP (Simple Cost-effective
Micro Processor by national semi-
conductor) computer had:
256 Bytes

28. 4 kilobytes of RAM

29. 4 kilobytes of RAM

34. All of the keywords in C64 BASIC

45. Problem

46. Solution?

54. Goal

58. Part II: SysAdmins

68. Source: Carlos León, DevOps Moscow

69. Source: Carlos León, DevOps Moscow

70. "Why should you (a DevOps
person) be the one who fixes
someone else's code running in
production?"
Carlos León,
Adopting DevOps: Are You Still on Time?

73. Jenkins
Ansible
Docker
Kubernetes

74. Part III:The Death of Childhood Innocence

76. Equifax is disaster of such epic
proportions that their brand now
looks like this:

78. We will look at just two of the epic
moments of this saga.
•The infamous CVE-2017-5638

81. At $4,000,000,000 this person is
worth way more than Steve
Austin who is currently worth
$29,791,399*
*adjusted for inflation since 1974.

82. What was the salary of the person
who has the manual/menial job of
update this package ?

83. “Equifax CEO Richard SmithWho
Oversaw Breach to Collect $90
Million”
http://fortune.com/2017/09/26/equifax-ceo-richard-smith-net-worth/

84. Whodunnit?
Was this a fault of Gary, the developer
who didn’t apply the patch?
Was this the fault of his manager
Diane?
I posit this was the fault of faulty
thinking about software.

85. Software is a function of time.

86. Software is a function of time.
Over time two things happen to
software:
• Creating new stuff
• Repairing broken stuff

87. Software is a function of time.
Creating new stuff is voluntary.You do
it on your own rhythm.
The better automation you have the
faster and more productive you will
be.
The better your tests are … the less
you will suffer from quality
degradation and rot.

88. Software is a function of time.
Repairing broken stuff is not on your
own rhythm.
The fix for CVE-2017-5638 should
have been deployed an hour after it
was out.

89. We will look at just two of the epic
moments of this saga.
1.The infamous CVE-2017-5638
2.The brilliant, flawless response on
the part of Equifax

92. No. It wasn’t this.That would be semi-competent.

98. Is it Diane or Gary’s fault again?
No. It is about snowflakes.When
infrastructure is done by hand you
need a “change request form”.

99. There is no way in hell a “mature
enterprise” will have procedures that
are lightweight enough to roll-out a
full new project in a day.
If you need to go through IT and
Security.
If you need to fill a form.

100. In an emergency someone will “power
through”.
And when that happens, you can get
Equifaxed.

101. And when you get Equifaxed

103. Part IV:The Rebirth of Childhood Innocence

105. 2018-11-14
“Adopt a Dev-Centric Position”
Gil Zellner, From Ops to Dev and Back Again

106. ✤deploy by git push or git merge.
This triggers the entire process. Note
that this is NOT “ssh into the server and
git pull”

107. “Make release management
a functional practice
instead of a technical one”
Rene van Osnabrugge,
Continuous Delivery 3.0 – the Next Step

108. ✤ Your system (code / applications / services)
has a build process.
Embrace that fact and standardize it for every
member of the team.

109. ✤ Alway test against real data.
Use copy-on-write technologies
(eg. CEPH) to make production data
available for every test environment.

110. ✤Every build should have a testable URL
that you can send to stakeholders.

111. “Create feedback loops to
improve communication,
Involve stakeholders and
management”
Mieke Deenen,
Get Started with DevOps for
Government

112. ✤ Built code should be put onto a read-only file system.
Your operating system should be put onto a read-only file
system.
The only writable volumes should be protected from
program execution.
Many applications violate this but there are workarounds.

113. ✤ Read-only file systems lead to disposable containers.
Containers should be built, used, then thrown away.
Don’t update containers.
Don’t maintain containers.
Rebuild them and replace them.

114. “Think immutable - build
your infrastructures from
code”
Rene van Osnabrugge,
Continuous Delivery 3.0 – the Next Step

115. ✤ Developers should have some (but not total) control over the
services and environment.
For example:
runtime versions
configuration of services that affect the application
nginx redirects / rewrites
extensions, libraries, and dependencies

116. ✤ Variables that change per-environment should
be injected into the running application.

117. “If you're running your application
in a Docker container, you want to
configure that from the outside.”
Patrick Baumgartner,
Demystifying Spring Boot Magic

118. ✤ Sensitive data (keys, tokens) should also be
injected into the running application.

119. "You don't want sensitive
information in your
configuration files"
Benny Michielsen,
Secure Multi-tenant Apps with Azure and VSTS

120. ✤ Deploy and test every git branch in isolation.

121. ✤ Deploy all applications and services in the same way.
Your Node.js app shouldn’t have a fundamentally
different deployment process than your Python app.

122. ✤ Make it easy - automatic! - to practice database migrations.
Test them on every deploy.

123. ✤ Deployments should be optimized for protecting data
consistency, but this may come at a price: downtime.

124. ✤ Feature toggles are a hack. Don’t do them.
Unless there’s no other way.

125. Jenkins
Ansible
Docker
Kubernetes
Your Goal

128. Erik Evrard
erik@platform.sh
erikevrard