SaaS, open source, and serverless: A winning combination to build and scale new businesses

The benefits of serverless and SaaS specifically are the result of competition among major CSPs to offer more—and more-compatible—applications of the best tech platforms “as a service.” This trend underscores the value of cloud as an enabler and driver of innovation, rather than just as a way to optimize IT costs. Recent McKinsey research, in fact, has shown that as much as 75 percent of the more than $1 trillion of value at stake in cloud comes from business innovation rather than from managing IT costs.

• Reduced initial investment outlay. Moving existing software to the cloud requires investments, especially in automation and often to a lesser extent in development and licensing. As companies “move up the stack” (in other words, consume more generalized services), they can increasingly take advantage of CSP offerings. For companies looking to set up quickly, build functionality efficiently, and test the market cheaply, serverless is an attractive option.
• Elimination of infrastructure management. Serverless requires zero infrastructure management (and hence no operational overhead) and significantly eases support for version upgrades. This frees product teams from hard dependencies on infrastructure provisioning, allowing businesses to shift resources to building products and services that directly generate value. Developers can take advantage of the fact that serverless architecture simplifies access to software functions as a service, reducing effort wasted on creating solutions that already exist. These functions can be flexibly recombined. With the right tooling and approach, many common application components can be standardized, audited, and easily reused, massively improving tech teams’ productivity. That can allow a company to quickly and easily test new-business functions with customers and adapt them as needed.
• Code brought “closer to the business.” Using SaaS and serverless to free IT from infrastructure management greatly reduces the complexity of app development and deployment. This, in turn, allows tech teams to organize around products—for example, “cards” or “loans”—which brings code “closer to the business.” As part of a commitment to agile and product-driven engineering, this approach makes it much easier for business leaders, product owners, and analysts to understand solutions and work with engineers in cross-functional teams.

An Asian oil and gas company spun out a series of products that have now become stand-alone businesses. By choosing to use the same serverless architecture across all of them, the company needed only 12 weeks and a small central team to stand up the new tech infrastructure, which was already supporting its core applications. Now the company can run a range of tasks, from complex visual-data upload and compression to drone steering, on its serverless architecture. As these businesses continue to grow, needed processing performance enhancements can be made rapidly.

A leading private-equity firm used serverless to develop an entirely new and highly configurable investor information and administration site. An application-programming-interface (API) gateway connects the new serverless architecture to the company’s legacy systems and customer data. The site can be flexibly adapted and enhanced, giving the firm the ability to easily boost the site’s performance. By using serverless, the firm was able to design, build, and launch this new digital customer tool within a few months, compared with more than a year using the traditional approach.

Serverless is still relatively new, and technical teams can underestimate the mindset shifts it requires. Indeed, IT leaders often erroneously think serverless is “just a few more cloud features.” In reality, serverless involves not just building differently but also using technology assets differently—from bringing a new, more modular approach that functions in a stateless architecture design (a microservice deployed in a container will translate to ten to 30 functions) to reconfiguring how database services are accessed.

Building functionality as needed will allow companies to reengineer processes at a completely different speed than is currently possible, where IT would need to plan in changes to customize the IT architecture to specific tasks and business processes, a time-consuming and resource-intensive task in most cases.

Teams that have not restructured to support cloud-native operating models must be reconfigured to focus more on architectural interplay, functionality development, and new capabilities for self-healing and on-demand scaling. The most successful organizations invest in tooling and in tech product teams to harness SaaS and serverless application components and integrate additional functions as required. The decision on whether to upskill existing in-house development teams or bring in new talent depends on a company’s starting point. Once IT functions embrace the new architectural-design paradigm and complete successful pilots, they will need added capacity to roll out serverless across the organization.

A serverless approach requires teams to have a clear view of how to integrate and manage the interplay of existing assets and providers. An up-front integration plan needs to be developed to make sure the tech requirements that enable existing assets to work well with serverless are met. This calls for the automated provision of additional provider services to ensure that endpoints, events, and fine-grained access controls are consistently provisioned.

Accidental risk of exposure is high for serverless if companies do not adopt mature secure-by-design cloud principles on day one. There are four categories of serverless considerations:

• securing serverless in public cloud, perhaps by isolating serverless workloads in public cloud with granular account-level segmentation, and limiting exposure through the use of blast-radius architecture
• rethinking authentication for transient serverless workloads by using ephemeral credentials and short-lived tokens, which are key risk mitigators for credential exposure
• protecting your availability in a serverless landscape with robust perimeter security that deploys public and internal functions at discrete gateways
• upgrading risk assessment, governance, and awareness by, for example, adopting policy as code for the codification of organizational policies; using regulatory frameworks in automated governance pipelines for cloud-service provisioning; and deploying all serverless workloads using an embedded DevSecOps pipeline