Guest post by CommunityBridge Intern, Arthur Silva Sens
I just graduated from my internship at Linux Foundation’s Community Bridge program, and I’d like to share my experience and explain why you should also consider applying if you are new to open source or the cloud-native world.
I already had some experience with cloud-native projects, I’ve been using cloud-native tools at my workplace for a couple of years. It is thanks to them that I got my first full-time job as an Infrastructure Analyst and later on as a Cloud Architect. And if you are reading this blog post, I assume that you have at least some knowledge about what CNCF does and you do know some of its projects, like Kubernetes and Prometheus, i.e.
Even though I had the desire to contribute to open source projects, I was always super cautious and had a false feeling that these projects are super complex and I’m not qualified enough to help. As you will read later, this is far from being true, you can always contribute in some way!
How did I get to know about the Community Bridge program?
I like Twitter xD, I admit that mine isn’t the most technical account you’ll find, but I do follow some of CNCF’s projects’ twitter profiles. So, on a random day, I came across with this tweet:
When I read it, I immediately searched for more information and found a really big list of projects that needed help. I’ve looked up almost every issue and project on that list, found their contributing guidelines and noticed that almost every project has issues that are labeled as easy and beginner-friendly, like Prometheus “low hanging fruit”, Kubernetes and Thanos “good first issue” and Linkerd “help wanted”. Those are the perfect issues for people that have never contributed to the project before and want to start contributing, like me 3 months ago. One example is the PR I did for Prometheus (that was my first PR for a CNCF project), which was only required some documentation changes.
Happily, some days after that, I’ve got selected to help the KubeVirt community by improving its observability.
Without further ado, let me present a few key learnings and thoughts I got after my internship. Things that helped me become a better software engineer.
Be clear about your expectations and capabilities
My first meeting with my mentors went pretty well. My fellow mentee, Hritvi, and I were very clear that we never had any experience with KubeVirt before. I also told them that I’ve been working with containers and Prometheus for some years and that my knowledge about virtualization was pretty close to non-existent.
After that conversation, they knew what they could and couldn’t expect from my side. If knowledge around a particular subject, that I didn’t have at the moment, was needed for me to complete my tasks, my mentors would happily guide me or provide the documentation.
Another topic that we talked about during our first meeting was “what I expect to achieve by the end of the internship”. My first desire was to learn how to contribute to open-source projects and to improve any skills required to start a career around open source. It happens that the skills that I needed the most were also the skills that I’ve been ignoring for years 😣 They are often called “Soft Skills” and I’ll talk more about them further in this blog post.
Improve your ability to write and speak English publicly
Even though I think that my English is pretty good overall, communication was the first real problem I faced with the internship. All starting with my writing.
The most common forms of communication with the KubeVirt community are the asynchronous ones, like slack messages and mailing lists (I’m pretty sure that applies to all other open source communities too). I live in Brazil, my fellow mentee is from India and our mentors are from Germany and Israel. We live in very different parts of the world and timezone difference is a real issue. I struggled a lot with my writing in the beginning, often making silly grammatical mistakes or just wasn’t clear enough about my thoughts and problems that I was facing. Mentors and community members couldn’t help me if they didn’t understand what was going on, right? That led to some delays and, as a result, I started coding only one month after the beginning of the program. On top of that my first PRs were also not clear enough about what I was expecting to do and reviewers had a hard time understanding and making the necessary suggestions.
Well, the only way to get better at writing… is writing! duh. Try writing blog posts about what you are doing, even if you think that no one is going to read it, just try to get used to it. Of course, some tools helped me a lot with the process. Grammarly is a *must* and Google Translate is always opened in a tab every day. If you want to contribute to CNCF’s projects, I also recommend joining the slack channels and mailing lists and just make a habit to read the conversations and learn how people interact with each other, you might end up finding something that you can contribute to as well 🙂.
What about public speaking?? That’s a tough subject for me😣. I’m very introverted, I get nervous easily when talking with large groups and that leads to me not being as clear as I’d like to when speaking at meetings. I often repeat myself, I stutter, and it is just not a good experience for me overall.
We had weekly meetings with mentors and mentees. My mentors are great people, super friendly and I’m pretty comfortable around them by now. BUT there are also community meetings. Those are the ones that are open to the public where users and contributors all around the world come to talk about anything that is KubeVirt related. My project was about improving KubeVirt observability by implementing new metrics. Monitoring solutions are heavily use-case oriented and since I have never used KubeVirt before, I wasn’t sure about what use-cases needed new metrics and which ones didn’t. I had no other choice but to bring that subject to the community meeting. Honestly, if I had my camera on during that moment, people would mistake me with a really red tomato 😂! But I’m glad that I did, I was suggested to start a discussion at KubeVirt’s mailing list and people did interact and helped me write a proposal for my project.
I’m well aware of this weakness of mine and I do want to get better when speaking in public or large groups. I have participated in every KubeVirt community meeting since I got selected to the Community Bridge. But that’s not all, I am also trying to participate in other meetings, like the SIG-Observability and Prometheus meetings. It’s far from perfect, but I’m trying my best to bring up the courage to speak up when I feel like I can contribute to a conversation. If anyone has any tips on how to get better with this problem, please hit me up!
I’m a newcomer
While working with KubeVirt, I got in touch with a bunch of talented people and I see awesome contributions every single day. I inevitably compare my work with theirs and I’m sure that a lot of other contributors could finish my project with less than half of the time that I had. In the beginning, I felt really bad about it and was often apologizing for taking so long to make my contributions.
I talked with my mentors about this feeling I had and they made clear that they weren’t disappointed at all with my progress. In fact, they were always giving me positive feedback. I started the program with 0 knowledge about KubeVirt or virtualization, but I was making progress every single week. That is the classic Impostor Syndrome right there! They never expected that I could make the same contributions as the Senior Software Engineers from Red Hat, I’m a newcomer after all. It is silly and even selfish of my part to think that I, with only a couple of months of experience, could be at the same level of engineers that have been working with KubeVirt for years.
As talked at the first mentors/mentees meeting, my objective was to learn how to contribute, and that’s not a simple process for us, newcomers. There were a lot of things that I had to learn that weren’t related to improving KubeVirt’s observability but were necessary for me to make my contributions.
Unit and e2e testing is an absolute must if we want to make sustainable code and even though I’ve been working as a developer for years, I never had any experience with testing before.
The git-flow was also something that I struggled at the beginning, I’ve used git for my entire career and I knew the best practices about using branches and Pull Requests, however, almost every company that I’ve worked did not follow those practices and I just used the very basic git commands like clone, add, commit and push . It took me some time to properly understand some commands that are a little more complex, like rebase and cherry-pick , and even how to dropand squash commits. I’ve messed up a lot of PRs, like this one, when trying to resolve merge conflicts and my first big contribution got merged with a lot of useless commits that I forgot to squash or drop. (It was 100% my fault 😅)
Expect blockers
When working with software development, it is super common to find blockers along the way.
There was one single question that was asked at the beginning of every “mentors/mentees” meeting: “Do you have any blockers?”. Our mentors’ responsibility was to make sure that we, mentees, could finish our projects and there is always a possibility that we could get blocked by something that we didn’t have the knowledge of power to solve. And it happened to me indeed.
At one of my PRs, I performed a big refactor of the package that was exposing metrics about KubeVirt’s workloads and, at the time, I thought that all my following PRs would need this first PR to get merged, or would be just way too many merge conflicts otherwise.
It happens that the KubeVirt community is pretty active, with several PRs and issues opened every day and I think there are not enough reviewers to handle all the contributions. I watch a few of CNCF projects and it is just insane the difference of notifications I get between KubeVirt and any other project when I don’t turn up my computer for a day.
Reviewers are often overloaded with work, also, my clarity when describing PRs was not the best back then, so this particular blocker took quite some time to be solved (around 2~3 weeks). That’s when I stopped my weekly series of blog posts about my progress with the project since I had nothing to write about.
In the meantime, I focused on learning more about KubeVirt itself, Kubernetes, and Prometheus. I tried to find other communities that needed help, and just interact with them. I’ll talk a little more about that in the next section of this blog.
But hey, while looking for more work when you face blockers, don’t be too greedy! Always remember that those blockers will get solved someday and all the work you had will knock at your door again! I made the mistake of volunteering to solve issues of other projects and when my blocker got solved, I didn’t have the time to help them. It was kind of embarrassing, but I was obligated to inform the Linkerd community that I couldn’t help them, even though I was the one who volunteered.
Interact with other communities
One thing that I didn’t know before I started the Community Bridge program was how all CNCF projects are so open to the public and how friendly people are to each other. They all have open community meetings, where anyone can participate and add topics to the discussion, which you can find here. They all have public slack channels that anyone could enter and chat about common interests (they mainly use CNCF’s slack or Kubernetes’ slack).
It’s super easy to get in touch with maintainers and if you have any questions about a particular project, you can ask them in the appropriate channel and someone you don’t know, someone that has no obligation whatsoever to help you… will help you.
As previously mentioned in this blog post, I did look for other projects that needed help while I was blocked, I was also trying to learn more about Prometheus and how to better improve KubeVirt’s observability. I had a lot of doubts about the usage of labels and no matter how much I looked up, I couldn’t find any guides that would solve the doubts I had. That’s when I reached out to SIG-Observability asking for help.
Bartek Plotka, who is the co-author of Thanos and Prometheus maintainer, quickly suggested me to create a new issue regarding my particular questions. I’m not gonna put a PrintScreen here because it’s quite an extensive issue, but I’m pretty happy with the follow up that I got there.
Bartek answered all my questions, brought that subject to the SIG-Observability community meeting and the discussion about building a community-driven learning page about everything around observability went on the mailing list. Ah, also if you are getting started with observability like me, I highly recommend this talk called Observability 101 from Richard Hartmann, from Grafana Labs.
Thanks to those interactions I was able to identify a lot of things that I was doing wrong with my project and a lot of changes were made to the initial proposal and the PR that was blocked at the moment. And also some gratitude from the KubeVirt maintainers, which is always nice too 😁.
Total dedication to the internship
In January 2020 I’ve joined an innovative company here in Brazil, called Neoway. They provide some Big Data Analytics and Artificial Intelligence solutions that help big and small companies with their decision making.
With the COVID-19 pandemic, they are playing an important role in helping a lot of Brazilian state governments and prefectures to make the right decisions to help our citizens go through the current financial crisis that our country is facing.
The people that I’ve got to meet there were pretty nice and I was part of a cool project. I was working with a pretty cool tech stack: Ansible, Terraform, Kubernetes, Prometheus, Docker, Gitlab-CI, and in a Hybrid Cloud environment, where we used Google’s GKE to run containerized applications and IBM Cloud to run legacy applications on Virtual Machines (if only I knew KubeVirt capabilities back then 🙃).
With that being said, I got selected to the Community Bridge program on May 22nd, and quit my job at Neoway on June 17th. It was a really tough decision, I was quitting a full-time job for an internship 🤔.
I’ve been dreaming about working with open source literally for years, so I really wanted to put a lot of effort into it, and working full-time on another job was pretty difficult. I would wake up every day at 5:30 AM, work on KubeVirt until 9 AM and then work for Neoway until 6 PM. Then I would have around 3 hours to do some physical exercise like parkour or calisthenics, make dinner, take a shower, and go back to sleep again. On weekends I would work for the internship since I was having a hard time getting used to so many new things that I had to learn. Well, it is safe to say that I got exhausted quickly 🥵!
I wasn’t satisfied with my productivity for both sides, the internship and for my full-time job, so I had to make a decision. Even though Neoway was great, it wasn’t too hard to make that decision. Working with open source is indeed a dream of mine, with KubeVirt I had the chance to work with and learn from first-class engineers from really influent companies at the Cloud-Native world like Red Hat, Grafana Labs, SUSE and Apple, and it’s also worth to say that the Linux Foundation also pays a generous stipend for us mentees! Especially if you live in a country with a weak currency when compared to dollars, like me 🤑.
After I dedicated myself full time for the internship, the project started to progress a lot faster, my quality of life got better and I’m happier overall. There isn’t a single day that goes by that I would ever regret my decision. The people I’ve got to meet and the amount of knowledge they shared with me is just priceless!
I’d like to express my gratitude with my official and unofficial mentors: Daniel Belenky, Daniel Hiller, Fabian Deutsch, Roman Mohr, and Luboslav Pivarc, who made this last three months a real pleasurable career-changing experience. Not to mention every community member who helped me by answering questions at the slack channel or interacting through issues and PRs. I hope I get the chance to meet all of you in person someday!
What’s next?
Well, without a doubt I want to keep contributing to KubeVirt as a volunteer. I still wasn’t able to implement everything I proposed, so there is still a lot of work to be done. Also, it’s a great opportunity to keep learning from experts on how to become a better software engineer.
Observability of distributed systems has always been a big interest for me, so I will keep an eye for every new functionality that could use some metrics. I’ve used ELK, Loki, and Jaeger on previous jobs, but I’m not too familiar with other areas of observability, so I hope I can get involved with logging and tracing issues around KubeVirt in the future as well.
The main functionality of KubeVirt is virtualization on top of Kubernetes, so it’s definitely an area that I want to get better at. Also, I want to be able to review other contributors’ PRs in the future and that requires me to understand KubeVirt far more deeply.
About my career, I’m considering going after my master’s degree in the parallel and distributed computing field… I think I have a pretty good idea about an architecture that implements Parallel State Machine Replication(PSMR) for stateful containers on Kubernetes, inspired by Prometheus’ WAL for a faster recovery. And of course, I’m looking for jobs in which one of the main responsibilities is to get involved and to contribute to cloud-native projects. Especially KubeVirt, Prometheus, and Kubernetes.
If you’d like to chat, you can find my twitter at @ArthurSilvaSens, that is also my tag name at both CNCF’s and Kubernetes’ slack, and my LinkedIn profile🙂
See ya.
