Why Cloud Stocks Came Into Focus During the Pandemic

The COVID-19 pandemic forced businesses worldwide to accelerate their shift toward digital-only operations almost overnight. What had been a high-priority strategic initiative became an operational necessity. Remote work, digital customer engagement, and cloud-hosted collaboration tools moved from “nice to have” to mission-critical infrastructure in a matter of weeks.

For investors, this context made cloud computing companies a notable area of interest—even as short-term market volatility hit nearly every sector. Three companies that analysts highlighted at the time were Salesforce.com (NYSE: CRM), Twilio (NYSE: TWLO), and Upwork (NASDAQ: UPWK). Each represented a different segment of the cloud ecosystem, with distinct risk profiles and growth stories.

Salesforce: The Enterprise Cloud Platform

Salesforce began as a provider of sales and customer service software and has since expanded into a broad enterprise cloud platform covering marketing automation, analytics, integration, and more. Its customer relationship management (CRM) software remains central to how thousands of organizations manage interactions across every customer-facing function.

The argument for Salesforce as a relatively resilient holding during an economic downturn rested on the sticky nature of its products. CRM and customer engagement software tends to be deeply embedded in business workflows. Cutting those systems requires significant internal disruption, which makes them among the last items to be removed from a corporate budget.

Financial Position at the Time (Early 2020)

• Cash, cash equivalents, and short-term investments: approximately $7.95 billion
• Total debt: approximately $2.67 billion
• Active acquisition strategy, including the pending purchase of Vlocity for approximately $1.3 billion
• Stock trading at approximately 34.8x trailing twelve-month free cash flow at the time of publication

Salesforce’s history of converting organic growth and acquired businesses into free cash flow was a key part of the investment thesis. Its valuation was premium-priced even after a pullback, but analysts argued this was justifiable given the company’s long runway in the enterprise software market.

Twilio: Building the Communications Layer of the Cloud

Twilio operates in a category it largely helped create: Communications Platform as a Service (CPaaS). Its APIs allow developers to embed voice, SMS, video, email, and authentication capabilities directly into applications—without building or maintaining the underlying telecom infrastructure.

The pandemic made Twilio’s value proposition more visible. Businesses scrambling to maintain customer contact through digital channels—chat, automated messaging, video, and secure login flows—found that traditional contact center infrastructure could not adapt quickly enough. Twilio’s cloud-native, developer-friendly approach allowed organizations to build or extend these capabilities rapidly.

Financial Position at the Time (Early 2020)

• Organic revenue growth: approximately 47% in 2019
• Cash and short-term investments: approximately $1.85 billion at end of 2019
• Free cash flow: negative $53.2 million (trailing twelve months at time of publication)
• Stock trading at approximately 10.6x trailing twelve-month revenue—described as the lowest revenue multiple since mid-2018

Twilio was not profitable at the time, which is an important caveat. The investment case rested on revenue trajectory, a strong cash position to fund continued losses, and the long-term market for programmable communications. The company’s Flex platform—a fully customizable cloud contact center—was also highlighted as a significant growth vehicle for enterprise customers modernizing their customer service operations.

Upwork: The Gig Economy’s Cloud Infrastructure

Upwork is the largest online marketplace for connecting businesses with freelance talent. Beyond matching employers and contractors, the platform provides collaboration tools, time tracking, invoicing, and payment processing—making it a full-stack operational environment for distributed work.

The pandemic created a complicated near-term picture for Upwork. On one hand, remote and flexible work arrangements became the norm almost instantly, validating the platform’s core premise. On the other hand, widespread hiring freezes and corporate budget cuts threatened to suppress demand from the employer side of the marketplace.

Financial Position at the Time (Early 2020)

• Market capitalization: approximately $826 million at time of publication
• Price-to-revenue multiple: approximately 2.6x 2019 revenue
• Available liquidity: approximately $134 million
• Total debt: approximately $18.3 million
• Free cash flow: negative $15.6 million (prior year)
• Revenue growth forecast for 2020 (pre-pandemic): 13%–15%

Upwork’s balance sheet gave it sufficient runway to weather a downturn and continue investing in product development. The longer-term argument was structural: the global shift toward flexible, project-based work was already underway before COVID-19, and the pandemic may have accelerated it. For a small-cap stock with meaningful volatility, the standard guidance applied—building a position gradually over time rather than committing capital all at once.

What These Three Stocks Have in Common

Despite serving very different customer segments, Salesforce, Twilio, and Upwork shared several characteristics relevant to the cloud computing thesis of 2020:

• Cloud-native architecture: All three delivered services entirely through cloud infrastructure, making them inherently scalable and accessible for distributed workforces.
• Network effects and switching costs: Each platform became more valuable as more users or developers adopted it, and each embedded itself deeply into customer workflows.
• Strong cash positions relative to debt: None faced immediate liquidity crises despite being in growth-investment mode.
• Long-term tailwinds: Remote work, digital customer engagement, and flexible labor markets were trends already in motion before COVID-19 and were expected to persist afterward.

Important Caveats for Readers

This analysis reflects conditions and valuations from April 2020. All financial figures, stock prices, and market conditions cited here are historical. This article is not financial advice, and past performance or historical analysis should not be used as the basis for current investment decisions. Consult a qualified financial professional before making any investment.

The original analysis was sourced from Motley Fool (fool.com).

Denis Žoljom, the automation representative for the WordPress theme review team, proposed moving much of the theme review system over to GitHub. The idea is to move the interactive parts of the review away from the current system. The proposal claims such a move would streamline the process via automated tools and make the manual, reviewer-to-author interactions easier.

Currently, the theme review process takes place on Trac. For many theme authors and reviewers, the software can feel archaic. It does not have the feature set that developers have become accustomed to with other solutions. With the move of major parts of WordPress, such as feature plugin development, to GitHub over the past few years, it might be time to reevaluate other areas of the core project.

Žoljom noted in the proposal that reviews handled through Trac are cumbersome. As a former theme review team lead and reviewer, I know how many on the team feel. Right now, much of the review process is manual. It is handled via a lot of back-and-forth communication between the reviewer and author. There is no good way to leave a note or comment on a specific line of code when there is an issue. This ongoing discussion between reviewer and author is sometimes hindered by a language barrier. The experience of comparing changes between code updates is lackluster at best. Plus, the only automated check is handled by the Theme Check plugin.

Handling reviews on GitHub opens a new world of possibilities that could make reviews more efficient and provide a better experience on both ends of the process.

From 2015 through 2019, I ran a side business with a partner where we performed code reviews on plugins and themes. The majority of that business was working with commercial theme shops. Around 90% of the reviews were handled on GitHub.

At the same time, I was still volunteering with the WordPress theme review team. There was no comparison in terms of user experience. GitHub won hands down. This experience turned me away from wanting to perform reviews for the official directory. Nothing there was streamlined. It was tougher to point to specific code issues and check if a problem was corrected when an author sent in an update.

Žoljom’s initial proposal outlines a system where the theme author submits their theme through the WordPress theme upload page. If it passes the initial check, the system would automatically create a new GitHub repository with the theme. Theme authors can then fork this newly-created repository to work on code changes based on reviewer feedback. Theme updates would also work through GitHub.

“I think that forks are a good middle ground,” said Žoljom. “Authors have forks on their own GitHub accounts and can update those, and make updates that way even. That would definitely help us with people who are trying to trick the system by updating their themes once they go live with things that break the requirements.”

The proposal is merely an idea to explore at this stage. Much of the process could change if it is given the green light to proceed.

“In the end, I hope this initiative will go live and help us bring the review queue down,” said Žoljom. He has hopes the team can integrate more automated checks such as the WordPress Coding Standards. With more automation, it could also mean the theme review team could focus on other projects it works on, such as preparing for the future of full-site editing and continuing education.

Beyond the Review Process
One of the primary issues the team has faced over the years is educating authors on writing cleaner and more secure code. Some issues like sanitizing data on input and escaping it on output are still prevalent during reviews. The team’s history of communication via Trac has not seemed to help with education on the whole.

“The main point is the fact that many people can be involved in the review process, and then you have experienced reviewers who can show why some code is not good or needs improvement,” said Žoljom. “This provides a way for many people to see what is wrong with the code and how they can improve it. Plus the forked theme stays in their repo, so they can see the changes that they made and why.”

Žoljom has a few items in reserve for the long-term wish list. One possibility for the future may be setting up themes on Packagist for installation via Composer. He admits that it is a longshot at best.

“I see this as an opportunity to bring one aspect of WordPress up to par with other modern PHP frameworks like Laravel,” he said. “Plus, utilize automatic tools at our disposal. From PHP CodeSniffer, PHPStan, ES Lint, and a plethora of other tools, we could also show authors how they can set these tools on their projects and make their coding skills better. Maybe throw some automatic integration tests in the mix. The possibilities are really endless.”

The Shadow IT Problem Is Bigger Than You Think

Do you know how much cloud and IT infrastructure your employees are actually consuming? For most organizations, the honest answer is: not entirely. Shadow IT — resources provisioned outside of officially sanctioned IT channels — represents a massive and often invisible drain on budgets and security posture.

According to research cited by the Everest Group, shadow IT spending accounts for 50% or more of total IT budgets at many organizations. The financial exposure is significant on its own, but the security risk compounds the problem further. Gartner has projected that a substantial share of security attacks would target shadow IT resources — systems and services that IT teams may not even know exist, let alone monitor or patch.

The takeaway is clear: shadow IT is not merely an accounting headache. It is an operational and security liability that, left unchecked, can expose organizations to breaches, compliance failures, and runaway spend.

Why Developers Go Rogue — and Why You Can’t Blame Them

DevOps and application teams are among the heaviest consumers of IT resources in any modern organization. They operate on tight release cycles, respond to shifting product priorities, and measure productivity in hours, not weeks. When they need a compute instance, a test database, or a staging environment, they need it now — not after a five-day ticket queue.

IT teams are not the villain here either. They are typically managing dozens of competing priorities, responding to incidents, maintaining compliance, and supporting the broader business. They are genuinely doing their best. But from a developer’s perspective, waiting days or even hours for a resource can feel like an eternity when a sprint deadline is looming.

The result is predictable: developers bypass IT, spin up resources on personal or departmental credit cards, choose whichever cloud service is fastest to provision, and — inadvertently — introduce security and cost risks the organization has no visibility into.

The Right Answer: Self-Service Provisioning With Guardrails

The goal is not to lock developers down further — that approach has already failed. The goal is to give developers a fast, sanctioned path to the resources they need, while preserving IT’s ability to enforce cost controls, security policies, and compliance requirements.

Self-service provisioning, backed by a curated service catalog, is the practical answer. Rather than forcing developers to navigate unfamiliar infrastructure systems (a process that introduces both delay and misconfiguration risk), a well-designed catalog surfaces only the resources relevant to a given team. Developers pick what they need, and provisioning happens in minutes rather than days.

Orchestration blueprints are a key enabler here. A blueprint is a reusable, pre-approved template that automates the provisioning of a defined set of resources — compute, networking, storage, permissions — in a consistent, policy-compliant way. Because the blueprint encodes IT’s security and configuration requirements, developers get speed without improvisation, and IT gets repeatability without manual review for every request.

Maintaining Control: Cost, Compliance, and Access Policies

Self-service does not mean ungoverned. IT teams can layer automated controls on top of the self-service model to prevent the cost and compliance problems that made shadow IT dangerous in the first place.

Cost Controls

• Automated quotas and spending limits: Cap how much compute, memory, or cloud spend any individual or team can consume in a given period.
• Power scheduling: Automatically shut down non-production VMs outside of working hours, preventing resources from running over weekends when no one is using them.
• Expiration dates on environments: Demo environments, staging clusters, and proof-of-concept deployments can be configured to terminate automatically after a set period, eliminating forgotten resources that silently accumulate cost.

This matters more than it might seem. Research attributed to ParkMyCloud suggests that roughly 44% of IaaS compute spend comes from non-production resources that are simply left running accidentally. Automated lifecycle policies directly address this waste.

Access and Approval Policies

• Role-based entitlements: Define who can request which types of resources — servers, workloads, XaaS offerings — and at what scale.
• Approval workflows: For higher-cost or higher-risk resource types, route requests through an approval chain before provisioning occurs.
• Real-time resource attribution: Maintain a live inventory of who is using which resources, so there are no surprises at month-end and no orphaned assets without an owner.

What Good Looks Like: IT as an Enabler, Not a Bottleneck

When self-service provisioning is implemented well, the dynamic between IT and DevOps shifts. Developers access pre-approved, correctly configured resources in seconds or minutes through a catalog designed for their needs. IT is no longer fielding repetitive provisioning tickets and can redirect that capacity toward higher-value work: architecture, security posture, platform improvements, and incident response.

Shadow IT shrinks not because developers are blocked from going around IT, but because the official channel is genuinely faster and easier than the workaround. When the sanctioned path removes friction instead of adding it, developers have no reason to go rogue.

Key Takeaways

• Shadow IT is a spending and security problem that grows when official IT channels are too slow or too complex for development teams.
• Self-service provisioning with a curated catalog is the most effective way to address the root cause, not just the symptoms.
• Orchestration blueprints enable repeatable, policy-compliant provisioning without requiring developers to understand underlying infrastructure details.
• Automated cost controls — quotas, power scheduling, expiration policies — prevent the runaway spend and forgotten resources that inflate cloud bills.
• Role-based access and approval workflows keep compliance intact without reintroducing the bottlenecks that drove shadow IT in the first place.

Taming shadow IT is ultimately about designing systems that make the right choice the easy choice. When IT becomes an enabler rather than a gatekeeper, both sides of the equation — developer velocity and organizational control — improve together.

Atlassian Tools in BizDevOps Transformations

IT professionals attending Atlassian’s Open conference in Boston reported that Atlassian products—particularly Jira and Confluence—had played a meaningful role in their organizations’ BizDevOps transformations. BizDevOps extends traditional DevOps principles by explicitly aligning IT workflows with business goals and measuring delivery outcomes in terms of business impact rather than purely technical metrics.

Atlassian’s product roadmaps at the time reflected this direction, with a stated emphasis on broadening collaboration features for non-technical business stakeholders. However, practitioners also highlighted persistent integration gaps across Atlassian’s growing product portfolio as a barrier to achieving those goals at scale.

A Real-World BizDevOps Pivot: Merrill Corp.

Joseph De Jarnett, software delivery manager at Merrill Corp.—a corporate mergers and acquisitions SaaS provider that had pivoted away from its legacy document printing business to focus on its DatasiteOne platform—described how the company reorganized its product and IT teams around BizDevOps principles during a transition the previous year.

“Our development teams used Jira before our transition as a company last year, but we’ve refined our usage,” De Jarnett said. The team now uses Jira to prioritize software defects, manage incoming feature requests, and share roadmaps with business stakeholders. “We opened up feature development to give the business an opportunity for more feedback, instead of doing ‘closed door’ meetings of developers.”

Atlassian’s Confluence was used for documentation and goal planning, while Statuspage handled customer-facing communication about outages and downtime. The team was also evaluating Jira Align (formerly AgileCraft, acquired by Atlassian in April 2019) for higher-level business visibility into the software delivery process.

“We’re interested in how we can use it to provide more transparency to upper management. We’re interested in its tree model that shows feature development plans, progress and allows executives to dig into each team.”

Joseph De Jarnett, Software Delivery Manager, Merrill Corp.

Users Want Streamlining Across Atlassian Products

Despite positive experiences with individual tools, De Jarnett and other practitioners at the conference expressed frustration with the fragmented experience across Atlassian’s portfolio. At the time, Atlassian offered multiple Jira variants—Jira Core, Jira Software (with both classic and next-gen project types), and Jira Align—each with different feature sets and limited cross-compatibility.

A key pain point was the gap between Jira’s classic and next-gen project types. The Roadmaps feature had been rolled out for next-gen projects but was not yet available in classic projects. Teams running both project types found themselves managing information in silos, unable to link stories across the two paradigms cleanly.

“Right now, there are discrepancies, and we’re in silos with linking to stories in a traditional project from an epic in Jira next gen. We plan to shift to next gen, but it requires changes not all of our teams are ready to make right away.”

Joseph De Jarnett, Merrill Corp.

Atlassian announced at the Open conference that it planned to bring the Roadmaps feature to classic Jira, but did not specify whether managing the two project types would remain a separate administrative concern. Scott Blacker—co-founder of AgileCraft and, following the April 2019 acquisition, head of solutions engineering at Atlassian—acknowledged the problem but stopped short of providing a timeline.

“There has to be continuity of experience. There has to be a common source of truth, especially for value stream management.”

Scott Blacker, Head of Solutions Engineering, Atlassian

Other management friction points raised by attendees included the inability to perform federated search across multiple on-premises Jira Server and Data Center instances, and the lack of seamless account switching between cloud identities within a single browser session. An initial account switcher utility was available for cloud products at the time, but an Atlassian spokesperson declined to comment on plans for on-premises federated search.

Atlassian’s Cloud-First Strategy and Its Trade-offs

Atlassian executives at the conference made clear that cloud customers represent the company’s primary development focus. According to Atlassian president Jay Simons, approximately 100,000 customers used cloud versions of Atlassian products at the time, including roughly 90% of new customers. Centralized user management across on-premises and cloud deployments was not on the immediate roadmap; the two deployment modes required separate products—Crowd for on-premises and Atlassian Access for cloud.

“There’s a long list of things that we need to build, and we need to focus on those that will have the biggest benefit to the biggest number of customers long term,” Simons said.

This prioritization drew criticism from some industry analysts. Chris Condo, an analyst at Forrester Research, noted that competitors including CloudBees, GitLab, and major public cloud providers were marketing end-to-end DevOps toolchain integration with hybrid cloud support—an area where Atlassian’s offering remained fragmented.

“Enterprise customers are struggling with the concept of scaling Agile to multiple teams. Atlassian could bolt together its products much more tightly so people have to worry less about integrating the tools, too.”

Chris Condo, Analyst, Forrester Research

Condo also pointed out that value stream management—a capability increasingly expected in enterprise DevOps platforms—requires end-to-end metrics spanning from idea to production deployment, something Atlassian users could not fully achieve out of the box at that point. He noted the company also faced the challenge of integrating a string of acquisitions, including AgileCraft and the recently acquired no-code automation company Code Barrel, before adding further complexity through additional M&A activity.

“Most developers today spend little time coding, and more time answering questions and building toolchains. People are looking for simplicity.”

Chris Condo, Forrester Research

On-Premises Users and Regulated Environments Left Behind

Atlassian’s cloud-first posture created particular anxiety for customers in heavily regulated sectors. Tanya Christensen, a senior cyber systems engineer at Northrop Grumman working as a contractor for an unnamed U.S. government entity, described being unable to use cloud-dependent products like Opsgenie and Statuspage due to security requirements that even Opsgenie’s Edge Connector couldn’t satisfy.

“We’d love to have an on-premises version of Opsgenie and Statuspage. We’ve had to come up with our own ways to solve those problems on premises.”

Tanya Christensen, Senior Cyber Systems Engineer, Northrop Grumman

Simons acknowledged the concern but expressed confidence that organizational pressures would eventually push even resistant customers toward cloud adoption. “A lot of customers say ‘never,'” he said. “Then there’s an executive shift and they go all in on cloud.”

Key Takeaways for DevOps and Platform Engineering Teams

• BizDevOps alignment is achievable with Atlassian tooling, but it requires deliberate configuration work and process discipline—it does not happen automatically out of the box.
• Multiple Jira product variants introduce friction when teams need to operate across classic and next-gen project types simultaneously, particularly around features like Roadmaps and cross-project linking.
• Value stream management remains incomplete without tighter native integrations across the full Atlassian suite, and third-party integrations often require custom scripting or configuration.
• Cloud-first investment means on-premises feature parity lags, which is a significant concern for government contractors and regulated industries with strict data residency or network isolation requirements.
• Competitors are offering more integrated alternatives, and teams evaluating DevOps platforms should assess total integration effort, not just individual tool capabilities.

Note: This article reflects the state of Atlassian’s product portfolio and roadmap as reported at Atlassian Open in November 2019. Product names, features, and acquisition statuses have changed since then. Readers should consult current Atlassian documentation for up-to-date information.