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: Alleged theft of GPL code, and Amazon will run its data centers on gas. (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: Alleged theft of GPL code, and Amazon will run its data centers on gas. (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: All of Microsoft’s cloud services go down, everywhere except China. Redmond’s IaaS, PaaS and SaaS—including GitHub—were dead for several hours, and are still running unreliably—despite Microsoft saying it’s fixed the problem. (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: EU-U.S. Data Privacy Framework reemerges, Berkeley brings cloud selection box, and proof that remote work is good work. (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: Home working is ripping the heart out of cities, the DoD’s bizarre cloud strategy, and Apple adds a $10,000 app price option. (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, four things that caught my eye from Amazon Web Services’ re:Invent 2022 conference: SnapStart turbocharges Lambda, Graviton3E ARM HPC SoC, AWS continues hiring, and AWS’s origin story. (more…)

As companies grow and expand to become global enterprises, IT infrastructure inevitably becomes more complex. When it comes to cloud computing, that usually means maintaining multiple clouds. There are many reasons for using different cloud service providers (CSPs)—some by choice and others by mandate.
For instance, a large enterprise with operations around the world may choose to use an in-country cloud vendor to be closer to the customer, therefore reducing latency and increasing application performance for operations in that country. Alternately, in some countries, data residency laws require that certain kinds of data reside on cloud providers within the country’s borders, which means companies with local operations can only use a cloud provider in that country. Both circumstances lead companies to maintain multiple clouds to facilitate operations at scale. Additionally, a company may decide to use two or more cloud providers as part of a fallback strategy to automatically reroute network traffic to another provider if a major outage occurs.
Regardless of whether the use of multiple CSPs is a choice or a mandate, enterprise IT leaders—and DevOps teams in particular—need to think strategically about multi-cloud environments and design their software delivery ecosystem from the outset to accommodate a multi-cloud strategy.
An effective multi-cloud DevOps strategy is essential for allowing businesses to easily scale application delivery across many different cloud assets and is therefore vital for enterprises operating globally. To create an effective strategy, consider these best practices.
With many CSPs—each with different requirements and tools—companies too often create siloed software development and delivery teams by vendor (AWS, Azure, GCP, etc.) or functional role (security, compliance, etc.). To avoid this pitfall and maintain control and visibility across all cloud providers, it’s important to implement a centralized software delivery platform, ideally one that’s environment agnostic. This will give your DevOps leaders the intelligence and insight they need to manage the entire software delivery ecosystem across multiple clouds anywhere in the world. At the same time, automated delivery processes can ensure quality checks and other milestones aren’t missed regardless of the cloud destination and that reporting, analytics and metrics from a centralized platform can identify and eliminate bottlenecks across different clouds.
Most cloud vendors have their own tools. However, maintaining a multi-cloud environment using vendor-specific tools can lead to lock-in and which can be costly and time-consuming to remediate. Too often, when companies move to the cloud, they use a set of vendor-specific tools for their software delivery processes. That works well initially, but as the company scales and requires a multi-cloud approach, the teams either find themselves heavily siloed without visibility across the whole ecosystem or there is significant technical debt that needs to be overcome. To avoid this, companies need to plan for the use of cloud-agnostic development and deployment tools from the outset so you can easily shift applications to different cloud providers as necessary to keep pace with changing business needs.
As developers assess and use tools and applications for different clouds, environments and use cases, they can create templates and abstracts to share lessons learned across teams, increase productivity and speed development cycles regardless of the destination CSP. For enterprises with more advanced DevOps practices, self-service capabilities—like a shared module catalog—can further speed development processes.
Once your enterprise has embraced a multi-cloud approach and the DevOps systems and processes are in place to efficiently deploy applications across different CSPs, a multi-cloud environment can be used to your strategic advantage—to increase flexibility, speed software delivery and reduce costs. Here’s how:
When you’re not dealing with the confines of country-specific cloud providers, IT and DevOps leaders can strategically align applications to specific cloud providers by region or country to reduce latency, optimize workloads or take advantage of specific service offerings from a particular CSP.
This concept is a great way for DevOps to leverage a multi-cloud architecture. If an application is run in one cloud and you want to add a feature that uses an application from a different cloud in your IT footprint, you can create a multi-cloud cluster using the same underlying cloud database to support both workloads. In this scenario, a production node resides in cloud A and runs in parallel to the read-only node in cloud B. This helps developers avoid the headaches that come with custom scripting as well as the costs of maintaining a backup and restore scenario.
This strategy is somewhat new, but it’s becoming more and more mainstream as competition increases among cloud providers. Here, you use a multi-cloud cluster to shift your workloads among several cloud providers to optimize your cloud environment and take advantage of negotiated discounts, specialized support, higher availability, lower latency or other unique features offered by a specific CSP.
To keep pace with our rapidly changing world, enterprise-scale organizations must be able to manage software delivery across multiple clouds. If your DevOps systems and processes aren’t designed for flexible development and delivery across different CSPs, you could limit your ability to adjust and successfully manage major disruptions or scale to take advantage of new opportunities.

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: Amazon Web Services falls on its face, Linux’s move to Rust takes the next step, and the FTC stabs another fatal wound in the horrible Arm/Nvidia deal.
First up this week: Amazon Web Services’ outage on Tuesday sent scads of DevOps teams scrambling. But what was the cause?
While we still don’t officially know, there is some chatter to speculate on. Could it be that AWS’s DNS infrastructure is vulnerable to DNS reflection attacks?
Hello. It’s Dave Lee: From angry Adele fans to broken robot vacuums
It started early on Tuesday morning. Robot vacuums ceased sucking, Wi-Fi cameras stopped watching and eager Tinder daters were left unable to “swipe right.”
…
Within Amazon itself … the unthinkable occurred: grounded delivery drivers were unable to load packages and deliver to customers’ doorsteps, just as the peak Christmas season begins to step up. … Drivers at multiple facilities across the country were sent home … some dreading whatever workload may await.
…
An outage at Amazon Web Services … had rippled through the online economy, crippling services used by millions of people. … An “impairment of several network devices” in … US-EAST-1 was the “root cause” of the disruption, Amazon said.
I was wondering what DevOps’ers learned? Enter Max Rozen:
AWS took approximately an hour to update their status page to indicate anything was happening. … While our infrastructure is hosted across 20 AWS regions, a single point of failure was hosted in us-east-1.
…
What we learned: … I learned the saying, “Friends don’t let friends deploy in us-east-1.” As a result, we’ll be moving some things over to us-east-2 to start with. Secondly, we’ll be adding redundancy and the ability to failover to another AWS region.
Getting inside the business, here are Eugene Kim and Katherine Long, to go over everything:
Even inside AWS … information on the outage remained sketchy [and] rumors spread among staff. One AWS employee speculated that the outage was caused by an “orchestrated DNS attack,” while another employee downplayed those concerns.
…
According to a screenshot of an internal AWS communique … ”firewalls are being overwhelmed.” … A separate internal note said … the network issue “specifically impacted” Amazon’s internal DNS servers.
The Rust language has taken the next step toward being part of Linux kernel development. Some “drivers and other non-core kernel programs” written in Rust can now be PR’ed. But there’s still no plan to go further.
Rust is much better than C for writing memory-safe code, and coding provable implementations. However, bootstrapping the toolchain is still stupidly hard.
Steven J. Vaughan-Nichols: Linux is getting more Rust in it by the day
It wasn’t that long ago that the very idea that another language besides C would be used in the Linux kernel would have been laughed at. [But] this has been coming for several years now. … Why? Because it’s much safer than C, especially at handling memory errors.
…
The next “patch series [adds] support for Rust as a second language to the Linux kernel.” … While he’s encouraging a slow but steady approach to introducing Rust into Linux, [Linus Torvalds] has also said that using Rust interfaces for drivers and other non-core kernel programs makes sense. [But] no one’s going to rewrite the kernel’s 25 million lines of C in Rust.
…
The Rust code proposed for the kernel now relies on the stable Rust compiler rather than the beta compilers. … As Linux kernel and lead Rust on Linux, developer Miguel Ojeda, put it, “By upgrading the compiler, we have been able to take off the list a few unstable features we were using.”
How is it “safer than C”? ssokolow shares this fascinating insight:
Rust tries to encourage that through good API design which allows it to be proven at compile time that the invariants will be upheld, thus avoiding the need to choose between safety and performance. My favourite example … is “the typestate pattern” which lets you teach the Rust compiler to prove correct traversal of any state machine.
…
A more mundane example would be the iterator APIs: No need for bounds checking if the iterator looks up the length once at the beginning and the APIs prevent you from wandering out of each entry it hands you. … Rust programs tend to run faster than their C and C++ counterparts because the developers feel comfortable introducing and maintaining more aggressive optimizations.
“And then a miracle occurs,” quips @dave_universetf:
I’m intrigued [but] I can’t help but feel sorry for the people doing bootstrapping work. C is hard enough to bootstrap, but Rust is a whole new level of pain.
…
Rust is literally not source bootstrappable. [The compiler] that works right now is Rust 1.39. So then you have to compile 18 more Rust compilers to get up to the current version.
As I’ve said before, this deal really shouldn’t go through. Ownership of the ARM ISA and the core designs would be a huge strategic stick to beat Nvidia’s competition with. ARM chips are an increasing fixture in the datacenter—especially those that value “performance per Watt.”
Nvidia’s attempt to buy Arm from SoftBank is suffering death by a thousand cuts. And the latest wound comes from the FTC’s Higonokami knife.
Paul Thurrott: FTC Sues to Block Sale of Arm to Nvidia
The U.S. Federal Trade Commission … sued to block Nvidia’s $40 billion acquisition of … Arm, citing competitive concerns. … Nvidia announced its intention to purchase Arm from Softbank for about $40 billion, over one year ago, in September 2020. But the deal fell under immediate criticism from the major industry players that rely on Arm’s … designs, and the UK government announced … it would “intervene” for national security reasons.
…
Now, it may not happen at all. “We will continue to work to demonstrate that this transaction will benefit the industry and promote competition,” Nvidia said.
Explain like I’m 5? Here’s swillden:
ARM has a non-trivial and increasing share in the data center. … ARM is much, much bigger than phones … Arm is an important competitor to Intel and AMD. … Arm licensing IP to Qualcom, nVidia, Mediatek, Unisoc, Samsung, Apple, Google, etc., has been great for many areas of technology.
…
Arm acting as a common … designer for a bunch of different chip vendors has been extremely good for … progress in CPU/SoC design. … It would be really unfortunate if a lot of the industry were to shift back to x86, eliminating all of the competition on hardware features that we get from the many ARM chipmakers.
But what of SoftBank? Ian King runs the numbers:
Wall Street analysts are all but calling the deal dead. … According to Citibank analysts, the chances of the Nvidia purchase closing are now just 5%.
…
The company faces the prospect of losing a jackpot of roughly $74 billion. … Other suitors are unlikely to match such an offer. … So SoftBank’s best alternative may well be an initial public offering for the Arm business—but that is likely to value the company at … $19.8 billion—only about 27% the value of the … Nvidia deal.
You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk. (It’s so typical of me to talk about myself—I’m sorry.)
Image: Ləman Şirinzadə (via Unsplash)

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: Three things that caught my eye from Amazon Web Services’ re:Invent 2021 conference: Private 5G, Graviton3 chips, and something called DevOps Guru for RDS (yes, really).
First up this week: AWS Private 5G is a new turnkey service, offering local private cellular data infrastructure, for places where Wi-Fi just doesn’t cut it. Despite the name, it offers a 4G/LTE fallback to 5G/NR. Because it’s AWS, the hardware is free—you just pay for usage.
Wi-Fi is unreliable and low powered. 5G over the 3.5 GHz “citizens’ band” seems like a great alternative (just don’t tell the lunatic fringe of the anti-5G brigade).
And, of course, AWS makes it easy to buy—Amazon ships you all the private radio gubbins for “free” and just bills you based on capacity and usage. It’s automatically configured and remotely maintained. You just take your internet connection and plug it in.
Aisha Malik: Amazon launches preview of new AWS Private 5G managed service
“AWS Private 5G” … is a new service that aims to make it easy to deploy and manage your own private network. … AWS CEO Adam Selipsky said that with AWS Private 5G, you can set up and scale a private mobile network in days instead of months.
…
There are no upfront fees or per-device costs: … Customers pay only for the network capacity and throughput they request. [It] scales capacity on-demand.
…
AWS Private 5G is available in preview in the United States.
And this is better than Wi-Fi how, exactly? Ballu counts the ways:
Industrial area coverage: Where you need 50 Wi-Fi radio units, you can provide service with 3–4 p4G/p5G radios.
…
Hazardous areas: Where you can’t provide the networking at all the corners or areas, one p5G radio blast area (esp with beam technology) can.
…
Packet loss: Less packet loss compared to Wi-Fi (believe me, it’s a big deal in the Industrial world)
…
Compatibility: What’s a negative for 5G modems (not many devices are available), is positive to some extent. Once investment is made with 5G modems, the devices can be on the road too.
Unsurprisingly, Brian Roemmele feels vindicated:
Precisely as I wrote about in 2017 to great ridicule from an analyst at a famous VC firm: Amazon is becoming a phone company.
…
From the Sidewalk Network to the Kuiper satellite system to local 5G. The network is no longer just “dumb pipes.”
Graviton3 is the latest version of Amazon’s ARM server chip. It looks like it’s based on a 5nm process implementing the latest ARMv9 ISA. AWS is making the usual claims about it being much faster than the previous generation, but it also has new security features.
AWS is deadly serious about low-power, high-performance compute. Amazon is just one licensee that would be distressed to have Nvidia owning Arm.
As I said last week—and the week before that—ARM chips are an increasing fixture in the datacenter, especially ones that value “performance per Watt.” Other IaaS providers might bleat about how they’re reducing the energy used to cool their data centers, but surely it’s a better plan to start with less waste heat.
Maria Deutscher: AWS debuts new compute-intensive and AI instances powered by custom chips
AWS’ new Amazon EC2 C7g instances target compute-intensive workloads such as analytics tools and scientific modeling software. The C7g series is based on the AWS Graviton3 chip, the third iteration of the cloud giant’s internally-designed processor.
…
Companies that plan to use C7g instances for machine learning workloads can expect an up to threefold performance jump in AI performance. The speed jump is partly the result of the processor’s support for bfloat16, a specialized data format [that] enables applications to process floating point numbers faster and using less memory than FP32, the data format historically used for the task.
…
For cryptographic tasks, Graviton3 delivers as much as double the performance of the Graviton2. … The chip introduces a feature called pointer authentication to reduce the risk of cyberattacks.
Tim Anderson has been sifting through the re:Invent announcements:
Top of the list perhaps is Graviton3, the next generation of AWS’s homemade [ARM] server processors. These chips will be used in new C7g instances previewed offering DDR5 memory (50 percent more bandwidth than DDR4) and up to 25 per cent better compute performance compared to instances powered by Graviton2.
…
Adam Selipsky gave his first Re:Invent keynote as AWS CEO. [He] said Graviton uses “up to 60 per cent less energy.” … Graviton matters because it is among those leading a charge to get more [ARM] microprocessors into data center and cloud infrastructure, and because if it’s more energy and cost efficient to operate, it’s critical to Amazon’s bottom line, sorry, today’s environmental concerns.
And is that pointer-authentication feature useful? Yes, very, says spijdar:
Very useful. … If the performance is good, this is a nice extra layer that makes return-oriented programming more difficult. Combined with NX bits, it really raises the difficulty in developing/using many types of exploits (it’s not impossible to bypass … but there’s no perfect security).
DevOps Guru for RDS is the latest upgrade for AWS’s oddly-named smart monitoring features.
Laplace and Gauss were right: Your DevOps team aren’t all rockstars. “Average” ops staff are in the majority. So extending AWS’s monitoring automation to your database instances should be a positive step.
But that branding: Can anyone take it seriously?
Stephanie Condon: AWS brings more automation to database management
The new Amazon DevOps Guru for RDS automatically can find and fix database issues … helping developers using Aurora detect, diagnose and resolve database performance issues. [It] can help remediate a range of issues, such as over-utilization of host resources, database bottlenecks, or misbehavior of SQL queries.
…
Last year, AWS introduced DevOps Guru, a service that uses machine learning to automatically detect and alert customers of application issues. … Amazon DevOps Guru for RDS builds on that
…
Users can view [issues] in the DevOps Guru console or via notifications from Amazon EventBridge or Amazon Simple Notification Service (SNS).
Sounds interesting, says u/random_dent:
I thought the DevOps Guru for RDS sounded interesting. You need to enable performance metrics first, which have their own charges, but it still looks not too expensive, plus three months free-tier, so we may try it out.
We’ve had some odd issues with RDS performance that are too inconsistent to lock down. It would be interesting to see if this could give us some insight.
But that name! Here’s Thomas LaRock—@SQLRockstar:
I’m old enough to remember when DevOps Guru for RDS was just called “database performance monitoring.”
And @shmick is young enough to say it like this:
such a cringe name
You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk.
Image: Andrew Svk (via Unsplash)

NS1 has extended the capabilities of its DNS and network management platform with the release of NS1 Connect. The platform is designed to serve as a delivery platform that integrates developer and network operations teams’ tasks for the creation and management of applications across highly distributed cloud-native and on-premises environments.
While DevOps teams typically rely on dozens of tools for the deployment of software and the management of the network connections on which the software runs, NS1 was created to—among other things—reduce the number of different tools DevOps teams require by improving visibility, automation and management for these processes.
In this way, NS1 Connect provides a unified API framework to automate DNS, traffic optimization and network services management across heterogeneous networks, Sanjay Ramnath, vice president of products at NS1, told devopsy.kinsta.cloud. NS1 Connect’s reach covers internal and external applications deployed via on-premises, cloud or hybrid infrastructure. This enables NetOps and DevOps teams to integrate NS1 solutions into their infrastructure and CI/CD pipelines with lower complexity and enables NetOps teams to accelerate management and minimize the risk of misconfiguration, Ramnath said. “Prior to this, teams had to deal with complex manual processes or disparate API frameworks that slowed down their ability to develop, deploy and deliver applications.”

In his talk, Your Business Depends on Eliminating Boundaries Between Applications, Users, Infrastructure, and Data during INS1GHTS 2021, NS1’s annual user conference, Ramnath described how a number of NS1 products and services are integrated into a single platform under the NS1 Connect umbrella. They include cloud-native network services for DNS, DHCP and IPAM (DDI), edge-to-cloud networking for NS1’s managed DNS, dedicated DNS, private DNS and DNS for China and application traffic automation for VPN traffic steering, pulsar active traffic steering and general traffic management. Other commonly used network services are provided as well, including IP address management that can be centralized across the network, said Ramnath.

The idea was to remove many of the roadblocks DevOps teams face when seeking to deploy on highly distributed infrastructures. “The goal here is to remove some of those boundaries and barriers that are talked about on the infrastructure side,” says Ramnath. “[This helps to make sure] that our control plane is centrally provided and centrally consumable as a cloud solution and that our products can be deployed wherever they are needed in a zero-touch way, in a lightweight fashion, making sure that we are aligned with cloud-native operations.”
The need to maintain low latency across distributed infrastructures is also key. As David Coffey explained during the conference in The Future of Application Traffic Intelligence and Automation session, low latency is essential for creating “that great experience for users.”
“Low latency is not an attribute of this feature, it is a top, tier-one priority for people to accomplish, but it’s an incredibly complicated aspect, given all of the frameworks that are out there—the tools, the DevOps capabilities and the components required to support and deploy these modern-day applications,” said Coffey. “That’s what enables application companies to deliver that low latency and treat it as an attribute in the system; not having to go out of their way to create this. We want to enable all developers to embed this into their system—and we can provide them with a degree of success for delivering that great experience to their customers and to their networks.”