Jorge Luis Castro Toribio

Hi, everybody. My name is Jorge Castro. I'm from Lima, Peru. And today I'm very happy to be here in the DevOps Enterprise Summit 2021 USA. So I am really happy to be here. This is my first time in the event, so

I hope you enjoy this talk. The title of this talk is Ensucklopedia of DevUps, an improvised glossary to help us for understanding of what DevOps should not be or become. Okay, as I said, my name is Jorge Castro.

I work as a DevOps program manager and agile coach. Here you can see my contact information, so please add me to your LinkedIn accounts. It would be great to, after this talk, we can keep in touch, share knowledge, and learn from

each other. That would be great. So create the networking. Okay. So, okay, this paper makes irreverence. Actually, the idea of this paper is try to have fun about some experiences in DevOps. And also at the end, we can

share some takeaways about what are the lessons learned from those journeys. But at the end, it's something that we want to have fun and think about what we can do to improve DevOps

actually in nowadays. Okay. Probably most of us working with IT helpdesk teams will be familiar to the situation. Probably. Hello, IT.

Have you tried turning it off and on again? Okay, well, the button on the side, is it glowing? Yeah, you need to turn it on. The button turns it on.

Yeah. You- You do know how a button works, don't you? No, not on close. Hello, IT. Yuh-huh.

Have you tried forcing an unexpected reboot? 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. No, that's the music you hear when

it... I'm sorry, are you from the past? You see, the driver hooks a function by patching the system call table, so it's not safe to unload it unless another thread's about to jump in there and do its stuff, and you don't want to end up in the middle of invalid memory.

Hello? Oh, really! Really, well, why don't you come down here and make me then? Huh? What, you think I'm afraid of you? I'm not afraid of you! You can come down here any time and I'll be waiting for you.

I told her. Okay. Wait, by the way, if you find something

similar in the video, something similar to reality, it was just a coincidence, okay? So have you heard of something like this? Something like,

"So you're a software engineer, right? Could you check my printer? It has a paper jam." Or something like, "Hey, you're a system engineer, right? Can you help me upgrade my Windows?" Or, "So you work as a security engineer?

Can you help me to hack my ex's Facebook account?" Or maybe, "Cool, you're a mobile developer, right? So what is the best app to make memes?" Yeah, that happens, right?

But why does this happen? And actually, as you can see here, we have a lot of roles nowadays, right, for IT guys, for IT people. SMEs, DevOps engineers, DevOps architects, IT engineers, heroes, and so forth. I think this is a kind of confusing

thing, right, for people that is not involved in IT. And also, what about DevOps terms around there? I think it's the same situation, right? We have DevSecOps. We have Mobile Ops, AnalyticsOps, StarWarsOps, Storage

Ops, Batman Ops, and Warcraft Ops, for example. A lot of them, right? So now imagine that you add words like ninja and engineer to each term. What happen with that?

Well, this start to be exponential, like a pandemic. We can have Master SecDevOps Coder, Ninja DevOps Engineer, Storage DevOps Hero, Data Ops Practitioner, and so forth. FastAndFuriousOps Freaky, for example.

A lot of terms. It's like a pandemic. A lot of gremlins there. So, does it stop there? Actually, no, because actually, the term

ops is something cool, make things cooler. So probably we will have more gremlins. And actually, today, I read about MLOps. So we are going to have more gremlins, more

probably.But actually, it's okay to extend that DevOps to another fields. Actually, DevOps is a kind of practices and culture, and I think it's great to move DevOps to another fields. But we need to care about it because we can dilute the importance

of it, lose our focus on software delivery. I think that is quite important. So DevOps has a lot of benefits, but we need to take care about not produce more gremlins in this spirit of EverythingOps that we are living right now.

So, yeah, Jorge, stop complaining, do something. Yeah, actually, I do something. That is why, seeing this problem, I decided to do this, the Ensucklopedia of DevUps, and it provides glossary to help us for understanding of what

DevOps should not be or become. Ha ha ha. So this is Encyclopedia, Encyclopedia has those contents. Content number one, DevUps from scratch. Number one, DevOps is the best ways that managers have found to

push dev and ops to stop the crap and work together. Number two, DevOps is 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 overwork, become unicorn developers with superpowers, which is not true,

but that is what we are looking with flow. Number four, there are only one kind of IT people, the ones who code. The rest are not part of this.

Okay. This is that classical DevOps cycle. And also in Encyclopedia, we have some definitions here. Number one, the plan. It's about planning stuff, no matter the goals,

no matter the resources, no matter the people, whatever. It's about planning stuff, no matter the future, actually. In this situation, we use the continuous screw-up practice. The second is code.

Actually, in this stage, basically before coding, we try to get the people, 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 buy some consultancy services. And also in this code part, we have the code enablers. The coding enablers, actually. We have these Facebook,

Square, videos on the tube, Slack, Netflix, and Dota games as coding enablers. The build part, actually, the build part is something cool. Here we have to work as a team for the first time, actually, and pray

together so our crappy code can build some stuff. In the test, and basically we come to normal. In this part, we hate each other again.

Developers hates testers, tester hates developers. The product owner basically

cares about the delivery and that's it. And we start to blame each other for the crappy code that we have. In this stage, basically, we use continuous retesting as a practice.

We have also deploy and release. And basically in deploy and release, we have this, here the team work as a real one for the second time, ever, and cross fingers hoping the production does not collapse after our

deployment. And the minimum of upper manager's user get affected. They don't care about your users. We only care about the upper managers and really important users, actually. In this state, we use the practice of continuous fixing,

because we are going to get tons of bugs in production. And also we use continuous rollback. Tons of s****y manual stuff that enables more hotfixing. Also, as part of the operate and monitor, here we have more of continuous

fixing and less sleep. We're going to spend a lot of time fixing codes in production, so you are not going to sleep. But turn more aggressive each time the upper managers are p*****g our bosses off.

That is a cycle in our encyclopedia. Okay. Murphy's law for DevOps. If a stuff can ever 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 and crazy sometimes. So who cares, right? We don't have mechanism to feedback, so who cares about it, honestly?

But at the end, the important thing is coding stuff as our requirement set, basically, and deliver stories. That's the goal. That's it.

So content number two, DevOps tools. And yes, this image is real. This is real. We have a lot of tools for DevOps. A 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

mindset. DevOps is about tooling, and tooling is about make money, saying, buying these

tools. No matter if actually there are open source tools that you can use, no, you need to buy it because at the end, the freemium version is more cool. And that is why you are going to get with your partners.

So number two, open source DevOps tools are only for proof of concept for spikes or demos. It's not for real business. If you want to scale DevOps, you need to buy

tools.Three, advantage of DevOps tools. Basically, they can make you look smarter and cool. Right? In spite of you keep the coders doing the same stuff with the same issues again and again and again, but of course, in a fashion

way. Content number three, the people, DevOps engineers. So you hire DevOps engineers imagining 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 this happen? This happen because of this. You are going to create this job description for your DevOps ninja, and your requirements are

quite interesting because you are going to require people with 20 years of experience in Kubernetes, in Dockers, in clouds, in cost engineering. People with experience with COBOL,

Java, Python. People with experience with operations, Terraform, Poker, NginX, Consul, Bolt, Azure, resource management, Terraform. People with English skills, Spanish skills, French skills, and

other skills. And also people with master degrees and with communication skills, leadership skills, and all the soft skills that you can imagine. That is why you don't

get what you're expecting when you hire DevOps engineers. Please be real. Content number four, DevOps and Agile. Number one, Agile DevOps cannot able afford to have bugs in

code. Is why developers test their own code and not need QA. Please, not need QA. Number two, DevOps is not true Agile if it's

not sold with an expensive Agile transformation consulting services. Yeah, that is a law. DevOps is about Agile, and it's about an expensive Agile transformation consultancy service. Number three, Agile needs DevOps in the same way that developers need

Stack Overflow to be really productive. Yeah, that is true. Number four, in theory, DevOps and Agile 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 Agile. I want to be Agile. Content number five, Scaled DevOps.

Number one, support from the top while let the self-organize teams do the work and train strips, et cetera, take the credit. Number two, scaling DevOps is the art of fail at scale

continuously. The practice is continuous screw up. Number three, threaten your senior DevOps engineers to lead scaling DevOps. They make your developers be in charge of scale it while they are in charge of scale down. And actually, that is a reality.

You can have that DevOps engineers with senior level, but at the end are the juniors are going to control that. That's true. Content number six, DevOps 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 debt delivery. Number two, feedback. Responding to the needs of CIO

and her closer friends foster fail fast through robust low performance reports. Practices, continuous screw up, continuous rollback, continuous retesting. Number three, continuous experimentation and learning. Try new stuff.

No matter if you have already a solution in your market or solution in your enterprise for that problem, no matter. It doesn't care. Try new stuff because that is cool, right? Make it hard. Make it complicated. Right?

Content number seven, DevOps and the digital transformation. So if you are working in an enterprise, your journey to digital transformation is going to be like this. You're going to fight very terrible fights with this legacy software

monster. And in the way, you're going to lose people. That's true, unfortunately. But of course, if you are working in a startup, at the beginning, it's going to be pretty nice. Your software is 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 your transformation. Agile, digital, DevOps, revolution, vegan, stuff

transformation. Yes, I know many of you don't like that word transformation, but let's keep it simple, right? Demands a clear purpose, great teams, and patience. Please, patience. That is something quite important.

Please do not be like that impatient caterpillar. Do not be like this, right? Like that impatient caterpillar. Let's wait for your time, right? Let's wait two weeks, three weeks, one month, one year, six year, whatever you need

to wait for your transformation. It's going to take time. Please don't be like this very impatient caterpillar. Don't become a monster. You need to wait for your time to transform. That is the message.

By the way, this is a children's book. Okay, so actually, this encyclopedia sucks, actually. So now I am

more confused than before. I more confused than before. Yes. And actually, that is something that is happening, right? If we see this meme,

which is funny, right? You have changed, DevOps, right? You used to be cool.And yeah, actually in the beginning when DevOps came up, it was something really nice. And actually it is still really nice, but

at the beginning it was a kind of new mindset, right? To work in IT with dev and ops to try to work together to improve the flow, improve the quality, improve that customer experience.

And actually, that is something great, but we have nowadays these lot of roles, right? A lot of terms, a lot of tools that we have. And

something that I ask to myself is, that is something that we need really, or maybe it's part of a kind of maybe a not lean way to do things, right? Maybe. So

that is why, as part of my speech, I want you to ask you about this, right? I think all of us are part of the community. We work as agile coaches or managers and DevOps

engineers, coders and so forth. So I think we all have some responsibility about this problem, about this misinterpretation about what is DevOps and what is the final goal of DevOps, which

DevOps is not about tools, right? It's not about automation only. It's about more than that. It's about culture, it's about team efficiency, flow, quality, right? And improve the customer

experience as well. So I want you ask you guys about this for idea that I think we need to foster in our daily work. First one, adopting a product-based

operation model, right? Basically, we need to move our companies from project to product. I think that is something really important for us nowadays, which is going to help us to

improve our productivity, to improve our products, and also be ready for the changes that we are going to have in our market. Number two, measuring and gamifying engineering productivity, data adoption, continuous improvement and collaboration. Right? I think we need to measure things.

We want to improve it. That is quite important, and we need to gamify engineering. I think that is something cool, and gamification is something cool as well. Number three, support and actively participate in open source communities, right? You need to share knowledge, share your codes,

share what you are learning, your lesson learned, your takeaways and so forth. I think that is quite important that we need to share. And this is a kind of responsibility for all of us. So please, we need to do it. And actually, that is why I'm here right

now, right? My main reason to be here is share knowledge. That is what I'm trying to do. Number four, make DevOps practices attractive as a hobby, right? Gamify it.

It will drive your company to have great teams and a new avenue to revenue. And actually, that is true. I think the best way that we can convert our work, our ways of working, is using a kind of

game approach, right? Imagine that if you can make your work as a game, it will be awesome because at the end you have people, right, working together for a specific goal, sharing knowledge,

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 gamification in my experience something that we need to apply and move as part of

our DevOps adoption. So please do it if you have the chance. So team, I just want to say thank you very much for the opportunity. I'm really happy to be here. Thank you very much to DevOps Enterprise Summit

organizers. Thank you very much for the opportunity. I really appreciate it. I hope you enjoy my talk. Thank you very much. Please remember that we all have dreams, so share and help more. Thank you. Thank you very much. I really appreciate it.