|
|
|
|
“There are tens of thousands of open source components being used across a typical enterprise. All of them need tracking for vulnerabilities.”
|
|
|
Site reliability engineers (SREs) are constantly balancing priorities. The job role continues to evolve but is very much real. Catchpoint’s “2020 SRE Report” surveyed over 600 people that do SRE-type work, of which 46% said their organization has a dedicated SRE team that is distinct from teams that handle IT operations and administration. Still, the role is often conflated with DevOps, with 19% of the respondents saying the DevOps team handles SRE responsibilities. In fact, there is reason to believe the two functions can be managed as a whole — 41% said SREs and DevOps are part of the same team, while only 26% consider them to be complementary.
While SREs juggle both development and operations responsibilities, more than half spend less than 25% of their time doing development. Almost half (48%) spend a moderate or large amount of time writing software to help with operations, with much of that code helping to automate previously manual tasks. Although it will take many years to make most infrastructure programmable, SREs can be expected to be leading the way as 71% said infrastructure-as-code is used by site reliability engineers.
Overall, monitoring and incident management continues to be the most common activities performed by SREs, but 55% said that application release and deployment management tools are used by SREs. As long as DevOps is the primary owner of application release management, then the distinction between the two teams will likely continue. However, this just means that there will be a new area of conflict. Is it self-evident to you whether SREs should focus on monitoring infrastructure or applications?
|
|
|
One of the bright points to emerge in Kubernetes management is how the core capabilities of the Istio service mesh can help make engineering teams more efficient in running multicluster applications. In this edition of The New Stack Makers podcast, we spoke with Dan Berg, distinguished engineer, IBM Cloud Kubernetes Services and Istio; and Neeraj Poddar, co-founder and chief architect, Aspen Mesh, F5 Networks. They discussed Istio’s wide reach for Kubernetes management and what we can look out for in the future. Alex Williams, founder and publisher of The New Stack, hosted this episode.
|
|
The New Cloud Native Radar
Every time we chat with an executive from the Cloud Native Computing Foundation, we always ask about the CNCF Cloud Native Interactive Roadmap. Here is CNCF’s comprehensive list of all the technologies — not just those hosted by the CNCF — that can be used for cloud native deployments. The list itself is quite voluminous, listing 1,395 entries at last count. While comprehensive, the interactive map leaves a lot of questions: How can a CTO pick and evaluate the right tools for the job?
The good news is that more help is on the way, thanks to the new CNCF Technology Radar project from the CNCF End User Community.
This initiative seeks to help in the selection process of cloud native technologies by offering curated recommendations about which technologies may be more ready to use than others. Every quarter, the group — comprised of representatives from over 140 cloud native-savvy companies and startups — will post a set of recommendations covering a certain group of technologies, along with patterns of successful usage.
For the initial round, the group looked at continuous delivery (CD) tools, a current hotbed of development. Each technology is put into one of four buckets:
- Adopt: A stable and useful technology that has been in production use for a while. The highest recommendation.
- Trial: A recommendation to test a technology that has been deployed with success
- Assess: A technology that has been tested and shows promise, but hasn’t yet won enough approval.
- Hold: A technology that has more suitable alternatives.
In CD Radar, for instance, both Flux and Helm are in the Adopt category, as their usefulness and stability have long been proven. In the Trial category fall CircleCI, Kustomize and GitLab, each of which has shown promise but may lack certain features or may not yet have enough champions. Technologies can fall into the Assess category for multiple reasons: Jenkins, for instance, is well-known in the community, though users are also moving away from the technology for newer alternatives. Alternatively, Spinnaker also has wide awareness in the community, but not enough users to be recommended.
For us here at The New Stack, such recommendations are gold mines. While we can talk with end users about what technologies work and don’t work for them, few can be able to talk “on the record” about their findings, due to legal or company PR rules. We applaud the CNCF End User Community for taking on the hard work of forging a road (map) through the vast cloud native landscape.
|
|
|
IT automation software provider Puppet has released into public beta its event-driven automation platform, Relay, software used to manage task-driven and model-driven automation. Relay comes with a number of pre-written workflows and connections to cloud platforms, tools and APIs, including PagerDuty, GitHub, Datadog, Jira, Terraform and Slack.
|
|
|
Here is a contributed post from Split Software’s Adil Aijaz that discusses the importance of controlled rollouts, or the ability to taper rollouts of a new feature in your app through the use feature flags. Thanks to automated development pipelines, the time has come for this technology. “Controlled rollouts are a powerful tool that allows product engineering teams to get creative while decreasing the blast radius of errors and also test in production,” Aijaz wrote.
|
|
|
Last week, project management software provider Basecamp showed off its multimillion-dollar effort to reinvent email, a service called HEY. This isn’t the first high-profile attempt to reinvent email — but with some streamlining and some innovation, Basecamp has come up with a number of fresh innovations that are causing a lot of people to take a second look at this age-old internet technology.
|
|
|
|
Caitlyn O'Connell, senior marketing manager for Cloud Foundry Foundation, gave a powerful intro for Dr. Shakti Butler's Diversity Luncheon “How Did We Get Where We Are? The System of Racial Inequity” at the Cloud Foundry Summit North America.
|
|
|
Chip Childers, executive director at Cloud Foundry Foundation, said during his keynote at the Cloud Foundry Summit North America: "We will continue ... to do our part to help to dismantle systemic racism ... But everyone needs to do their part. And so, we welcome your ideas about what we can do to help drive change."
|
|
|
|
Dr. Shakti Butler, spoke at the Diversity Luncheon “How Did We Get Where We Are? The System of Racial Inequity” at the Cloud Foundry Summit North America. “Racial inequity is a problem of bad policy, not bad people,” she said.
|
|
|
JUNE 29 - JULY 02 // VIRTUAL
Open Source Summit
Join over 2,000 developers, technologists and industry experts in an exchange of ideas on the latest trends in open source and open collaboration, how to navigate the open source landscape, and how open source is shaping innovation. Register now!
|
|
|
|
The New Stack Makers podcast is available on:
|
|
A lot has changed since we published the original Kubernetes Ecosystem ebook in 2017. Kubernetes has become the de facto standard platform for container orchestration and market adoption is strong. We now see Kubernetes as the operating system for the cloud — evolving into a universal control plane for compute, networking and storage that spans public, private and hybrid clouds. In this ebook you’ll learn:
- Kubernetes architecture.
- Options for running Kubernetes across a host of environments.
- Key open source projects in the Kubernetes ecosystem.
- Adoption patterns of cloud native infrastructure and tools.
|
|
|
|
|
|
|
|
|
|
