Continous Delivery of Your infrastructure , why it matters, my Devops Meetup Prague online talk

1. GitOps done Right
Kris Buytaert
@krisbuytaert

2. Continuous Infrastructure
First
Kris Buytaert
@krisbuytaert

3. @krisbuytaert
Kris Buytaert
●
I used to be a Dev,
●
Then Became an Op
●
CTO and Open Source Consultant @inuits.eu
●
Everything is a freaking DNS Problem
●
Evangelizing devops
●
Organiser of #devopsdays, #cfgmgmtcamp, #loadays,

4. @krisbuytaert
devops (<)> continuous delivery

5. @krisbuytaert
CI
In software engineering, continuous integration (CI) is
the practice of merging all developers' working copies to
a shared mainline several times a day.[1] Grady Booch
first proposed the term CI in his 1991 method,[2]
although he did not advocate integrating several times a
day. Extreme programming (XP) adopted the concept of
CI and did advocate integrating more than once per day

6. @krisbuytaert

7. @krisbuytaert
Continuous DISIntegration

8. @krisbuytaert
Why Ops First ?

9. @krisbuytaert
For years we've tolerated humans to make structural manual
changes to the infrastructure our critical applications are running on.
Whilst at the same time demanding those critical applications to go
through rigid test scenarios.
Who let this happen ?

10. @krisbuytaert
history of devops
●
Europe :
– Starting from Operations,
– Improved Artifact Quality,
– Less pain / stability
●
US :
– Push from development
– Faster Platforms
– Faster change

11. @krisbuytaert
NoOps & YOLO Ops
●
Startup
●
VC
●
Exit Strategy
●
6-9 months
●
Actual Business
●
Real Customers
●
Survival
●
6-9 years

12. @krisbuytaert
3 Different Transition Cases:
Startups & Multinationals

13. @krisbuytaert
Case 1: Chaotic Ops
●
Complete Chaos
●
10% reproducibility
●
CI infra hides under a dev’s desk
●
Ops in Debug Mode
●
No standardization
●
Apollo Moment

14. @krisbuytaert
Case 1: T0+3months
●
Build a Reproducible Jenkins + Slaves
●
CI for Puppet by OPS
●
Test your code
●
Promotion Stage for Infrastructure Code
●
Split config out of code
●
Keep delivering updates

15. @krisbuytaert
Case 1: T0+6 months
●
Stack Alignment
– 1 jdk, 1 jboss , ...
●
Project Dolly :
– Puppet for everything
●
90% reproducibility
●
Standardized Builds
●
Increased Test Coverage
●
Java Developers contribute to Infra Tests

16. @krisbuytaert
Case 1: Conclusion
●
Started with preparing ops folks to automate
●
Learned the same tools developers use
●
Developers help the ops folks to improve
●
Collaboration + Progress ++

17. @krisbuytaert
Case 2: CI by Devs
●
Some devs have tests
●
Some dev teams have “CI”
●
Deployments are Chaos
●
Ops nags about Artifact Quality

18. @krisbuytaert
Case 2: T0+18 months
●
Found the first ops skills in the org
●
Mostly overworked Brent’s
●
Move them out of their offices
●
Focus team
●
Teach Agile
●
Adopt IAC (puppet)
●
First Successes
●
Move people back to teams

19. @krisbuytaert
Case 2: T0+24 months
●
Grey Beard Ops person has converted to Agile
Evangelist
●
Preaches Kanban (for ops) and Scrum
●
Writes Test for his Code
●
Coaches developers to achieve CI/CD

20. @krisbuytaert
Case 2: Conclusions
●
Starting with dev delayed the collaboration for
1+ year
●
Ops were fire fighting and not involved
●
Once ops resources were dedicated
collaboration and quality improvement started
to happen

21. @krisbuytaert
Case 3:Ops NOT involved
●
Large Transformation
●
“devops” team dictates tools they have never used them
selves
●
Tools they as a team don’t need themselves
●
Developers complain about unusable tools
●
Developers complain about broken tools
●
Tools enforce a manual process

22. @krisbuytaert
Case 3: 2 years later
●
Average “devops” role stays for 2 months , then leaves
●
Senior IT management has left (2x)
●
Only In house analysts remain
●
Mostly contract based developers
●
Failing Cloud Strategy
●
Legacy Container Ecosystem

23. @krisbuytaert
Case Conclusions
Earlier involvement of the Ops Skills creates
much higher success rates , and smoother
Continuous Delivery adoption

24. @krisbuytaert
Why ops first ?
●
You can’t support / understand what you don’t
do yourself
●
Code = Code
●
Unblock delivery
●
Unblock provisioning
●
Metrics & Monitoring Build in

25. @krisbuytaert
Culture vs Tools

26. @krisbuytaert
Culture Hack
Set up CI/CD for your CI/CD infrastructure
first, If the people running your infra don't
know how CI/CD works , how do you
expect them to support / teach your
application teams ?

27. @krisbuytaert
Not Continuous Deployment
●
@stahnma @#devopsdays Ohio

28. @krisbuytaert
A CI Ecosystem
●
Version Control
●
Deployment
●
Build Tooling
●
Artifact Repository
●
Code Coverage Tooling
●
Testing Tools
How many of those tools is your average ops person used to
use ?

29. @krisbuytaert
Arguments against CI
●
Setting up the stack costs time
●
U don’t have tests anyhow
●
Operations and development are
different budgets
●
One shot projects , fire and forget
●
...

30. @krisbuytaert
Infrastructure as Code
●
Treat configuration automation as code
●
Development best practices
●
Model your infrastructure
●
Version your cookbooks / manifests
●
Test your cookbooks/ manifests
●
Dev/ test /uat / prod for your infra
●
Model your infrastructure
●
A working service = automated ( Application Code + Infrastructure Code + Security +
Monitoring + ... )
PS. Converting Bash to Yaml != IAC

31. @krisbuytaert
Continuous Integration
Continuous integration (CI) is the practice, in software engineering, of merging all
developer working copies with a shared mainline several times a day. It was first
named and proposed as part of extreme programming (XP). Its main aim is to
prevent integration problems, referred to as "integration hell"
(WikiPedia)
Does the app you are deploying still work ?
Did you break your puppet / chef code ?

32. @krisbuytaert
Pipeline As Code
●
Generate Pipelines / Jobs based on config files
●
Build libraries
– CheckoutJob
– DeployJob
– PackageJob
●
Use Groovy / JobDSL to generate PipelineDSL

33. @krisbuytaert
On Prem vs Cloudnative
●
Puppet, Chef, Ansible,
Terraform
●
Kvm/OpenStack/..
●
VPN, Firewalls
●
Pipelines & Pipelines
●
Standardisation
●
Security
●
Monitoring
●
Puppet, Chef, Ansible,
Terraform
●
EC2 etc ..
●
VPC, SG
●
Pipelines & Pipelines
●
Standardisation
●
Security
●
Monitoring

34. Todays IAC Requirements
●
3 types of tools needed
– Provisioning :
●
Create me an instance of application X
– Container instance
– VM instance
– K8s Cluster
– Service X configuration via API
– Desired state
●
Ensure that this file present / service is always running
●
With these permissions
●
User Removed
●
Always / Verified
– Orchestration
●
Non frequent
●
Trigger action X on resource Y based on characteristics A,B and or C
●
First do X here then do Y there
●
One off actions

35. @krisbuytaert
Large Challenge
●
How do you automatically spin up a K8s setup in an
existing Ecosystem
●
No vendor Lock-in, Open Source only ?
●
How do you deploy applications on K8s , reproducible,
not using 30 bash scripts
●
Container Ecosystem is no where close to the level of
automation / reproducibility which we are used in VM’s

36. @krisbuytaert
Continuous Delivery of your Automated
Infrastructure
vs
GitOps

37. @krisbuytaert

38. Contact
Inuits
Inuits
Essensteenweg 31
Essensteenweg 31
Brasschaat
Brasschaat
Belgium
Belgium
891.514.231
891.514.231
+32 475 961221
+32 475 961221
Kris Buytaert Kris.Buytaert@inuits.eu
Kris Buytaert Kris.Buytaert@inuits.eu
Further Reading
Further Reading
@krisbuytaert
@krisbuytaert
http://www.krisbuytaert.be/blog/
http://www.krisbuytaert.be/blog/
https://inuits.eu/
https://inuits.eu/