Let’s talk about BBQ and DevOps, how cooking BBQ and DevOps are connected, or at least, how It’s for me, and how it ended being my new adventure and may be a future company.

Let’s begin with some history… I was born in a region of Brazil where “churrasco” (a.k.a Brazilian BBQ) is a mandatory lunch for Sundays, basically you have it for almost all Sundays of the year, and also, it’s common to have other two or three “churrascos”, but how I’ve ended in American BBQ, and yes… it starts with my work. Yes and it’s not in a meeting on some restaurant, but for a contact and chance to have worked with people from Europe and EUA and specially with North Americans, that made me pursue a move out from Brazil.

Thinking on moving out from Brazil, I decided to visit Texas as that one would be closest to Rio Grande do Sul in behavior and love for BBQ. While I was there, once I asked a suggestion of some restaurants that I should try, one of them was Salt Lick in Driftwood, that was my first contact with American BBQ culture. Few years later I decided to replace my Brazilian BBQ “pit” for a hybrid PIT, half smoker, half grill, that was in 2018, also that was the year when I’ve served the biggest amount of people that I’ve ever served.

Two years later, many many BBQs (smoked ones) later and two smokers, I can say honestly that I was lucky on that one, even that I considered it perfect (beautiful bark and taste).

Now you (reader) should be asking what does this have to do with DevOps, I can say everything.

DevOps, at least for me (should be for everyone), is a culture to deliver faster, safer and better, basically when you make BBQ you should be worried about your delivery on time, safer and better too. Just to make an analogy.

On IT the input for DevOps is basically the code, it must be transformed and delivered in the best way possible using a lot of consumables and tools, just like BBQ, the input is the meat then you have to transform it using a lot of consumables and tools, and for both… always paying attention to the results for a fast feedback.

You will always have goals, for BBQ, the bark, the tenderness, the taste… Those will produce in you a great satisfaction when you see people eating it and loving it, that’s the main purpose! During the process you connect people, make friends and a lot of food. BBQ requires you to manage non virtual things like wood, fire, meat you control the temperature things that you touch, you feel, you taste. Usually is a work done by a pitmaster and his small crew.

In such a way, DevOps have their own goals, people working together to deliver a better product, faster, reliable, secure. Beautiful in his own way, moving the gears of the world. Different from BBQ here we want to have things faster, on BBQ things have their own timing the quality comes first, not that the code that arrives to a pipeline should not be good, nowadays it must first work, not necessarily be the beautiful one, DevOps culture and techniques must make sure that it works (at least).

Just to compare another aspect of BBQ and DevOps, both have pipelines, and as I always say not necessarily automated nor described, but somehow comes to a working or beautiful end.

When I’m preparing my pork ribs at Father’s BBQ my pipeline (simplified version) starts when I get them from the meat supplier, then I have some wait time (for those used to see value stream maps) which could be up to two weeks. Then the process really comes to my control, moving it from the freezer to the refrigerator for a slow defrost, around two days later, I clean it up and season. Next day I wake-up around 5am to start smoking it, and the delivery process begins around noon, and usually finishes 1 hour late. At the end it’s not that different from a software pipeline, except that I can cut my fingers off and burn my hands.

For those who are not used to a DevSecOps pipeline, the idea is simple (simplified version too). The developer receives the specification, produces the code, pushes it to some repository. That code is submitted to some kind of build procedure, should be tested locally to make sure that it’s not smelling bad… If everything goes well, it then should be delivered to the end user.

For both we have a huge number of tools and consumables, BBQ: knife sharpener, huge number of different purpose knives, peppers, salt, spices, thermometers, wood, charcoal, cloths… for DevSecOps the list can be huge, but just to simplify: code repository, code quality analysis tool, testing suite, pipeline orchestrator, security analysis suites, deployment tools…

See… There is not much difference from the delivery perspective, both should always focus on the client.

Since I started Father’s BBQ with one or two sales a month in the last 12 months at least, I only had two services that weren’t sold out, none of them are related to quality or bad quality… both were related to the dates and late announcement…

Some friends ask me about if one day I’ll focus only on BBQ. Right now I don’t know the answer… and usually I answer… if you had asked me two years ago if I would sell some smoked meat to someone, I’d probably had answered NO. But today after smoking for more than 2 years, and spending 4 days a month working to serve some ribs, where I use all the techniques of fast feedback that I learned and improve everyday the combination of tools, the study, the pursuit of perfect bbq. I can just say…. that makes my both works better, nowadays one complements the other.