As we close out 2023, we at devopsy.kinsta.cloud wanted to highlight the most popular articles of the year. Following is the latest in our series of the Best of 2023.
Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: Scrum sucks, sources say; and here comes the Linux 6.5 kernel. (more…)
Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: VS Code drops support for Python 3.7, Windows drops VBScript, and Europe plans the fastest ARM supercomputer. (more…)
Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: Google fires hundreds of recruiters, and ARM gets a sky-high valuation. (more…)
Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: Birmingham looks like the Detroit of the UK—is it Oracle’s fault?
Plus: Was Toyota’s factory failure caused by running out of disk space? (more…)
Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: Rethinking return-to-office mandates and a ridiculous, ancient Windows bug. (more…)
Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: Redmond SaaS keeps failing, RISC-V is RISEing, and Meta is enforcing hybrid work. (more…)
The technical oversight committee (TOC) for the Cloud Native Computing Foundation (CNCF) announced today it is elevating the open source LitmusChaos application testing platform to the incubation level.
LitmusChaos is a chaos engineering platform donated to the CNCF by ChaosNative in 2020. Since then, it has seen adoption within production environments by more than 25 organizations, including Intuit, Lenskart, Orange, Red Hat and VMware.
ChaosNative CEO Uma Mukkara says LitmusChaos was developed to provide DevOps teams with a chaos engineering platform built using containers that makes it easier to scale up and down than existing monolithic alternatives. The platform itself, however, can be used to test both monolithic and microservices-based applications.
The platform consists of a Chaos Operator based on a software development kit (SDK); a ChaosHub for hosting and sharing experiments; Litmus Workflows that declaratively chains experiments (either in sequence or parallel) to build a chaos scenario; a centralized control plane, dubbed ChaosCenter, to design, schedule and monitor Litmus Workflows; Litmus Probes for creating chaos scenarios that automate steady-state validation and remediation actions and a Chaos Observability tool to export Prometheus metrics.
In total, there are now more than 400 contributors to the LitmusChaos project and more than 4,000 pull requests have been made. Mukkara said since the beginning of this year, Litmus operator installations have grown to more than 2,000 per day. Going forward, the goal for 2022 is to significantly increase the number of LitmusChaos integrations there are for a wider range of DevOps platforms, added Mukkara. Additional sets of experiments for Kubernetes and non-Kubernetes targets, improved observability and integration with other platforms—via the open source OpenTelemetry agent software also being advanced by the CNCF—is also planned.
In general, it’s still early days as far as the adoption of chaos engineering with DevOps workflows is concerned. However, Mukkara said that as more organizations embrace observability to better understand IT processes, the number of organizations that also use chaos engineering to test IT resiliency should also increase. In fact, as IT environments become more complex—thanks mainly to the rise of microservices-based applications—chaos engineering approaches to testing may someday be required, noted Mukkara.
In the meantime, there are still a lot of IT professionals that are uncomfortable with chaos engineering approaches to testing that deliberately break underlying services to test the resiliency of an application. The core idea, however, is that no application should have a single point of failure that could lead to it becoming unavailable. In theory, a microservices-based application won’t fail because when a service becomes unavailable calls are automatically rerouted to another service. The performance of that application will degrade, but it won’t go offline. The challenge is that building an application that achieves that level of resiliency using microservices requires a significant amount of DevOps expertise.
Regardless of how an application is constructed, the one thing that is clear is how dependent organizations are on applications to drive revenue. As such, the tolerance for application failures—or performance degradation—has never been lower.
Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: Working from home is de rigueur, JEDI redux, and more about Nvidia/Arm.
First up this week: GitHub’s annual survey of developers has some fascinating data on the workplace (ahem) “new normal.” The pandemic has radically changed devs’ expectations of where they can do their jobs.
As with other roles, Dev people want to continue to work from home. But does this pose a threat to your DevOps culture? Make sure you can do Ops with equal flexibility.
Paul Krill: Dev productivity is back to pre-pandemic levels
GitHub’s “2021 State of the Octoverse” research … sees signs that work rhythm is returning to pre-pandemic levels. GitHub also found that 46 percent of developers who worked co-located with teammates now expect to work fully remotely or in a hybrid environment.
…
Based on data culled from more than four million repositories and surveys of more than 12,000 developers … JavaScript and Python remain the top languages, followed by Java and TypeScript. [And] GitHub found that development team performance can increase as much as 87 percent when reusing code and as much as 43 percent when using … CI/CD.
Zeroing in on the WFH angle, it’s Richard Speed:
Respondents who were in the office either full or part-time dropped from 42 percent before the pandemic to a mere 10.7 percent now. … That’s a lot of empty desks.
…
Fans of the ctrl-c, ctrl-v combo will be delighted to note that GitHub found that when code reuse was made “frictionless” at work, developer’s performance increased by up to 87 percent. … It’s all splendid stuff.
But beware of statistical fallacies, thinks Henrik Ingo—@h_ingo:
#WorkFromHome may have been more common than anyone realized. [But] is the population of GitHub users/respondents somehow skewed toward pioneers/early adopters? … This might be a case of correlation is not causation.
The DoD issued its latest cloud contract opportunity notice, with the snappy title of “Joint Warfighting Cloud Capability” (JWCC). Reading between the lines of the notice, it all sounds very DevOps-cum-Agile.
The Pentagon has backed away from its previous insistence on a single supplier, and now wants at least two cloud providers.
JWCC is the follow-on from the aborted JEDI procurement. Amazon Web Services was “disappointed” to have been passed over in favor of Microsoft. Now it appears the DoD wants them to share.
What can you learn from such a multi-vendor DevOps strategy?
Jordan Novet: Pentagon asks Amazon, Google, Microsoft and Oracle for bids
Amazon and Microsoft were the finalists for a single Joint Enterprise Defense Infrastructure. … Microsoft won it in 2019, Amazon filed a protest and the Pentagon canceled the contract in July.
…
The new effort [is] known as Joint Warfighting Cloud Capability. … JWCC differs from JEDI because it allows the Pentagon to rely on multiple cloud providers.
…
The U.S. General Services Administration … said only two U.S. cloud infrastructure providers, Amazon and Microsoft, appear able to comply with all of the Pentagon’s requirements. … The value of the new contracts is not known, but the Defense Department estimates it could run into the multiple billions of dollars.
In summary, heed this Anonymous Coward:
Competing suppliers will try harder than one non-competing supplier. The DoD has had a lot of problems with One-Ring-to-rule-them-all systems like the F-35. … JEDI would have been the same.
…
Smaller steps with upgrades while testing/using offers better returns. Done right they can get a better deal by making the companies compete against each other in making sure the products are actually useful.
But look carefully at the DoD contract opportunity, says bustinbrains:
They’ll all get contracts. Then DoD will simply use the one that they actually like the best. No one can complain because it’s open-ended with no guarantees.
Last week, we talked about Nvidia’s goal to acquire Arm Ltd from SoftBank, and the regulatory challenges it poses—notably in the UK, home of the chip architect. After we went to press, the other shoe dropped.
As we said last week, Nvidia can’t be allowed to do this. Not only are ARM chips found in 99% of smartphones, but they’re an increasing fixture in the datacenter—especially places that value “performance per Watt.”
Richard Waters: What’s next for the tumultuous takeover of Arm?
Nvidia’s acquisition of UK chip design company Arm from SoftBank has provoked serious opposition on both sides of the Atlantic. … The US Federal Trade Commission had its own worries. China, meanwhile, is waiting in the wings.
…
The deal has shone a spotlight on the unique position Arm plays in the chip industry. [Nvidia] offered a guarantee that it won’t block any other companies from licensing Arm’s designs. The offer has fallen on deaf ears, with both the EU and UK ruling it inadequate. … Post-Brexit politics have also come into play.
…
At what point might Nvidia and SoftBank call it a day? … A stock market listing [is] the most likely alternative, with the UK a favoured venue.
How’s it viewed from the inside? Here’s a hint from fivemack:
I was at ARM when Softbank bought them; it came as a surprise to everybody, because we were absolutely confident that we were unbuyable because anyone interested in us would want to use differential licensing as a weapon against their competitors, and we … were confident that regulators wouldn’t accept that.
…
Lots of people went home with a year’s pay check in free money. And not a few people … went home with a decade’s pay check in free money.
More and more DevOps workloads are running on ARM silicon. Here’s Biophoton:
The low power expertise of ARM has to be an advantage in the data centre (DC) market. … Plus Linux is available on ARM so architectural lock-in of Intel could be eroded in the DC market.
You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk.
Image: Lukas Mann (via Unsplash)
Microsoft has made available a bevy of updates to its DevOps portfolio that, collectively, are intended to increase its share of a wave of applications that will be rolled out across the extended enterprise.
Additions to the Microsoft DevOps portfolio were announced at the Microsoft Ignite 2021 conference and include DevOps Workflow Generator, a free tool designed to help DevOps teams visualize their toolchain, and updates to Azure Automanage, a framework for automating the management of virtual machines on Windows Server and, in preview, on Linux.
At the same time, Microsoft has added support for open source OpenTelemetry agent software to Azure Monitor and made available a preview of Azure Chaos Studio, a service for testing application resiliency.
Microsoft is also making available a preview of Windows Server 2022 that adds secure-code capabilities for workloads deployed on the platform. Microsoft also previewed updates to backed databases such as SQL Server 2022, Cosmos and its implementation of the Redis database created by Redis Labs.
Finally, Microsoft has also made available a preview of integration between GitHub Actions for automating software development tasks and Azure Active Directory (Azure AD) using Open ID Connect, an authentication protocol advanced by the OpenID Consortium.
Microsoft CEO Satya Nadella told conference attendees the next 10 years will witness more digitization than the previous four decades as IT shifts from an era defined by mobile and cloud computing to one defined by ubiquitous computing and ambient intelligence.
Applications built in everything from procedural code to the Microsoft Power Fx, a low-code tool that Microsoft created using the programming language it originally built for users of the Microsoft Excel spreadsheet. Microsoft envisions those applications will primarily be built on its cloud and distributed everywhere. On the backend, a range of database and artificial intelligence (AI) services will be invoked primarily via application programming interfaces (APIs).
Of course, every major cloud service provider has similar ambitions. Most organizations today are not standardizing on a single cloud. Rather, they are determining which class of workloads run best on which cloud computing platform regardless of whether that approach increases the total cost of IT. Each additional platform adopted typically requires IT teams to master separate tools. However, Microsoft is now also making a case for a cloud-native framework that can be deployed anywhere to build, deploy and manage applications.
In the meantime, the number of workloads deployed on cloud services continues to grow. The market research firm Canalys reported worldwide spending on cloud infrastructure services reached $49.4 billion in the third quarter of 2021, a 35% increase. Microsoft currently trails Amazon Web Services (AWS) in overall market share but continues to steadily make gains. Microsoft and AWS collectively account for roughly half of all cloud infrastructure service consumption.
DevOps best practices will need to evolve to meet the challenges of multi-cloud computing. In addition to cloud platforms and on-premises IT environments, applications are now starting to be deployed at the edge in greater numbers. DevOps teams need to be able to continuously deploy applications and their associated updates across a wide range of platforms. The challenge, of course, is that all those platforms have unique attributes that make truly automating the entire process on an end-to-end basis an elusive goal.
In the digital economy, preventing downtime is paramount. When digital systems fail, the consequences for business can be huge. The cost of downtime can run to thousands of dollars per minute for large businesses. That’s without taking into account the impact of customer dissatisfaction and reputational damage for the company and the IT careers involved.
No matter how you measure it, IT failure is costly. It’s also largely unavoidable due to the increasing complexity and interdependence of today’s distributed IT systems. The combination of cloud computing, microservices architectures and bare-metal infrastructure create many moving parts and potential points of failure, making those systems anything but predictable.
That IT faults will occur is easy to acknowledge. Understanding how to fix them is harder, especially when interdependencies are not always obvious. Until recently, build testing has been the go-to method for assuring quality and resilience, but this kind of testing does not take into account environmental factors that cause unpredictable events or how cascading failures that lie dormant and unnoticed can trigger larger failures.
Chaos engineering is a relatively new approach to enterprise software development and testing designed to eliminate that unpredictability.
Introducing chaos into a system may sound counterintuitive if your end goal is to get clarity and improve resilience. Indeed, if you have heard anything about chaos engineering, you may have been alarmed at some of the terminologies: “blast radius,” “random terminations,” “fault injection” and “storms,” to name a few.
In practice, chaos engineering is about performing controlled experiments in a distributed environment so that digital engineering teams can build confidence in the system’s ability to tolerate inevitable future failures.
The process of chaos engineering involves stressing applications in testing or production environments by creating disruptive events in a controlled manner, such as server outages or API throttling. By observing how the system responds, improvements can be made before those weaknesses affect real customers.
Experiments are meticulously planned from initial scoping to execution and the insights they deliver are far-reaching.
Chaos planning starts with identifying the target deployment for the experiment. This process requires a comprehensive review of the application architecture and infrastructure components to first define what we call steady-state behavior. In other words, you need to understand what “normal” looks like before you start experimenting.
You can then form a hypothesis about how the system will behave during the disruptive event. You’ll need buy-in from the business areas you are potentially disrupting and you’ll need to plan the parameters of the test carefully, reducing the scope if necessary.
It’s a good idea to start small with chaos experiments. You’ll need to replicate them many times over in any given system to properly test its resiliency.
Luckily, many different tools already exist to help organizations implement and manage planned disruptions. Chaos engineering as we know it today originated back in 2010 from experiments conducted at Netflix using the tool Chaos Monkey, which still exists and is used today.
Nowadays, there are many more chaos offerings available, including services from Microsoft Azure and AWS as well as Gremlin, ToxiProxy, Litmus and many more. Organizations can choose tools tailored to the size of their environment and decide just how automated they want the process to be. Tool selection will also depend on whether experiments are designed to test the system at an infrastructure, network or application level.
Chaos engineering is much more than a set of tools and rules. It involves adopting a culture in which teams trust each other and collaborate to build resiliency and advance innovation.
When it comes to thinking about this culture shift, it can be helpful to think back to when DevOps was new. Sure, people would say they were using DevOps tools, but that did not necessarily mean they were actually practicing DevOps. DevOps involves breaking down siloes between different groups in an organization, creating an atmosphere of trust and enabling collaboration–some of the same attributes a chaos engineering culture needs to have.
Although chaos engineering sounds like a disruptive or uncontrolled exercise, it is actually the opposite.
Chaos experiments require meticulous planning with an emphasis firmly on rooting out failures before they become outages. Far from lacking in control, chaos testing is a closely coordinated process and the organization retains a firm grip on everything from the speed at which testing happens to what components are tested. Chaos engineering doesn’t create problems, it reveals them.