devopsy.kinsta.cloud

Category: Blogs

  • DevSecOps: 5 Tips for Developing Better, Safer Apps

    DevSecOps: 5 Tips for Developing Better, Safer Apps

    The cloud is rapidly becoming a major battleground for cyberattacks — and the cost of a breach has never been higher. According to IBM, the average cost of a breach was $4.5 million, and according to the CrowdStrike 2023 Global Threat Report, there was a 95% increase in cloud exploits in 2022, with a three-fold increase in cases involving cloud-conscious threat actors. The acceleration of cloud-focused threat activity and its effects has made security a key priority across organizations – especially DevOps teams.

    Security in the Cloud is a Shared Responsibility

    Security teams are accountable for protecting against risks but cannot be the only ones. Each team must try to communicate why their part of the development lifecycle is important to the other teams in the pipeline. With the growth of cloud-native applications and the demand for faster application delivery or continuous integration/continuous delivery (CI/CD), the use of containers is increasing widely. Complex security issues arise as businesses adopt containerized and serverless technologies and cloud-based services.

    Application developers have a tricky balance to maintain between speed and security. In DevOps, security used to be an issue addressed after development — but that’s changing. Now, developers who previously had to code right up to the last minute — leaving almost no time to find and fix vulnerabilities — are using shift-left capabilities to ensure that code with security vulnerabilities is not moved into production.

    When security is considered at every step in the pipeline, it ensures developers find and address issues early on and reduces the cost of downstream fixes. DevSecOps helps developers find and remediate vulnerabilities earlier in the app development process. Vulnerabilities discovered and addressed during development are less expensive and faster to fix. Automation of testing, remediation and delivery ensures stronger software security without slowing development cycles. The goal is to make security a part of the software development workflow, instead of having to address more issues during runtime.

    Below are five key tips for developing apps with security and efficiency.

    1. Automate Security Reviews and Testing.

    Every DevSecOps pipeline should utilize a combination or variation of tools and features like those listed below. A good automated and unified solution will provide broad visibility and address those issues as they arise, while alerting, enforcing compliance and providing customized reports with relevant insights for the DevOps and security teams.

    SAST: Static application security testing to detect insecure code before it’s used

    SCA: Software composition analysis to detect library vulnerabilities before building

    CSA: Container scanning analysis to detect operating system library vulnerabilities and mitigate risk

    IaC scanning: Infrastructure-as-code scanning to detect vulnerabilities in infrastructure

    ASPM: Application security posture management to detect application vulnerabilities and risks once deployed

    2. Integrate With Developer Toolchains.

    Streamline and consolidate your toolchain so developers and security teams can focus attention on a single interface and source of truth. The tighter the integration between security and app development, the earlier threats can be identified, and the faster delivery can be accelerated. Seamlessly integrate with Jenkins, Jira, Bamboo, GitLab and other cloud security solutions to allow DevOps teams to respond to and remediate incidents faster within the toolsets they already use.

    3. Share Security Knowledge Among Teams.

    DevSecOps is a journey enabled by technology but a process that starts with people. Your DevSecOps team should share lessons learned and mitigation steps after resolving the compromise. Some organizations even assign a security champion who helps introduce this sense of responsibility for security within the team. Be prepared to get your teams on board before changing the process, and ensure everyone understands the benefits of DevSecOps. Make security testing part of your project kickoffs and charters, and empower your teams with training, education and tools to make their jobs easier.

    4. Measure Your Security Posture.

    Identify the software development pain points and security risks, create a plan that works well for your organization and your team, and drive execution. Ensure you track and measure results such as the time lost in dealing with vulnerabilities after code is merged. Then, look for patterns in the type or cause of those vulnerabilities, and make adjustments to detect and address them earlier. This introduces a shared plan with integration into the build and production phases.

    5. “Shift Right” as well as “Shift Left.”

    Detection doesn’t always guarantee security. Shifting right and knowing how secure your applications and APIs are in production is just as important. By leveraging ASPM to uncover potential vulnerabilities in the application code once they are up and deployed, teams can find potential exposure in their application code that could allow backdoor access to other critical data and systems.

    The bottom line is that while security and development used to be separate, the lines are now blurring to a point where security is becoming more integrated with the day-to-day job of developers. The benefit is that the modern practice brings together teams across the company to a common understanding, which drives business growth. DevSecOps requires teams to collaborate and enable the organization to deliver safer applications to customers without compromising security.

    Security is not meant to be a red light on the road to your business goals or slow down your software development. It is to enable you to reach those goals safely with minimal risk.

  • The IT-DevOps Life Cycle is Like a Pyramid That Keeps Growing

    The IT-DevOps Life Cycle is Like a Pyramid That Keeps Growing

    Don’t let anyone tell you how much easier IT life is these days. It is, in many ways, more fun and productive … but it is not easier. In fact, we’re doing more with less, cubed, at this point. My point is—think of the life cycle as a pyramid. The base is the build++ chain, from VCS to public-facing active protection; the height is the new technologies and systems being bolted on daily—like SaaS tools someone in accounting just signed up for or the new architectures a dev team in a subsidiary just decided to adopt (but which will eventually have to be maintained by IT). And the depth is the completely new capabilities that are required by market forces or regulation – SBOM is the poster child for this group; suddenly, just about every vendor is giving it to you as part of their product.

    No matter which of these axes is growing, the workload is generally growing commensurately. Think about it: If a new product is implemented, it impacts IT’s workload. If a new technology that solves a problem is implemented, it, too, impacts workload. And if a new capability in an existing product is dictated by the compliance team for any reason, this, too, increases workload. This is just the business side, and doesn’t include the fact that most orgs are dropping newly developed applications on a pretty regular basis these days.

    Automation has helped, but it hasn’t solved the problem yet. I believe it can, given time and focus, but for the most part, the demand for new technology to solve age-old problems (“We can’t effectively test” being met with “Here is automated test generation, execution and results filtering”) has been a net increase in workload. Though far smaller than it might have been, it is still increasing. This is true across IT. The test example above applies to app dev and security, with result sets that did not exist six years ago because the process was too expensive in staff hours. It also applies to ops because the processing power to get those tests done – and it is a lot with large test environments – is ops’ responsibility.

    Painting a bleak picture? Nope. Making certain we’re realistic. Trying to ensure that we consider how much we are already doing, and take a chance to implement actual time savers. For example, applying that same test automation to testing (for most orgs, I’m thinking security testing) that was actually being done already will reduce the cost of getting it done. Using SBoM for SCA to contribute to existing compliance saves a lot of time generating that information. Using new coding assistants shortens coding time and (arguably at this point, but inevitably, given the fullness of time) improves code quality, reducing rework, which is costly, even in an agile environment.

    We are growing our capabilities almost daily. I’m just suggesting that, in the process, we backward-apply the good stuff to reduce existing overhead. And as always, this big, complex beast exists and keeps clipping along because you’re there, keeping it fed and stable. Keep rocking it, and save yourself some time by using new technology smartly—there is plenty more to do than whatever you streamline.

    Image source: Photo by Michael Dziedzic on Unsplash

  • JFrog Survey Surfaces Raft of DevSecOps Challenges

    JFrog Survey Surfaces Raft of DevSecOps Challenges

    A global survey of 1,224 security, development, and IT operations professionals published today by JFrog finds that 60% typically spend four days or more remediating application vulnerabilities in a given month.

    JFrog security researchers, however, noted it’s probable most of those vulnerabilities are not as severe as they have been rated. After analyzing 212 vulnerabilities, the JFrog Security Research team downgraded the severity of 85% of the vulnerabilities rated as critical and 73% of one rated as high.

    JFrog researchers also found that 74% of the reported common vulnerabilities and exposure (CVEs) with high and critical CVSS scores assigned to the top 100 Docker Hub community images weren’t actually exploitable.

    Only 17% of the vulnerabilities analyzed enabled remote code execution, compared to 44% that could enable a denial of service (DoS) attack, the researchers noted.

    Stephen Chin, senior director for developer relations for JFrog, said that analysis suggests organizations are arguably spending too much time on application security at the expense of productivity. Tools that generate alerts based on severity rather than also rating exploitability are creating too much noise simply because they don’t provide enough contextual analysis, he added.

    Conversely, in the absence of that level of detailed analysis, it’s possible a low-level vulnerability that might be especially severe in a specific IT environment, also known as a false negative, might not be further investigated, noted Chin.

    Security concerns, however, also limit innovation, with 40% of the survey respondents noting that because of security reviews, it typically takes a week or longer to get approval to use a new package/library.

    Nearly half of IT professionals (47%) say they use between four and nine application security tools, with 90% reporting they use some type of tools that rely on machine learning algorithms or other forms of artificial intelligence (AI) to scan, identify and remediate vulnerabilities.

    Less than a third (32%), however, work for organizations that use AI to write code. That relatively low level suggests many organizations are still not comfortable with the quality of the code generated, noted Chin. Of course, individual developers may still be using those tools without approval.

    More than half (53%) say their organization uses between four to nine programming languages, with nearly a third (31%) reporting they use 10 or more.

    The most frequently used tools are static application security testing (61%), dynamic application security testing (58%), software composition analysis testing (56%), and application programming interface (API) security (56%).

    A full 89% said their organization has adopted a security framework such as OpenSSF or Supply-chain Levels for Software Artifacts (SLSA).

    Finally, the survey finds little consensus concerning when to run security scans, with 42% saying it’s best to perform security scans as code is being written versus 41% that prefer to perform scans on new software packages before installing them. A total of 41% said runtime is the least desirable place to run scans. More than half (56%) said their organization applies security scans at both the code and binary scanning levels.

    The degree to which DevSecOps best practices are being adopted will naturally vary from one organization to the next. The challenge is to prioritize remediation efforts in a way that enables developers to spend more time writing, for example, business logic versus patching vulnerabilities are not actually a material threat. In that context, the quality of the vulnerability analysis generated by scanning tools matters because of the unnecessary toil that might be eliminated, noted Chin.

    It may be a while before most organizations are able to strike the right balance when it comes to DevSecOps, but as a greater appreciation for the nuances of application security continues to take hold, the less stress there should hopefully one day be for all concerned.

  • Navigating the Maze of SSDLC Models: A DevOps-Centric Analysis

    Navigating the Maze of SSDLC Models: A DevOps-Centric Analysis

    In the rapidly evolving world of software development, the integration of security into the software development life cycle (SDLC) is no longer a luxury but a necessity. The concept of secure SDLC (SSDLC) has become pivotal in ensuring the creation of software that is not only functional and efficient but also secure from the ground up. With a plethora of SSDLC models available, such as Microsoft’s security development lifecycle (SDL), the OpenWeb application security project’s software assurance maturity model (OWASP SAMM), and others, it’s crucial for organizations, especially those embracing DevOps, to understand their distinct characteristics. This article provides an insightful comparison of these models, highlighting their strengths, weaknesses and applicability to various project types, underpinned by relevant statistics and research findings.

    Microsoft’s Security Development Lifecycle (SDL)

    Microsoft’s SDL, introduced in the early 2000s, is a security assurance process designed to reduce software vulnerabilities and address compliance requirements. A notable aspect of SDL is its emphasis on security training for developers, a practice that has been shown to reduce the introduction of security flaws by up to 30%. The SDL framework includes security-focused activities such as threat modeling, code reviews and security testing throughout the SDLC.

    Strengths: SDL’s structured approach is well-suited for large-scale, complex software projects. Its comprehensive documentation and detailed guidelines are beneficial for organizations seeking a thorough security framework.

    Weaknesses: The extensive nature of SDL can make it cumbersome for smaller projects or teams that adopt rapid development cycles typical in DevOps environments. Its prescriptive nature may also stifle agility.

    OWASP’s Software Assurance Maturity Model (SAMM)

    OWASP SAMM offers a flexible and prescriptive approach to integrating security into software development, making it particularly attractive for organizations adopting DevOps methodologies. SAMM focuses on continuous improvement and can be tailored to an organization’s specific needs.

    Strengths: SAMM’s flexibility allows it to be easily integrated into various development processes, including Agile and DevOps. It supports incremental implementation, a critical factor given that 60% of companies are adopting some form of DevOps practices.

    Weaknesses: Its less prescriptive nature can be a double-edged sword, potentially leading to inconsistencies in implementation. Organizations without a strong security background may find it challenging to interpret SAMM’s guidelines effectively.

    Comparing SDL and SAMM in a DevOps Context

    When viewed through a DevOps lens, SDL and SAMM cater to different organizational needs. SDL’s structured approach is ideal for large enterprises with well-established development and security processes. However, its rigidity may clash with the dynamic, iterative nature of DevOps. In contrast, SAMM, with its adaptability and emphasis on continuous improvement, aligns more closely with the principles of DevOps. It allows for faster integration and adaptation in a fast-paced development environment.

    Other Notable SSDLC Models

    Beyond SDL and SAMM, other models like the V-Model, Agile SDL and BSIMM (building security in maturity model) also offer unique perspectives. For instance, the V-Model’s linear and straightforward approach is well-suited for projects where requirements are well-defined and unlikely to change, a scenario less common in DevOps-focused organizations. Agile SDL integrates security practices within Agile methodologies, making it a viable option for teams that balance rapid development with security considerations. BSIMM, based on real-world data from over 100 organizations, provides a benchmark for companies to measure their secure SDLC practices against industry standards.

    Tailoring SSDLC to Project Needs

    A one-size-fits-all approach does not work in the realm of SSDLC. The choice of model depends largely on the organization’s size, the nature of the project, compliance requirements and the existing development methodology. For instance, one survey indicated that 45% of small to medium-sized enterprises prefer flexible models like SAMM due to their limited resources and need for agility.

    The Role of Automation and Tooling in SSDLC

    Irrespective of the chosen model, the integration of automation and tooling plays a pivotal role in the successful implementation of SSDLC in a DevOps environment. Automated security testing tools, for example, can identify vulnerabilities early in the development cycle, a practice that has been shown to reduce the cost of fixing security issues significantly.

    Evolving Security Challenges in the DevOps Era

    As the software development landscape continuously evolves, so do the security challenges, especially in the context of DevOps. DevOps practices, which focus on integrating development and operations to enhance agility and efficiency, also bring unique security considerations. The rise of microservices architectures and containerization, for instance, has introduced complexities in managing security at scale. Data suggests up to 70% of organizations using microservices have faced security incidents due to misconfigurations.

    In this context, SSDLC models must evolve to address these new challenges. For example, incorporating security into container orchestration tools and ensuring secure service mesh configurations are becoming increasingly important. Furthermore, the integration of security into continuous integration/continuous deployment (CI/CD) pipelines, a hallmark of DevOps, demands that SSDLC models be adaptable enough to automate security checks without impeding the speed of deployment.

    Bridging the Gap Between Security and Development

    A critical aspect of SSDLC in a DevOps environment is bridging the gap between security and development teams. Traditionally, these teams have operated in silos, often leading to security being considered late in the development process. This misalignment can be costly. Research has reported that identifying and fixing security vulnerabilities post-deployment can be 100 times more expensive than addressing them during the design phase.

    To mitigate this, modern SSDLC models are increasingly advocating for a ‘shift-left’ approach, where security considerations are introduced earlier in the development process. This approach not only reduces the cost and effort associated with addressing security issues but also fosters a culture where security and development goals are aligned. Tools like automated security scanning and threat modeling are instrumental in this regard, enabling developers to identify and rectify security flaws early.

    The integration of SSDLC into DevOps is not just about selecting the right model but also about adapting to the evolving landscape of software development and cybersecurity. By understanding and addressing the unique challenges posed by DevOps practices, organizations can create a more secure and efficient development environment. Whether adopting Microsoft’s SDL for its structured approach or OWASP’s SAMM for its flexibility, the key lies in tailoring the SSDLC model to fit the organization’s specific needs, culture and project requirements. As we move forward, the convergence of security and development will continue to be a cornerstone in the journey towards creating resilient, secure software.

    Conclusion

    The landscape of SSDLC models is diverse, each with its strengths and weaknesses. For organizations embracing DevOps, the choice of SSDLC model must align with their culture of rapid development and continuous delivery. Microsoft’s SDL offers a robust and structured approach, ideal for complex, large-scale projects. OWASP’s SAMM, on the other hand, provides the flexibility and adaptability needed in a fast-paced DevOps environment. Ultimately, the decision should be guided by the organization’s specific needs, project characteristics and security objectives, ensuring that security is ingrained in the software from inception to deployment and beyond

  • CircleCI Adds Release Orchestration Capability to CI/CD Platform

    CircleCI Adds Release Orchestration Capability to CI/CD Platform

    CircleCI today added a release orchestration capability to its namesake continuous integration/ continuous delivery (CI/CD) platform to give developers more control over application deployments.

    CircleCI CTO Rob Zuber said a CircleCI releases capability provides development teams with the ability to release a controlled subset of their code in a live production environment in a way that provides immediate feedback on how that code is performing. That level of visibility can then be used to determine whether that code might need to be rolled back using automation tools embedded in the CircleCI CI/CD platform, he added.

    In the absence of that capability, noted Zuber, it takes DevOps teams, on average, 45 minutes to an hour to manually roll back an application.

    Initial platforms supported by CircleCI releases are Kubernetes and Amazon SageMaker. CircleCI releases is also compatible with the open source Argo CD platform that CircleCI integrated its platform with last year.

    CircleCI also plans to add support for blue-green deployments later this year, enabling DevOps teams to deploy one application version more gradually to replace another.

    The way CD is managed often varies widely from one organization to another. In highly regulated industries, CD is typically managed by a central team to ensure compliance requirements are met. In other instances, developers are directly responsible for building and deploying their code. Regardless of approach, CircleCI enables organizations to define a set of guardrails to ensure best practices are observed, noted Zuber. In effect, each organization can implement a set of checks and balances that are aligned to their specific needs, he added.

    As DevOps continues to evolve, more organizations want the ability to control deployments at a more granular level by, for example, only making a new application or an update available to a select number of users. Once deployed, developers need a more holistic view into not just how that application is performing but also how it impacted the business, said Zuber. If, for example, the number of logins declines after an update, a developer needs the information to determine whether that update should be rolled back as quickly as possible, he added.

    It’s not clear how many organizations are managing the entire CI/CD workflow on an end-to-end basis. While most DevOps teams make extensive use of CI to build an application, the deployment of applications is still often managed manually. However, as CD capabilities become simpler to employ across platforms with standard interfaces, the number of organizations automating CD should steadily increase. In fact, that capability will soon prove essential as, thanks to the rise of generative artificial intelligence (AI), the pace at which applications are being built only continues to accelerate.

    In the meantime, each organization will need to determine how closely it wishes to integrate CI and CD workflows. However, the more tightly integrated these processes become, the simpler it becomes for developers to assume full responsibility for building and maintaining the software they create.

  • Three DevOps Trends to Watch in 2024

    Three DevOps Trends to Watch in 2024

    The world of DevOps has evolved at an unprecedented rate in the last few years, yet it continues to be a primary driver of efficiency, innovation, and digital transformation for many organizations. Google’s 2023 Accelerate State of DevOps Report shows that a company’s software delivery performance quality predicts organizational performance, team performance and employee well-being.

    In 2024, there are several trends that practitioners can expect to have a major impact on the industry. Forward-thinking tech companies will take advantage of the convergence of these trends as the year progresses. Opportunities exist for leaders in the cloud and virtualization arenas to increase operational flexibility, improve disaster recovery measures and leverage the rapid advancement of new technologies to give their company a competitive edge.

    As the year rolls on, here are a few key DevOps trends to watch for in 2024:

    1.  Apple Silicon Release Cycles 

    The era of Apple Silicon is now in full force. With Apple now creating its own chips, the company can have complete control over its product development timeline. Additionally, each release is increasingly nuanced in how the hardware/software stack is built. In 2023 alone, we saw the introduction of the new M3 chip series, the completion of Mac’s transition to Apple Silicon among many other new capabilities and innovations. As the use of Apple technology in the enterprise continues to expand, companies that can quickly adapt to the faster release cycles of Apple’s new chipsets will see significant performance improvements.

    2.  Hybrid and Multi-Cloud Adoption 

    To compete in today’s dynamic business landscape, harnessing the power of cloud technologies is essential. The industry can expect to see a major surge in hybrid and multi-cloud adoption. In addition to the cost-efficient nature of the cloud, enterprises are increasingly moving towards hybrid and multi-cloud models to enhance operational flexibility and improve disaster recovery measures. In fact, global spending on cloud adoption is projected to top $1 trillion in 2024. As the cloud continues to be a key driver of innovation across industries, the ability to serve and integrate solutions across cloud providers or on-premises is increasingly becoming table stakes. Platforms that can operate seamlessly across these diverse cloud environments will offer a significant competitive advantage.

    3.  Securing Remote Work and Virtualization Environments

    As virtual desktop infrastructure (VDI) continues to take the world by storm, security and compliance across complex environments is crucial. The continued advancement of cyberthreats makes the challenge of securing virtual identities more pertinent than ever. Especially as companies look to mitigate the risks of device and intellectual property theft in offshoring and consulting scenarios, the demand for secure remote desktop technologies has never been higher.

    Additionally, security and compliance regulations are becoming increasingly robust. And providers should leave no stone unturned to ensure that their platforms are compliant with all security regulations and consistently audited to address any vulnerabilities that may pop up. Ensuring that the solution provided is living up to its promise especially as it relates to security and compliance is crucial to the public’s perception of your business. Solutions that offer robust security features while also enabling scalability and flexibility in operations will have a competitive edge as we enter the new year.

    To hear more about cloud-native topics, join the Cloud Native Computing Foundation, Techstrong Group and the entire cloud-native community in Paris, France at KubeCon+CloudNativeCon EU 2024 – March 19-22, 2024.

  • Controlling Cloud Costs With Efficient Ramp Plans

    Controlling Cloud Costs With Efficient Ramp Plans

    A mix of rapid migrations to the cloud and complexity over usage and costs has companies desperately trying to reduce waste and gain control over their spending. Making matters worse is a volatile economy that has decision-makers on edge, considering cost-cutting measures and placing a priority on locking down revenue.

    Without a formal FinOps or cost optimization strategy in place, it’s easy for companies to see cloud expenses snowball out of control. In fact, analysts from Gartner report that organizations that do not employ cloud cost optimization can overspend by up to 70%. That said, ramp plans are becoming a vital tool for containing cloud resources.

    Still, while this strategy can show how to effectively grow your environment and increase workloads, the way a ramp plan is carried out is key to its success. The following looks at what companies should do to succeed with ramp planning accompanied by some strategic advice for handling unique needs that may arise.

    Ramping Up

    A ramp plan, at its most rudimentary level, is data tracking toward how your organization consumes cloud resources versus what it commits to with a cloud service provider (CSP) or reseller. By committing to spend a set dollar amount, you can get healthy discounts or other incentives. As an example, a 50% increase in consumption by the end of the year might earn a 10% discount from a CSP on compute workloads. But there is risk: A company is still obligated to pay that figure, even if it uses far fewer resources than it committed to.

    Still, just as you don’t want to spend money needlessly, CSPs—even high-volume hyperscalers like Amazon AWS and Google GCP—would rather see customers get what they need and grow their footprint. For some organizations, the answer is bringing in a partner to help forecast spend. Questions regarding what is needed, past usage, anticipated growth, potential for acquisitions and more need to be answered. You also have to examine such things as product and service offerings. For instance, a subscription app you offer could catch fire and bring in customers—but you’ll need to plan accordingly so the resources will be in place to meet this demand.

    Compiling and projecting this all isn’t easy, but this type of data is needed so you can develop a ramp plan and budget effectively. In the past, this process required time-consuming manual research, a host of spreadsheets and sophisticated algorithms. However, technology has been developed to automate, drive and scale this process. For some businesses, the ideal is to find a partner with this capability in-house and a depth of expertise to use it correctly.

    Processes and Partners

    Ideally, a ramp plan should be developed before a commitment is made. It should be reviewed on at least a quarterly basis with the C-suite and appropriate technical executives and then revised as necessary. On the whole, CSPs like to sign customers to contracts extending more than a year, with three-year terms being typical.

    Working with a third-party partner, reseller or directly with a hyperscaler comes down to personal preference. Big companies, much like hyperscalers, tend to have a lot of bureaucratic processes and requirements. So, if you want a tactical agreement with AWS, you may have to buy tactical support. You may get a good financial incentive in exchange, but the cost of enterprise-level support could offset that.

    Partners and resellers of cloud services, on the other hand, help hyperscalers scale their businesses, so they often have special arrangements that lower support costs. The development of ramp plans is usually less when going through a third party versus registering with a CSP. These services are often designed for smaller companies that larger CSPs don’t have time to handle. Third parties tend to provide tailored services more in tune with customer needs, including more flexible usage, optimization and security. These partners tend to negotiate more effectively than customers themselves because they better understand the ecosystem and which levers to pull.

    Measuring Success

    It’s not easy to measure and track the success of a ramp plan. Beyond understanding and meeting your commitment—and getting the most from cloud spend—the best measure is profitability. Are you just eating costs or acquiring new customers? Is your efficiency boosting or lowering your margins? It’s even possible to apply unit economics to assess if you’re making money on the resources being used.

    Making a commitment and ramp planning should involve more than financial incentives. Maybe there’s some other strategic aspect you want to achieve? From service-level agreements to support, a lot of things can be woven into a commercial contract. Benefits can come in various forms, but when they’re added together, you can take success in the cloud to a whole new level.