US 2021
ENSUCKLOPEDIA OF DevUps - An improvised glossary to help us for understanding of What DevOps should not be or become!!!
This paper makes irreverent fun of some of our working experiences and shares lessons learned to avoid being a DevOps Zombie.
Please do not take it too seriously and be open to real life similarities.
JL
Jorge Luis Castro Toribio
agile coach, ntt data
Transcript
Um,
Hi everybody. My name is I'm from Peru. Uh, and today I'm very happy to be here in the DevOps enterprise summit to the 2021 USA. So I are really happy to be here. Uh, this is my first time in the bench. Um, so I hope you enjoy this talk. The title of this talk is encyclopedia of DevOps. I improvised a glossary to help us for understanding of what the ops shouldn't be or become. Okay. I said, my name is . Um, I work as a diva for a month, a year and a year coach here. You can see my contact information. So please add me to your LinkedIn accounts. It will be great to know after this talk, we can keep in touch, share knowledge and learn from each other. That would be great. So then it working. Okay. So, okay. This paper makes it your, your reverence. Uh, actually the idea of this paper is try to have fun about some experiences in dev ops. I also, at the end, we can take, we can, you know, share some takeaways about what are the lessons learned from those journeys, right? But at the end is something that we want to have fun, you know, and think about what we can do to improve the bops actually in nowadays.
Okay. Probably most of us working with IP help desk teams will be familiar to the situation properly.
Hello? I T have you tried turning it off and on again? Okay. Well the book and on the side, is it glowing? Yeah. You need to turn it on the button. Turns it on. Yeah. Yep. You do know how a book works don't you? No, not on clothes.
Hello it. Yeah. Huh? Have you tried forcing an unexpected reboots?
No. No. There you go. No, there you go. I just heard it come on. No, no, that's the music you hear when it comes on now that's the music you hear when I'm sorry. Are you from the past?
I think the drawing of the hooks have functioned by patching the system called table. So it's not safe to unload it unless another thread's about to jump in there and do it stuff. And you don't want to end up in the middle of invalid memory.
Well, why don't you come down here and make me then what you think I'm afraid of you. I'm not afraid of you. You can come down here anytime and I'd be waiting for yet. I told her.
Okay, wait, by the way, by the way, if you find some, you know, uh, you find something similar in the video from this email to reality is it was yes. A coincidence. Okay. So have you heard of something like this? Something like, so you're a right. Could you check my printer? Cause a paper jam or something like, Hey, you're sitting in your chair, right? Can you help me upgrade my windows? Or so you work as a good thing in there. Can you help me to hack my ex fake accounts or maybe cool German white developer. Right. So what is the best app to make memories? Yeah, that's happens. Right.
But why does this happen? And actually, as you can see here, we have a lot of roles nowadays, right? Friday guys, Friday people S M a D S engineer, DevOps, architects, ID, engineers, heroes, and so forth. I think these are kind of confusing thing, right? For people that is not in both ID. And also what about dev ops terms around there? I think it's the same situation. Right? We have secondary DevOps. We have Morelos analytic ops. It started white ops. It's traditional ops, but more ops and worker ops, for example, a lot of them. Right. So now imagine that you at works like ninja and engineered to each term. What happened with that? Uh, well, this has started to be explanation like a pandemic. We can have books go there in the DevOps engineer, DevOps hero that the ops petitioner and so forth, fast and furious ops freaky, for example, a lot of terms, right?
It's like a pandemic, a lot of Grammy's there. So, uh, that is stopped there actually. No, because actually the term ops is something cool, you know, make things cooler. So probably we will have more Grammys. And actually today I write about M L ops. So we are going to have more Grammys more broadly. Um, but actually it's okay to extend that fields, right? Actually DevOps is the kind of practices and culture is great to move DevOps to another and there are fields, but we need to be cared about it because we can dilute the importance of it, lose our focus on service delivery. Right. I think that is quite important. Um, so the obstacles, because a lot of benefits, but uh, we need to take care about not or produce more gram needs in this spirit of everything that we are living right now. So yeah.
For him, stop, stop complaining, do something. Yeah. Actually I do something right. Uh, that is why, you know, uh, seeing this problem, I decided to do this, the encyclopedia of DevOps, I need provide glossary to help us for understanding of what they should not be or become. Ha. So this is a grippier and superior has those contents content number one, dev ops from scratch. Number one, they, whoops, is the best way that managers can found to push their ops. We'll stop the crap and work together. Number two, they will. It's about speed of stuff. No matter if you have a goal or you have a mess. Yeah. It's about being faster. That's it. Number three, flow. Number three flow. It's enabled by buying more nonsense tooling and pressure teams to our work become unicorn developers with superpowers, which is not true. But that is what we are looking with flow. Right? Number four. Uh, there are only one kind of people, the ones who coach the rest are not part of this.
Okay. Okay. This is that classic. They will cycle. Right. And also in we have some definition of care. Number one, the plan, right? It's about planning stuff. No matter the goals, no matter the resources, no matter the people, whatever it's about planning and stuff, no matter the future, actually in this situation, we use that continuous screw up practice. The second is coach actually in this stage, basically before coding, we try to get the people, right, because we don't have it because we have these new, it technologies like cloud security and so forth. And we don't have the people there. So that is why we need to hire new people. Or maybe we need to, uh, buy some consultancy services. And also in this code part, we have the coordinators, the according to neighbor, actually we have these Facebook square videos on you, tube slack, you know, uh, Netflix and Dora games as calling the neighbors. The build part, actually the B part is something cool. Here we, the work as a team for the first time, actually I'm braid together. So we're critical can build some stuff in the test. And basically we come to normal in this part, we hate each other. Again, developers hates the service tester, hates developers. The product owner basically cares about the delivery and that's it. And we start to blame each other for the critical with that we have in this stage, basically we use continue to retesting separately.
Uh, we have also deployed right and release basically in deployer and release. We have these, uh, here, the team work as a real one for the second time ever anchors fingers hoping the production does not collapse after our deployment and the minimum of upper managers user get affected. They don't care about your users. We are good. You only care about that. Upper managers, aren't really important users. Actually in this state, we use the practice of continuous fixing via because we are going to get tons of bugs in production. And also we use continuous product, right? Tons of shitty manual stuff that enables more outfitting. Also as part of the operator monitor, can we have more of continuous fixing and less slip? You know, we're going to spend a lot of time. Fishing goes on production. You're not going to sleep. But third Margaret is, if each time do a permanent years are pissing our bosses off.
They didn't say cold in the, in our superior. Okay. Morphis low for the ups. If a staff come able to go wrong, it means it's already wrong. So we know that. So we are losing money. We are losing clients. Our people is unmotivated, um, crazy sometimes. So who cares? Right? We don't have a mechanism to feed back. So who cares about it? Honestly? Uh, but at the end, the important thing is calling stuff. You know, as, as, uh, as our requirements set basically and deliver stories, you know, that's the goal, that's it? So content number two, the obstacles and yes, this image is real. This is real. We have a lot of tools for the ops, lot of. So as part of the content, number two, we have this number one, a hard part in DevOps is make money from tools. Actually that is a kind of a mindset, right?
Uh, they will, it's about tooling and tooling is about, uh, make money, you know, fame, uh, uh, buying these, these, um, these tools, no matter if actually they are open source tools that you can use now, or you need to buy it because, uh, the end, the freemium version is more cool, you know, and is why you are going to get weird partners. So number two, open source, their ops tools are only for proof of concept for spikes or demos is not for real business. You know, if you want to scale the bops, you need to buy tools, three advantage of DevOps tools. Basically they can meet you. They can make you look smarter and cool, right? The spite of you keep the colors, doing the same stuff with the same issues again and again, but of course, in a fashion way, content number three, the people dev ops engineers.
So you hire DevOps, engineers, imagine something like this, right? But actually you get something like this because the reality is a little different from your expectation. And that is true, right? And why these have been, uh, discovered because of this, you are going to play these jobs, bridge them for you. They will ninja on your requirements are quite, uh, interesting because we are going to require people with 20 years of experience in 200 areas in Dockers, in clouds, in, in a cross engineering, uh, people with experience with Colwell, yabba, , uh, people with experience with operations that are for Booker named console, boat, ashore, restaurant management, or form people, uh, with English skill or Spanish skills, French skills or skills. Um, also people with, uh, have degrees, um, with communication skills, you skills and all that. Uh, so all the soft skills that you can imagine, that is why you don't get what you were expecting when you hire the ops.
Engineers is be real. Cause the number four, they will jail. Number one, I jail. The ops can not able to afford to have boxing. Coach is why developers test their own code and not need Koa. Please not, not need for number two. They will. It's not for, it's not if not their ops is not. If it's not sold with an expensive either from HR consulting services. Yeah. That that is alone. DevOps is about agile. It's about an expensive information. Number three, I J needs DevOps in the same way that developers need stack overflow to be really productive. Yeah. That is true. Number four, in theory, there are just as important in practice. They are not advantage of agile is allowing DevOps gets nowhere much faster. Of course, without a purpose in the middle. That's the magic of fire. You know, I want to be a ya.
Cause the number five scum, scumbling their ops. Number one support from the top. Why let the self organize teams do the work and thrips et cetera. Take the credits. Number two is filling the ups is the art of failed at scale continuously, the practice is continuous as crew up. Number three, threaten your senior dev ops engineers to lead scaling DevOps. They make your developers be in chairs. Overscale it. While they are in charge of scale down. And actually that is a reality. You can have that deal engineers with senior level, but at the end or the union's control that that's true.
Content. Number six there oops, principles and practices. Number one, flow flow is a polite way to foster pushing teams to work faster. The practices here are continuous disintegration and continuous depth, Liberty. Number two, feedback, responding to the needs of CIO's offer on her closer friends, foster fail fast to rebels, low performer reports. Braggy says, continue to screw up, continue to roll back. Read that thing. Number three, produce this experimentation and learning, try new stuff. Normally, if you have already a solution in your, in your market or solution on your enterprise for the problem, no matter it doesn't care, try new stuff because that is cool, right? Make it cards, make it complicate, right?
Contact number, filling the poops and the data information. So if you are working at enterprise, your journey leader information is going to be like this. They're going to fight very terrible fights with these legacies of what monster. I mean the way they're going to lose people. That's true, unfortunately, but of course, if you are working a startup at the beginning, it's going to be, be nice. You know, you're somebody going to be really cool, but wait for a time and you're going to become this. So please try to do the right things in the right moment. As part of the information I Gil Dita DevOps revolution began stuffed information. Yes. I know many of you, the light, I want information, but let's keep it simple. Right? Uh, demands that clear purpose, right? Teams and patients, please pay attention patients. That's something quite important. Please do. Don't be like that. Impatient rather breeder to them be like this, right? Like the inpatient caterpillar. Let's wait for your time. Right? Let's wait two weeks, three weeks, one month, one year, a year, whatever you need to wait for your information, it's going to take time, please. Don't be like these very impatient, that Wheeler don't become a monster. You need to wait for your time for the reform. That is a measure by the way, this is a child book.
Okay. So actually this encyclopedia sucks actually. So now I am more confused than before I more confused than before. Um, yes. Um, actually there is something that is happening, right. Um, if we see this moment, which is funny, right? You have changed. They were right. You used to be cool. And yeah, actually at the beginning, when DevOps came up, it was something really nice, you know, and actually it is still really nice, but you know, at the beginning it was a kind of new, new mindset, right? Working it with the app and more ops to try to work together, to improve the flow, improve product quality, improve that customer experience. And actually there is something great, but we have nowadays these roles, right? A lot of terms, a lot of tools that we have. And my something that I asked to myself is that is something that I, we need to really, or maybe it's part of a kind of, um, you know, uh, maybe a not lean way to do things.
Right. Maybe so, so that is why, uh, as you know, as part of my speech, I want to, I want you to ask you about this, right. Um, I think all, all of us are part of the community. You know, we work as hire coaches for many years and you have engineers that go there and so forth. So I think we all have some responsibility about this problem, you know, about this, uh, missing, missing interpretation about what is DevOps and what is the final goal of DevOps, which are, which the option, not about tools, right? It's not about automation only. It's about more than that. It's about culture. It's about team effect, uh, team efficiency, uh, flow quality, right. Um, and improve that the customer experience as well. So, so I want, when you ask you guys about this for, for, you know, for, um, for the idea that I think we need to, we need to foster, you know, where they work first, well adopting a product based operation model, right?
Basically we need to move our companies from project to product. Um, I think that is something really important for us nowadays, which is going to help us to, you know, to improve our productivity, improve our products, and also be ready for the changes that we are going to have in our market. Number two, measuring again, find engineering, productivity, data, adoption, continuous improvement, collaboration, right? I think we need to measure things. You want to improve it. That is quite important. And we need to game-ify engineering. I think that is something cool and integration with some Nicole as well. Number three, support and actively participate in open source communities like right? You need to share knowledge, share your coats, share what you are learning your lesson learned. You take some so forth. I think that is quite important that we need to share an easy, this is a kind of responsibility for all of us.
So please, please, we need to do it. And actually that is why I'm, I'm, I'm, I'm a cure right now. Right? My main reason to be here is share knowledge. There's what I'm trying to do. Number four, make DevOps practices attractive as a hobby, right? Then if I, it, it will drive your company to have a great team and a new avenue to revenue. And actually that is true. I think the best way that we can compare our work, our ways of working is using a kind of game approach, right? Imagine that, uh, if you come, you know, make your work as a game, it will be also because at the end you have people right, working together for a specific goal, sharing knowledge, uh, sharing experiences, working together in a collaborative way to score a goal, for example, right. I think that is something powerful, really powerful.
And I think that is why unification, it may experience something that we need to apply a move as part of our DevOps adoption. So please do it if you have a chance. So team, I just want to say thank you very much for opportunity. I'm really happy to hear. Thank you very much to, uh, DevOps enterprise summit. Uh, NYCERS secure. Thank you very much for the opportunity. I really appreciate it. Um, I hope you enjoy. Thank you very much, please remember that we will have friends so share and have more. Thank you. Thank you very much. I really appreciate it.