|
|
|
|
“For the most part, the technology we’ve been building hasn’t been doing a good job of serving us. We built it as technology first, not for all of the humans that are connected to that service.”
|
|
|
Overcoming Problems With GitHub Stats
Assessing who contributes to an open source project is not as easy as running a few queries against the GitHub API. Yet, as we continue to see, that doesn’t stop people from trying. Red Monk’s James Governor riffed on the risk of using GitHub stars. We concur because they can be gamed and are only a measure of ephemeral popularity among a subset of developers. As we wrote about before, GitHub organizations are a poor way to measure a corporation’s open source activity.
A better, but still limited way is to look at contributors’ email address to identify their employer. Google’s Felipe Hoffa uses this approach to report that Microsoft had over 1,300 employees push a contribution in 2017; Google had 911 employees and Amazon had 134. As Felix explains in his methodology, the data was filtered to exclude many legitimately active repositories and contributors. Furthermore, it excludes participants that are only submitting issues and entire organizations that use over version control systems for most of their development activity. Yet, it is possible to conduct a similar analysis for non-GitHub projects. For example, the 2017 State of Linux Kernel Development identified the top organizations involved with recent Linux kernel development. Unsurprisingly, Intel, Red Hat and Linaro topped the list, with many chip producers making an appearance. Yet, the report also said over eight percent of contributors came from a company called “none” and another four percent came from “unknown." This was not a mistake. While unknown means that the contributor’s identity and or affiliation could not be identified, “none” represents developers that may have a day job with a bit company, but are doing the work on their own.
What is someone to do? Can they use GitHub stats to identify winners and losers? Can data prove, for example, that AWS is not as committed to open source as other cloud providers? Companies should probably benchmark their software development processes, but against what metrics? While there are no easy answers, the Linux Foundation is supporting standardization efforts with the Community Health Analytics Open Source Software (CHAOSS) project. Within this group is a Metrics Committee trying to define implementation-agnostic metrics for assessing open source communities' health and sustainability. In other words, they’re getting together lots of people that have done this type of analysis in the past and working towards consensus on common variables and ways to apply data to various use cases. Perhaps one day we’ll be able to argue about the data without arguing about the methodology. Until then, stay tuned for more open source analysis from The New Stack.
|
|
|
“Sometimes the shift to Kubernetes opens the door to re-evaluating a lot of other things that might make it easier to get to CI/CD,” said Craig Martin, the senior vice president for software engineering and consulting firm Kenzan, as part of a panel for this edition of The New Stack Analysts with Alex Williams, “and look at how they work with technologies holistically. Kubernetes is not the thing that gets them there, but it might be the thing that opens up the door, to get them to think even bigger than they did before.”
Martin was joined by Microsoft software engineer and Kubernetes co-lead Michelle Noorali, and Google staff developer advocate Kelsey Hightower, for a wide-ranging discussion of the key topics for the upcoming KubeCon and CloudNativeCon events, scheduled for the first week of December in Austin, Texas. Noorali and Hightower will co-chair this year’s KubeCon. Listen now to this panel discussion, and get a glimpse of how the leaders of today’s growing Kubernetes community may be taking some time for introspection.
|
|
The New Battle Lines
In a recent Vergecast podcast (the flagship podcast for The Verge consumer tech website — it’s pretty fun, check it out), Verge editor Dieter Bohn railed against the impending death of the mobile phone audio jack, the universal standard for plugging in headphones. As music fans, we took note at TNS.
Both Apple, and now Google, are removing these jacks from their phones in favor of proprietary wireless headphones. Sure, users can still opt for third-party Bluetooth headsets, but they never will work as well as the tightly integrated (and probably more expensive) sets from the phone manufacturers themselves. This might be the way of the future for some time, Bohn lamented. With their consumer products, Apple, Amazon, Google and Microsoft all now follow the same playbook: offering a seamless delivery of content through tight integration of hardware, software and services. It really is the only way that voice assistants like Alex, Siri and Google Play can offer an excellent experience, with all the many connecting pieces working seamlessly.
Could the same hold true for the cloud services these companies offer? Certainly, Microsoft CEO Satya Nadella has made a mantra of hardware, software and services. Could tomorrow’s CTO fret over the question of which big cloud provider to go with, weighing if Google BigQuery and container engine service would be a better or worse fit than AWS’ Redshift and container service? And correspondingly, less thought may be given to using an out-of-the-box open source software that would need to be assembled from scratch. And what about Kafka vs. Spark? Mesos vs. Kubernetes? Break out the aspirin.
While these choices may offer greater flexibility, they also bring more complexity into the perpetual “do more with less” IT environments of today. This morning, we ran a nifty case study about how Amtrak bypassed containers altogether to go with AWS Lambda and related AWS services. For the data layer, the rail service looked at various NoSQL options (Couchbase, MongoDB) but went with an all-AWS stack instead.
At TNS, we’ve covered in depth the evolution of open source software and its value over proprietary enterprise software. But that battle appears to be coming to an end (tl;dr: open source is winning pretty handily). The new battle is certainly around the convenience of the cloud providers’ own value-added, and increasingly trouble-free, services versus the freedom of using open source tools to make cloud providers themselves as much of a commodity as possible. Mirantis’ Boris Renski makes a good case for the latter view of this world. Read it and tell us what you think.
|
|
|
Microsoft’s new Brigade is a framework for scripting together workflow tasks to be executed inside of containers. The Kubernetes-native tool allows devs to build an ordered workflow of Kubernetes containers in any magnitude, from one to multitudes.
|
|
|
Development of machine learning applications has required a collection of advanced languages, different systems, and programming tools accessible only by select developers. Before you break out the credit card for some TensorFlow cycles, take a look at all the machine learning magic you can do through plain old SQL first.
|
|
|
We’ve been following the emerging practice of something called “site reliability engineering,” which has been pioneered by — who else? — Google. In this write-up from a talk at New Relic’s FutureStack, we learn how the company carries out this discipline. “It’s really about communication, humility and trust,” Google engineer Liz Fong-Jones said. New Relic’s own Matthew Flaming called the SRE role “the purest distillation of DevOps principles into a particular role.”
|
|
|
|
From left to right: Nikhil Deshpande, Kendra Skeene, Jenna Tollerson, all of Digital Services Georgia.
|
|
|
Shane Curcuru of Punderthings Consulting and Jim Jagielski of Capital One.
|
|
|
Kubernetes emerged from a need to run cloud-native applications on a massively scaled network, and that’s exactly what it’s enabling its growing user base to do. The demand for platforms that can run web-scalable workloads means Kubernetes is increasingly under consideration by IT engineering teams, and many will choose to adopt the project.
This ebook serves as a primer for both newcomers, assessors and implementers who are looking to make the most of the ecosystem of products and services emerging around Kubernetes. We also go well beyond the basics and explore where Kubernetes fits into the DevOps pipeline, how to overcome production challenges, and considerations for Kubernetes adopters.
|
|
|
|
We are grateful for the support of our ebook foundation sponsor:
|
|
|
|
|
|
|
|
|
