Category: DevOps Practice

  • How Generative AI Enables Unified Continuous Testing Platforms

    How Generative AI Enables Unified Continuous Testing Platforms

    It is time for a unified continuous testing platform.

    Existing software testing platforms and tools specialize in testing activities for a subset of the different stages of value streams. The landscape of software testing tools includes a wide range of solutions, each with its strengths, focusing on specific aspects of software development, delivery and operations.

    For instance:
    • Unit Testing Tools focus on the earliest stages of development, allowing developers to test individual units of code for correctness.
    • Integration Testing Tools aim to test the interactions between different modules or services within an application.
    • System Testing Tools are designed for end-to-end testing of the complete system before it goes live.
    • Performance Testing Tools assess the application’s behavior under load and stress conditions.
    • Security Testing Tools focus on identifying vulnerabilities within the application.
    • User Acceptance Testing (UAT) Tools facilitate the final testing phase, where end-users validate the solution against their requirements.

    The challenge with unifying these diverse testing needs into a single continuous testing platform is multifaceted. Such a platform needs to seamlessly integrate with a wide variety of development tools and environments, support different testing methodologies, and be flexible enough to adapt to different organizational processes and quality standards.

    While there are Continuous Integration/Continuous Deployment (CI/CD) tools that incorporate multiple testing stages, they often do so by integrating with specialized testing tools rather than offering a unified testing solution themselves. These CI/CD tools are closer to orchestrating the various testing activities rather than unifying them under a single platform’s capabilities.

    However, the concept of a fully unified continuous testing platform, covering every stage from requirements through to deployment and in-production testing, represents a significant opportunity for innovation in the software development tools space. Achieving this would likely require leveraging advancements in areas like generative AI, as discussed in my prior blog Applying AI/ML to Continuous Testing to create adaptable, intelligent testing processes that can cover the full spectrum of testing needs in a cohesive manner.

    Benefits of a Unified Continuous Testing Platform

    Improved Efficiency and Speed: A unified CT platform integrates testing across all stages of the software development lifecycle (SDLC), significantly streamlining the testing process. This integration facilitates automated, continuous feedback loops that promptly identify and address defects, allowing development teams to quickly iterate and improve. As a result, teams can release new features and fixes more rapidly, accelerating the product’s time to market and enhancing responsiveness to customer needs and market changes.

    Enhanced Quality and Reliability: By ensuring comprehensive and consistent testing across the entire application, a unified CT platform plays a crucial role in identifying and mitigating issues early in the development cycle. This early detection helps maintain a high level of software quality and reliability, leading to increased user satisfaction and trust in the product. The consistent application of quality standards across all testing phases contributes to a robust and dependable software product.

    Cost Savings and Reduced Maintenance: Automating the testing process through a unified CT platform not only optimizes resource utilization but also significantly reduces the costs associated with manual testing and late-stage defect remediation. Early defect detection translates to lower fix costs, and the streamlined process decreases the overall time-to-market. Additionally, high-quality, reliable software requires less maintenance, further reducing long-term costs and freeing up resources for innovation and development efforts.

    Improved Collaboration Across Teams: A unified CT platform fosters a culture of collaboration and transparency among development, testing, and operations teams. By providing a common framework and tools for all testing activities, it breaks down silos and enables seamless communication and collaboration across the SDLC. This improved collaboration ensures that teams are aligned with the project goals, can share insights more effectively, and work together to identify and solve problems more efficiently, leading to better outcomes.

    Together, these benefits highlight how a unified Continuous Testing platform can transform the software development process, making it more efficient, cost-effective, and collaborative while ensuring the delivery of high-quality and reliable software products.

    While many tools address specific parts of the testing lifecycle, the vision of a single platform that seamlessly unifies all stages of testing from requirements to in-production remains an ambitious goal. It’s a gap in the current technology landscape that presents both a challenge and an opportunity for future development.

    Challenges for Unified Continuous Testing Platforms

    Creating a continuous testing platform that unifies test activities for all stages of the end-to-end value stream is a complex challenge due to several factors:
    1. Diversity of Technologies and Tools: Modern software development environments are highly diverse, incorporating various programming languages, frameworks, and technologies. Creating a platform that seamlessly integrates with all these technologies is challenging.
    2. Complex Integration Points: Continuous testing needs to integrate with multiple stages of the development pipeline, including development, deployment, and operations. Each of these stages might use different tools and processes, making it hard to create a one-size-fits-all solution.
    3. Varying Quality Metrics: Different teams and projects may have different definitions of quality, success criteria, and performance metrics. A unified testing platform needs to be highly customizable to cater to these varying needs.
    4. Change Management: Adopting a new platform requires changes in the organization’s processes and workflows. Resistance to change is common in organizations, and transitioning to a new way of testing can be met with skepticism and inertia.
    5. Scalability and Performance: Ensuring the platform can scale to handle the testing needs of large organizations with thousands of tests running concurrently is a technical challenge. Performance issues can become a bottleneck, affecting the overall efficiency of the development process.
    6. Security and Compliance: Integrating testing across all stages of development also introduces security and compliance challenges. The platform must ensure that sensitive data is protected and that testing practices comply with regulatory requirements.
    7. Cost and Resource Constraints: Developing, maintaining, and supporting a unified continuous testing platform requires significant investment. Organizations might be hesitant to commit the necessary resources without clear evidence of return on investment.
    8. Evolution of Practices: Software development practices and tools are constantly evolving. Keeping the platform up-to-date with the latest practices and technologies requires ongoing effort and innovation.

    Despite these challenges, there is a growing recognition of the value of continuous testing throughout the software development lifecycle. Some companies and open-source communities are making strides in this direction, creating more integrated and flexible testing solutions. However, achieving a fully unified platform that addresses all these challenges is an ongoing effort and represents a significant opportunity for innovation in the software development and testing industry.

    Generative AI Can Facilitate a Unified Continuous Testing Platform

    Generative AI can play a significant role in overcoming the challenges associated with creating a continuous testing platform that unifies test activities for all stages of the end-to-end value stream. Here’s how generative AI might address each of the challenges:
    1. Diversity of Technologies and Tools: Generative AI can be trained on a wide range of programming languages, frameworks, and technologies to understand and generate code or testing scripts. This capability allows it to adapt to different environments and create testing materials that are compatible with various tools and technologies.
    2. Complex Integration Points: AI can analyze the workflow of development pipelines and suggest optimal integration points for testing. By learning from different CI/CD (Continuous Integration/Continuous Deployment) configurations, AI can recommend best practices for integrating testing seamlessly into existing workflows.
    3. Varying Quality Metrics: Generative AI models can be customized to understand and apply different quality metrics and success criteria based on project-specific requirements. By training on diverse datasets, these models can adapt to various definitions of quality and generate relevant tests or analysis.
    4. Change Management: AI can assist in the change management process by simulating the outcomes of adopting new testing platforms, thereby providing evidence-based benefits and mitigating resistance to change. Furthermore, AI-driven analytics can highlight the efficiency gains and quality improvements to support the transition.
    5. Scalability and Performance: Generative AI can optimize testing processes by identifying redundancies and suggesting improvements, thus enhancing performance. Additionally, AI can dynamically allocate resources based on testing needs, ensuring scalability without compromising efficiency.
    6. Security and Compliance: AI models can be trained to identify and flag potential security and compliance issues in the testing process. By continuously learning from the latest security standards and compliance regulations, AI can help ensure that testing practices meet the necessary requirements.
    7. Cost and Resource Constraints: By automating the generation and optimization of test cases, generative AI can significantly reduce the manual effort required, lowering costs and resource demands. AI can also help prioritize testing efforts based on risk assessment, ensuring that resources are focused where they are most needed.
    8. Evolution of Practices: Generative AI models are inherently adaptable and can continuously learn from new development practices, tools, and technologies. This ensures that the testing platform remains up-to-date with the latest advancements in software development.

    Generative AI has the potential to transform continuous testing by providing adaptive, efficient, and intelligent solutions to the complex challenges of unifying test activities across the end-to-end value stream. However, realizing this potential requires careful design, extensive training of AI models, and ongoing management to ensure that the AI systems remain effective and aligned with evolving testing needs.

    Summary: Call to Action

    The need for a unified Continuous Testing (CT) Platform has never been more urgent. Current testing platforms, each adept in their niche, cover only fragments of the software development lifecycle (SDLC), leading to a disjointed and inefficient testing process. This fragmentation not only slows down development and deliveries but also compromises the quality and security of the final product. The dream of a single platform that seamlessly integrates all stages of testing, from requirements through to deployment and in-production testing, represents a monumental leap toward efficiency, security, and quality in software development.

    The challenges in creating such a platform are manifold, ranging from the diversity of technologies and tools to the evolving nature of software development practices. Each challenge, from integrating diverse technologies and managing change within organizations to ensuring scalability and compliance, adds complexity to the development of a unified CT platform. Yet, the potential benefits of overcoming these hurdles are immense, promising a significant boost in the speed and quality of software delivery. The industry’s recognition of these benefits is growing, evidenced by the efforts of some companies and open-source communities moving towards more integrated and flexible testing solutions.

    Generative AI emerges as a beacon of hope in this quest, offering innovative solutions to the multifaceted challenges of unifying test activities. By harnessing the power of generative AI, the industry can address the diversity of tools, integrate complex testing stages, adapt to varying quality metrics, manage organizational change, scale efficiently, ensure security and compliance, and evolve with the practices of software development. The path forward requires a concerted effort, but investments in AI-driven testing innovations can realize the vision of a comprehensive, unified, continuous testing platform. This is not just an opportunity for enhancement but a call to action for the industry to redefine the future of engineering platforms.

  • 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.

  • 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.

  • 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.

  • The IaC Weight on DevOps’ Shoulders

    The IaC Weight on DevOps’ Shoulders

    It’s often challenging for established tech companies to adopt modern DevOps practices around infrastructure-as-code (IaC). It’s not so much in adopting the syntax, but rather the DevOps culture that IaC is part of for engineering organizations.

    Organizations often struggle to transition from traditional operations models to collaborative DevOps culture, which is a byproduct of transitioning infrastructure operations to code.

    In many cases, legacy tendencies persist, while IaC duties stay siloed within ops-centric DevOps teams—which is the exact opposite of the benefits of leveraging powerful technology like infrastructure-as-code. What this ultimately creates is bottlenecks in development velocity and product iteration.

    With all this in mind, it begs the question: What changes can enable a smoother IaC journey?

    The Pitfalls of IaC Silos

    Having DevOps teams shoulder the entire IaC burden is the exact anti-pattern we’re looking to avoid when truly transitioning to DevOps culture in our organizations. What many organizations start to experience is these familiar pain points that start to emerge:

    1.) Knowledge Gaps Widen

    Developers—by nature of their day job as software engineers—often lack access, visibility and context into infrastructure changes. Yet, with more and more infrastructure requirements shifting left, they are left (pun intended) with insufficient capabilities to manage these growing needs.

    This is compounded when they are faced with minimal cloud permissions. Limited permissions make it difficult to experiment and familiarize themselves with cloud tools and capabilities the way they would with code and its parts of the stack.

    Meanwhile, DevOps teams—as the exact mirror image and the nature of their role in the organization—don’t grasp application needs and objectives. This often results in a widening chasm of broken communication and collaboration around IaC initiatives.

    2.) Collaboration Suffers

    A common tool that exacerbates the problem is a ticketing and support platform. Developers, as their modus operandi, lacking a shared understanding of the domain, will often resort to opening tickets to achieve their goals. This creates a culture of inefficient cross-team communication via ticketing systems.

    This doesn’t mean the ticketing platforms are the problem, it just results in inefficient communication methods, as developers don’t always know what questions to ask.

    What this does mean is that DevOps engineers operate largely on instinct, being mostly in the dark on the real application requirements that can’t all be communicated in a simple Jira ticket. This results in final solutions that rarely satisfy needs on the first attempt and take longer to deliver.

    3.) Releases Slow to a Crawl

    DevOps teams hold the responsibility for conducting and orchestrating release engineering, on top of provisioning environments, maintenance, monitoring and other tasks that fall in the DevOps engineering domain.

    This is why DevOps tasks can become a bottleneck, as they not only dictate deployment timing (due to important considerations of uptime and client disruption, among others) but are also tasked with juggling infrastructure changes across many and multiple environments.

    This causes unpredictable delays in provisioning dev environments and other developer-oriented tasks that frustrate developers and stall production updates, and delivery velocity.

    The Obstacles of Change

    Recognizing these inefficiencies and shifting these responsibilities left became the popular way for DevOps leaders to distribute IaC duties. This allowed developers to gain sufficient autonomy to choose the solutions for their needs, while DevOps teams provided guidance and oversight for how to practically achieve these solutions.

    However, like all things shift left, this comes with its own set of unique challenges. Adopting the DevOps paradigm faces fundamental obstacles that add further complications and complexity to these cultural transitions, including:

    • Uncontrolled sprawl
    • Ballooning costs
    • Security concerns

    On the one hand, distributing the IaC load lessens the burden on the DevOps teams, but the downside is that it becomes difficult to understand which resources are actually in use and which have been temporarily created for testing purposes.

    With many owners creating resources on demand, once they are no longer needed, these leftovers create confusion around dependencies and make cloud platforms disorganized and difficult to maintain.

    Just like enabling more hands to touch IaC creates greater sprawl and disorder, more users with less governance invite careless sprawl in terms of costs as well. This often results in duplicate and unused resources accumulating, wasting budgets that are currently tight, and every penny counts. With a lack of automation and oversight, environments grow messy and expensive.

    The sprawl issues can also impact security, as expanding permissions raises valid security concerns that are intensified when clouds become disorganized and difficult to maintain.

    Well-intentioned developers may misconfigure resources or expose sensitive systems, and without proper methods to manage drift or misconfiguration, this can pose real risks to organizations and systems. Another important aspect that also increases with less oversight is intentional insider risk.

    From Silos to Shared Responsibility

    OK, that must have been really disheartening—and you’re probably thinking you should run for the hills before attempting any transitions to shared responsibility.

    But wait—don’t panic yet. It is possible for teams to redistribute IaC responsibility while avoiding these pitfalls.

    Below are some key factors to help you make the transition smoother in the short and the long term:

    • Automate everything—If DevOps practices have taught us anything, it is that manual cloud environment maintenance doesn’t scale. Automation has been the backbone of much of the evolution we have undergone when it comes to infrastructure operations, and this has been powered by the programmability and everything-as-code mindset—from IaC to policy-as-code (PaC). This automation-based optimization makes it possible to reduce neglected resources through regular and automated analysis and response. What you get is cost savings and the prevention of runaway sprawl.
    • Empower through governance—Remember when we spoke about automation and governance? Well, programmatic policy enforcement is a good way to constrain unwanted resource proliferation without manual intervention. Governance comes in to handle auto-remediation of misconfigurations or other anti-patterns that do not align with automated policies, which simplifies environment management at scale. Importantly, governance, if done right, can be a tool to empower teams, break silos and encourage autonomy. Having the right guardrails in place is how you instill confidence and provide helpful direction.
    • RBAC for the win—Role-based access control (RBAC) limits permissions to appropriate needs, establishing important guardrails that can help prevent some of the issues we spoke about above, including sprawl and security concerns.

    RBAC will enable developers to gain the necessary freedom while minimizing security risk. Minimum required access encourages responsibility and constraint.

    Now that you have a solid grasp of the principles, it’s time to put them into action!

    Fortunately, there are numerous solutions at your disposal. You can jump in and build them yourself using capable tools like Jenkins or Atlantis.

    Alternatively, for a more comprehensive approach, there are excellent commercial IaC management tools on the market. These can assist you in reaching your objectives swiftly and with greater efficiency.

    An Evolutionary Vision for IaC and DevOps

    As technology complexity increases, no single team can handle infrastructure alone. Dev and Ops must unite abilities to shepherd modern systems and the underlying code powering them. This requires closing knowledge gaps through collaboration and communication

    With a thoughtful process, IaC automation, governance guardrails and the right access policies, tech leaders can guide this cultural transition smoothly without exposing the organization to unnecessary risk and spending.

    When done right, Shared IaC responsibility will boost velocity, agility, and autonomy—the trifecta of crucial traits that quantify and qualify elite engineering teams and differentiate companies in a competitive landscape.

    Interested in learning more about env0 to manage your IaC at scale and confidently?

    Stop by Booth L12 at KubeCon EU to speak with an expert or see a demo!


    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.