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: Why Apple services were down, Linux gets a huge RNG overhaul, and we wonder if Okta was hacked again. (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: ByteDance restricts TikTok in Russia, Unified Patents escalates the fight against trolls, and Google Chrome beats the magic 300.
First up this week: Russian TikTok users won’t be able to view or upload new content. For users in Russia, TikTok has frozen its catalog of cringe.
Putin’s vague new “fake news” law is concentrating minds in Beijing’s ByteDance. Is your organization exposed too? To protect its employees—and perhaps its users, too—it’s hitting the Safe Mode button.
Dan Milmo: TikTok restricts service in Russia
Chinese-owned TikTok said it would block livestreaming and uploading of new content in Russia after the Kremlin criminalised the spreading of what it deems to be fake news about its invasion of Ukraine. … The BBC, CNN and other global media outlets have temporarily suspended reporting in Russia to protect their journalists.
…
TikTok spokesperson Hilary McQuaide said the app in Russia now appears in “view-only” mode and won’t let people post or see new videos or livestreams. They can still see older videos, but not if they came from outside the country.
…
She said, “The safety of employees is our top priority,” … adding that the video-sharing service—part of China-based tech company ByteDance—did not want to put either its Russian employees or users at risk of severe criminal penalties.
With more on that head-scratching law, here’s Aimee Chanthadavong:
Russian President Vladimir Putin signed a new law on Friday that bans what the country calls “fake” news about the military. This law will target any statements referring to the invasion of Ukraine as an “invasion”, any attempt to discredit the armed forces, or calls for sanctions on Russia. Those found to be spreading so-called fake news could face up to 15 years in prison.
…
TikTok’s in-app messaging service will not be affected. … “We will continue to evaluate the evolving circumstances in Russia to determine when we might fully resume our services with safety as our top priority,” TikTok added.
And Scott Nover thinks about the effects on Russian citizens:
Russia’s fake news law is a severe step for a country whose government is already antagonistic to … a free press. … The country has blocked Facebook, Twitter, and YouTube proactively, but TikTok beat Russia to the punch. The result is the same, however: The people of Russia … will be locked out from another window into the real-life consequences of Putin’s war.
“Patent assertion entities,” also known as “non-practicing entities,” are organizations that don’t produce anything, but simply acquire and hoard patents—later asserting them against unsuspecting organizations. The aim is to extort money from those they claim are infringing.
The problem? Many of those patent claims are as weak as a sickly kitten.
You might think you’re safe, but trolls also go after the users of the disputed technology. Examples include podcasting, JPEG images, order-confirmation emails, geo-locating a car and even caching data.
Steven Vaughan-Nichols: Open Source Zone grinds away at patent trolls
Patent trolls, aka Patent Assertion Entities (PAEs), have plagued … software for ages. … The attacks keep mounting up. The reason is simple: It’s profitable.
…
[But] Unified Patents, an international organization of over 200 businesses … brings the fight to the trolls. It deters patent trolls from attacking its members by making it too expensive for the troll to win. … With United Patents’ high success rate in knocking out bad patents, slowly but surely the patent trolls are being driven back.
…
For example, an Accelerated Memory Tech patent 6,513,062, was used by the troll IP Investments Group to claim … Redis, which manages cache resources on the cloud, violated the patent. [The troll] went after Hulu, Citrix Systems, Barracuda Networks, Kemp Technologies, and F5 Networks for their use of Redis software. IP Investments Group gave up rather than fighting it out. Everyone who uses Redis wins.
Ban software patents? Beware of throwing out the baby with that bathwater, thinks WierdUncle:
Patents themselves are a good idea: … Inventive people should be rewarded for their contributions to the economy.
…
[But] patent trolls are parasites who contribute nothing to the prosperity of citizens. … The patent troll business plan is unfortunately quite viable. You don’t invent anything, or fund new developments. You have sufficient funds to clobber anybody who challenges you, by having better lawyers.
The underlying issue is weak patents. Here’s nzkbuk:
Start suing the patent office for damages against wrongly issued patients. It would then be in their best interest to set up this sort of thing as an alternative where the patient can be investigated first.
Google Chrome on macOS boasts a better benchmark score than Safari on an M1 MacBook Pro. Hilariously, this is using Apple’s own Speedometer benchmark tool.
Great PR, and popcorn-worthy Cupertino trolling. But aren’t there better optimizations Google could be making?
Frederic Lardinois: Chrome on macOS is now faster than Safari
Version 99 of Chrome on macOS manages to score 300 points on the Speedometer benchmark, which was originally developed by Apple’s WebKit team. This, Google points out, is the fastest performance of any browser.
…
It’s been a while since competition in the browser market focused on speed. … When a new chip comes along, though, there’s always room for optimization. Originally, Chrome on Apple’s M1 chips had passable performance, but … Chrome now runs 43% faster on them.
…
Speedometer 2.0 tests for responsiveness, which makes it a good proxy for user experience. … It doesn’t take much to make software feel more responsive, so the 43% on M1 Macs will surely make you feel more productive.
How? Try not to gloat, Max Christoff:
Building on many performance changes over the last year, we enabled ThinLTO in M99, a build optimization technique that inlines speed-critical parts of the code base, even when they span multiple files or libraries. … Two of the other recent major contributors to Chrome’s speed are the V8 Sparkplug compiler and short builtin calls. Sparkplug is a new mid-tier JavaScript compiler. … Short builtin calls are used by the V8 JavaScript engine to optimize the placement of generated code inside the device’s memory [which] boosts performance by avoiding indirect jumps when calling functions.
…
We know that benchmarks are just one of many ways of measuring the speed of a browser. [But] combined with recent graphics optimizations (namely, pass-through decoder and out-of-process rasterization) … Chrome is now 43% faster than … 17 months ago.
Benchmarks/schmenchmarks, thinks codedokode:
Browser developers are optimizing the wrong thing. … Optimizing for speed usually causes increased memory consumption, and this increases the chance of invoking swapping. If the system starts swapping, it becomes orders of magnitude slower.
…
If the browser could use [half the] memory while using twice amount of CPU time, that would be perfect. Just think how many laptops with 2 or 4 GB of RAM would become usable again.
You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk.
Image: Rostislav Artov (via Unsplash; leveled and cropped)
Privacy has taken on an unprecedented level of importance in 2022, primarily online privacy. There are multiple reasons behind this increase. The primary one is that users online are now more educated, informed and concerned than ever before about the collection of their personal data and, perhaps more importantly, how the website collecting this data manages and uses it.
Privacy management refers to the practices, tools and strategies that an organization develops behind the scenes to ensure that any and all data collected is managed in a way that is fully compliant with data regulations.
Like every other division within an organization, the dev and DevOps teams play a vital role in successfully implementing and executing privacy management solutions. But how can the dev and DevOps teams contribute in this regard? Where should they begin? What practices to adopt?
This has less to do with the organization’s practices and more to do with the overall philosophy about privacy. There’s no point in beating around the bush regarding data collection and users’ privacy since the better educated and informed your users, the higher their chances of giving you the appropriate data collection permissions.
You should be straightforward and let your users know why you need to collect their data. While this topic will undoubtedly be covered in the website’s privacy policy, it should also be reflected in the user’s browsing experience while on the site.
This can be done by ensuring there’s an easy-to-find and quickly accessible link to the site’s privacy policy across all web pages on the website.
This may seem like a given in 2022, considering how unyielding and austere most data protection regulations are. However, there are still organizations that are in the middle of transforming their data collection practices. That means that even though the legislation they must comply with requires minimal data collection, in actuality, their practices paint another picture.
This is not necessarily a deliberate or malicious practice. Most legislation, even those that are quite clear in stating that only the most essential data required for a website to function properly may be collected, gives organizations leeway regarding when they must adhere to these laws. The CPRA is perhaps the most vivid example of this.
While the CPRA was passed in 2020, it will not go into effect until January 2023. Most organizations are expected to ensure their data collection practices are in line with the law when it goes into effect. There’s no point in delaying the inevitable. If your organization hasn’t begun transforming and altering its data collection practices, it is high time to start.
This is arguably the most sensitive part of any organization’s privacy management infrastructure. This is down to the fact that while an organization may have to comply with a data protection regulation in one country to process and collect data on its residents, it may find itself having to balance out its practices to be able to transfer this data to another jurisdiction.
Moreover, nearly every data protection regulation has a stringent set of requirements that an organization must fulfill before it can transfer the data out of the jurisdiction in the first place.
Naturally, this can all become incredibly messy and escalate into a crisis unless you have a proper data transfer mechanism and strategy in place that takes into account every possible step that may hinder your compliance efforts.
Ultimately, the buck stops with the dev team and DevOps team, in this case, to ensure that whatever mechanism the organization ends up adopting is fully capable of transferring data securely across jurisdictions without leading to a breach of any regulatory statutes an organization is required to follow.
Some would argue that the entire philosophy of privacy management is built upon accountability. While various data protection regulations globally are meant to ensure all businesses follow a certain set of practices that reduce any chances of data breaches, true accountability comes from within.
The most practical method of ensuring such accountability is by maintaining a regular and up-to-date record of processing activities (RoPA). Again, this is something that most data protection regulations will require businesses to maintain anyway, with processing activities, data flows and categories of data subjects the most common items that need to be covered.
Similarly, make sure any third parties or vendors you work with have the relevant practices in place before going forward with any sort of data sharing, even if you have user consent to do so.
Remember, accountability means holding yourself and those you work with to the highest standards.
The most effective way to do this is to automate the process of record keeping. Owing to both the sheer volume of data that may become involved and the risks associated with human error in record keeping at scale, the best way forward is to opt for a data-centric automated approach.
Depending on which laws your organization must adhere to, regular assessments, known as privacy impact assessments (PIA), could be legally required. Most organizations design and implement their own PIA depending on their current practices and data collection methodologies.
However, there are some fundamentals that each PIA is supposed to follow, such as the following:
The purpose of any PIA is to help you evaluate just how at-risk your organization is based on its current data collection practices. These evaluations can help you identify gaps and flaws in your current practices while also highlighting areas for improvement.
On the off chance that you do discover discrepancies, the best option going forward is to contact the organization’s internal data protection officer (DPO) and develop a roadmap for eliminating those discrepancies before they cause any real damage.
Welcome to Ukraine Week here at 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: Censoring the Russian internet, Snap fears for hundreds of Ukrainian employees, and Eugene Kaspersky acts like a ****.
First up this week: Ukraine has asked ICANN to drop Russia from the DNS. Andrii Nabok, the Ukrainian representative of ICANN’s Governmental Advisory Committee argues a DNS blockage would “help users seek for reliable information in alternative domain zones, preventing propaganda and disinformation.”
Given today’s confirmation that Muscovite K12 students had been arrested for laying flowers at the Ukrainian embassy, this goal seems all the more laudable. But frankly, a moment’s thought says it’s a bad idea.
John Gilmore was right. Such a move would inevitably fail. And there’s a real risk of undesirable, unintended consequences.
Kat Bouza and Noah Shachtman: Ukraine Pushes to Unplug Russia From the Internet
Ukraine’s request to the Internet Corporation for Assigned Names and Numbers (ICANN) seeks to revoke domains issued in Russia and shut down primary Domain Name System (DNS) servers in the country. [It] would send a strong message to a regime pumping out digital propaganda.
…
The DNS root zone is a crucial element of the overall functionality of the internet, responsible for handling queries to top-level domains — such as .com, and country-specific domains like Russia’s .ru. Removing Russia’s access to this cluster of servers would prevent Russian internet-service providers from communicating.
…
But … the unprecedented request has the potential to do more harm than good. … Representatives for ICANN … declined to comment.
But the request is pretty naïve, thinks this Anonymous Coward:
All they would have to do is get the ISPs to add a zone to their DNS that says “ru. IN NS x.x.x.x” and then for all their users, any requests for a .ru domain would be directed to x.x.x.x
OK, the rest of the world would miss out, but I doubt that they would care.
Is there a better way? ArmoredDragon breathes fire:
A better way … is to ask western certificate authorities to revoke all [Russian] certificates. Then ask the major OS and browser vendors to remove any CAs that don’t comply.
That would really **** with them because there’s nothing [Russia] can do about that. And it would even **** with Russia’s ability to do business with Chinese companies and Chinese customers.
Snap, Inc.—formerly Snapchat—owns the Ukrainian company that created the technology used in the real-time video shenanigans behind “I’m not a cat.” It has hundreds of employees in Kyiv and Odesa.
This very human DevOps story is but a footnote to the wider picture of tech companies acting to echo Western governments’ sanctions. It’ll cause us a little pain, but that’s nothing compared to the suffering felt by Ukrainians. And it’ll be worthwhile if it shortens the war.
J. Clara Chan: Three hundred Snap employees are from Ukraine
In a public note, … Snap — the parent company of Snapchat — said … that 300 of Snap’s “most creative and talented team members” are from Ukraine, … the birthplace of Looksery, the augmented reality platform that Snap acquired in 2015. … Snap said it has pledged over $15 million in humanitarian aid to support Ukraine. … The company is also providing emergency assistance to employees who need help safely relocating.
…
“We stand in solidarity with our Ukrainian team members and the people of Ukraine. … This is a devastating conflict with far-reaching consequences. … It is a direct threat to many of our team members and their families.
…
“Over many years working with our Ukrainian colleagues and friends, we have gotten to know the inventiveness, strength, and resilience of the Ukrainian people. … We will continue to work tirelessly to help our Ukrainian team members and their families, support our Snapchat community, and determine how we can help make positive contributions to the immense humanitarian efforts underway.”
It’s bang on trend, reports Corinne Reichert:
Snapchat has followed suit after Facebook, Twitter and YouTube began pausing ads on Friday, saying it has now stopped all advertising running in Russia, Ukraine and Belarus following the Russian invasion of Ukraine. … The Snapchat app remains live in Ukraine, Russia and Belarus, [but] Snap is monitoring the platform for misinformation or other misuse.
…
Apple has also halted sales of its products in Russia, as well as online transactions, Apple Pay and some Apple Maps features. Google [is] temporarily disabling some live Google Maps features, adding an SOS alert to Search and blocking Russian state-controlled media. It said Google Pay “may become unavailable.”
But don’t hang up on Dade “+++ATH” Hayes: [ask your parents]
In terms of any financial sacrifice from the foregone advertising opportunities, it isn’t clear that all that much is at stake for Snap. … While the company’s stance on the Russia-Ukraine situation clear and emphatic, it is also an easier one for for Snap to take than for many of its tech rivals.
The figurehead eponym of AO Kaspersky Lab is being publicly shamed for comments he made about the war in Ukraine. In stark contrast to Snap’s statement, he is accused of overt neutrality, minimizing the war’s severity—and even of shoehorning in some marketing.
Desmond Tutu was right. But, while it’s tempting to “cancel” Eugene, dial down the emotion and think instead about your security posture. If you use Kaspersky products internally, what risks are you exposing your organization to? How might the Russian government exert pressure on the company to compromise your network?
James Coker: Eugene Kaspersky’s Statement Provokes Controversy
Cybersecurity industry veteran Eugene Kaspersky has provoked a strong reaction from leading figures in the sector. … Kaspersky, CEO of the Russian-headquartered IT security vendor of the same name, broke his silence on the conflict:
…
“We welcome the start of negotiations to resolve the current situation in Ukraine and hope that they will lead to a cessation of hostilities and a compromise. We believe that peaceful dialogue is the only possible instrument for resolving conflicts. War isn’t good for anyone. … The main thing we can do in this situation is provide uninterrupted functioning of our products and services.”
…
His description of the conflict as a “situation” and apparent attempt to advertise his firm led to a number of furious responses. … Following Kaspersky’s tweet, the hashtag #BoycottKaspersky appeared.
With a balanced view, it’s Nick Farrell:
Kaspersky sits on the fence … in Russia it is not a good idea to have a view. [But] whoever is advising Kaspersky on PR might need to have a rethink.
…
After all a compromise is [not] always possible when one side is firing missiles into residential areas. If he applied the same premise with ransomware, he would be suggesting, … “It is better that you talk to the people who are holding your servers hostage.” … How much is Kaspersky, the company, influenced by the Russian government?
Does your shop use Kaspersky? Nick Lange cuts to the chase:
I would like to remind all readers that, in case of war, … software with access to companies and the capacity to be updated worldwide in matter of hours at the same time is a high class target to get forced to cooperate by a autocratic government.
You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk.
Image: Brandon Morales (via Unsplash; leveled and cropped)
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: Linode gets bought by Akamai, Firefox market share is “measly,” and Google brings staff back to the office.
First up this week: Why is Akamai buying Linode? Whatever the reason, it’s a big payday for its solitary shareholder: Not far off a billion dollars.
The 100 lb gorilla of edge computing and CDNs is promising not to mess with Linode’s winning open source cloud formula: No change, steady as she goes, etcetera. But how many times have we heard that before?
Here’s local scribbler Paige Gross: Linode’s $900M acquisition by Akamai is a ‘game changer’
A household name in the Philly tech scene … CEO Christopher Aker founded the company in 2003, and it’s been bootstrapped ever since, growing to about 250 employees. … Aker has owned 100% of Linode since he founded it.
…
Aker said the deal brings the company closer to solving evolving challenges “as cloud services become all-encompassing, including compute, storage, security and delivery from core to edge. … We’ve been talking about ‘alternative cloud’ — alternative to the big guy — and now we’ve sort of validated ourself in this market.”
…
The Old City company maintains “well over a million accounts” but has anywhere around 150,000 active users of its platform at any particular time. Linode’s HQ, the bank building at Third and Arch Streets, remains. … For clients and Linode employees, there won’t be too much noticeable change [Linode] says.
Why does Akamai want Linode? Jonathan Greig asked the CEO:
Akamai CEO Tom Leighton [explained] that Linode has great customer support and is already in 11 locations, which Akamai is going to “dramatically” expand. … Leighton also noted the September 2021 acquisition of Israel-based Guardicore, a cybersecurity company that offers a micro-segmentation solution to reduce the potential attack surface of corporate networks, secure applications, and meet compliance standards.
…
According to Leighton, the company is expecting the cloud compute category — which includes edge applications, its net storage business, and Linode — to reach “well over half a billion dollars in 2023. … We were pioneers in edge computing and now we’re taking a big step forward in cloud computing with Linode.”
But here’s a worried-sounding zoid.com:
Well good for them but I hope [Akamai] don’t screw it up. Linode is a great hosting company.
Last week, a journalist innocently asked, “Is Firefox OK?” And people lost their minds.
We need Firefox and Gecko. A Chromium monoculture is bad for the web and bad for DevOps. (Before you ask: No, the existence of WebKit doesn’t change things, thanks to Apple’s ridiculous policies). Much as I tried to say something nice about Firefox last month, its market share is, frankly, pathetic.
Matt Burgess: Is Firefox OK?
In the two decades since Firefox launched from the shadows of Netscape … the browser has slid to less than 4 percent of the market—on mobile it’s a measly half a percent. … Its fate also has larger implications for the web as a whole.
…
Each year Google pays Mozilla hundreds of millions of dollars in royalties. … In its 2020 financial results … Mozilla listed its total revenue as $496 million. … The Google-Mozilla deal was last renewed in 2020 and is expected to expire in 2023. … Mozilla and Firefox acknowledge that for its long-term future it needs to diversify the ways it makes money.
…
Firefox still matters: … The browser market is dominated by Google’s Chromium codebase and its underlying browser engine, Blink. … Microsoft’s Edge Browser, Brave, Vivaldi, and Opera all use adapted versions of Chromium. Apple [has] its WebKit browser engine [but] other than that, Firefox’s Gecko browser engine is the only alternative.
Firefox, how do we love thee? Let not_count_zero count the ways:
I still use Firefox because:
a) I remember Internet Explorer and the standards wars. …
b) I don’t trust Google. …
c) Most sites work well.
…
I do have questions though. … They’re currently getting around a half a billion‽ What are they doing with it? … This seems really off—really, really off.
But heed a deeply worried Thom Holwerda:
The decline and potential demise of Firefox is a massive problem that everybody seems to be kind of tiptoeing around—too afraid to acknowledge that if Firefox were indeed to disappear, we’d be royally screwed. We’d end up right back where we started 20 years ago, with Chrome being the new IE6.
…
The situation is especially dire for … Linux users, developers, and distribution makers. … Gnome Browser or KDE’s Falkon can barely be taken seriously, and … are based on Apple’s WebKit, which isn’t a great position to be in.
Google is planning “celebrations” to welcome back employees after being fully remote. And in practice—unlike at IBM—this doesn’t mean a vaccine mandate.
It was just three months ago that Google said it “firmly stands behind our vaccination policy.” What changed? It’s unlikely to have been due to a tiny minority of staff publishing a manifesto.
Jennifer Elias: Google relaxes mandates
The company will no longer require vaccination as a condition of employment … as it prepares to bring workers back to the office … at least three days a week for a “hybrid” work model. … The company [had previously] told employees that they must comply with vaccine policies or they’d face loss of pay and eventually loss of employment.
…
According to Google spokesperson Lora Lee Erickson … the company dropped the requirement … after removing the Jan. 18 deadline it had set for employees to either get vaccinated or get exemption approval. She declined to provide further details on the policy or the reasons for the reversal.
…
Google Real Estate and Workplace Services VP David Radcliffe [said Google] is preparing to begin its 30-day transition period to the hybrid work week if conditions continue to improve. He said his team is planning “celebrations” to welcome back employees. … Unvaccinated employees who are approved to enter offices will still need to follow additional protocols, including testing and wearing a mask.
It’s too simplistic to say the anti-mandate brigade are also anti-vaxxers. For example, raxxorrax:
I am vaccinated and HR knows this. … But if they officially demanded a certificate, I think I would have called it quits. Many people don’t have that option [but] there are consequences for such unreasonable demands.
…
I understand a mandate for vaccinations in certain occupations relating to health. It is something you have to personally accept if you want to work in the field.
Although a few others are way over at the end of the bell curve. Greg Jinkerson:
Don’t get excited, [Google is] still evil and stupid. … Now they’re backing down for some reason, [but] this is barely anything notable as far as a rollback of restrictions. [It] is not any kind of encouraging news.
You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk.
Image: Aleksey Kuprikov (via Unsplash; leveled and cropped)
Think! Welcome to Big Blue Week here at 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: IBM’s employment practices scrutinized, IBM z/OSaaS breaks cover, and IBM encourages staff back to the office.
First up this week: IBM’s defense in an employment age discrimination lawsuit looks to be shredded. Internal emails “appear to show high-level discussion about paring the ranks of older employees.”
According to one of the plaintiff’s lawyers, unnamed “top IBM executives were explicitly plotting with one another to oust older workers … to make room for millennial employees.” On the face of it, they seemed to be doing the polar opposite of the Age Discrimination in Employment Act.
Noam Scheiber: Making ‘Dinobabies’ Extinct: IBM’s Push for a Younger Work Force
Top IBM executives were directly involved in discussions about the need to reduce the portion of older employees … sometimes disparaging them with terms of art like “dinobabies.” … Documents made public by a Federal District Court … show executives discussing plans to phase out older employees.
…
The newly unsealed documents, which quote from internal company emails … show top IBM executives specifically emphasizing the need to thin the ranks of older workers and hire more younger ones. [One] email refers to IBM’s “dated maternal workforce,” an apparent allusion to older women, and says: “This is what must change. They really don’t understand social or engagement.”
…
Adam Pratt, an IBM spokesman, [claimed,] “IBM never engaged in systemic age discrimination.” [He] said that some of the language in the emails “is not consistent with the respect IBM has for its employees” and “does not reflect company practices or policies.”
Yikes, ageism and sexism? Experienced staff are valuable, says MrBanana:
I did some time at IBM [and] remember being invited to a meeting with a new group, headed by a new “thinker,” who had something to present to myself and a colleague. We walked past the foosball table to the meeting room. Naturally the room had no chairs, and was covered in multi-coloured Post-it Notes. Once they had gone through their mood boards and the non-linear presentation of this new idea, I turned to the other old geezer in the room. “Didn’t we look at something like this 8 years ago?”
“Yeah, we worked out that compute power just to run the UI for one session wouldn’t be available for a couple of decades.” The children were somewhat disappointed, and (fortunately) we were never asked back to their romper room.
But experience can be both a blessing and a curse, learned aahortwwy:
I experienced both sides of this in five years at a company in hypergrowth. … I learned so much at that job: … In year 1, I was determined to accomplish X and ignored the skeptical comments of some colleagues who’d been at the company longer than me. I failed and wasted some time. In years 4 and 5, new colleagues were determined to accomplish X and ignored my skeptical comments.
“Mainframe” is not a dirty word. It’s secure, vertically scalable, and it put the VM in VMware. Now, what IBM Wazi did for on-prem LPARs, Wazi aaS promises to extend to hosting z/OS instances.
Mainframes and cloud-native DevOps need not be incompatible. To modernize legacy apps using hybrid cloud instances for dev/test—and even prod—can be a big productivity boost. But isn’t it weird that IBM spun out its mainframe-as-a-service zCloud offering only a few months ago?
Mike Vizard: IBM Shifts Mainframe App Testing to the Cloud
While many workloads over the years have been migrated off mainframes or simply retired, the applications that run on z/OS today are still among the most mission-critical that organizations run. … IBM this week revealed it has added the ability to set up testing environments on the IBM Cloud for z/OS mainframe applications.
…
IBM plans to make IBM Wazi as-a-Service (Wazi aaS) for z/OS generally available in the second half of this year, [which] will enable DevOps teams to self-provision an instance of a z/OS virtual server on a secure private space running on IBM Cloud. … At the same time, it will become easier to modernize mainframe applications by making them more accessible to other applications via a set of secure APIs … using a cloud-native set of DevOps tools that run in a Kubernetes environment.
…
Modernizing mainframe applications is a less complicated endeavor than migrating them. The challenge is that building, deploying, maintaining and securing all the APIs required to do so represents a significant amount of effort.
OK, boomer, why are we talking about 1960s mainframes on DevOps.com? Here’s ArchieBunker:
Mainframes are different beasts altogether, almost alien when you compare them to PC hardware. You have binaries written for the S/360 system in the 1960s? Good news you can still run them natively without a recompile.
You think virtualization and containers are a hot topic? IBM was running multiple OS instances inside a VM in the 1970s. … The engineering is incredible.
But z/OSaaS? It’s déjà vu time for Beleagured Greybeard:
“Cloud Managed Services for z” AKA “zCloud” has been around for over 10 years. … IBM offloaded it with the Kyndryl spin, so its odd that they now want to re-invent it.
…
If it’s a strategic platform, why didn’t they hold onto it instead of spinning it off to Kyndryl? Sounds like yet more daft leadership decisions.
IBM wants to “keep employees safe” as they return to office work after being fully remote. In practice, this means a vaccine mandate.
Although there are exemptions on medical or religious grounds, IBM has promised to place dissenters on unpaid leave. As you might expect, the policy has a few employees up in arms.
Cassie Werber: How Salesforce, IBM, and HSBC are approaching return to work
When the pandemic hit, and IBM moved 95% of its workforce to fully remote, it was pleasantly surprised to discover no drop in productivity. … Still, they planned to return to offices.
…
The company saw this as a way to keep employees safe. … One example … is its development of the IBM Digital Health Pass as an alternative to vaccine cards or paper vaccine certificates, which they use to make sure all the staff that come into their offices are vaccinated.
…
Arvind Krishna, IBM’s CEO, meanwhile came up with what he called the IBM Work From Home Pledge. [It] included commitments to flexibility, kindness, sensitivity to family, setting boundaries, and acknowledged video fatigue. It concluded with a commitment to “be connected.”
Tricky to “be connected” if you’re not allowed back in the building. Anne D’Innocenzio, Heather Hollingsworth, Tali Arbel, Mae Anderson, Ken Sweet, Matt O’Brien and Dee-Ann Durbin:
IBM software engineer Justin Albano said his company recently notified employees that it would be revoking badge access to workers who aren’t vaccinated or haven’t proved that they are. “We’re not able to enter an IBM office at this time,” said Albano.
…
He said some workers have successfully sought religious exemptions but “my thought process was I shouldn’t have to explain to my company my faith” to get out of a policy that’s “immoral in its foundation.”
What’s the alternative? With a perspective, it’s Chris Haney:
Or, get the vaccine. Protect yourself and the people around you. You people really are detached from reality.
You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk.
Image: Marcin Wichary—cc:by; leveled and cropped (ask your parents)
You can find plenty of high-level definitions out on the internet about what site reliability engineering means and what site reliability engineers do.
But if you want to understand what it’s actually like to work as a site reliability engineer, there is perhaps no better source than job descriptions. SRE job ads explain what real companies are looking for and what they expect on a day-to-day basis.
To provide insight on what SRE looks like in practice, we’ll look at some job ads from several leading companies. As we’ll see, each company has a slightly different take on what the site reliability engineer role entails, but it’s possible to identify some core themes that underline what businesses expect.
To understand the content of SRE job descriptions, let’s examine examples from four leading companies.
GitLab’s SRE job description contains most of what you would expect from a typical site reliability engineer job ad. It highlights the importance of having a mix of technical skills and collaboration skills. It also emphasizes expertise in areas like Unix/Linux, infrastructure-as-code and Kubernetes.
What may be slightly surprising, however, is the emphasis that GitLab’s job description places on programming skills. GitLab expects SREs to know how to code in specific languages, like Ruby and Go. The takeaway is that SREs need to know more than just how to use code to solve IT operations problems. They must also be able to develop applications or contribute code to application platforms (the job description mentions “contributing to code in GitLab” as a required SRE technical skill).
Also interesting is the fact that GitLab expects site reliability engineers to be able to write blog posts. Blogging may not be one of the first skills that come to mind when you think of a site reliability engineer’s responsibilities, but at GitLab, at least, it’s part of the job.
LinkedIn provides an SRE job ad template that businesses can use when posting their own SRE jobs on the site.
LinkedIn’s ad is pretty high-level (which is unsurprising, given that it’s a template rather than an ad for a particular job). For the most part, it doesn’t mention specific tools—although the main exception is programming languages, where it says SREs should know how to code in languages like C, Python, JavaScript and Ruby. Like GitLab, then, LinkedIn clearly sees development as a core SRE job responsibility.
The LinkedIn job description also places a heavy emphasis on the ability to “gather and analyze metrics.” It doesn’t use the word “observability,” but that seems to be what LinkedIn is getting at.
Continuing the theme of development-centric SRE work, a recent job ad for a specific SRE opening at Microsoft reads a lot like a DevOps engineer job description. The ability to “design, write and deliver software” is the top responsibility listed in the ad, which also mentions familiarity with CI/CD tools.
The Microsoft job description also mentions the importance of written and verbal communication skills. Unlike GitLab’s ad, this one doesn’t say SREs will need to write blog posts; still, it’s clear that companies expect people in this role to be creative communicators in addition to technical experts.
It’s worth noting, too, that Microsoft wants site reliability engineers who know both Windows and Unix. If you need further proof that Unix skills are absolutely central to SRE work, look no further than this job ad from the company that created Windows.
Even Amazon—a company that is more of a platform provider than a software vendor—places major emphasis on the ability of SREs to code in one of its recent SRE job ads.
Interestingly, the Amazon job also highlights networking skills as a major qualification. That’s understandable given the complexity of networking in the AWS cloud. But it’s a bit surprising because most other site reliability engineer job ads don’t call out networking expertise as a key skill—despite the fact that network engineering is critical to SRE work.
The Amazon job description mentions the importance of an applicant’s willingness to be on-call, too. We suspect that’s critical in virtually any SRE job, but at least Amazon is upfront about the fact that, at time, you’ll be woken up at 4 a.m. to manage incidents.
There are a few key takeaways from these various SRE job descriptions.
This is not to say that all SRE roles are identical or that all companies expect the same things from their SREs, of course. But the jobs ads or templates we’ve surveyed do highlight how the high-level understanding of SRE translates to on-the-ground reality at actual companies.
DevOps is not just about technology. In many ways, the technology aspect of DevOps is finite but the people, organizational and cultural aspects are infinite. We see many clients get so focused on the tools and technology that they forget about the impact beyond the technology. An important part of building a world-class DevOps process is understanding the cultural and organizational changes that are required to be successful and making those a priority, as well.
Many organizations have still either not started their DevOps journey or are in the first generation of DevOps, which is creating a greater gap between elite and low performers. The business changes and delivery cycles are coming faster than ever, making it critical to use world-class DevOps. Pushing toward continuous flow requires technical, process, people and cultural evolution to keep pace. To achieve continuous flow, we need a continuous mindset. A continuous mindset requires new skills, new ways of thinking, new cultural norms and new responsibilities.
Most companies don’t realize the cultural impact a fully automated pipeline and continuous flow will have on development and operations (and beyond). Change can be difficult and organizations are often met with FUD: Fear (automation brings fear that jobs will be automated away), uncertainty (the unknown creates anxiety) and doubt (needing to employ new skills and new ways of thinking can create doubt about whether resources can adjust).
The rapid pace of business change requires more nimble, flexible and lean approaches to DevOps to meet tomorrow’s demands. This requires changes to structures, interactions, control, processes and expectations. All of these impact the culture and connections within the organization.
Let’s start by defining a few terms:
Continuous integration: The practice of merging all developers’ working copies to a shared mainline several times a day. Grady Booch first proposed the term in 1991, although he did not advocate integrating several times a day. Extreme programming (XP) adopted the concept of CI and did advocate integrating more than once per day—perhaps as many as 10 or more times per day. Common continuous integration practices include maintaining a code repository, automating the build, making the build self-testing, testing in a clone of the production environment and more.
Continuous Delivery: The official definition is, “A software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time and, when releasing the software, doing so manually. It aims at building, testing and releasing software with greater speed and frequency. The approach helps reduce the cost, time and risk of delivering changes by allowing for more incremental updates to applications in production. A straightforward and repeatable deployment process is important for continuous delivery.”
Continuous Deployment: A strategy for software releases wherein any code commit that passes the automated testing phase is automatically released into the production environment, making changes that are visible to the software’s users. The logical next step after continuous delivery: Automatically deploy the product into production whenever it passes required validations.
Continuous mindset is intertwined throughout all three of the above approaches. To reach the maximum value in each area, a continuous mindset needs to be enabled, matured and applied to disciplines in other DevOps areas. The changes are across people, processes, technology and culture. Like DevOps, gaining a continuous mindset is a journey that will take time, many steps and constant learning.
Continuous mindset changes the way people achieve outcomes for your business. This requires an emphasis on changing the way people think at every level of the organization, the way people are connected and the way they work. Achieving true continuous mindset ROI requires significant cultural adoption and collaboration. A key component is leveraging strong organizational change management (OCM). Six OCM steps to achieving the cultural shift to a continuous mindset include:
Ultimately, a continuous mindset changes the organizational engagement model and requires organizations to align on how and when they will work together. This requires shifting responsibilities and empowering teams/individuals to contribute to the improvement of DevOps capabilities. Learning and knowledge transition is an important element to enabling the team long-term.
The organization will need coaching as they begin to understand the concepts and adjust the way they work. Different approaches can be used depending on the overall needs. This purposeful DevOps learning approach will provide DevOps coaches to engage with teams along with DevOps subject matter experts to provide input in the preparation activities. Another option is to provide less formal DevOps coaching to engage with targeted teams. This approach is less structured and primarily relies on direct engagement with less focus on the training and scaling project approach.
Part of creating a continuous mindset involves an environment where transparency is fundamental; where everyone feels committed to the results takes ownership and responsibility for improving them. Successful DevOps transformation requires a holistic approach that includes people, processes, technology and culture. Working in cross-functional agile teams; working with small batches; working in sprints; communicating and collaborating all provide the strong foundation necessary to create a solid continuous mindset. If done correctly, breaking cultural changes down into smaller changes can ensure a certain level of quality in the long term.
DevOps issues can be a thorny subject. The coming together in harmony of Dev (developer) and Ops (operations) represents an arranged marriage of sorts that, for some, will never have a ‘happily ever after’ ending as both parties ultimately grapple with irreconcilable differences.
But despite the naysayers, the very existence of DevOps as a portmanteau (and perhaps sister labels like DevSecOps, to form a security sandwich) is, in many ways, a validation of the need to form a bond of tighter unity and harmony between two factions that have often been at odds with each other over the years.
Even with the popularization, extrapolation and democratization that DevOps has enjoyed through the last decade, not everyone will be convinced of its worth and/or its effectiveness—some even doubt its very existence. Some say that DevOps already existed without a formalized label if you look at the software development practices IBM championed a quarter-century ago.
One thing we can be certain of is that DevOps almost always throws up a few meaty bones of contention. Let’s take a closer look at these issues in the hope that we can harness some of the angst and turn it into positive energy for a DevOps-enriched future. If we are to analyze the most contentious and sensitive DevOps issues in this space, what should we be aware of and how do the big issues break down?
Arguably, the biggest problem DevOps faces is categorizing it. Some call it a methodology for software application development. Proponents of ‘classic’ software methodologies disagree with this idea as, for the purists, a software methodology can only be Agile, waterfall, extreme, rapid, joint or Scrum.
These semantics mean that many people would prefer DevOps to be classified as a culture, a workplace ethic, a technique, a culture and/or a mindset or, perhaps in the vaguest terms, an approach. To be truly successful with DevOps you must take a holistic approach and look at the entire development cycle from beginning to end. Closely evaluate the processes that go into development to find bottlenecks and roadblocks to productivity. By finding the areas where your current processes come up short, you will be able to identify the areas to emphasize when implementing a strong DevOps strategy.
Anyone who hasn’t been living in a cave since the turn of the millennium will know that cloud computing has grown, faltered occasionally and, ultimately, blossomed to become a new standard barometer for all organizations on their journey toward so-called digital transformation.
That’s the good news. The not-quite-so-good news is that cloud (and the contemporary drive to go cloud-native) is still complex from initial deployment to ongoing maintenance, management and reporting.
Taking DevOps into the world of cloud-native will ultimately pay off, but first, there will be challenges as teams get used to the new shape, form and function of the altogether more abstracted and virtualized software toolsets.
The key to getting cloud-native DevOps right will be a prudent approach to monitoring and observability. As cloud-centric DevOps teams ingest the logs, metrics and traces they need to perform solid and dependable system observability, they will need a consistent set of tools to monitor and observe systems in the long term. Within this practice, it will also be important to remember that monitoring shows you lower-level granular information related to system performance. Observability includes all the information gleaned from monitoring and also includes higher-level tools, some of which will be data visualizations for DevOps practitioners to use. When the two are combined for cloud-native DevOps, system health can be optimized, preserved and maintained while any debugging or root cause analysis is executed at the lower level.
With machine-to-machine events now happening more prevalently inside the internet of things (IoT), the need to capture, integrate and analyze the event streams that go on outside of the human loop and bring those log metrics back closer to the sphere of ‘human’ software engineering is not a plug-and-play quick fix.
Getting machines to play nicely and be a part of expansive and progressive DevOps teams should be a given. After all, they’re just machines. In reality, there will be specific skills needed and human DevOps personnel will be required to get used to updates and other alerts that they have not considered before.
Related to our last point on machine events, we need to think about AIOps. When we build AI-driven DevOps and create AIOps, we will need to stop and question where we set limits on process automation and where the wider elements of automation hit the limiter/restrictors. To know just how far we should build out our AIOps practice, exhaustive auditing and analysis must to be carried out; the whole technology proposition here is no simple point-and-click affair. Even when we do establish workable AIOps, know that there will be perimeters.
Add all that to the fact that some AIOps implementations will require what we like to call ‘human handoff’ support when the AI intelligence engine doesn’t know what to do next and needs additional data and training—only then can we start to appreciate that AIOps itself is no simple plug-and-play affair.
One of the unfortunate truths in too many real-world IT shops today is that, where the cloud is used, it is used poorly. Too many technologies are unceremoniously lifted and shifted to cloud instances that an organization procured. This makes cloud-centric DevOps harder to achieve. But why?
Because what happens back down in terrestrial (i.e., non-cloud) programming is the development of individual cross-functional software teams. This silo-based approach happens due to corporate legacy structures, company management systems and, sometimes, for personal, parochial or cultural reasons. When different teams are all reinventing wheels (running diagnostics tests, setting up CI/CD pipelines, delivering upgrades and so on) that should be shared and accessible to all, a natural level of inefficiency surfaces.
These are the five most contentious DevOps issues in the near term, and it would, of course, not be too hard to find and categorize even more. In the future, we might even need to argue over which developers should be categorized as core devs and which core members of the operations department to include.
For software developers, software architects—really, all the software engineering professionals who work in systems administration, database admin, testing, security and all other forms of operations—there’s quite a lot at stake and quite a lot to fight over. And if you ask me, that’s what makes DevOps great.
A corporate axiom is changing, shifting from “Big eats small” to “Fast eats slow.” But change doesn’t happen overnight.
While Agile and lean methods continue to chip away at the status quo, making gains and increasingly moving beyond pockets of teams to the portfolio and then enterprise-wide adoption levels, waterfall approaches to delivery persist.
Rumors of waterfall’s demise, it seems, have been somewhat exaggerated. A survey conducted by the Scrum Alliance (2017) of Scrum practitioners revealed that 78% of respondents said they used Agile-Scrum practices in parallel with waterfall practices. Mixed waterfall/Agile environments are complex. For many large companies, this is the norm. This is when the cohabitation challenges of agile and traditional workstyles become more glaring.
Importantly, as IT finance management (ITFM) leaders know, becoming “more agile” doesn’t give you a pass when it comes to financial discipline and oversight. Agile organizations are still responsible for their ROI and saying you’ve adopted lean methods doesn’t automatically make you lean. Or fiscally responsible. Or well-governed. Or profitable.
Technical organizations are in the midst of evolving from being project-centered to product-oriented solution delivery and scaling Agile from the team level up to the portfolio/enterprise. In these evolving, hybrid working environments, faced with larger and more vocal agile communities, ITFM managers are facing increasing process dissonance between traditional and agile methods, wreaking havoc with their reporting, planning, budgeting and oversight.
In a blended traditional/agile financial portfolio, understanding the true cost of projects, portfolios, value streams and OKRs helps companies make better use of their financial resources to drive profitable outcomes.
And with interest in the value of IT spreading beyond the CIO to the rest of the C-suite, integrated reporting and decision-making that combine Agile work with traditional IT projects, the ITFM role itself is even more essential.
For many ITFM leaders, a focus on the discipline of technology business management (TBM) has improved their ability to better understand IT costs and influence governance and behavior through targeted analysis of real-time reporting (and chargeback) for IT resources. TBM provides a decision-making framework to help leaders understand the true costs involved in the delivery of products and services to customers. That has worked well, particularly in industries where project-centric, traditional waterfall projects are the norm. As it turns out, it works very well for supporting Agile, too.
As agile gains momentum, finance is where it collides with P&L statements, budget dollars and fiscal quarters. With the seemingly irreconcilable Agile release trains and program increments, story points and cycle times, it can be difficult to see an integrated path forward. Fortunately, for teams that have embraced it, TBM provides a well-tested, proven framework that is easily extended to support enterprise Agile transformation.
Agile transformation and scaling initiatives occur as teams of teams seek to reap the rewards of end-to-end enterprise agility.
And, as enterprise agility expands, ITFM leaders will likely encounter process improvement initiatives that are key to an Agile transformation and that directly influence IT finance. Central among them are lean portfolio management (LPM) and value stream management (VSM). Due to their direct influence on ITFM and their intertwined agile characteristics, these two especially deserve early focus. And, while there are certainly more dimensions to enterprise agility, this is a good place to start.