4️⃣friday four Issue #23
Welcome to issue #23 of the friday four newsletter. Git's been ruling the roost as far as this week is concerned! With a bunch of exciting announcements on the GitHub blog, this week's newsletter was certainly pretty difficult to curate.
Apologies in advance for the rant against the Thursday section, because I do believe in keeping it real & trying to voice out concerns (surprise!) that I may have. Not all features are created equal, you see.
That being said, I hope you're looking forward to welcoming the weekend as much as I am and that you get some well-deserved time off from all things tech. But before you do, let's move on to our regular programming for Friday eve, shall we?
Thursday
I know this might not be as fascinating an update as a new release and I've forever been skeptical of things that help keep folks motivated in their journey - whether it be towards their fitness goals or open-source contributions. Primarily because a lot of it ends up being a way for things to be curated in a specific way. Don't get me wrong! I love curating content too, but given the kind of unhealthy competition this can lead to, I'm not sure if I really am a big fan of such trends. Who can forget the "What prevents you from coding like this" trend that had taken over all of Twitter a while back?
But coming back to GitHub Achievements that was launched yesterday - my thoughts on it are still mixed. While gamifying contributions is a great way to get more people involved, what are the tangible effects of those badges beyond recognition of the journey? I like the idea of having major milestones recorded, but I'm a bit wary about how easily these badges could become status symbols & promote an unhealthy atmosphere. That's just plain old overthinking me speaking, though and I'd love to hear what do you think about this?
For more information on what these badges are and what they signify, you can check out the introductory blog below.
Introducing Achievements: recognizing the many stages of a developer’s coding journey
Wednesday
While I had mixed feelings about the latest GitHub feature, as a documentation maintainer & technical writer, I'm thankful for this particular one! Signing off on commits via GitHub's web interface has always involved painstaking efforts owing to the absence of an alternative to the command line equivalent --signoff. Contributors are typically required to use "Signed-off-by:" in their commit messages so that they can pass the DCO checks. What's worse is that the phrase could easily be wrongly formatted or overlooked and cause an overall slowdown of contributions.
With this newly introduced feature by GitHub, project admins & maintainers can easily remove this extra overhead with a few changes at the repository level. Read more about it in the blog post linked below!
Admins can require sign off on web-based commits
Tuesday
With a plethora of new features & bug fixes, the folks on the Knative project have released v1.5 of the open-source solution that adds components toward the deployment, management, and running of serverless, cloud-native applications in Kubernetes. Go, check out the blog post below to learn more about the newest release!
Announcing Knative v1.5 release
Monday
WebAssembly, as a specification, is famous for its portability - across hosts & languages. It's no surprise then that considerations around how we could potentially leverage Wasm modules towards running distributed algorithms are being made at this juncture.
The proposal below is for the creation of a resilient & distributable data API that can bring us closer to the aforementioned goal. Standing on the shoulders of other active proposals for Wasm & WASI including interface types, modules, and shared-nothing linking, this one focuses on allowing a Wasm program to work with distributed data.
These are truly exciting times to be in the Wasm ecosystem & if this is an area you're currently working on, consider checking out the proposal by clicking the link below!
Bonus
CNCF's Security Technical Advisory Group has, in the past, delivered some stellar content to assist organizations with the planning, design, and implementation of secure cloud-native systems with the help of the Cloud Native Security Whitepaper and the Software Supply Chain Best Practices Paper. Towards helping organizations set up some guardrails in the form of checklists/automation, the first phase of the Cloud Native Security Controls Catalog is now available for public consumption.
What does this aim to do? Chock full of recommendations listed in the aforementioned whitepapers, additional implementation details, and a mapping of these controls to NIST SP800-53r5, the effort is designed to leverage & complement existing industry efforts in securing cloud-native infrastructure.
If you're a site reliability engineer, on the platform engineering, or on the DevSecOps teams, this is definitely something up your alley & you should consider giving this a read. Of course, legal, governance, risk, and compliance teams are part of the anticipated audience too, given their role in improving the security posture overall.
Introduction to the Cloud Native Security Controls Catalog
DevOps and CI/CD are two terms that almost, always go hand-in-hand. The State of CD in 2022 report linked below draws its audience a picture of DevOps adoption by detailing how software delivery performance has evolved and what are the factors affecting it.
According to the report, around 47% of the developers who took part in the survey used either continuous integration or continuous deployment and only one in every five developers (around 20%) used both. Not only is this indicative of continuous growth in the adoption of these tools, but it also signifies that even the sky isn't the limit with adoption across multiple sectors.
While I pride myself on keeping abreast of things in the cloud-native ecosystem, there definitely are times when I feel like I don't know enough. This post falls under the latter category. I've still got multiple re-reads before I fully comprehend the awesomeness of this.
But TL;DR: there's a pretty cool CNCF incubating project named Dragonfly that improves the large-scale distribution of container images by using P2P networks.
While the Nydus image acceleration service, a subproject under Dragonfly, was open-sourced earlier this year, this particular post linked below talks about its evolution.
P.S. It is definitely a tech-heavy post, so if you're anything like me make sure you have a lot of time set aside to grasp the meaty parts of the post!
The Open Source Technology Improvement Fund (OSTIF) performed a security audit of CRI-O, an open-source project that is the implementation of the Kubernetes Container Runtime. While the primary security finding of a high severity issue was reported from this search along with some minor issues, the general outcome of the audit was that CRI-O is a well-written project.
Read more about the GitHub advisory for the high severity issue here and check out the blog post linked below for more details on the audit.
Audit of CRI-O is Complete – High Severity Issues Found and Fixed