From 2d8bdddda9d9b55c26e7d73fcff85874ccdbc351 Mon Sep 17 00:00:00 2001 From: wineshuga Date: Tue, 30 Jun 2026 19:28:10 +0100 Subject: [PATCH 1/2] add blog content Signed-off-by: wineshuga --- blog/posts/2026-06-30-learn-cloud-with-lfx.md | 96 +++++++++++++++++++ 1 file changed, 96 insertions(+) create mode 100644 blog/posts/2026-06-30-learn-cloud-with-lfx.md diff --git a/blog/posts/2026-06-30-learn-cloud-with-lfx.md b/blog/posts/2026-06-30-learn-cloud-with-lfx.md new file mode 100644 index 000000000..520eaee62 --- /dev/null +++ b/blog/posts/2026-06-30-learn-cloud-with-lfx.md @@ -0,0 +1,96 @@ +--- +title: "Learning Cloud-Native Engineering Beyond Tutorials Through LFX" +created_at: 2026-06-30 +kind: article +author_name: "Uzochukwu Winnie (@wineshuga)" +--- + +I joined the Prometheus mentorship expecting to spend three months writing documentation. A few weeks later, I was deploying OpenTelemetry Collectors across EC2 instances, debugging networking problems between machines, and trying to understand why a pipeline that looked healthy wasn't sending a single metric. + +That shift from documenting systems to building and troubleshooting them made the LFX Mentorship one of the most effective and exciting learning experiences I've had in cloud-native engineering. + +Most people don’t struggle to learn cloud-native tools because they're inaccessible. They struggle because tutorials stop at the easiest possible version of reality. + +The LFX Mentorship exposes systems as they behave in reality, not as they are presented in tutorials. That difference is what makes it one of the most effective ways to grow into cloud-native engineering. + + + +## The work changed quickly + +I worked with Prometheus on improving the Documentation for Prometheus and OpenTelemetry Interoperability. I assumed my contributions would be solely to improve or create documentation for both tools. +Documentation was part of the experience. I contributed to OpenTelemetry documentation, and my [pull requests](https://github.com/open-telemetry/opentelemetry.io/pull/9570) were merged. That gave me direct exposure to how large CNCF projects review, refine, and maintain technical documentation at scale. + +But that was only the surface. Before long, my work had expanded beyond documentation into deploying and troubleshooting the systems I was writing about. + +In addition to writing about OpenTelemetry and Prometheus, I was deploying them across AWS infrastructure and learning how they behave under real network and deployment constraints. These were things I’d never done before, and it was wonderful to be involved in this way. + +This is different from how cloud-native systems are usually learned. Most learning environments are designed to eliminate failure. And this leads to junior developers facing unexpected challenges in production. + +## Why tutorials fail at this level + +Local environments and guided tutorials often hide the hardest parts of distributed systems: +assuming every service can reach every other service +- debugging communication across multiple machines +- configuration drift caused by manual changes +- partial failures where some components work, and others don't +- infrastructure inconsistencies between environments + +The deployment I made during the mentorship looked like this: + +- Django applications running on multiple EC2 instances +- OpenTelemetry Collectors deployed alongside each application +- A dedicated EC2 instance running Prometheus as a metrics backend +- Metrics exported in Prometheus format from all instances into Prometheus + +Every component introduced another opportunity for failure. Most failures were silent: missing metrics, broken pipelines, or unreachable services that still appeared “healthy.” That is not something tutorials prepare you for. This is what a mentorship like LFX exposes you to. + +## Where the system actually broke + +The hardest debugging experiences were not tied to a single tool like OpenTelemetry or Prometheus. They came from interactions between components. + +Problems ranged from: +- EC2 instances unable to communicate due to networking constraints. +- Collectors running but not exporting data. +- Pipelines silently dropping telemetry. +- Local setups behaving correctly, while AWS deployments failed +At some point, debugging stopped being about individual services and became about understanding system behavior. I wrote about one of those debugging experiences in more detail [[here]](https://uzochukwuwinnie.com/articles/lfx-mentorship-4-setting-up-multi-vm-observability-infrastructure-on-aws-with-terraform). That shift, I believe, is the point where someone stops being a tool user and starts becoming a systems engineer. + +## Learning without a playbook + +A defining aspect of the LFX Mentorship model is autonomy. Mentors provide direction and feedback, but they do not solve problems for you. In my case, feedback and guidance from Tiffany Hrabusa, Arthur Sens, and Victoria Nduka were just as valuable as the technical work because they shared the reasoning behind engineering decisions, not just the decisions themselves. Understanding why a solution was preferred often mattered more than the solution itself. + +At first, the lack of detailed guidance felt uncomfortable and scary. Over time, I found it beneficial for my skill and knowledge growth. + +Instead of learning how to follow instructions, I learned how to: +- break down unclear problems +- make architectural decisions +- debug across system boundaries +- validate assumptions in real environments +This structure is what makes the learning curve steep but also real. + +## What changed through this experience +By the end of the mentorship, the most important shift was not tool-specific knowledge. It was how systems are perceived. Looking back, that change was far more valuable than learning any single technology because it fundamentally changed how I approach engineering problems. It made the experience far more impactful than I had expected when I first joined the program. I also gained a more realistic understanding of observability itself as pipelines that must be designed to survive failure. + +## Outcomes +Beyond learning, the work produced tangible contributions: +- Documentation improvements to OpenTelemetry were merged +- Work was completed, [clarifying Prometheus and OpenTelemetry interoperability](https://github.com/open-telemetry/opentelemetry.io/issues/9650) using the Prometheus metrics format +- A [blueprint proposal](https://github.com/open-telemetry/sig-end-user/issues/339) was developed for deploying observability systems in non-Kubernetes environments + +The last point is particularly important because while Kubernetes dominates much of the cloud-native conversation, many teams still operate workloads on virtual machines. Expanding documentation for these environments helps make observability practices accessible beyond Kubernetes-first deployments. + +## Why programs like LFX matter +The value of structured open-source mentorship is not just exposure to tools. It is exposure to reality. +Specifically, it provides: +- production-style environments instead of controlled labs +- real system failures instead of isolated examples +- architectural thinking instead of tool usage +- autonomy instead of guided execution +This combination is difficult to replicate through self-learning alone. Most importantly, it forces engineers to deal with the parts of systems that are usually abstracted away in early learning stages. + +## Final thoughts +The LFX Mentorship gave me more than exposure to cloud-native tools. It changed how I think about building, debugging, and operating distributed systems. Contributing to open source, learning from experienced maintainers and mentors, and working through real production-style challenges made it one of the most valuable learning experiences in my career. + +If you're looking to grow beyond tutorials and learn in a real engineering environment, I highly recommend applying for a mentorship like this one. + +If you're working in cloud-native systems or exploring similar challenges, I'm always happy to connect on LinkedIn: [[link]](https://linkedin.com/in/uzochukwu-winnie). From 9c5e9caaa9f404b0bd58619255c9b7d120b35c9f Mon Sep 17 00:00:00 2001 From: wineshuga Date: Sat, 4 Jul 2026 00:09:44 +0100 Subject: [PATCH 2/2] apply suggestion and fix missing line breaks Signed-off-by: wineshuga --- blog/posts/2026-06-30-learn-cloud-with-lfx.md | 73 +++++++------------ 1 file changed, 28 insertions(+), 45 deletions(-) diff --git a/blog/posts/2026-06-30-learn-cloud-with-lfx.md b/blog/posts/2026-06-30-learn-cloud-with-lfx.md index 520eaee62..49514b367 100644 --- a/blog/posts/2026-06-30-learn-cloud-with-lfx.md +++ b/blog/posts/2026-06-30-learn-cloud-with-lfx.md @@ -5,81 +5,63 @@ kind: article author_name: "Uzochukwu Winnie (@wineshuga)" --- -I joined the Prometheus mentorship expecting to spend three months writing documentation. A few weeks later, I was deploying OpenTelemetry Collectors across EC2 instances, debugging networking problems between machines, and trying to understand why a pipeline that looked healthy wasn't sending a single metric. +I joined the LFX mentorship expecting to spend three months writing documentation. A few weeks later, I was deploying OpenTelemetry Collectors across AWS EC2 instances, debugging networking problems between machines, and trying to understand why a pipeline that looked healthy wasn't sending metrics. -That shift from documenting systems to building and troubleshooting them made the LFX Mentorship one of the most effective and exciting learning experiences I've had in cloud-native engineering. - -Most people don’t struggle to learn cloud-native tools because they're inaccessible. They struggle because tutorials stop at the easiest possible version of reality. - -The LFX Mentorship exposes systems as they behave in reality, not as they are presented in tutorials. That difference is what makes it one of the most effective ways to grow into cloud-native engineering. +I went from having zero knowledge about observability to building and troubleshooting systems. This made the LFX Mentorship one of the most effective and exciting learning experiences I've had in engineering. I was exposed to how systems behave in reality. That difference is what makes it one of the most effective ways to grow into cloud-native engineering. -## The work changed quickly - -I worked with Prometheus on improving the Documentation for Prometheus and OpenTelemetry Interoperability. I assumed my contributions would be solely to improve or create documentation for both tools. -Documentation was part of the experience. I contributed to OpenTelemetry documentation, and my [pull requests](https://github.com/open-telemetry/opentelemetry.io/pull/9570) were merged. That gave me direct exposure to how large CNCF projects review, refine, and maintain technical documentation at scale. - -But that was only the surface. Before long, my work had expanded beyond documentation into deploying and troubleshooting the systems I was writing about. +## No expertise needed -In addition to writing about OpenTelemetry and Prometheus, I was deploying them across AWS infrastructure and learning how they behave under real network and deployment constraints. These were things I’d never done before, and it was wonderful to be involved in this way. +A few months before joining the LFX mentorship, I was a Frontend Developer exploring backend engineering. My first encounter with observability was curiosity leading me to articles about traces and metrics. For years, I looked forward to contributing and joining an active Open Source community. So when I came across this mentorship with Prometheus on improving the documentation for Prometheus and OpenTelemetry Interoperability, I thought this was a perfect opportunity to contribute. -This is different from how cloud-native systems are usually learned. Most learning environments are designed to eliminate failure. And this leads to junior developers facing unexpected challenges in production. +I expected my contributions to focus solely on improving or creating documentation for both tools. Documentation was part of the experience. I contributed to OpenTelemetry documentation, and my [pull requests](https://github.com/open-telemetry/opentelemetry.io/pull/9570) were merged. That gave me direct exposure to how large CNCF projects review, refine, and maintain technical documentation at scale, but that was only the surface. Before long, my work had expanded beyond documentation. To properly document real systems, I first had to understand them. This led me to deploy and troubleshoot the systems I was writing about. -## Why tutorials fail at this level +## The system deployed -Local environments and guided tutorials often hide the hardest parts of distributed systems: -assuming every service can reach every other service -- debugging communication across multiple machines -- configuration drift caused by manual changes -- partial failures where some components work, and others don't -- infrastructure inconsistencies between environments +The deployment I made during the mentorship looked like this: -The deployment I made during the mentorship looked like this: +- Django applications running on multiple EC2 instances. +- OpenTelemetry Collectors deployed alongside each application. +- A dedicated EC2 instance running Prometheus as a metrics backend. +- Metrics exported in Prometheus format from all instances into Prometheus. +Every component introduced another opportunity for failure. Most failures were silent: missing metrics, broken pipelines, or unreachable services that still appeared “healthy.” -- Django applications running on multiple EC2 instances -- OpenTelemetry Collectors deployed alongside each application -- A dedicated EC2 instance running Prometheus as a metrics backend -- Metrics exported in Prometheus format from all instances into Prometheus - -Every component introduced another opportunity for failure. Most failures were silent: missing metrics, broken pipelines, or unreachable services that still appeared “healthy.” That is not something tutorials prepare you for. This is what a mentorship like LFX exposes you to. - -## Where the system actually broke +## The big challenge The hardest debugging experiences were not tied to a single tool like OpenTelemetry or Prometheus. They came from interactions between components. - Problems ranged from: - EC2 instances unable to communicate due to networking constraints. - Collectors running but not exporting data. - Pipelines silently dropping telemetry. - Local setups behaving correctly, while AWS deployments failed -At some point, debugging stopped being about individual services and became about understanding system behavior. I wrote about one of those debugging experiences in more detail [[here]](https://uzochukwuwinnie.com/articles/lfx-mentorship-4-setting-up-multi-vm-observability-infrastructure-on-aws-with-terraform). That shift, I believe, is the point where someone stops being a tool user and starts becoming a systems engineer. +At some point, debugging stopped being about individual services and became about understanding system behavior. I wrote about one of those debugging experiences in more detail [[here]](https://uzochukwuwinnie.com/articles/lfx-mentorship-4-setting-up-multi-vm-observability-infrastructure-on-aws-with-terraform). At this point, I knew I wasn’t going back to be a Frontend Engineer. ## Learning without a playbook -A defining aspect of the LFX Mentorship model is autonomy. Mentors provide direction and feedback, but they do not solve problems for you. In my case, feedback and guidance from Tiffany Hrabusa, Arthur Sens, and Victoria Nduka were just as valuable as the technical work because they shared the reasoning behind engineering decisions, not just the decisions themselves. Understanding why a solution was preferred often mattered more than the solution itself. +A defining aspect of the LFX Mentorship model is autonomy. Mentors provide direction and feedback, but they do not solve problems for you. In my case, feedback and guidance from Tiffany Hrabusa, Arthur Sens, and Victoria Nduka were just as valuable as the technical work because they shared the reasoning behind engineering decisions, not just the decisions themselves. Understanding why a solution was preferred often mattered more than the solution itself. -At first, the lack of detailed guidance felt uncomfortable and scary. Over time, I found it beneficial for my skill and knowledge growth. +At first, the lack of detailed guidance felt uncomfortable and scary. Over time, I came to appreciate how much it contributed to my technical growth and confidence. -Instead of learning how to follow instructions, I learned how to: -- break down unclear problems -- make architectural decisions -- debug across system boundaries -- validate assumptions in real environments -This structure is what makes the learning curve steep but also real. +My mentors and I would discuss problems and explore different approaches to achieve our goal. We worked as a team, and that gave me the space to grow while still taking ownership of my work. During the development of the blueprint, for example, one of my mentors generously gave me access to a platform where I could test an idea we had. While it allowed me to validate the approach, it also came with a major limitation: I couldn't automate deployment, and the environment had a time limit. During our next meeting, we discussed this challenge together and came up with an alternative approach that ultimately proved successful. + +This kind of guidance is all I could ever wish for. I was challenged to think independently while being reassured that I wasn't solving problems alone. ## What changed through this experience + By the end of the mentorship, the most important shift was not tool-specific knowledge. It was how systems are perceived. Looking back, that change was far more valuable than learning any single technology because it fundamentally changed how I approach engineering problems. It made the experience far more impactful than I had expected when I first joined the program. I also gained a more realistic understanding of observability itself as pipelines that must be designed to survive failure. ## Outcomes -Beyond learning, the work produced tangible contributions: -- Documentation improvements to OpenTelemetry were merged -- Work was completed, [clarifying Prometheus and OpenTelemetry interoperability](https://github.com/open-telemetry/opentelemetry.io/issues/9650) using the Prometheus metrics format -- A [blueprint proposal](https://github.com/open-telemetry/sig-end-user/issues/339) was developed for deploying observability systems in non-Kubernetes environments +Beyond learning, the mentorship produced tangible outcomes. + +The improvements I made to the OpenTelemetry documentation were merged. I also completed documentation on [Prometheus and OpenTelemetry interoperability using the Prometheus metrics format](https://github.com/open-telemetry/opentelemetry.io/issues/9650), and developed a [blueprint proposal](https://github.com/open-telemetry/sig-end-user/issues/339) for deploying observability systems in non-Kubernetes environments. -The last point is particularly important because while Kubernetes dominates much of the cloud-native conversation, many teams still operate workloads on virtual machines. Expanding documentation for these environments helps make observability practices accessible beyond Kubernetes-first deployments. +Another outcome is that I now understand how open source communities organize themselves. If I wanted to join a Prometheus Working Group or an OpenTelemetry SIG, I know how to get involved and contribute effectively. + +Perhaps the most valuable outcome is the network I’m beginning to build. Through this mentorship, I’ve started forming relationships with experienced engineers, and I’ve come to realize that building genuine connections is one of the best ways to grow in this industry ## Why programs like LFX matter + The value of structured open-source mentorship is not just exposure to tools. It is exposure to reality. Specifically, it provides: - production-style environments instead of controlled labs @@ -89,6 +71,7 @@ Specifically, it provides: This combination is difficult to replicate through self-learning alone. Most importantly, it forces engineers to deal with the parts of systems that are usually abstracted away in early learning stages. ## Final thoughts + The LFX Mentorship gave me more than exposure to cloud-native tools. It changed how I think about building, debugging, and operating distributed systems. Contributing to open source, learning from experienced maintainers and mentors, and working through real production-style challenges made it one of the most valuable learning experiences in my career. If you're looking to grow beyond tutorials and learn in a real engineering environment, I highly recommend applying for a mentorship like this one.