TL;DR: I’ve joined the OpenShift Bare Metal team at Red Hat. It feels a bit like coming home, back to OpenShift, and forward with Golang, into the gritty, fun world of image-based OS, provisioning, and at-scale cluster plumbing.

I started on OpenShift before it was “Kubernetes-shaped”

Twelve-plus years ago, OpenShift wasn’t the Kubernetes platform you know today. It was a Ruby-powered PaaS with cartridges for your favorite runtimes and databases. I even hosted my blog there for a while (yes, the one you’re reading now has ancestors living in little gears). You’d rhc your way to a running app and feel like a wizard. It was opinionated, developer-first, and, most importantly for me, an invitation to build.

Consulting and the OpenShift 3 years

When I joined Red Hat as a Middleware/AppDev consultant, I lived at the intersection of middleware and OpenShift CI/CD. That meant OpenShift 3: Kubernetes under the hood, templates, Jenkins pipelines, quirky edge cases, and lots of real customer problems. Consulting taught me speed, empathy, and preparation (read: build the deck before you walk into a room expecting 3 people and find 40). It also cemented my love for platforms that help teams ship better software, faster.

OpenShift 4 changed the shape of the platform

Then came OpenShift 4: image-based nodes, Operators everywhere, and a platform that leaned into being a product, not just a distribution. It felt like the moment OpenShift fully embraced its Kubernetes DNA while keeping the Red Hat polish: opinionated, secure-by-default, and boring in all the right places.

My zig-zag path inside Red Hat (and why it matters now)

I’ve worn a few hats here: consultant -> training -> engineering. On the engineering side I first joined the Kafka/Strimzi team, which I wrote about in “Back to Engineering: An engineer’s gainings through time.” Later I moved to Ansible Lightspeed, which became an adventure of its own and earned a sequel article: “Back to Engineering Vol. 2: A Path to Wisdom.” Both journeys stretched different muscles: platform building, developer tooling, content, and community, while keeping me close to the problems that real teams face every day.

So… why Bare Metal now?

Because the layers I want to understand deeply are the ones just below most people’s comfort zone:

• RHEL CoreOS & image-based operations: reproducible nodes, transactional updates, and fewer snowflakes.
• Go all day: my happy place, clean, fast, readable. (I wish we had Rust in the stack too:( )
• Provisioning at scale: Assisted Installer, Metal³, and Ironic, plus ZTP workflows.
• Owning the “boring bits”: boot flows, disk layouts, updates, where reliability is earned, not assumed.

Also, and I say this with a smile, it is a good way to heal from the traumas of the destructive disabled (by Master Ken. If you know, you know; if not, just visit: Enter The Dojo.)

Sometimes the best move is to step away from particular situations or people and carve new paths through obstacles, because, as Marcus Aurelius reminded us, “the obstacle is the way.”

What I’ll focus on (and write about)

I will continue to post about my projects around Strimzi/Kafka, Gamification, Kubernetes/Openshift Operators, and a surprise project (not a software project) is coming soon about software development, career development & coaching, and AI.

Gratitude and next steps

I’m grateful for every team and customer who shaped this path: consulting for the unpredictability that made me resilient, training for the discipline of clear, organized thinking, Kafka/Strimzi for the rigor of distributed systems, and Lightspeed for reminding me that good tools make teams braver.

Now, back to OpenShift, this time closer to the metal. If that sounds like your cup of tea, stick around. I’ll be writing about the lessons learned, the footguns avoided, and the tiny victories that add up to reliable platforms, and more will come, as I mentioned above; not only about OpenShift or bare metal.

May your pods schedule cleanly, your nodes be identical, your updates transactional, and your clusters delightfully boring.

About the cover photo – Not exactly related to my move to the Bare Metal team, but this was from a recent concert of Limp Bizkit, an old (and still performing) nu-metal band, that I had a chance to attend in Istanbul. I have ben listening this band for over 20 years and I always admired how the band guitarist, Mr. Wes Borland, loves what he does and the way he does it, by thinking always differently, always out of the box, using his creativity. I caught his guitar pick in the concert and have been keeping it on my desk to have it as an inspiration anchor for my work. Hope I can be the Wes Borland of the OpenShift Bare Metal team and my own stuff.

A Path to “Wisdom”

I have been a Java developer for about 17 years already, starting with Java 1.4 and Struts 1.2 and JSP-related stuff. I had a chance to use many other frameworks such as Spring, JSF, Spring Boot, and as a web developer, I enjoyed developing Java for web programming. This was the part before I joined Red Hat.

When I was a consultant at Red Hat, I mainly used the Java stack as the Red Hat Middleware was mainly written with Java stack, and Red Hat application runtimes consist of mainly Java-related technologies such as Spring Boot, Vert.x, and Quarkus.

My Java journey didn’t end with my moving to the Red Hat training team, where I created applications mostly again with Java. I was in the AppDev team and as I said previously, Java was one of the main languages that are used in application development on the Red Hat technologies.

It was about 9 months ago that I wanted to get serious with Java development under the “engineering” title again by moving to the Red Hat AMQ Streams/Kafka team. I truly enjoy Kafka as it has been my technical niche for years. However, as the Rolling Stones say in their song (and as it is re-stated a couple of times in the House M.D. series): “you can’t always get what you want”.

In your -engineering- career, there are times when you should take a decision on what to do next; your path.

It can be a new company or a new team. It can be a new city or a country. Moreover, it can be a new language or a new framework. Maybe you are doing a total technology stack change by choosing a new path. Sometimes it is the time to learn new things and grow your career and improve yourself.

The Wisdom Move

A month ago or so, an internal opportunity happened and I decided to move to another team within Red Hat -again as an engineer.

I am moving to the Ansible Lightspeed (formerly Wisdom) team as of August 21!

Ansible has been one of the technologies that I’ve been interested in for some time, especially when I was a Middleware Consultant at Red Hat. I remember I got a lot of help from Ansible, for automating things like installing and setting up a Kafka cluster for a few customers. Now it is time for a giveback to Ansible I guess:) Therefore, I am happy to be a part of the Ansible Lightspeed/Wisdom team.

For this move, I am switching my development stack from Java to Python (and Django).

Python has been one of the languages that I am interested in for some time. I developed the Strimzi Kafka CLI with Python and I have no regret using it as Python is one of the best languages for developing a CLI. Apart from my CLI development experience with Python, I have some Django experience. I had a chance to develop a few Django services for World Health Organization for a project called “WHO Academy” when I was working with the Red Hat Open Innovation Labs team for them. While you have a main stack and you just touch other languages, it is easy, but since this is a stack change, as Master Yoda says, I might need to unlearn some things to learn new things as I am putting something new onto my 15+ years of experience.

Answers for the Mere Mortals

This move will cause many questions in the brilliant minds of the folks who already know me for sure. Let me answer some of them upfront.

Q: Why Python? Java is a more enterprise language(!) than Python, so why choose Python?

Wrong. Python has an easy start for anyone but it is also widely used in many enterprise areas. Python is widely used in machine learning and the Ansible project itself is written with Python.

Also, being a fan of a language or technology is wrong. You can love them, but you mustn’t be a fan of them. Lately, I like Python a bit more than Java, because of a few reasons, but I am not a fan of either of them.

As a Software Crafter, a software programming language doesn’t matter to me as it is just a tool. Tools can be switched, changed, or updated over time, depending on the work and circumstances.

Q: Don’t you think that this is a career suicide?

No. For the recruiters or similar professions maybe yes, but to me it is not. Because having more than one tool in your pocket is always an advantage. Learning different things can make you gain different perspectives on things so these kinds of moves are far from being a career suicide.

Q: What about Java/Jakarta EE/Quarkus? Will you be still contributing to the communities by creating content, giving speeches, and doing workshops?

Absolutely! I will continue to write about Java and Quarkus-related stuff, create videos and workshops and speak at Java/Jakarta EE conferences.

Q: What about Apache Kafka?

I like Kafka and it’s my niche technology that I’ve been specializing in. I cannot and will not stop creating content for it. Even if I am moving from the Strimzi team, I will continue to work on my Strimzi CLI project, continue to write about it, and record videos for it. There are many articles and related video content in my queue to be created and released. So stay tuned!

Q: Any plans on writing about Ansible/Ansible Lightspeed here?

Ansible will be my second niche for sure so why not! I like the technology and its control on any system so thinking this site’s name is “System Craftsman”, that would be a pity not to include Ansible-related content here. This can be thought of as the System Craftsmanship: Software Craftsmanship in the Cloud Native Era article’s theory can come into practice from now on.

Do you have some other questions? Feel free to ask me by using the comment section below, or just wish me luck with my new journey in lightspeed:)

May the Force be with you!

EDIT: As of August 21, I am joining the Ansible Lightspeed engineering team. Stay tuned for another possible article about it!

EDIT2: Here is the new article: Back to Engineering Vol. 2: A Path to Wisdom

TL;DR: As of December 1st, I am starting a new job in Red Hat, this time as a Principal Software Engineer in the Kafka/Strimzi team. If you are curious about my Red Hat journey so far, read the rest:)

It’s been almost 5 years in Red Hat. I started my journey in Red Hat as a middleware consultant. After about 2.5 years I moved to the Red Hat Training team and have been working here as a Senior Content Architect, till now. Because it has changed recently. I am moving back to software engineering!

Before Red Hat, I was a Senior Software Engineer at Sahibinden.com, one of the highest-traffic-consuming websites in Turkey. Apart from some Business Intelligence journey or coding in .Net and PHP, most of my career consists of writing code in Java. So I called myself a “Java developer” most of the time and developed web application backends with several types of frameworks such as Struts 1.2 (yeah I am that old), JBoss Seam Framework, and Spring Framework (not Spring Boot!).

At some point, in the company I was working at, I felt that I am doing similar things in similar loops so I was in a kind of vicious cycle that I had to break. This way I wouldn’t be able to improve myself to be better in my career so I decided to learn some “new stuff” in my spare time in a scheduled way. Cloud, Kubernetes, and cloud-native were popular terms back then and I started to teach myself in very small chunks (The Kaizen Way) and tried not to break the chain.

Anyway, as a developer who was not much aware of the new cloud-native world, I learned about AWS, Kubernetes, OpenShift, and Fabric8, which was a Java library for Kubernetes.

It was early 2018, I remember reaching out to my Red Hat software engineer friend, Ali Ok, for an open position in Red Hat, asking if he can be a referral or not (Red Hat has a great job referral mechanism, which is called “Ambassador Program” and they value referrals a lot). The position was for a “Middleware/AppDev Consultant”, which requires the applicant to take care of the customer deliveries for Red Hat middleware, cloud-native apps, and most importantly: OpenShift CI/CD!

I don’t want to expand this part of the story too much but I joined a couple of interviews (including Java code interviews via Hackerrank at that time) and finally got the job and started at Red Hat as a Middleware/AppDev Consultant.

The Consultancy

I spent my ~2.5 years as a Middleware/AppDev Consultant, worked with about 20 different customers, and traveled to many countries including Senegal (West Africa), learned and taught a lot of Red Hat technologies such as Apache Camel (Fuse), Infinispan (Datagrid), Jenkins for OpenShift CI and ArgoCD for OpenShift CD, Quarkus (pretty new), and most importantly a technology that I am in love of; Apache Kafka. My Kafka journey did not start with Red Hat (as I knew a bit about Kafka from my previous job), but it became my “niche” technology in Red Hat. (For the curious ones: This presentation includes my short story with Kafka.)

Working with customers can be hard because their requests might vary, and communication and the way of working can vary depending on the people’s personalities (like everywhere) or the company culture.

As a software engineer, whose job was to just write code and almost only have to talk in the meetings, it was really hard for me initially because you could have “randomness” in that area, which makes the processes “unpredictable”.

An example of an unpredictable situation that I remember of is, once I contacted a customer to arrange a meeting and we arranged the meeting for a start of delivery (delivery here means the consultancy work/labor for the customer). There were only 3 or 4 people in the meeting request in my calendar so I was very relieved as I was not a good public speaker back then, so doing things among 3-4 people always meant it would be a small meeting in a small room. Easy start! I prepared only my hardware in relief and went to bed for the next day.

I went to the customer’s office the next morning, met the person who welcomed me to their company and we headed to the meeting room. When we came by the door of the meeting room, because of the external view I suspected that it was a big room. Well, sometimes we had small meetings in big meeting rooms, so that was something I was used to and that had to be a similar case.

He opened the door of the meeting room and there was a big long desk full of people around it (I could not count but it must be more than 40), waiting for me and my unprepared presentation as an intro for development processes with OpenShift.

Well, of course, I did not say “sorry but I didn’t prepare the presentation” or “I can’t show you anything today”, but sat down and requested about 5 minutes to be “prepared”. What do you think I did after this?

Well luckily, my dear colleague Cenk Kulacoglu, who is now the manager of the Red Hat Consultancy team in Turkey (he was a senior architect back then), had taught me to be prepared in any time. I had seen him he always had a couple of presentations in his Google Drive so that he could either present them or change them regarding the customer needs. That was what I did for that customer.

I told you about this story because being a consultant, not only makes you improve yourself technically but also improves your soft skills so that you can give more to your clients.

In consultancy, you can not only learn how to be “always being prepared” to overcome the “unpredicted situations”, but also many other skills that I think improved me in many ways:

• Public speaking: I was shy about speaking in public probably because of a couple of traumas I had in my childhood. I had a chance to overcome this with the “unpredicted situations” many times. When you expect to see 3 people but learn that you have to present to 40, it improves you. Now I am pretty relaxed talking in front of public.
• Presentation skills: I learned a lot from my craftership master Lemi Orhan Ergin in the past, and I think I had a chance to evolve it in my way with the style that I learned by just preparing slides. The key part is the “flow” and you learn it by doing. And if there are times that you have to do it in just 30 minutes to prepare a deck, then you learn it better:) (This is another story that I will not give any detail about.)
• Presenting skills: A presentation is not only about slides, but you have to learn how to explain the topic to the audience, especially if they are your customers, you have to do it better because they want to learn from you and they are consulting with you. You must distill the knowledge and present it with the tools (presentation) and your public speaking abilities.
• Persuasion/Negotiation skills: Well sometimes you have to convince the people/customer you work with. When you are a consultant, you are the one who is consulted so you might need to use your persuasion or negotiation skills from time to time.
• Fast learning: You must learn things faster in the moving environment of consultancy because you will always be expected to know things, especially if that things belong to a wide group, such as middleware or CI/CD.
• Flexible attitude (Politics skills): This is not about any politician or what they do but this is more about managing yourself and your clients. You must be always nice to the customers and should not be too direct. Sometimes there will be misunderstandings, or sometimes there can be really tough customers, you have to manage them all so you should not have one and only one solution for the same thing but many. This is not about a “customer is always right” thing, but about using your persuasion, negotiation, and “niceness” skills and being flexible as much as you can. This is one of the things that I learned very later on.
• And many more that I might not remember… You can add your own in the comments section below.

WHO Built This

Just before finalizing my days as a consultant, I had a chance to work with a very special team; Red Hat Open Innovation Labs team, on a very special project; the World Health Organization (WHO) Learning Experience Platform (LXP), at a very special (and weird) time of the year; just after the pandemic happened!

It was a great experience with the WHO team, trying to implement and stabilize a real DevOps culture within their organization and creating a functioning application for their LXP project in just 8 weeks.

Enough for the words for this, for the curious mere mortals, here is how we did it:

Gaining these kinds of experiences as a “Software Engineer” or consultant makes you think differently. Being physically in a customer environment is one thing, having a kind of remote customer engagement, which is worldwide, timezone dependant, and important (because it is directly about health in a pandemic time), is another thing.

After my ~2.5 years of consultancy journey, because of having a small taste of working in a remote worldwide environment, and a bit of love for writing and creating content to teach people, I decided to move to another team, where I can access these benefits and improve myself on creating training content. I moved to the Red Hat Training (internally aka. Global Learning Services – GLS) team.

The “Content” Development

In February 2021 I joined the Red Hat training team, with the enthusiasm and excitement of having a chance to create professional content. I would write books for training and I was very excited about that.

Before being a consultant, I had been admiringly looking at the techie people who created content consistently. Some consistently wrote blog posts, others created YouTube content.

Especially the writing part took a lot of interest in me because if think if I did not become a “techie” I would be a writer; a novel writer. I remember I left similar notes to every close friend of mine in the high school diary book like “…in the future it is likely you find me in a book…”, giving the message to both their subconscious and mine. It is kind of childish but I have to admit that I liked writing because I had been writing short stories and poems at that time (poems in both English and Turkish. Edgar Allan Poe was -and still is- my favorite).

After years, in university, I lost my interest in writing and things went more with Maths and 0-1s but while trying to learn things on the web, I realized writing (actually creating content) is still a thing, which will not be rotten away. I tried to create some forums first, wrote one by myself with PHP, then used vBulettin and similar things but end up creating the site and writing a couple of posts or two then forget the website.

Later on, I understood that it is not a matter of quality, but quantity and consistency. This is another topic though, so I am leaving this for another article.

While I was working on the “Strimzi Kafka CLI”, writing blog posts about it, and creating video content, I always thought about writing better. If you are a software engineer who has this mindset that seeks a spec for everything technical, you also seek a spec for everything in the real world, like written content. I knew that my writing was not good (and still not perfect), but I probably sensed that there should be a better way to do that with a spec or something.

There are books around about creating content better such as Everybody Writes by Ann Handley and On Writing: A Memoir of the Craft by Stephen King, I bought both of them before I joined the training team and read both but it was the time I really learned about writing: writing, reviewing and get your content reviewed by your colleagues and the editors.

I learned that there is really a spec like developers have for their programming languages or frameworks. We used the Red Hat Style Guide and IBM Style Guide, which guided us a lot while we write. I think this is the actual process you really learn doing something. While I might be still chased by zombies of passive voice, I think my writing got improved a bit, good enough for helping a content creation agency with creating high-quality content for their customers. I am going to expand on this part later on in a different post about “Writing for Developers”.

Training the Experts

Working in a training team not only gives you a chance to improve your writing skills, but also you become a trainer by thinking from the trainee’s perspective.

We had a lot of discussions about how to present the content to the students, and how to write better quizzes, labs, and guided exercises, we even tried out different models of instructions so that we could get feedback about those and improve our end.

Training content is not like blog post content so you must think about its architecture (because it is actually a book), you have to have inclusive language, your style should be formal, you have to be clear with your instructions, and so on. Most importantly, because it is teamwork, you have to know how to work together and how to connect the dots of yours and other people’s because, in the end, it is a whole content that customers and Red Hat trainers use.

In the period that I’ve been involved in, I had a chance to work on many training contents including OpenShift CI/CD and OpenShift Serverless.

Here is a short list of the training courses we created during my tenure:

• Red Hat DevOps Pipelines and Processes: CI/CD with Jenkins, Git, and Test-driven Development
• Developing Event-Driven Applications with Apache Kafka and Red Hat AMQ Streams
• Cloud-native integration with Red Hat Fuse
• Developing Applications with Red Hat OpenShift Serverless and Knative

While I contributed writing content for these courses, I had a chance to use my connections from consultancy to reach out to people who are experts on those topics so we could get a lot of useful feedback before, during, and after the course development.

I can say that the Kafka one is my favorite one as I not only contributed to its content but also helped shape the outline of this course. It was the first course that I had a chance to start from scratch so I can admit I had a lot of fun. (Also thanks to my friends Jaime and Pablo who made this process fun for me. Long live the 3 Musketeers!)

I also had a chance to do a few Taste of Training (ToT) webinars where we demonstrated a training-relevant technology and did announcements about our present or future courses. You can find one about “Openshift Serverless” here still live on the Red Hat Webinars page, and another one about “Building event-driven systems with structure” is here on my YouTube channel:

In the training team, I had many chances to use my previous skills like presentation, people connections, fast learning, and product information, and learned new ones such as writing and training mechanics. Knowing how to write, as a developer, helped me a lot because when you write, you learn how to express your opinions better and you become more organized. Also if you start writing here and there, it is inevitable that you get some attraction which helps your self-marketing. I don’t write on popular technical content websites much but as I mentioned before, in my free time, I help a developer content creation agency where I can hone my writing or outlining skills.

It has been fun to work as a Content Architect at Red Hat but after some time I felt like I should focus on a single technology and work on it in a lower-level manner. Since I have been very much interested in Kafka and Strimzi for some time, I took a chance to move to the Red Hat Kafka engineering team, and luckily I was able to become a part of that team, which consists of very smart, talented and friendly people that I already know of!

The New Journey: Red Hat Kafka Engineering

As I mentioned at the very beginning of the article, it has been quite a time since I haven’t been doing R&D and writing low-ish-level code. I mean I wrote a lot of code for customer projects when I was a consultant, I wrote code for the guided exercises and labs for the training team, and wrote code for my open-source pet projects but writing the code for the product itself is a different thing. It is something that I haven’t been “directly” doing for 4+ years so I have to admit that I am a bit nervous and excited about it.

However, hopefully, I will have a chance to use my gainings from other teams and past experiences from them, and waking up the “software engineer” inside me with those past gainings, I believe, will create a beneficial combination for the team.

I am a lot excited that I will have a chance to do direct contributions to the Strimzi and AMQ Streams. I know that it is not like contributing from the outside because when you become a member, expectations become higher:)

I am starting my Principal Sofware Engineer role in the Kafka/Strimzi engineering team as of December 1st, so wish me luck with my new journey in Red Hat:)