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: Passkeys is getting another big-tech supporter, and the four-day workweek train picks up speed. (more…)
Category: DevOps and Open Technologies
Editorial Calendar for February 2016
-
Kill the Password: Google on Board | 4-Day Week Proves Worthy
-
GraphQL: Security by Obscurity Just Isn’t Enough
The debate about how to secure GraphQL rages on. Many organizations are hesitant to adopt GraphQL for public-facing APIs as there is no precise method to handle authorization concerns as of yet. Without a role-based access layer to enable fine-grained permissions for each field (and underlying services that GraphQL might wrap), the query language can be prone to access control issues.
One method to hamper GraphQL access is to turn off introspection features altogether. Some may assume that hackers can’t perform introspection on an endpoint if it’s not visible. But this isn’t entirely true—even though an “internal” endpoint may not be fully documented, any endpoint on the public web can be searched and introspected quite easily by brute-forcing queries or through field suggestions.
I recently met with Karim Rustom, cybersecurity engineer, Escape Technologies. According to Rustom, “making something obscure isn’t enough to make it secure.” Leveraging a single slip-up in access control could be used as a doorway into these systems. Although it’s a best practice to limit introspection, it’s likely not enough to protect production GraphQL endpoints, he said. Below, we’ll consider some common GraphQL threats and alternative solutions to retain a safe GraphQL implementation.
Common GraphQL Threats
Having run thousands of scans on production GraphQL endpoints, Rustom found common trends emerge around GraphQL threats. First, he noticed the potential for denial-of-service attacks to be quite high. GraphQL, by design, is intended to query whatever data the client requires. But sometimes, these queries can return a mountain of data.
If GraphQL owners don’t place a limit on what can be requested in a single query, the platform can easily fall victim to denial-of-service attacks and service interruptions. And limits aren’t only necessary for bulk read-only operations—although GraphQL is primarily used for fetching data, some methods might initiate intense server-side processing, which should be limited in some form. According to Rustom, such data manipulation methods are especially pervasive in FinTech, food delivery or health care-related applications.
Another rampant GraphQL threat lies in access control issues. This comes as little surprise, as access control is ranked as OWASP’s most common web application security risk. Often, when creating new objects or new queries, a developer might forget to add the correct authorization, said Rustom. This can become a huge problem and lead to privilege escalation.
Finally, too many production GraphQL implementations rely on security by obscurity. “Folks think that disabling introspection is a layer of security—we highly stress that it’s not,” said Rustom. He recalled performing penetration testing for a certain client; even though they had disabled introspection, the team was able to fetch ample open paths and discover an unsecured doorway to divulge secret internal knowledge.
Solutions and Best Practices
To avoid some of the vulnerabilities presented above, it’s recommended to first place request limits on overly complex GraphQL calls to prevent denial-of-service attacks. One nuance here that Rustom recommended is to consider request complexity—not in terms of the query size, but the overall processing required. He suggested assigning scores for every query and permutation to help inform the decision about whether or not to process the incoming call.
Furthermore, it’s recommended to disable field suggestions as the feature could be prone to abuse. Using field suggestions, hackers can leak a lot of information to build a partial or complete introspection. These tactics are similar to the word-busting techniques black hats use to perform introspection on REST endpoints.
Although it’s a good practice to limit the possibility of surveillance, hackers can still discover systems and leverage other common vulnerabilities like broken access control. Rustom suggested other tactics, such as luring attackers into a honeypot or logging them into a fake account. Or, creating error messages that are intentionally misleading for a attacker.
To retain a safe GraphQL implementation, organizations can use pre-made free and open source tools to audit their surface area and scan for known vulnerabilities. For example, GraphQL.security quickly scans your GraphQL URL endpoint to discover vulnerabilities. Or, Graphinder can examine a subdomain to discover GraphQL endpoints, which could aid auditing purposes. There’s also middleware that wraps a GraphQL service with additional security, such as GraphQL Armor and GraphQL Shield.
Future of GraphQL in the Market
There appear to be many flavors of GraphQL throughout the market. We’ve seen it emerge as a mechanism to power backend microservices. We’ve also witnessed the technology adopted as a layer to centralize multiple REST services with a more usable data retrieval mechanism for frontend engineers. Some GraphQL endpoints also run on the public web to serve end clients and external partners.
“GraphQL is a beautiful technology, just lacking in security,” said Rustom. And unfortunately, his outlook for API security looks grim—amid political turmoil and economic instabilities in regions like Europe, some companies may seek to cut cybersecurity investments to stay lean. For companies that haven’t yet suffered a breach, security is easy to ditch to slim budgets, but it should remain a priority, said Rustom. “Keep securing GraphQL.”
-
BMC Survey Surfaces DevOps Mainframe Progress
A global survey of 1,000 executives and IT professionals that rely on mainframes found 70% are now employing DevOps processes to build and deploy applications on the venerable platform, with 60% of those respondents now deploying applications faster. A full 80% of respondents also wanted to deploy mainframe applications faster, according to the survey.
The survey also found that integration of IT processes across mainframes and distributed computing environments has increased, with well over half (57%) now sharing platform operations roles. A total of 44% reported site reliability engineering (SRE) as a shared role that spans both platforms.
Applications developed in-house are being delivered faster than a year ago, reinforcing the mainframe’s business value, with 76% realizing value in under 12 months.
More than half of respondents (53%) said their organizations is also implementing DevSecOps practices in a way that spans all those platforms. The top priority for organizations that have mainframes is security and compliance (67%), the survey also found.
Nearly a third have also adopted artificial intelligence for IT operations (AIOps) across mainframes and distributed computing platforms. Survey respondents that have adopted both mainframe AIOps and DevOps reported they are gaining visibility into service issues 70% faster, with 41% improving uptime and availability, according to the survey.
Finally, the survey found 95% of respondents still had a positive perception of the mainframe as a platform for running applications, with 62% reporting transaction volumes on the mainframe are increasing. More than half (55%) also noted workload volatility and unpredictability is increasing. A similar percentage (55%) also reported more than half of their data is on a mainframe.
John McKenny, senior vice president and general manager for Intelligent Z mainframe optimization and transformation at BMC, said IT teams in a downturn are, as usual, trying get the most out of their existing investments. The thing that is changing most is the mainframe is now becoming more integrated with distributed computing environments as IT teams strive to achieve that goal, he added.
In general, there’s still much work to be done in terms of furthering adoption of DevOps best practices in mainframe environments, noted McKenny. Each organization will most likely determine at what level to apply those practices based on the frequency at which applications running on mainframes need to be updated. There are still plenty of applications running on mainframes that might not need to be updated for many years, but as organizations embrace digital business transformation initiatives, the need to update mainframe applications more frequently has increased, noted McKenny.
Regardless of the type of application deployed, it’s apparent that the days when mainframes were managed in isolation from the rest of a distributed computing environment are slowly coming to an end. A mainframe is, arguably, just another node for deploying applications. The one major difference is that, as platforms are considered, the mainframe is a lot more secure, said McKenny.
The challenge and the opportunity now, of course, is as much about changing attitudes toward the mainframe as it is making the right DevOps tools available to the IT teams tasked with managing heterogeneous IT environments.
-
Low-Code/No-Code Options Key to Bringing Web3 Mainstream
Driven by cryptocurrencies and NFTs, Web3 is one of the most talked about technology industry waves in the last several years. But even with all the money it’s generated and the media coverage received, Web3 hasn’t yet gained the mainstream acceptance that Web2 has achieved. One of the main reasons for this gap is that blockchain-based technology continues to be complex, requiring developers to learn new languages and development environments as well as gain expertise in concepts like cryptography, hashing, oracles, zero-knowledge proofs, proof of work, proof of stake and more. And even once users understand that they then need to figure out how these pieces all fit together. The required time and money investment has slowed adoption by developers—until now.
Web3 is finally coming into its own, thanks in part to the abstraction provided by SDKs and APIs. This technology is making it increasingly possible for all developers, not just Web3 developers, to participate and innovate on this new wave of technology disruption.
If you look at many of the providers in Web3 like Infura (ConsenSys), NFT Port and OpenSea, for example, and their growth, there’s been a significant movement from these providers over the past couple of years from simply providing nodes for underlying blockchains to now offering higher-level APIs. This translates into developers and companies no longer having to set up their own nodes to provide SDKs and higher-level APIs that rely on data indexers and pre-audited smart contracts to simplify token minting and reading from blockchains.
With the evolution of APIs and SDKs, developers using these programs no longer have to learn the intricacies of creating contracts on different blockchains, multiple developer tools, syntax and languages nor must they possess a deep understanding of these different blockchains. Instead, developers can rely on APIs that abstract the underlying complexity, easing the burden for developers who need only pass parameters like chain for indexing, token or smart contract IDs and other general-purpose information. These APIs will evolve into providing more low-code/no-code offerings with larger graphical UI components that developers can simply drag-and-drop to extract value as well as create DApps that can also be retrofitted into their existing applications or app infrastructure.
This evolution will be similar to the way the cloud evolved; look at AWS’ and Azure’s infrastructure-as-a-service (IaaS) as a current example. Existing apps could be lifted and shifted onto the cloud. This led to platform-as-a-service (PaaS) offerings with APIs that were cloud-ready; with developers’ latency, security and scalability needs augmented by low-code or no-code offerings. This is also similar to Microsoft’s Power Platform which used drag-and-drop operations on many cloud components, allowing integration and extensibility of the Microsoft platform in a short amount of time. This spawned a new generation of ecosystem players as the bar to participate and innovate in the cloud lowered; now every type of developer, no matter what their area of expertise, can take advantage. This also meant that the new technology was accessible for all developers to solve business challenges more quickly while significantly decreasing time-to-market.
You can already see this parallel in the Web3 world. A lot of the key players building developer tools are starting to target the business and technical decision-makers. They are talking about how easy it would be for Web2 developers to leverage their high-level APIs and SDKs (something that Web2 developers understand extremely well) to use Web3 technology to solve new business challenges. And they can do so without setting up expensive innovation organizations and looking for scarce (and expensive) Web3 developers. The next step in this evolution would be to extend these APIs for NFTs, analytics, streaming, MEVs, estimating gas and more to have no-code, automatically generated components that finally allow more Web2 developers to transition to Web3 and, as a result, bring Web3 into the mainstream.
-
Linux 6.0 is Faster, Cooler | Debian Goes Proprietary | Google Africa Region
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: Linux 6.0 promoted to Stable, Debian 12 will include closed-source binaries, and Google Cloud opens its first Africa region. (more…)
-
Driving Organizational Success With the 2022 State of DevOps Report
“Ship it!”
We have just completed the research and analysis for the 2022 Accelerate State of DevOps Report (SODR) and oh boy, do we have some interesting things to share! First, let me take a short step back for those of you that may be new to the DevOps Research and Assessment (DORA) and our annual report, the SODR. DORA is an academically rigorous research program that seeks to answer the questions, “What practices enable teams to be high-performing software teams? And how do these practices impact organizational performance?”
Since 2014, we have surveyed 33,000 practitioners around the world spanning all major industries. The project is intentionally–and staunchly–tool- and platform-agnostic. The research builds on itself, and each year we seek to both evaluate previous findings and expand in other directions or areas of research. This is important to note because many of the core findings, such as “software delivery performance drives organizational performance,” have been validated year after year. I would encourage you to go back and read all the reports from years past.
Security
This year, we doubled down on our 2021 research into software supply chain security by looking at the technical practices that improve software supply chain security and the non-technical practices that impact an organization’s ability to excel at securing their software supply chains. We leveraged two frameworks to focus our research: Supply Chain Levels for Software Artifacts (SLSA) and NIST’s Secure Software Development Framework (SSDF). Below is a summary of some of our key findings in this area:
- Shifting left on security is a broadly adopted practice. Our research shows that two-thirds of respondents are actively pursuing software supply chain security by seamlessly baking security into the development process.
- Culture is the primary driver of security practice adoption. One might expect that technology is the primary driver, but our research showed that a generative organizational culture (eg. performance-oriented, highly cooperative, shared risk) leads to healthier software practices.
- Technical practices around CI/CD predict success in security. Companies that use source control, continuous integration (CI) and continuous delivery (CD) have more established SLSA practices. These practices shift security left to the developers and ensure consistent security scanning.
- Cloud enables secure software practices. The five characteristics of cloud computing as defined by NIST enable the successful adoption of software supply chain security which, in turn, predicts greater organizational performance.
Our research showed that companies who prioritize and excel at securing the software supply chain experienced fewer service outages, anticipate fewer security breaches and demonstrate high levels of both software delivery performance and organizational performance. The data showed that through the use of modern practices like continuous integration, teams can improve their security posture and even amplify the positive impact these security practices have on software delivery metrics (MTTR, deployment frequency, lead time-to-restore service) and overall organizational performance.
Culture
We saw above that the biggest predictor of an organization’s application development security practices was the presence of a generative organizational culture based on shared risk and information sharing. We also see that elements of these types of cultures lead to higher overall organizational performance, as well. Our research showed that high organizational performance can be achieved by fostering environments that are:
- Supportive: Teams that felt supported and that they had buy-in from leadership (e.g., more financial support, more allocation of resources, sponsorships, etc.) were associated with high-performing organizations.
- Stable: Teams that did not experience much change in membership over the last 12 months were more likely to be a part of high-performing organizations.
- Flexible: Organizations with higher levels of working flexibility around where work was performed–remote, in-person or hybrid–were higher-performing overall.
We also looked at burnout again this year and expanded the scope to understand which elements of culture contributed to lower levels of burnout. We found that generative culture, team stability and work flexibility all contributed to a reduction in burnout among employees.
Reliability
In previous years, our research told us that those that excelled in technical practices also excelled at organizational performance. This year, we have more nuanced data about this topic. This year, we saw that software delivery does not predict strong business outcomes unless these practices were paired with reliability. Think about it–will a customer be satisfied with new features if the service isn’t stable? What is the benefit of pushing code quickly into a fragile environment? Reliability is an essential component of driving organizational performance through software delivery performance.
We also see that site reliability engineering’s (SRE’s) impact on organizational performance is non-linear; reliability engineering practices often do not result in additional reliability or organizational performance until a certain maturity is reached. It’s important for teams to know this and approach their SRE practice as an investment. It will likely not be sparkly ponies and unicorns initially as you build the reliability muscle but, as you advance, high performance and success are likely.
Cloud
Public cloud use is up a whopping 36% over 2021, whereas companies reporting no cloud usage at all are down by 50%. The use of hybrid cloud is up by 25%. Unsurprisingly, the use of cloud computing was associated with higher organizational performance. In past years we saw that it wasn’t “using cloud” per se that led to organizational performance, rather it was the achievement of the five essential characteristics of cloud computing–on-demand self-service, broad network access, resource pooling, rapid elasticity and measured service. This year, we saw that cloud computing enabled things like reliability, continuous delivery and improved supply chain security which drive organizational success.
Over 50% of folks who took our survey reported that they leveraged multiple cloud providers. We asked respondents what benefits they realized from using multiple cloud providers. Here are the top three:
- Availability
- Leveraging the unique benefits of each provider
- Trust is spread across multiple providers
Given the fact that reliability seemed to be the key to being a successful software delivery shop as well as a successful organization, it is not surprising to see availability listed by almost 63% of respondents as a benefit derived from using multiple clouds.
Summary
Our research continues to progress and we continue to dig deeper and deeper into the capabilities and practices that impact your business. We see broad adoption on the topics of security and reliability which are both heavily anchored in culture. Good culture leads to success. Period. There is no magic culture button and it takes work, but it is very achievable. Start by defining organization-wide or line-of-business-wide goals and then just start continuously improving. Don’t worry about creating a three-year plan for improvement; create a one-month plan and just get to work instead. At the end of that month, evaluate your learnings, refine your focus and get back to work. With a commitment to hard work and continuous improvement, your investments should start paying off and, as an added bonus, you’ll have a better culture.
We hope you have enjoyed these juicy findings as much as we have and we encourage you to read the entire 2022 State of DevOps Report.
Also, please join us at dora.community to continue the discussion about these findings and to share and discuss your experiences on your journey toward excellent software delivery and operations.
-
Cosmonic Previews Deployment Platform for Distributed Wasm Apps
Cosmonic has made available a preview of a platform for deploying applications built using the portable WebAssembly (Wasm) binary format that enables applications to be deployed on any platform.
Cosmonic CEO Liam Randall said the company is providing early access to the Cosmonic Platform Developer Preview platform to enable developers to experiment with a new type of software artifact that will be used to build a new class of cloud-native applications.
The Cosmonic Platform Developer Preview platform is based on wasmCloud, an open source application runtime that hosts components written as Wasm modules that can then be loosely connected to build applications. Originally developed under the auspices of the World Wide Web Consortium for building browser applications, Wasm is a portable binary instruction format for building software that describes a memory-safe, sandboxed execution environment.
That approach replaces the current predominant method for building software that relies on the aggregation of software components that tend to lack distinct boundaries. It’s that lack of distinct boundaries that enables malware to flow so easily from one software module to another. The wasmCloud runtime, originally developed by Cosmonic, provides a platform for deploying distributed Wasm applications and is now being advanced under the auspices of the Cloud Native Computing Foundation (CNCF).
Prior to Wasm, Randall noted, every format for building applications led to the creation of ‘walled gardens’ that resulted in developers being locked into a platform. Wasm is the first software artifact that enables applications to run on an platform, including Linux and Windows, without any modification required, said Randall.
It may be some time before Wasm becomes the preferred artifact for building applications, but it’s clear the walls that have separated one IT platform from another are about to crumble. Once applications become much more portable, the longstanding goal of writing an application once and then deploying it anywhere may finally be achieved. Just as importantly, those applications will run in a memory-safe sandbox that is more secure than what can be enabled in legacy IT platforms. In fact, as more organizations review the security of their software supply chains, they may decide to accelerate their embrace of Wasm to build more secure applications.
Naturally, the transition to Wasm will have major implications for DevOps teams, as it represents an opportunity to streamline deployment processes across multiple platforms. In effect, the total cost of application development and deployment would decline as processes spanning multiple platforms become more automated using platforms such as wasmCloud. Ultimately, much of the infrastructure complexity that developers need to navigate today would be eliminated, noted Randall.
It’s not clear just yet to what degree Wasm will drive a transition to another era of computing, but the potential to change almost every aspect of IT is on the horizon. Ultimately, the issue will be decided by how quickly developers are willing to embrace yet another software artifact for building and deploying applications. What is clear is that the number of platforms that will make it possible to experiment with Wasm are starting to multiply.
-
Using Internal Wikis for Web Development Projects
A team-based web development project is always a complex endeavor. It involves different developers with varying levels of experience, different fields of expertise, milestones to accomplish and a timeline to achieve.
To facilitate the sharing of information, it’s not always enough to use project management tools like Asana or Jira. Sometimes, a wiki may be needed to help distribute knowledge and best practices to everyone working on the project.
In this guide, we discuss the practicality of using wiki tools for information sharing among web devs.
What is a Wiki?
A wiki is a program that enables users to collaborate in the creation and population of the content for a website. The word comes from the “wikiwiki,” which is Hawaiian for “fast.” In other words, a wiki is an app that allows for crowdsourced content to create pages of information.
In addition to wiki pages, Web 2.0 tools allow users to connect and share information via rich media such as RSS, OpenSocial and OpenID. Another use for wiki tools is to share creative content such as photography and design concepts. A very simple way of sharing web pages on the wiki is to add a share icon at the top of the page. Simply add the share icon to a wiki page.
The Benefits of Wikis
Wikis bring a number of benefits to web dev teams, such as:
Knowledge Sharing
Since people working on the project have different levels of expertise and experience, the wiki allows subject matter experts to contribute information based on their specialization. This valuable knowledge can be accessed by others who need such information and dispels the formation of “information silos” that usually impede teams working in isolation from each other.
Searchable
The information stored in a wiki is categorized and organized in hierarchical and logical structures. It allows users to easily search for information based on topic, field or category, and learn what they need in an instant. This improves productivity and minimizes the need to chase other colleagues down in the search for data.
Single Source of Truth
By acting as a central repository of information, all data gets vetted before making it into the wiki. This makes the stored information verified and accurate and the wiki acts as the single source of truth for the whole team.
Easy Updates
The wiki allows contributors to update information easily and conveniently. As such, all references are up-to-date–a critical factor for any web dev project.
Wikis and Web Development
Wikis have the potential to make it easier to share knowledge with stakeholders as well as spread the expertise of a motivated development team, leading to better management and accountability.
Many wikis are publicly funded in different ways. For instance, several open source wikis exist, such as BikiWiki, ObjectiveWiki, GrowWiki and PDFLabs wiki, but we can see a few web-based initiatives in this space as well. These include Virgil Technology wiki and KnowledgeVerify.
Microsoft’s SharePoint platform is arguably one of the best solutions for online collaboration on web-based projects. Because SharePoint is integrated with almost all major applications (Windows, Word, Excel, PowerPoint, etc.), users can create shared webpages based on SharePoint site templates and share these with their colleagues. While it’s true that SharePoint cannot solve all the problems related to information sharing and preservation, it provides a great starting point for finding common ground on project development.
The Advantage of Wikis Over Other Collaborative Tools
While project management tools usually incorporate collaborative functions, they are not as full-featured as a wiki is when it comes to knowledge sharing. The wiki is notable for having the following features that other tools may lack:
Search functionality: Wikis have full-featured search capabilities to aid in the search for information. No need to drill down tree structures and categorical hierarchies.
Comments: Adding comments to a page is an efficient and fast way to contribute and help others.
Content creation: You can write wiki articles using any text editor, or you can write it using the wiki syntax—it largely depends on the platform. The wiki syntax is quite similar to the HTML format. One thing that makes wikis useful is that when you share a wiki page, everyone can see the changes as they are made. So sharing works through a web link instead of having to publish to a file.
The wiki markup is a sequence of tags that represent the structure of a page. There are two main types of wikitext; the wiki syntax and the HTML syntax. The wiki syntax comes from Wikipedia, which is a popular wiki. Both are immediately available to devs, making content creation and editing easier.
Access control: Since wikis can change based on edits and the number of links get added to the pages, they use an access control and version management system.
With its growing array of software options and constant framework decisions, the world of web development always needs quick, organized patches of information. Rapid creation and publishing options mean that, for an almost 20-year-old technology, wikis can still be a valuable tool for web devs today.
-
Alleviating Developer Workflow Headaches by Moving to the Cloud
Leaders in tech make one common mistake when it comes to serverless and cloud computing: They want to migrate their current environment exactly as it is to the cloud. That’s about as limiting as planning a flight path along the road network and deciding the route based on street-level traffic. You can do it, but everyone’s going to look at you like you’re crazy.
Keeping that ‘lift and shift’ mindset prevents developers from seeing the real ROI of cloud computing and serverless technology. Instead, we have to challenge our traditional ways of thinking.
Redefining How we Think About Software Development
The traditional definition of software is anything that makes the hardware do what we want it to. We use operating systems to control internal functions as well as peripherals. We use application software to direct our computers to execute commands. So we tend to think of software as programmatic, needing specialized programming languages to develop. But the most popular functional programming language isn’t Erlang or Haskell or Lisp. It’s Microsoft Excel, if you can believe it, with over 750 million users.
Every Excel spreadsheet represents someone’s software; it makes their hardware process data in a way that’s valuable to them. In a similar way, the “systems” we build on the information technology side are just more software. And cloud computing gives us a new range of powerful tools so we can build bigger systems faster than before.
What are Cloud Computing and Serverless Computing?
Cloud computing largely references data centers and data storage. Serverless computing is one piece of cloud computing. It lets developers create software without managing infrastructure. In the end, it increases productivity, speeds up product delivery, optimizes resources and keeps developers focused on the end product rather than infrastructure maintenance.
Once deployed, serverless apps respond to demand, scaling up or down as needed. So when a serverless function sits idle, it costs nothing.
Key Benefits of Cloud Computing and Serverless Computing
There are many benefits of cloud computing and serverless frameworks. By far, the one leaders are most excited about is cost control and increased ROI. It’s also one that leaders most often miss.
Increase ROI With Cloud Computing and Serverless
The number-one way to increase ROI with serverless frameworks and cloud computing is to avoid building anything from scratch. Invest in open-minded research. Sometimes you need to build something yourself, but often there’s a way to shift some of the burden away from your team.
An easy example is functions. The first thing most developers think of when they hear “serverless” is functions. But the functions running code are just a tiny piece of the puzzle. Serverless technology allows development teams to hand off as much work as they can to cloud platforms like Azure, Amazon Web Services (AWS) and Google Cloud Platform (GCP).
Just like someone wouldn’t buy a field, till it, plant wheat, water it, thresh the wheat into flour, bake bread and toast it to make a piece of toast, developers shouldn’t write their own code when the building blocks already exist in their cloud platform. Take, for example, Azure’s Durable Functions feature. This feature manages stateful workflows so teams don’t need to explicitly create, store and retrieve the progress through your data’s workflow in some other place. This process is so common to the systems that teams build that the cloud providers made it available without needing us to write lines of code. It’s like instant toast delivered to your door!
The more a team can leverage already-made code, the more time they get back on their schedules and the more money goes back into the team’s budget, something we can all appreciate!
-
Wipro Fires 2-Job Staff | Python Bug from 2007 | Lite Layoffs
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: Wipro fires 300 for moonlighting at competitors, Python has a nasty 15-year-old bug, and companies are finding new ways to lay people off without calling it a “layoff.” (more…)