This month, we’re shining a spotlight on CNCF Ambassador Alex Ellis, the creator of OpenFaaS, an open source serverless platform on the CNCF Landscape. But that’s just the tip of the iceberg of what Alex has contributed to the community. You may also know him from the numerous other open source projects he’s created, as well as the tutorials he’s written and the talks he’s given.
Alex answered a few questions about how he’shelping companies and individuals understand how CNCF projects fit together and when to adopt them.
What led you to the cloud native community?
I’ve been working with software for most of my career now with a strong focus on engineering and on architecture. The first half was focused on the enterprise with proprietary software, and the second half has seen me learn programming languages like Node.js, Golang, Python, and Ruby. I see this as a kind of renaissance for my career, and it was the catalyst for me creatingOpenFaaS.
OpenFaaS is one of the most popular open source serverless platforms on the CNCF Landscape, but it actually started way back in 2016. I wanted to build functions in containers instead of zip files, and to run them anywhere, not just on within cloud-based platforms. Today there’s been hundreds of contributors, and the community of end users and developers is thriving — it’s the highlight for me.
Cloud native took over my career, and now I spend most of my time consulting with companies that are adopting Kubernetes or cloud computing and helping them speak to developers about their products.
How did you get more involved in the community?
My first touch with cloud native was with Docker; I’d created a series of training courses and was invited to be a Docker Captain. After that I moved my focus to Kubernetes and other CNCF projects and started learning about them and writing beginner and intermediate tutorials along the way.
As I’ve helped users, I’ve created various other open source projects for solving problems users run into:k3sup.dev helps users bootstrap Kubernetes fast,arkade is a tool to install Kubernetes applications using Helm, andinlets is a Cloud Native tunnel to open up any internal services you may have to the internet.
Why did you become a CNCF Ambassador?
Whilst I don’t run a meet-up group, I do spend a lot of my time writing tutorials and speaking about the various CNCF projects and make heavy use of them in OpenFaaS, such as Prometheus, Linkerd, NATS, and Kubernetes.
My goal is to help companies and individuals understand how CNCF projects fit together and when to adopt them. For a recent consultation, the best advice I could give a friend was to make investment in hiring DevOps talent, rather than taking on Kubernetes too early. Being independent, and not paid to push certain products, means that I can give impartial advice and help people pick the right solution for them.
One of the highlights of the year for me is KubeCon — being able to network and connect with so many other people working on similar problems and to collaborate with them.
In your experience, how has CNCF been helpful to you as an individual not working for a large company?
Running an independent open source project and business can be an uphill struggle at times, so any support is appreciated. CNCF offers discounts for events and training courses to CNCF Ambassadors, which would not normally make much difference to an employee at a FAANG company, but can be the deciding factor for someone who is funding their own way.
What message would you like to send to the cloud native community?
Adopting cloud native technologies can be challenging, and at times, you may find yourself feeling confused or out of your depth. I think that’s a natural feeling, but it does subside. I didn’t learn everything overnight. Starting out with a clear problem statement and exploring the more obvious options should be first of mind. If you are unsure whether you should adopt containers, serverless, service mesh, or all three, then the community and many independent businesses are here to help you make an informed decision.
We’re midway through this year’s Google Summer of Code, during which more than 1,000 university students around the world contribute to open source projects, including those in CNCF. So for this round of community spotlights, we’re profiling Goutham Veeramachaneni, a former intern who has gone on to become a maintainer for Prometheus and Cortex— and a GSoC mentor himself!
Goutham took time to chat about going from intern to mentor and getting a cool job along the way.
How did you get interested in cloud native technology?
I was doing my first summer internship at a startup, and they had very poor observability systems. They had to SSH into systems and check the logs and I was tasked with setting up a monitoring system across their 5,000 targets. I evaluated InfluxDB and Prometheus and chose Prometheus for the project. It was at a large scale, and we ran into problems like running out of inodes on disk. I jumped onto the Prometheus mailing list, and the community and maintainers were quick to answer all my questions, and this positive experience made me want to contribute. Unfortunately, I didn’t immediately find time. Six months later, I found out that CNCF was participating in GSoC, and I saw no reason not to contribute. 🙂 Fabian Reinartz was working on a new version of the storage engine and asked me if I could contribute. I jumped at the chance and never really stopped I guess 🙂
Do you remember your first open source contribution?
To Prometheus? Very vividly! It is this PR. I was very new to Go and all the best practices, and I needed to redo my PR several times, but the maintainers were super nice and explained everything clearly. The experience felt very welcome, and after it got merged I remember just going around my college dorm showing it to everyone who’d look. 😛
I did have a little experience contributing to OSS projects before though. I actually learned how to code contributing toReaction Commerce.
How did your summer internship impact your career path?
So, a confession. I actually didn’t end up accepting the GSoC internship. CoreOS gave me another offer for an internship doing all the same things (contribute to Prometheus full-time), but I could also travel to the Berlin office for a couple of weeks to spend time with the team, and I decided to take that! I contributed to Prometheus and went to Berlin to hang out with the wider Prometheus team as well as the CoreOS team. 🙂 I also gave my first public talk at theBerlin Prometheus meetup!
After this, the community encouraged me to give more conference talks and I did just that. I’ve met and continue to meet so many amazing people in all the conferences! All the conversations I’ve had with the community over IRC, Slack, and in person affected my thought process and career path immensely. In fact, I was hired into Grafana Labs, my current employer, by Tom Wilkie, another Prometheus maintainer whom I met at conferences!
What other open source projects are you working on?
Most of my time today is spent maintaining and contributing toCortex, another CNCF project that provides a horizontally scalable Prometheus implementation backed by cloud storages. We are currently using Cortex to provide a hosted Prometheus SaaS service at Grafana Labs, which is enabling me to contribute full-time to both the Prometheus and Cortex communities.
What do you think are the most important responsibilities of a project maintainer?
Having a healthy and welcoming community! Code can be great, but for adopters and contributors, the first and ensuing interactions with the community will be more important than features and code. A maintainer needs to make sure that there is clear documentation for the project and also that newcomers to the community feel welcome. I think the Prometheus community did a great job at it, which made me come back to it 6 months after my initial interactions. 🙂
Have you worked with GSoC as a mentor since your own internship? What was it like to be on the other side of it?
I did! It was great! I mentoredGanesh Vernekar, and that was one of the most fulfilling things I’ve done in my career. He took over my Prometheus maintainer responsibilities when I started focusing on Cortex and made a ton of valuable contributions to the community in ways I could not have imagined! This is one of the instances where the student definitely surpassed the mentor! He is still very active in the Prometheus community making surePrometheus and the surrounding community have the fastest and leanest TSDB out there!
Being on the other side was eye-opening. I did not realize the amount of time required to mentor someone, and I definitely leaned on the community to fill the gaps when I was busy. Having said that, it is also the most fulfilling role. 🙂
What advice would you give to the current crop of interns?
I would say once you’re comfortable around the community, start contributing outside just your code. Help users with their questions in Slack, IRC, mailing lists, etc. This will give you unparalleled insight into how people are using the software and even features you’ve built yourself! Also, don’t be afraid to leave a review on PRs. While you won’t catch all the bugs, you’ll still gain a lot of understanding into how reviews are done, and within no time you’ll be doing insightful reviews!
Don’t stop! If you just stop right after GSoC, you won’t fully benefit from the OSS ecosystem. It takes around 6 months of consistent contributions (need not be full-time, just spend 10 hours per week, but be consistent) to become a maintainer, and once you become a maintainer you’ll be on a fast track in the software engineering career ladder! You’ll learn how to build communities and how to maintain OSS projects, which will come in handy even in your day job. And more likely you’ll end up getting a job where you’ll be paid to be part of the community you love. 🙂
And finally, make noise around the work and the project! Write blog posts, give conference and meetup talks, and just speak to people about your work. All of your work is open source, which means you can talk about it as much as you want. 🙂 And do just that and people will start taking notice, and this will help you find potential employers as well!
Congratulations to the Fluentd project for the release of Fluent Bit v1.5! We’re spotlighting Fluentd, which graduated within CNCF last year, for this major release from its sub-project Fluent Bit.
“Fluent Bit v1.5 is a great milestone for the community,” says Fluent Bit maintainer Eduardo Silva. “What makes it special is the joint work of many companies that use it internally and with their customers. On this release we see contributions coming fromAmazon,Google,Sumo Logic,LogDNA,New Relic and 2nd Quadrant, among others. All these companies are adopting Fluent Bit to solve their logging needs. They either use it as a standalone service or together in combination with Fluentd. On this release we are providing certified connectors for the services provided by these companies.”
Another important development is the integration withGoogle OSS Fuzz on critical parts of the Fluent Bit code base, which is fuzzed 24×7. “From a performance perspective, we did even more improvements reducing overall CPU and memory under high-load scenarios,” adds Silva. (For more details about the release, join his Fluent Bit v1.5 webinar on July 17.)
But that’s not all the Fluentd project has accomplished this year. Fluentd maintainer Masahiro Nakagawa notes that Fluentd users often deploy the service and “barely touch it again since ‘it just works.’” But that also meant that several companies were using very old versions of Fluentd, particularly v0.12. “So this year we worked together with the community to help in the migration phase toward the latest improvements, which has been a major milestone for us,” he says. With that work done, the team has been “focusing on stability and strong connectivity during our v1.x cycle,” Nakagawa says. One notable new initiative is providing Fluentd packages for Arm64.
For community members, Nakagawa says there are different ways to contribute. “If you are a developer, you might want to be interested in writing an extension for Fluentd, either an input, parser, buffer, or output plugin,” he says. “Written materials are always welcome! If you want to write documentation, tutorials or arrange webinars, you are welcome to participate. Every person who has experience with Fluentd as a user likely is in a position to share some level of knowledge. Just raise your hand and you will get our support.”
With Fluentd and Fluent Bit growing on many platforms — cloud native, IoT, and more — the team hopes to “continue working towards community needs and solve any hard challenges end users are facing in the data management space,” says Nakagawa. “Fluentd has been around for 9 years, and even today we see new challenges to solve. Next year Fluentd turns 10 years old! It will be a great time to launch Fluentd v2.0.”
Congratulations to Helm! Recently graduated within CNCF, Helm is the latest subject of our project spotlight.
We spoke to two Helm maintainers — Matt Butcher, a Helm co-founder and Principal Software Development Engineer at Microsoft, and Matt Farina, a Senior Staff Engineer at Samsung SDS — about how the project reached this point and where it’s headed next.
Graduation is of course the big milestone, but what are you proudest of along the way?
Matt Butcher:We hit one million Helm downloads per month in November 2019. That was a really exciting milestone for us. Knowing that so many organizations and users have put trust in our project is a momentous occasion — though one that brings a high burden of responsibility.
At KubeCon San Diego, we got to do our first big introduction of Helm 3. Helm 3 had been a long and frustrating journey for us. The development work was arduous. It took longer than we wanted, and all the while we were frantically trying to keep Helm 2 up to date. KubeCon felt like the victory lap, and a good chance to celebrate all of the contributions and contributors that made Helm 3 a reality.
Matt Farina: When it comes to developing software, there are a lot of competing voices with opinions. There are Kubernetes insiders who know how the sausage is made. There are new application operators who are just getting started. There are those at fast-moving startups. There are those at slow-moving enterprises with regulations they need to meet. And just about everywhere in between.
The Helm developers have taken the time to listen to users and potential users. For example, some of the changes made to Helm v3 and the changes we are talking about in the coming year are targeted at making application operator experiences better and easier. I am proud that the Helm maintainers take the time to listen to end users and work on solutions to their real-world needs.
I think this is one of the things that’s made Helm a success.
Can you talk a bit about the graduation requirements, and how well Helm measured up on all the criteria?
Matt Farina: Graduating is no easy task. We didn’t just want to pass but wanted to excel at the graduation criteria.
For example, one of the criteria is to obtain a Core Infrastructure Initiative Best Practices badge. We not only obtained the best practices badge but are almost all the way to the silver level. This included the creation of a Helm Security Assurance Case, which looks at the way Helm is developed and operated from a security perspective.
Another requirement related to security is having completed a third-party independent security audit. This audit looked at both Helm and the security processes we have around the project. I was blown away at the conclusion from the security auditors, who wrote:
To conclude, in light of the findings stemming from this CNCF-funded project, Cure53 can only state that the Helm project projects the impression of being highly mature. This verdict is driven by a number of different factors described above and essentially means that Helm can be recommended for public deployment, particularly when properly configured and secured in accordance to recommendations specified by the development team.
A third criteria deals with adoption. While not a listed element in the criteria, which looks for some names of those using Helm which we provided, we also looked at Helm downloads over time in the spirit of viewing adoption. Between KubeCon + CloudNativeCon San Diego and Helm graduation, which was a little less than 6 months’ time, the number of downloads per month had doubled. I had to double check those numbers as I was just so surprised by them.
What are your goals or personal hopes for Helm?
Matt Butcher: I think the most interesting thing about Helm, vis-a-vis CNCF, is the fact that we are an old project. Helm was introduced at the very first KubeCon, and has grown up alongside the cloud native community. Over time, we have watched the broad CNCF community change from the “wild west” of research, experiment, refine to the mainstream enterprise market. I think every single one of the Helm core maintainers will tell you that today we spend most of our time talking about stability and maintainability, not new features and fun ideas.
In this vein, Helm will have two major challenges over the next few years.
On the one hand, we will have to learn how to say “no” to exciting features that are either too experimental or are of only niche appeal. I think Helm 3 is the last release where we’ll see any major feature changes. On the other hand, Helm has become the main “interface point” to Kubernetes for so many people that it is now incumbent upon us to protect people from the changes in Kubernetes. In this way, the Helm community has asked us to be the “backward compatibility” layer for Kubernetes. It’s an interesting circumstance to find ourselves in, but if we want to welcome and support the mainstream enterprise with its steady cadence, this is very much something that we should prioritize.
The days of “moving fast and breaking things” are over for Kubernetes, for Helm, and for the rest of the graduated CNCF projects. Sometimes that is hard for people like me to accept. I look back with fondness on the days when we could spike out a new Helm feature in a few days, and then cut a brand-new release a week later. Now, it routinely takes months to get a single pull request merged. An idea for a new feature might require months of debate, only to be rejected at the end. But if we are to keep the user’s best interests in mind, then this is absolutely the way we should go. So it is not just the project that must mature, it is us as core maintainers as well.
Any shoutouts you want to give to the community?
Matt Farina: In the past year we have seen some new people and new contribution areas that, I think, deserve to be highlighted. These are beyond the usual suspects and typical Helm topics.
Marc Khouzam rewrote the way Helm handles auto-completion to make it easier to work with. The feature worked so well, he was able to get it upstreamed into Cobra, which Helm uses for its base console functionality.
The OCI is working on artifact support in distributions, which will allow us to store Helm charts in container repositories. Josh Dolitsky has done a great job working with the OCI and getting code, currently in experimental form, into Helm to support this.
Helm is moving to a distributed Helm repository environment, where we make it easier for organizations to run their own repositories. Scott Rigby and Reinhard Nägele have been working on tools, including GitHub Actions, to make the automation easier. You can find the actions in the GitHub Marketplace.
These are just a subset of the people doing amazing work in the community. There are too many to name, and we appreciate all of them.
Matt Butcher: I almost feel like it would be unjust to call out only a few. Thousands of people have contributed over time. And sometimes it’s those small patches or updates to the documentation that make a world of difference. But I do feel like I should call out Martin Hickey, one of the Helm core maintainers, for his long-term “chop wood, carry water” mentality. If one were to assemble a room full of Helm users, and then ask those in the room to raise a hand if Martin had helped them (via Slack, via issues, or even with his helpful utilities and conference talks), I would not be surprised if 75% of the audience put a hand in the air.
Of course, Martin is not the only generous soul in the community, but I am deeply appreciative of the work he has done day after day.
What do you want the greater community to know about Helm?
Matt Butcher: Since the very first day of Helm development, we have called it the “package manager for Kubernetes.” Hidden in that phrase, though, are two goals that we keep at the top of our minds:
Helm should be a reliable tool for installing, upgrading, and deleting Kubernetes applications.
Helm should be the easiest way for a new Kubernetes user to install their first application.
It has been hard to stick to these two goals. Many people want Helm to be a replacement for Chef or Puppet or tools like that. Others pit Helm as a competitor to the operator design pattern. Still others want us to morph Helm into an application management platform. It was not until recently that we, as the core group of maintainers, had to begin to draw some lines. Helm cannot be the Swiss army knife of the cloud. And we shouldn’t be. There are thousands of brilliant developers out there building excellent tools in each of those niches. The mentality that we need to “own the space” is, to put it bluntly, nonsense.
At the end of the day, Helm needs to stay true to its role as the package manager for Kubernetes, and strive to meet those same two goals we set out to achieve five years ago.
Maturing as a project is hard. Maturing as a developer and a project leader is hard. But I earnestly believe that if we can build a project that keeps a tight and narrow focus, we can produce a superior tool that solves a core set of problems well. If we let our focus drift, we may solve more problems — but we will solve them poorly in ways that frustrate and ultimate drive away the users we care about.
We’re shining the spotlight on Ariel Jatib, CNCF Ambassador and webinar moderator extraordinaire.
Ariel first got involved with the cloud native community when he started the NYC Kubernetes Meetup in 2015, and helped organize many of the groups in cities like Seattle, San Francisco, and L.A. He is currently a Business Development Manager for cloud native at NetApp, which acquired his company, StackPointCloud, in 2018.
More recently, he’s become very active in moderating CNCF webinars — 9 and counting! “With no meetups happening [right now], I’ve had more time to host webinars,” he says. And it fits in with what he considers his overall goal as a CNCF ambassador: “To promote cloud native technologies and the spirit of the community.”
Ariel took some time to chat with us about being an ambassador.
What’s the best part of being an ambassador? Any fun KubeCon + CloudNativeCon memories?
I’ve always enjoyed the ambassador breakfast at KubeCon. It’s there I join up with [fellow ambassador and MLB Principal DevOps Engineer] Mike Goodness and we go to catch the opening keynotes. We’ll say hi to Nanci Lancaster from [the Linux Foundation events team] after the talks — she was key in helping the NYC group grow while working at DigitalOcean. Coffees with Joonas Bergius. Those traditions bring me joy, and it’s something I look forward to at each KubeCon.
Do you have any favorite moments from the webinars?
Are there any shoutouts you’d like to give to the community?
A big shoutout to the NYC blueberries — Paul, Stephen, Pop, Liz. May we all soon enjoy each other’s company and some deviled eggs. Shoutouts to Mark Coleman, Daniel Sasche a.k.a. RUNK8S, and the old StackPoint crew — Matt, Pabs, Fran, Nate, and Tareque.
Any final thoughts?
Thank you all for a magical ride. May you and your loved ones be safe and be well during these trying times.
You’ve seen her on the keynote stage as co-chair of the 2018 KubeCon + CloudNativeCon events in Copenhagen, Shanghai, and Seattle. Now Liz Rice is settling into her new role as chair of CNCF’s Technical Oversight Committee (TOC). In this community spotlight, we’re celebrating Liz and her many contributions to the cloud native world.
Liz, who’s the technical evangelist at container security specialists Aqua Security, took time to tell us about her journey from open source contributor to TOC chair.
Please tell us a bit about how you got into the cloud native world.
My interest in programming started as a child when we got a ZX80, and from that point on I knew I’d work with computers. At the start of my career I worked on network protocol software, and then spent a few years at consumer-facing companies Skype and Last.fm. I was working on a TV and film recommendation service when I first heard of Docker from one of our neighbors at an accelerator, and ended up a few months later co-founding another startup called Microscaling, where we explored container auto-scaling (way before it was fashionable!). Then I joined Aqua Security, where I got really immersed in cloud native security.
Do you remember your first contribution to an open source project?
I couldn’t remember it, so I looked it up — the PR was called “Make social-friends-finder work with django-allauth” back in 2012.
Is there any advice you’d give to people who want to start contributing?
By the time I started wanting to contribute, I already had years of development experience, and my initial fears were more about the social side of it: I was worried about getting the process wrong, or unintentionally offending someone, or not having the credibility to have my changes accepted. Open source is as much about collaboration as it is about code, so it’s helpful to remember that you’re dealing with other people! I’ve seen people get disheartened because they tried to do too much at once without discussing changes first, creating a giant PR that’s hard to review. It’s a good idea to start with small changes, or by explaining first what you’re thinking of doing, rather than jump in with thousands of lines of code. But my experience of open source, particularly in cloud native, is that maintainers are generally excited that you want to contribute, so they’re likely to welcome you and point you in the right direction if you ask for help.
Why did you decide to get more involved?
The cloud native world is based on open source, so when I started working with containers I found myself using lots of open source code. I was also starting to do more talks, and it made sense to publish the demos and code from those so that people could try them for themselves. I love experimenting with ideas and building proof-of-concepts to see how things work or whether certain ideas might fly, and the feedback loop from people using and building on my work was really rewarding. Fast forward to today, where I manage open source engineering at Aqua Security, with a team of great folks contributing to projects and building open source security tools that complement our commercial products.
How did you become KubeCon + CloudNativeCon co-chair?
[CNCF Executive Director] Dan Kohn reached out to me, and I jumped at the opportunity! My first co-chair was Kelsey Hightower, and I learnt a ton from him, particularly around trying to build a program that reflected what the community wanted to see (even though you can’t please everyone all of the time!).
Do you have any favorite moments from the KubeCons you co-chaired?
So many! In Copenhagen I remember asking the audience to help me pronounce the word “hygge” properly, and being amazed that people responded with such enthusiasm! It’s a real privilege – and SO MUCH FUN – getting to interact with so many people.
What led to your becoming TOC chair?
Once my time as co-chair came to an end, I really wanted to carry on being involved in some deep way with the CNCF, and I realised that I had built up some useful knowledge and experience. I had put together the project update keynote for three KubeCons, and that involved research across the whole breadth of the CNCF landscape. Whatever my inner imposter was telling me, I recognised that this knowledge was fairly rare. Combined with my general software engineering experience, plus some confidence-inspiring conversations with people who encouraged me to put myself forward, I figured it was worth throwing my hat into the ring.
What are your goals for this role?
One of our biggest challenges right now is dealing with the pace of incoming TOC work, which has increased dramatically as the cloud native ecosystem grows. TOC members are all doing this work alongside our full-time jobs at our various companies, so it’s a tricky balance! We’re working hard to streamline the processes, and leverage skills, time and enthusiasm from a broader range of folks to help us, through the CNCF SIGs. But it’s important to recognise that this work can’t be reduced to a simple pass-or-fail checklist; there will always be judgement involved – and the TOC members are elected for having the skills and experience to apply that judgement.
Also as the CNCF grows, and we have more end user members with more production experience to learn from, I’m keen for us to work more closely with them to make sure our project portfolio addresses their needs.
What message would you like to send to newcomers to the cloud native community?
Welcome! You won’t be unusual if you feel confused or overwhelmed at times, but there are a ton of people here who are really keen to help you find your feet.
Any fun facts about you that you’d be willing to share?
In my spare time I’m a decent cyclist and a very mediocre drummer!
This month, we’re shining a spotlight on Torin Sandall, co-creator and maintainer of Open Policy Agent, an incubating project in CNCF.
OPA has many recent developments to highlight: The v0.19 release includes a new parser for OPA’s language (Rego), which reduces memory allocations and improves performance by about 100x. New features have been launched in the playground to “help new users kick the tires, e.g., a catalogue of example policies, bundle serving, and better support for external context,” says Torin. Plus, the project has recently completed a security audit with the help of Trail of Bits, removed the use of finalizers, and added support for standalone audits of Kubernetes clusters.
Torin took time to answer a few questions about all the buzz around OPA.
Tell us a bit about your background.
I’ve spent most of my career building libraries, tools, and services for other developers. Eventually I became interested in helping organizations efficiently manage their stacks using more general-purpose technology. Declarative systems like Kubernetes and OPA are a key part of that story. I joined Styra as an early employee and co-created OPA (along with Tim Hinrichs and Teemu Koponen) to provide a building block that unifies policy and authorization across a range of technology. I’ve been maintaining OPA actively since inception.
What do you think is the most important part of being a maintainer?
Excellent question! I think there are many ways to be a great maintainer. Obviously it’s nice if you can ship the right features for your users as efficiently as possible. However, I think it’s equally (if not more) important to ensure that users and other contributors have a positive experience when they interact with the project. This goes way beyond just writing code. You need to care about developer experience, documentation, testing, support, process, communication, and so on. In the end, I think it comes down to focusing on quality (whatever that means to you) in as many areas as possible.
Any messages or shoutouts you’d like to give to the OPA community?
The OPA community is growing quickly. We’ve received a lot of positive feedback about the experience people have when they join Slack, post on GitHub or Stack Overflow, etc. So, as the community gets bigger, let’s continue to treat new users kindly and be conscious of the fact that people have differing experiences, points of view, and goals and sometimes those don’t align with our own. Hopefully OPA can continue to meet as many needs as possible.
I’d like to give shoutouts to the other OPA maintainers that keep the project going: Tim Hinrichs, Ash Narkar, Patrick East, Rita Zhang, Max Smythe, Sertaç Özercan, and Craig Tabita. I’d also like to recognize Stephan Renatus from Chef who has consistently supported new community members over the past two years.
How has being part of CNCF been beneficial to the project? What else can we do for you?
At a very high level, CNCF gives OPA a vendor-neutral home that is aligned with our goal of providing reusable building blocks to end users as well as vendors. More specifically, CNCF provides valuable funding for things like security audits as well as advice and support around project governance and community engagement. Also, CNCF helps us out with messy infrastructure needs like artifact signing. Keep up the good work!
Any final thoughts?
We’re always looking for new integrations between OPA and other software systems. If you’re interested in contributing code to the OPA community, this is a great way to get started. For example, we’ve recently seen end users contribute new integrations for projects like Kong and Kafka. Please reach out if this sounds interesting to you.
We’re kicking off our first project spotlight with etcd, which recently completed a security audit with Jepsen.
A CNCF incubating project, etcd is a distributed, reliable key-value store for critical data in a distributed system. As part of a security audit, the etcd team worked with Jepsen to verify etcd v3.4.3’s key-value operations, locks, and watches. The report, which was released earlier this year, concluded that there were no problems with key-value operations or watches. However, a theoretical risk discovered with the locks — that they could not guarantee mutual exclusion in asynchronous networks — led the etcd team to do further work on documentation around safety guarantees.
“Besides Jepsen analysis, the etcd community always welcomes contributions related to correctness and reliability,” says etcd co-creator Xiang Li. “We are excited about the results of this testing, and will remain vigilant while building a well engineered and correct product.”
Our first ambassador spotlight goes to Queeny Jin, who has been spreading the word about the incubating CNCF project TiKV since its inception in 2016. She’s been working at PingCAP, the company that created the project, since May 2016, and “I am very lucky to witness the birth, the development, and the evolution of TiKV, both in terms of the project and the community,” she says. “It’s so exciting to see how popular TiKV is after it became part of the CNCF community. Now it has 7.2k stars and 230 contributors all over the world.”
As a contributor to TiKV, Queeny says, “I have witnessed the importance and influence of the CNCF community,” so she became an ambassador to “make a difference together in the Chinese open source community and CNCF ecosystem.”
Indeed, one of Queeny’s biggest accomplishments has been making the content created about TiKV by Chinese contributors available to a wider English-speaking audience. “I see the potential of TiKV being the foundation of future cloud native infrastructure all around the world, so I decided to organize a team of transcreators (not just translators),” she says. “The content published on the TiKV website, such as the documentation and the blogs, are all from this team.” (One of the blogs was the 4th most popular post in CNCF’s 2019 annual report, with 13,859 page views: Building a Large-Scale Distributed Storage System Based on Raft.)
Here’s a quick interview with Queeny about her work with TiKV.
What do you want the public to know about TiKV?
The TiKV project aims to enable and empower the next generation of databases by providing a reliable, high quality, practical storage foundation. We are in the process of graduating and would really love to have your support.
Do you have any shoutouts for the TiKV community?
Thank you, my beloved contributors, committers, maintainers, adopters, and especially the great CNCF community, for your great contribution and support in the past! I believe we are on the right track to make TiKV the foundation of next-generation infrastructure and have a very promising future ahead of us. Together we can go further!
Is there anything else you’re working on?
I would also like to advocate for another project, chaos mesh, a Chaos Engineering Platform for Kubernetes. Chaos Mesh is a versatile Chaos Engineering platform that features all-around fault injection methods for complex systems on Kubernetes, covering faults in Pod, network, file system, and even the kernel. It’s in the process of being reviewed for the CNCF sandbox.
What’s the best part of being an ambassador?
Exposure to all these cutting-edge cloud native technologies (a lot of them!) and meet other cloud native people with the same vision.