1. The Basics of DevOps November 21, 2015 / Rakuten Technology Conference Ryuzee.com Ryutaro YOSHIBA (a.k.a @ryuzee)
2. Self Introduc.on Ryutaro YOSHIBA (@ryuzee) Ryuzee.com TIS → Startup → NRI → Startup → AWS → ??? ExperOse: DevOps・Cloud・ Agile・Organiza.on・Sushi
3. I’m going to upload this deck at my website (hJp:// www.ryuzee.com/) soon aMer the presenta.on finished. You do not need to write down the text in this deck.
4. Current Situa.on • Business changes faster • IT becomes a key element for business • In 2015, you guys may be using “GitHub” (2008), “Dropbox” (2008), “Evernote” (2008), “Slack” (2014), Uber (2010), Airbnb (2008) , SORACOM (2015, Japan)
5. Muda (Waste)… 64% Always 7% SomeOmes 16% Never 45% OWen 13% Rarely 19% of all features were rarely or never used. You can imagine it by taking your computer’s buil.n soMwares’ usage into considera.on… The Standish Group “Chaos” report 2002
6. Seven types of Waste • Waste of over-producOon • Waste of wai.ng • Waste of transporta.on • Waste of processing • Waste of inventory • Waste of mo.on • Waste of making defects
7. Hey!! Our team can develop lots of new features per each sprint. We need to avoid building unused features. It will increase cost, complexity, term for investigating whole application/fixing bugs…
8. It’s hard to predict what customers really want, whether a feature is used by customers and whether there is a room to improve the business results. hJp://hrnabi.com/2015/11/05/9552/
9. It’s difficult to know right things or future in advance. It’s important to have a capability to catch up with fast changes.
10. Building fast feedback cycle This is not only for Startups!! d Learn Bu il s a e M e r u
11. Waterfall (V Model) Requirement Defini.on Acceptance Test t e g o t e m Basic Design . g d n n o A l . s e e r k a a t w M It o s g d n i n k fi r u o o w y f y o l l g n i finaDetailed Design d n a t s r e … d s t n n u e s i m m e r i u q e r e th System Test Integra.on Test Coding / Unit Test
12. So that, (Big) Waterfall process does not work in fast changing areas.
13. Agile methodologies become mainstream State of Agile Survey 2014 (c)VersionOne
14. Current Challenges • Delivering good soMware to customer is cri.cal for business • However, the speed of delivery is too slow and error prone (especially in tradi.onal or large companies…) • This causes the lost of chance and money in business • Or you have your own issues • IT oMen becomes BoJleneck
15. The origin of DevOps • At Agile 2008 Conference, Patrick Debois (also know as the developer of several useful tools such as veewee / sahara) made a presenta.on “Agile Infrastructure & Opera.ons”. • At 2009 O’Reilly Velocity Conference, two Flickr employees—John Allspaw and Paul Hammond made a presenta.on known as “10+ Deploys per Day: Dev and Ops Coopera.on at Flickr.”
16. You can watch the full presenta.on on YouTube!! Go to hJps://www.youtube.com/watch?v=LdOe18KhtT4
17. Ops who think like devs. Devs who think like ops. However…
18. Conflict between Dev and Ops • Differences of mission and responsibility (Who decides them…? Reasonable?) • It’s not my business (Says who?) • Silo • It creates overhead
19. You have responsibili.es to have the applica.on up and running on your server!!! DO NOT BLAME ME! Why don’t you build your applica.on with solid quality? We got tons of calls from monitoring system at all hours of the night!!!
20. You can find same situa.on in your organiza.on • This code was wriJen by others. Thus I do not know XX • This task is owned by XX-san and I do not have to be blamed • This is defined by rule. Thus we need to follow it… • Other division is always slow. Then we are forced to be delayed… • We have other tasks…
21. “The major problems of our work are not so much technological as sociological in nature” –Tom DeMarco
22. Overhead of Silo • You are using lots of .me to communicate with other divisions • (of course, communica.on is important… However the content of the communica.on is about procedure). • It results in not using your .me for the direct values to customers.
23. “If managers spend more than 25% of their .me in mee.ngs, it is a sign of poor organiza.on.” –Peter F. Drucker
24. • A team had beJer to have full func.onali.es to deploy soMware to customers with .mely fashion without any hand-off • Change team structure or decouple .ghtly-coupled if possible
25. Werner Vogels, CTO, amazon.com You build it, You run it hJps://www.flickr.com/photos/interopevents/6217288899/
26. Two Pizza Rule. You need to keep a team small enough to be full stomach by 2 pizza
27. • Amazon replaced verbal communica.on to API when provisioning servers for amazon.com • By doing that, they can eliminate the communica.on overhead and shorten necessary dura.on for provisioning
28. I imagine you are considering “You’ve been talking about organiza.on. However…. What is DevOps?”
29. DevOps is not a silver bullet Hey guys!! When you adopt our great new tool, you can easily achieve DevOps!! It is too black humor to laugh at it…
30. DevOps is not a Framework Hey men!! I heard from other company’s CEO that his company adopted DevOps and met with success. We have to do the same!! Bring us this framework ASAP!! I’m willing to use budget!! It is too black humor to laugh at it…
31. DevOps is not only about automa.on DevOps?? Finally you see the light?? Tired of wai.ng…. Let’s start wri.ng automa.on code!! We have lots of things to be automated!! It’s not enough…
32. DevOps intends to achieve business results, to enhance business agility and to avoid or reduce business risks by leveraging culture and tool.
33. DevOps includes CLAMS **** Important **** • Culture • Lean • AutomaOon • Measurement • Sharing
34. Lean Thinking • Look at whole value stream across organiza.on • If your team reduces your team’s cycle .me, it does not directly mean the reduc.on of whole lead .me • There’s a possibility to exist BoJle Necks… • You need to learn Theory of Constraint (ToC)
36. Where is BoJleneck in your process? Case:1 WIP: 2 2 day / item WIP: 4 3 day / item WIP: 6 2 day / item WIP: 1 20 day / item Analysis Develop Test QA / Deploy Dev $$$$ Ops In this case, lead .me is so long due to 20 days for QA and deploy. Throughput is quite small. If you improve the producOvity of Dev team, it does not affect on lead Ome and throughput…
37. Where is BoJleneck in your process? Case:2 Defect… Decline to deploy. Waiting for fix… Analysis Develop Dev Test QA / Deploy $$$$ Ops In this case, lead .me is so long due to poor quality of the soMware. Although you automated deploy procedure, it does not increase the number of features to deploy.
38. TOYOTA Produc.on System (TPS) said… 前工程は神様 後工程はお客様 • Appreciate your previous steps • Customer means both end customers and internal customers • Build quality in and do not pass defects to next steps
39. Why we need DevOps • The business changes fast • However, you need to iden.fy your reasons of the need of DevOps • “DevOps is a trend and popular” is one of the worst answers • You need to find your own objec.ves
40. Organiza.onal structure affects on architecture Conway’s law organizaOons which design systems ... are constrained to produce designs which are copies of the communicaOon structures of these organizaOons - M. Conway You may be interested in Microservices. However, whether you are able to apply Microservices Architecture is depending on your organiza.onal structure. DO NOT embrace the illusion of it.
41. Typical steps to apply DevOps • Look at whole process • IdenOfy problems and challenges about the relaOonship between business and IT or boalenecks that let you slow down • PrioriOze them • Consider Flow, To-Be model, metric to confirm the status, schedule, formaOon per each item • Keep doing above (PDCA cycle) • It means DevOps needs to be implemented by an Agile way
42. Priori.ze your ac.on items • You may be able to find piles of poten.al ac.onable items. However you can not do these items all at once because of resource, cost and your daily jobs. • Changing lots of things may let you, your team, your organiza.on and your customers confuse. In addi.on, It’s difficult to iden.fy the effec.veness of your ac.on.
43. Con.nue to improve your process hJps://www.flickr.com/photos/gkirk/3351943143/ • Focus on both whole value stream and things around you. Retrospec.ve is one good approach regardless of your development method. • Use metrics data to confirm the progress towards goal
44. DevOps needs Leadership and Sponsorship All of you are a leader. In addi.on, DevOps is quite related to organiza.on and then execu.ve sponsorship must be required. You can improve things around you and it may increase business agility. However improving whole system gives you quite large benefit.
45. Building excellent team Diversity will accelerate your improvement.
46. Having enough technical capability • Skill map in a team shows the capability of deploying soMware by their own, risky area, things to learn and so on. RSpec Harada ○ Yoshiba ◎ Sato ○ Kawagu. ・ Ito ・ Yamaguchi ○ HTML5 jQuery Fluentd Elas.cSea MongoD rch B ・ △ ・ △ ◎ ◎ ★ AWS Chef Circle CI △ △ △ ◎ ◎ △ ◎ Go ◎ ・ ◎ ・ ◎ ◎ △ ◎ △ Git ◎ ○ ◎ ○ ○ ・ ◎ ★ ◎ ★ : Ace / ◎ : Good / ○ : Able to do / △ : Able to do with help / Blank : Not able / Want to learn :・
47. Adop.ng tools • Clarify the reason(s) to use selected tools • Select major tools • Do not adopt lots of tools simultaneously • Train users • Maintain tools by your own
48. Where to start using tools? First you need to do is using Basic technical elements such as version control, automaOng tests, conOnuous integraOon.
49. Recap: DevOps consists of… • Culture • Lean • AutomaOon • Measurement • Sharing
50. Thanks for coming!! Any questions?
