DevOps interview : Part 2. Yasunobu Kawaguchi and Kotaro Ogino on Challenging for silos

DevOps guys always encounter the "silo" problem. How do they conquer it? Stay tuned!

	Tsuyoshi: Then, could you tell me about the "People" element?
	Kotaro: In terms of opinion, we had some conflict between Devs and Ops.
	Tsuyoshi: How did you kaizen it?
	Kotaro: We showed them some positive outcome. After automating their system testing, They gradually understand the merit. They could notice problems quite quickly. Then they said that it is cool.
	Eiji: Did you have any trigger for the change?
	Kotaro: Yes. It's a "Smoke test". We wrote a simple smoke test for the search engine.　We have a problem that non-Japanese developers didn't notice about Japanese processing. It is very difficult for them to understand the Japanese character's problem. However, it is crucial for the Japanese market. We added Japanese-character-testing for the smoke test. Then they understood the importance of testing.
	Tsuyoshi: It is very hard to notice the problem related to foreign languages. Do you have any challenges related to Dev and Ops? /p>
	Kotaro: These are separated by division. Ops guys learn about infrastructure as code and all infrastructure configurations are managed and treated in Continuous Integration manner.
	Tsuyoshi: Splendid!
	Yasunobu: Now we have a DevOps meeting , on a regular basis to promote DevOps.
	Kotaro: Ops uses infrastructure as code related technologies. However it was separated from Dev's system. Now they collaborate and integrate their own automation tools.
	Tsuyoshi: Interesting. Both silos have high technical practice but did not collaborate. A lot of companies struggle with silos between Devs and Ops. Why do we have these silos?
	Tsuyoshi: Interesting. Both silos have high technical practice but did not collaborate. A lot of companies struggle with silos between Devs and Ops. Why do we have these silos?
	Kotaro: I think we need to understand each other. Devs know about TDD and CI but Ops does not. Now infrastructure as code is coming, it is very common to fire chef recipes from Jenkins. Same thing happens on Dev side. System testing was executed only by the Ops person.
	Yasunobu: I think a silo is just a structure. You may think "Hey, what a silo. It is ridiculous!" but the structure must have been reasonable in the past. According to the progress of technologies, it would have become a silo.
	Tsuyoshi: What do you mean?
	Yasunobu: We had someone who is in charge of operating tapes for a computer. It was effective at that time. Now we can easily back up a system, now we don't have that role. It is my assumption that it is called "silo" when some technologies change something.
	Tsuyoshi: By the way, you guys are Dev guys except for Yasunobu, right? From the Dev's view point, what do you think about the ops guys?
	Kotaro: Generally speaking, I want more communication with Ops guis. It was really great to see the presentation from Ops guys in Dev's event.
	Tsuyoshi: What do you learn in DevOps meetings?
	Kotaro: Well, We don't know much about each other. Ops don't understand what Devs need and what they want. They can solve real problem of software development by Infrastructure as Code.
	Eiji: I think some of them don't understand the vision like "who will be happy from this project".
	Kotaro: They are now changing. They start accepting the passion of Devs.
	Eiji: Now we are about starting to have mutual understandings.
	Yasunobu: An Ops person has craftsmanship. Like a master carpenter. Their job is about to creating stable environments and operating it safe and sound. It is really important. That is why they keep a high-level of self-control. So they try to make it perfect. They design and test it. Then, they hand you an environment, saying "Hey, now you can use this!" with full confidence. However, no matter how hard they try, it may include some small problem. Then the Dev guys say, "This is rubbish. They are not professional and perfect at all."
	Tsuyoshi: Everyone makes mistakes. I think.
	Yasunobu: Yes. So Ops guys try to polish perfectly. This hands-off-model leads to a boring job to an Ops person where they need just follow the Dev's opinion. It is not cool. But from Devs point of view, Ops don't need to solve a small problem from the start. That is why, Devs need to understand the catharsis of Ops. We need to understand each other's passion.
	Kotaro: I have an experience related to this topic. At first, we called it non-functional testing, then we changed the name into operability testing, then Ops guys started to give us requirements related to operations.
	Tsuyoshi: Tell me more about it.
	Kotaro: When we called it non-functional testing, they thought the project was led by Devs and they didn't have a right to give a requirement. After we called it Operability testing, they noticed that they can provide some requirements.
	Tsuyoshi: It must be a breakthrough. Cool. By the way, if you were Ops guys, what is an Devs problem?
	Everyone: ...
	Tsuyoshi: I think it is very difficult to cover all learning areas, so we need to collaborate with others.

Next

They told me about the Real-World-Example of DevOps. This problem occurs everywhere and it is still the most difficult problem to adopt DevOps. The next blog post will be the last part of the interview of Rakuten guys!