devopsy.kinsta.cloud

Category: Continuous Testing

Continuous testing is the process of executing automated tests as part of the software delivery pipeline to obtain immediate feedback on the business risks associated with a software release candidate.

  • From Cloud Chaos to Cloud Smart With Multi-Cloud Services

    From Cloud Chaos to Cloud Smart With Multi-Cloud Services

    Organizations that embrace multi-cloud services experience real results and a heap of advantages—including greater resiliency, agility and data sovereignty. This is why it’s no surprise the majority of enterprises today are using two or more public clouds, with 81% reporting in a recent survey that they plan to adopt a multi-cloud strategy by 2024.

    But despite the benefits, it’s also been proven that multi-cloud can be complicated and even overwhelming. It requires an entirely new approach to optimize workloads, simplify development and tackle a growing pattern of operational complexities. This has been described as cloud chaos, where greater cloud choice has led to a massive spike in complexity. Most report that building new apps is slow and cumbersome, and managing their entire app portfolio across disparate clouds is difficult and expensive. No wonder, when each cloud requires its teams to use proprietary tools that are siloed and incompatible with one another. Meanwhile, for the average employee, getting fast, secure access to critical apps from anywhere is imperative, yet it’s often a challenge. All this complexity has broad repercussions on the business, from managing costs to attracting and retaining top talent.

    Tackling this multi-cloud complexity needs to start with creating a layer of abstraction that spans various, diverse cloud environments and doesn’t hinder access to each cloud provider’s unique services. However, organizations must take it a step further to solve the challenge of how best to build, manage, govern and optimize apps and workloads across a multi-cloud environment.

    Multi-Cloud Services

    Multi-cloud services—a fast-emerging category of IT services—are the key to helping organizations implement a multi-cloud strategy that simplifies and streamlines development, operations, networking and security across clouds. A multi-cloud service provides a consistent API, object model, identity management and other core functions across clouds. And, it has one or more of the following characteristics:

    1. Runs on a single cloud but supports interactions with at least two different clouds
    2. Runs on multiple clouds and supports interactions with at least two different clouds
    3. Runs on any cloud or edge, even in disconnected mode, and basic operations are fully automated

    Multi-cloud services can be used to standardize cloud infrastructure and operations into one platform to reduce the complexity of individually building or consuming the equivalent native services from multiple clouds. In this model, public clouds, data centers, private clouds and edge locations are all verticals, and multi-cloud services are horizontals that provide functionality across these environments.

    Let’s take a closer look at the five most common categories of multi-cloud services and when to use them.

    1. Application Services

    Application services allow teams to use core services in a standardized manner across clouds. These core services include observability, replication, backup, and restoration. By implementing application services, enterprises can increase their speed of innovation and make their technologies easier to use. Examples of application services include developer tooling, databases, modular development platforms, artificial intelligence, machine learning and serverless and CI/CD capabilities.

    2. Infrastructure Services

    If your organization chooses to run its applications as VMs, containers, or both, using infrastructure services is the right move to standardize management and operations across the clouds. Different types of multi-cloud infrastructure services include the ability to manage and observe compute, storage and network services leveraging VMs or containers, infrastructure automation and Kubernetes management solutions. When applied, infrastructure services can improve resiliency, security, performance, interoperability and portability.

    3. Security Services

    When using multiple clouds, an issue enterprises run into is that each individual cloud has its own security tools and approaches, making it difficult to ensure your enterprise is protected against cyber threats. That’s where multi-cloud security services come in – centralizing security operations and secure software supply chains. Some examples of multi-cloud security services are network detection and response, endpoint detection and response, next-gen antivirus and secure access service edge. These services enable organizations to achieve cohesive visibility, context and control by providing a single interface.

    4. End-User Services: Access to Data and Services

    No matter how big your enterprise is, or how many applications you use, it’s necessary to provide the right level of access to applications and data. But this can prove difficult when you have a multi-cloud infrastructure. Multi-cloud end-user services, which consist of virtual desktops, device management and end-user application delivery, will provide your organization a uniform way for all employees to have quick, secure access to your applications, all while simplifying device management.

    5. Data Plane

    In the past, workloads were restricted to a single data plane contained within a single public or private cloud or edge location. Now with the rise of multi-cloud services, enterprises can run workloads in the multi-cloud data plane. A prime example of workloads running in the multi-cloud data plane is a distributed application that runs in multiple cloud provider environments. Part of the application might run in the private cloud and the other services are deployed in a public cloud. The multi-cloud data plane is where the containers, services and data exist and where user interaction occurs.

    From Cloud Chaos to Cloud Smart

    The desired destination of every multi-cloud journey should be to move from a position of cloud chaos to one of cloud smart. Being cloud smart means taking an architected and planned approach to multi-cloud and digital transformation. As more enterprises adopt multiple clouds, multi-cloud services will be key to becoming cloud smart by helping to reduce complexity and risk and proving the freedom to select the right cloud for all situations based on technical and business requirements.

  • Business Leaders Will Trade Speed for Security

    Business Leaders Will Trade Speed for Security

    A global survey of 600 C-level executives conducted by CloudBees found that when it comes to building software, more than three-quarters of respondents said it is more important to be secure and compliant than fast and compliant.

    As a result, more than three-quarters (77%) also noted their organization is implementing a shift left strategy for implementing security and compliance even though 58% recognized that those efforts created additional burdens for developers.

    Three-quarters of respondents also conceded that compliance (76%) and security (75%) challenges limited their company’s ability to innovate. Nevertheless, 83% said shift left is important for them as an organization despite the fact that 88% of executives said their software supply chain is secure or very secure. However, only 33% of respondents said their software supply chain is completely compliant.

    Not surprisingly, 86% are focusing on compliance more now than they were two years ago and, in the wake of a series of high-profile breaches of software supply chains, 82% are more concerned about attacks.

    CloudBees CEO Anuj Kapur said it’s clear there is a greater need to reduce security and compliance burdens for developers by putting guardrails in place that automate DevSecOps processes. The survey noted that only 22% of executives believed their software delivery supply chain is completely automated, while another 37% said it is close to being automated. Only 22% said their compliance process is completely automated, with 35% believing it is almost completely automated.

    Three in five (59%) executives said they have all, or mostly all, external tools for security and compliance issues and 29% said they have a mix of internal and external tools. Only 11% use mostly internal tools. A full 90% said their risk management team has the tools, knowledge and expertise to build and/or maintain a secure software supply chain.

    The real challenge, of course, is that while compliance issues are relatively static, new security issues arise all the time. Developers make mistakes or a new zero-day vulnerability is discovered after an application has been deployed in a production environment. It’s critical for organizations to embrace automation to enable developers to address those issues as part of a continuously automated update cycle, noted Kapur.

    As more responsibility for compliance and security is shifted left, the degree to which DevOps workflows will need to be adjusted will naturally vary by organization. However, the days when developers could ignore security issues during the application development process are all but over. The leadership of organizations of all sizes are making it clear they want to see a reduction in the number of security and compliance issues that arise in production environments.

    Ideally, efforts to build more secure and compliant applications would not slow down the rate at which applications are being built and deployed. However, the CloudBees survey made it clear that more executives are willing to prioritize security and compliance over speed of application development. The issue is how to strike a balance between what are clearly two competing priorities.

  • Latest DORA Report From Google Surfaces Raft of DevOps Challenges

    Latest DORA Report From Google Surfaces Raft of DevOps Challenges

    The annual Accelerate State of DevOps 2022 report published today by the DevOps Research and Assessment (DORA) team at Google found the percentage of high performers is at a four-year low, with the percentage of low performers rising dramatically from 7% in 2021 to 19% in 2022.

    Based on a survey of 1,350 DevOps professionals, the report evaluated organizations based on the five DORA metrics: Deployment frequency, lead time for changes, time to restore service, change failure rate and operational performance. The DORA team also identified clusters of DevOps teams ranging from “starters” to “flowing” based on their overall maturity. Only 17% of respondents achieved a ‘flow’ state defined by high reliability, high stability and high throughput characteristics.

    The DORA survey sample shifted this year to include more respondents that are earlier in their careers than in previous reports. However, Claire Peters, DORA research lead at Google, said that while there are a lot of factors that impact those metrics, the current hypothesis is that the COVID-19 pandemic has taken a toll on DevOps productivity as more DevOps professionals continue to work remotely.

    The report noted a marked shift in deployment targets requiring new skills, with 54% of respondents now working with container artifacts.

    Overall, the report finds software delivery performance is beneficial to organizational performance when operational performance is also high. The challenge is the number of organizations that have achieved high operational performance is relatively small. In fact, the report also noted that site reliability engineering (SRE) practices had a negative impact on software delivery performance until an organization achieved a high level of SRE maturity.

    The report also concluded that organizations that built software on and for the cloud tended to have 1.4 times higher organizational performance than those that didn’t. The percentage of respondents using public clouds is 76%, up from 56% in 2021, while the number of respondents not using a cloud stands at 10.5%. Usage of multiple public clouds is at 26%, while 35% reported using a private cloud.

    Less clear is the impact on DevOps teams of shifting application security left. The report suggested the biggest challenge organizations face when it comes to achieving application security have more to do with cultural issues than any technical shortcomings. The report notes that organizations that focus on accelerating software delivery without implementing meaningful DevSecOps best practices find themselves in a vicious counterproductive cycle that results in applications being successfully deployed in production environments less often.

    Peters noted that there is greater developer fatigue because organizations attempt to address security issues either just before an application is deployed or they remediate applications after they are deployed. Organizations that have low levels of security practices are 1.4 times more likely to experience developer burnout.

    The DORA team used both the supply-chain levels for secure artifacts (SLSA) framework defined by Google and the Secure Software Development Framework (SSDF) defined by the National Institute of Standards (NIST) to evaluate organizations. The most widely-adopted practice is application security scanning within a continuous integration/continuous delivery (CI/CD) system, with 63% of respondents reporting these tools are “very” or “completely” established. Preserving code history and using build scripts are also highly established, the report finds.

    In general, Peters said the report suggested the biggest predictor of application security success was whether an organization had a high-trust, low-blame culture focused on performance. Organizations that have these cultures tend to have higher organizational performance. Similarly, organizations with teams that felt supported through funding and leadership sponsorships tended to have higher organizational performance, the report noted. In addition, team stability and positive perceptions about one’s team also tended to lead to higher levels of organizational performance. Lastly, companies that offer flexible work arrangements tended to see higher levels of organizational performance.

    Each organization, as always, will implement DevOps best practices in ways that best fit its internal culture. However, the latest DORA report makes it clear that the more empowered a DevOps team is the more proficient they tend to become.

  • Building a Platform for DevOps Evolution, Part Two

    Building a Platform for DevOps Evolution, Part Two

    In the introduction to this series, we discussed the concept of change and how it applies to DevOps environments and release managers. 

    In a world of constant changes in our surroundings and user demands, DevOps has to maintain hundreds of moving pieces across large organizations of people who, by nature, are adverse to change. This requires release managers to delegate power, transition from a centralized commander to an enabler, understand different value streams and constantly experiment. 

    In this section, we’ll cover some of the ways and types of experiments DevOps organizations can conduct to improve their release management procedures and meet their objectives using DevOps principles.

    Value Stream Mapping

    Value stream mapping is a series of steps used by organizations to provide products or services their customers want or need. In the traditional sense, the release and deployment process can seem tedious, especially if teams must communicate with a release management team to schedule release slots on a calendar.

    Despite its advantages, value stream mapping has a few drawbacks. It requires a lot of people and it can be difficult to coordinate and sparsely repeated.  

    Value stream management platforms can extract the four key DevOps metrics for teams to inspect and adjust in real-time. However, there are some shortcomings with using the four metrics:

    • Lead time is characterized as time from code commit to live; however, in value stream management, we also consider the time it takes for an idea or customer request to reach value realization.
    • Deployment frequency becomes interesting when teams deploy sporadically but are still improving, but when teams attain the ability to release on demand, other metrics become more helpful.

    As a result, teams must alter metrics over time to match team ability. This is why it’s critical to empower value stream teams to discover and measure their own metrics. Another factor is that people are more likely to change when doing it for themselves rather than having it done to them.

    Lessen Batch Size

    Reduced batch size lowers risk and reduces the time an activity waits in a queue. When changes are minimal, they may be implemented quickly and with less danger of causing disruption, thereby making the distinction between the phases less significant.

    While some key metrics may be accessed through specific tools such as backlog or release automation, without a value stream management platform, it’s more difficult to gain insights into overall queueing time.

    The value stream map is automated when all aspects of the DevOps toolchain are combined, resulting in a unified system from idea through the realization that allows teams to understand their cycle time and value flow efficiency and observe how changes improve work.

    Evolving Architecture From Monolith to Microservices

    Most organizations have monolithic, tightly coupled applications because that was the best software design approach available in the past. However, as the industry evolves, release managers become increasingly conscious of the limitations of this architectural approach:

    • Large batches of work are required to build, test and deploy.
    • Dependencies must be managed, including people and systems.
    • Dependencies cause fragility.
    • Fragility causes bureaucracy (e.g., CABs).
    • Bureaucracy and handoffs hinder flow.

    Rearchitecting applications to microservices, like changing human behaviors in a system, does not happen overnight, and there are frequent bottlenecks along the way. This is often a “change or die” conversation. If the application does not become more capable of change, market disruptors will provide new experiences to consumers, and customers will jump ship for these competitors.

    A value stream management platform can reveal where restrictions, delays, and dependencies occur and how they might be reduced. As a tenet of DevOps says, “Don’t manage dependencies; break them.”

    For many companies, however, the road to systemic autonomy, or loosely coupled systems, is lengthy with many incremental steps of improvement. This method is recommended by the strangler pattern: chipping away at the monolith one bit of functionality at a time.

    During the application architecture change, we need to support value stream teams, so they don’t waste time on unexpected work caused by unknown dependencies. We also need them to see and appreciate the improvements they’ve made with the support of a value stream management platform.

    Part of the release manager’s job is to identify value stream success stories and share them with the other value streams so that local improvements can become global ones.

    Transfer the Release Management Role to the Value Stream Team

    When teams work independently on small changes, they can release them as soon as they are ready. However, moving from one state to another takes time to transition to that stage of the journey.

    In a traditional method of working, the release process is likely to be coordinated by a release manager or a team of release managers. The release manager role can be transferred to the value stream team, with the team providing access to systems that provide visibility into current releases to the release manager.

    Transparency into operations across value streams provides traditional release managers with great comfort during this transition, relieving them of the administrative strain. It allows individuals to learn new skills and refine the meaning and purpose they derive from their work.

    By taking an end-to-end and cross-value stream approach to change and improvement and ensuring blame becomes accountability, release managers can be key to the success of these improvements. Platforms for value stream management give the data needed to support the conversations that will lead to this cultural and behavioral shift.

    In this series’s third and final part, we will cover more types of experiments and DevOps best practices for achieving change and driving results. 

  • To Build a Durable SaaS Business, Rethink Your Product Roadmap

    To Build a Durable SaaS Business, Rethink Your Product Roadmap

    During a tech downturn, with enterprises cutting their subscription software budgets and VC funding drying up, SaaS businesses are increasingly shifting their strategic focus from growth to resilience. 

    The standard startup playbook—hunker down, cut burn rate and hope the market improves before you run out of runway—isn’t the right path forward for SaaS businesses. Instead, the key to durability is to lean into efficient growth. By revamping their product strategy, companies can lower the cost of customer acquisition with low-touch onboarding strategies and also increase revenue retention with stickier products, helping to unlock new ways to scale up and sustainably grow revenues. 

    Implementing this approach requires a fresh approach to your product roadmap—because when you scale through retention and expansion, the primary goal is maximizing utility for existing customers so they’ll increase usage and be willing to spend more over time. That means prioritizing core features and usability and not tacking on new features in a bid to draw in new customers with adjacent use cases.

    Getting that right, in turn, requires SaaS leaders to leverage the product itself as a key to understanding which features need attention, as well as a messaging channel and conduit for two-way communication with end users so you can influence user behavior and collect user feedback. Here are four steps that product managers can take to drive durable, resilient growth for their companies:

    Get Serious About Analytics

    Every business wants to use data to drive better decision-making—but many organizations fail to realize that their own product is their most potent source of data. Unlike web analytics which show only the behavior of random web users, product data has the power to help you understand the user journey, what they’re finding useful, what they’re struggling with—and how you can create value to keep them coming back for more.

    That makes product analytics—data showing how your product is being used, along with user surveys, messaging and other more qualitative measures—a powerful resource as you seek to anchor your development roadmap in the things your customers actually need. Armed with user feedback, it’s possible to learn how your customers feel, understand what’s missing—and invest in improvements that align with your users’ evolving needs.

    Stay Focused on Stickiness 

    Your analytics dashboard should have a strong focus on your stickiest features—the ones that keep users coming back for more. Those will include your product’s key value drivers during the early evaluation stage when you’re looking to hook new customers and turn their curiosity into a compelling use case for your product. But they will also include outcome-related features that enable established customers to measure and increase ROI as they scale up. Finally, they will include features that directly drive organic expansion, such as collaboration functionality that drives users to invite colleagues to use your product.

    Product managers (and their bosses) naturally get excited about new features—but by taking a data-driven look at stickiness across the whole customer life cycle, it becomes easier to identify opportunities to innovate around your core functionality and make it more integrated, scalable and productive. Customers won’t renew or expand their contracts because you rolled out a shiny new feature—but they will keep renewing if your team keeps investing in making their outcome-driven features the best they can possibly be so they can be successful at their job.

    Make Space for Quick Wins to Drive Advocacy

    If you view your roadmap as a waitlist for dev resources, it’s tempting to simply add newly identified usability bugs or hiccups to the bottom of the list, and circle back to them months later once your team is done working on building out new features. But in the end-user era, users control the renewal decision, so customer satisfaction isn’t a nice-to-have—it’s something you have to make time for to build and grow a durable business. That means pre-allocating time and resources for quick fixes and small enhancements that reduce friction, eliminate pain points with core features and drive stickiness for existing users. 

    As you track user experience across your stickiest features, you’ll find errors and pain points that need to be remedied promptly to keep your users happy. These are hard to plan for because they’ll emerge on a daily basis based on usage data and user feedback—so the key is to proactively assign resources to address these unplanned issues and turn them into quick wins, enabling you to iterate quickly rather than risking user frustration by adding core-feature fixes to your standard product roadmap.

    Influence User Behavior 

    User enablement is sometimes underestimated by product teams, but the shocking truth is that most customers won’t carefully read through your release notes in search of new features. In fact, they may not even notice your newly released functionality—and those that do might still struggle to understand how that feature supports their core use cases or to intuit the best practices for using it effectively. 

    To increase visibility into new features, you need to leverage in-app messaging, enabling your core users to unlock new functionality in an optimal way so you can capitalize on your product investments. As part of every release process, invest in user enablement by creating effective in-app communication with links to articles and videos that can help users adopt features successfully. 

    Invest in Revenue Drivers

    Of course, focusing on stickiness doesn’t mean slamming the brakes on all new features. The key is to use product data to ensure that innovations aren’t coming at the expense of core-feature usability. Before signing off on a new feature, make sure you have a hypothesis on how it will drive revenues—and remember: Innovative new capabilities might attract a subset of early adopters, but during a down economy your customers care more about must-have features than about nice-to-have add-ons. 

    Be sure to weigh a feature’s projected value—for your users and also in terms of revenues—against the cost of maintaining that feature over time. Every company has a finite amount of dev-hours to dedicate to perfecting its product, so even revenue-positive features can prove a drain on resources. Be realistic about what you can manage and don’t sacrifice long-term stickiness for short-term innovation.

    Remember Your North Star

    To make the right decisions during tough times, every SaaS business needs to focus on its North Star. For product managers, that means taking the time to understand—in a granular, data-driven way—exactly what makes their SaaS product worth paying for. Real resilience comes from leaning into those things and scaling by optimizing the user experience to make the product as sticky as it can be.

    Building durable and resilient SaaS businesses isn’t just about belt-tightening. It requires a commitment to scaling through the product and using it as a vehicle to drive retention and expansion by increasing value across your core features in ways that keep customers coming back for more. That, in turn, requires a fresh approach to your roadmap—because more than anything else, the way you understand and invest in your product will determine your company’s success or failure during the tough times that lie ahead.

  • GitBOM Tool Automatically Identifies Software Artifact Components

    GitBOM Tool Automatically Identifies Software Artifact Components

    An open source GitBOM tool, discussed at the Open Source Summit Europe conference this week, can automatically track every source code file incorporated into each built artifact.

    Nell Shamrell-Harrington, a principal software engineer for Microsoft, told conference attendees via a video link that the GitBOM tool, based on a compact Artifact Dependency Graph (ADG) technology, can verify which artifacts are being used across any programming languages, environments and packaging formats without any effort made by developers. To do this, GitBOM repurposes the directed acyclic graph made available in Git version control software.

    All that is required is for GitBOM identifier—a unique, content-addressable reference—to be inserted into the artifact at build time. That identifier then creates a Gitoid that can be consumed by ADG, Shamrell-Harrington said. Each Gitoid then views an artifact as a binary large object (BLOB) through which of all the components that went into it, including source files, dependencies and object files can be identified.

    Support is also included for the Software Package Data Exchange 2.3 format for sharing software bill of material (SBOM) information discovered by GitBOM.

    GitBOM can also detect potential vulnerabilities at runtime, regardless of the depth, in every software artifact that might be impacted to make it simpler for IT teams to remediate issues. That approach makes it simpler to find, for example, every instance of the Log4j vulnerability that might exist in an application environment. GitBOM only includes the minimum information required to create a fingerprint to enable efficient runtime scanning for a known-vulnerable artifact.

    The goal is not to replace SBOM tools but rather to make it easier for them to collect data about artifacts in the most frictionless way possible for developers, Shamrell-Harrington said. GitBOM enables any metadata to be linked to a specific set of corresponding software artifacts to make it easier to discover exactly how they were constructed. Artifact IDs can then be extended to produce GitBOM documents that can be consumed by other build tools.

    GitBOM is being shared at a time when the focus on securing software supply chains has never been higher. In the wake of the Log4j vulnerability disclosure, the Biden administration is requiring every federal agency to construct SBOMs to enable developers to find instances of vulnerable software components. Most large enterprise organizations are generally following suit.

    However, collecting SBOMs is only the first part of a bigger challenge. Organizations will then need to acquire tools to analyze SBOMs and provide feedback to application developers. In effect, eventually, organizations will be able to accept or reject software based on the components being used to create it. Armed with those insights, developers then have the option to upgrade software components to bring applications in line with any policy an organization defines.

    It may be a while before SBOMs proliferate across IT organizations, but the immediate issue at hand is simply finding the least-intrusive way possible to create them.

  • Heat Cooks Twitter DC | AI Will Kill All Humans | Patreon Layoffs, CSAM Claim

    Heat Cooks Twitter DC | AI Will Kill All Humans | Patreon Layoffs, CSAM Claim

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Twitter is in a “non-redundant state” thanks to a hot summer, AI is likely to eliminate us, and Patreon fires 80 staff amid nasty allegations (TW: Child safety). (more…)

  • How IaC Helps Relieve Development Pain Points

    How IaC Helps Relieve Development Pain Points

    Developers spend much of their day digging into their systems’ guts, allocating storage to an application, connecting the security system to the user interface and tracking which version of the application is where in the development cycle, among other tasks.

    That’s why a new category of software has emerged, infrastructure-as-code (IaC), that promises to automate system infrastructure provisioning and integration. It frees up time so developers can focus more on frontend solutions rather than backend configuration management. First, though, let’s find out what IaC is and how it helps your organization.

    What is Infrastructure-as-Code (IaC)?

    IaC reduces system infrastructure creation and configuration time through the use of sets of tools, protocols, languages and processes. In conventional data center system management, each configuration entry and change has historically required manual action. Now, technology teams can manage everything in an intelligent, automated manner. 

    With IaC, infrastructure configuration management data is stored within standardized files. The tools monitor and maintain the state of the infrastructure and ensure that the right resources are available whenever an application runs. This saves DevOps teams from excessive manual effort. In essence, large-scale configuration and management become dramatically simplified.

    Development Pain Points 

    Currently, development is a cumbersome process because friction arises in many places. A great deal of progress has been made in speeding up the front end of application development—building the feature set. Still, the process slows down on the back end when the software components are tied to the computer infrastructure. 

    Historically, software was deployed as one large, monolithic block of code. Updates were tedious to make because all of the application’s code had to run, even if it wasn’t involved in the update or bug fix. The advent of containers and microservices enabled developers to design applications that are modular in nature and therefore easier to update, add to or debug.

    However, the application still has to be tied into the existing compute infrastructure. Cloud solutions—like AWS, Google Cloud Platform or Microsoft Azure, for instance—provide companies with quick access to large volumes of computing processing power. But that application software must be told how to access the network, present security information, allocate storage and run code on central servers.

    Because of this, developers spend a lot of time building and maintaining infrastructure-as-code. To do so, they use languages like Python and solutions such as Chef and GitHub. They want to use automation to simplify and accelerate the process, but here, again, they encounter some roadblocks.

    Workflow Bottlenecks

    As applications become larger and components become smaller, developers find themselves mixing and matching software from a wide variety of places. Tracking what’s where in the process is a frequent challenge. Current workflows are often non-intuitive and rely heavily on pull requests. Some solutions try to address the problem with multiple workspaces, but the end result is fragile and nondeterministic code.

    Without mapping of projects to branches or tags, someone who comments on an approved pull request can push unapproved code to production. In today’s fast-paced DevOps work environment, an approval meant for a short-lived test run becomes the current release, creating a ripple effect of unintended consequences that create confusion and defective code, slowing development—often substantially.

    Access Control

    Most tools do not offer access control models. Developers can track a single repository and a single Terraform project, for example, but as the number of repositories and projects grows, ensuring that proper access control features are in place becomes more daunting. 

    Workspace Challenges

    Legacy waterfall and static development projects allowed IT teams to set their system infrastructure up once and forget about it. But in a dynamic environment, microservices come and go in the blink of an eye. New environments proliferate and product teams must continually configure their own workspaces, which eats up time and resources.

    Drift Detection

    Generic IaC platforms don’t provide mechanisms to detect if the infrastructure is drifting. Because so much configuration is done at runtime, differences arise between the desired and the actual state of the infrastructure.

    Drift has many causes, such as developer or machine script contingencies or the lack of system resources. Too much drift results in unstable applications. Catching such problems early in the development cycle is more efficient than trying to fix a production system. But needed visibility is often lacking, and shortcomings become clear only when the system is fully in use.

    Resource Visualization

    Given today’s dynamic environment, developers need clear visibility. They must be able to closely examine what happens as their job runs. Though they offer many advantages, CI/CD platforms deliver little insight into resource usage from a real-time or historical perspective.

    So, whenever performance problems arise, these platforms offer little insight into what the source of the problem is or how to fix it. Consequently, developers’ attention shifts from application enhancements to troubleshooting.

    Lack of Reusability

    Legacy infrastructure failed to let teams reuse tried-and-true system images across multiple environments. To address this problem, teams often create a new image for each version of each application, slowing development time. 

    High Prices

    Setting up each IT environment manually requires time and manpower, which raises costs. Companies must have dedicated teams of engineers responsible for creating the infrastructure. But they also need supervisors and data center resources, which ultimately boost technology expenses. IaC tools centrally manage the process and create the right environment. That way, organizations pay only for system resources that they truly need.

    How Does IaC Improve the Business? 

    Legacy IT practices are expensive, slow and inconsistent because they rely heavily on manual input. Infrastructure-as-code automates much of the infrastructure management process, which delivers a range of benefits.

    Speed 

    With IaC, provisioning and management are lightyears faster and more efficient than with a manual system. The environment’s infrastructure is defined in code. That code-based infrastructure significantly accelerates each phase of the software development and delivery cycle. Consequently, DevOps teams deliver applications faster and at scale while improving software quality.

    Consistency

    IaC deploys consistent configurations constantly and with no discrepancies. Because of this, it enables fast delivery of consistent infrastructure and environments. This reduces errors and overhead while boosting productivity.

    Eliminating Management Overhead

    Infrastructure automation helps to reduce the number of people with hands on the routing parts of the software development process. That’s because human resources aren’t needed in the management of networking and storage. Companies free up personnel to work on more strategic initiatives.

    Reducing Risks and Errors

    IaC helps to reduce risks and avoid human errors. It also protects against runtime issues and security weaknesses caused by missing dependencies or configuration drift.

    Visibility

    Developers version IaC configuration files the same way they do any other source code file. This gives them complete traceability of any changes. In this way, IaC ensures efficient, exceptionally transparent workflows and speeds up the development process.

    Finding an IaC Solution 

    Maintaining legacy infrastructure was a time-consuming, complex process. IaC is emerging as a solution that alleviates much of the stress and pain that developer teams feel daily. Now, they can speed up the deployment and connection of system resources to applications. Developers can become more efficient and enable the company to respond to business demands in a faster, more reliable and more cost-effective manner. The development process no longer slows down the business. 

  • DevOps World 2022: DevOps is Not Just CI/CD

    DevOps World 2022: DevOps is Not Just CI/CD

    There was a time when pundits said that DevOps was the symptom and CI/CD the cure. While that may or may not be true, there is no denying that CI/CD is the very heart of DevOps. While that might still be true, DevOps today is so much more than CI/CD; it has evolved, far beyond just its core of CI/CD.

    In my preparations for the upcoming DevOps World 2022, held in Orlando, Florida, September 27 to 29, I’ve been briefed on upcoming product announcements by the CloudBees product team. I find it fascinating to see where the CloudBees product line is going. In many ways, CloudBees product evolution mirrors the evolution of DevOps itself.

    Today, DevOps includes areas such as observability, security and compliance, GitOps, cloud-native and more. Developing, integrating, testing and deploying software is only one aspect of today’s DevOps. Without divulging any specific product announcements that CloudBees will be making at DevOps World, I can tell you that CloudBees is on a journey that closely mirrors that of DevOps itself.

    In my opinion, this is as it should be. CloudBees was one of the pioneers of the DevOps movement. By harnessing Jenkins—the original DevOps killer app—CloudBees helped move DevOps into the mainstream. Of course, Kohsuke Kawaguchi (KK), the creator of Jenkins, has moved on from CloudBees and the Jenkins community was always independent of CloudBees. Nevertheless, many of us in the field see CloudBees and Jenkins as inextricably linked.

    While Jenkins is still widely deployed and used, it is no longer the epicenter of the DevOps universe. Over the last couple years, CloudBees has transitioned to become much more than just Jenkins or Enterprise Jenkins and remains at the center of DevOps innovation.

    This year‘s DevOps world will be a great opportunity for CloudBees to showcase just how far they’ve come from being solely the enterprise Jenkins company while remaining a preeminent end-to-end DevOps tools provider. If you want to know just how far, well, stay tuned for our coverage of DevOps World where we will be covering all of the product announcements as well as speaking to CloudBees executives and customers about the new products and product lines and capabilities that will be announced.

    I have written before that the theme for DevOps World this year is DevOps Remix. Our own DevOps Experience virtual event, coming in November, has a theme of DevOps Everywhere. I think both of these themes speak to the same general idea: DevOps is going where it’s never gone before. It has evolved beyond CI/CD to a new way of developing, delivering and managing software that includes securing it and testing it. Over the next few years, I think we’ll see we’re entering a new golden age of DevOps.

    If you can, join us in Orlando for DevOps World. Techstrong.TV will be broadcasting live from the event; if you can’t make it, we’ll keep you updated on all of the developments announced there. Also, join us in November for our own DevOps Experience virtual event, which will highlight DevOps Everywhere: The Edge and Beyond. Hope to see you soon!

     

  • Rust Foundation Allies With OpenSSF and JFrog to Secure Code

    Rust Foundation Allies With OpenSSF and JFrog to Secure Code

    The Rust Foundation announced today it is working with the Open Source Security Foundation (OpenSSF) and JFrog to help maintainers secure open source software created using the Rust programming language.

    Rebecca (Bec) Rumbul, executive director at the Rust Foundation, said even though Rust is a memory-safe language, there are still security issues that maintainers need to be able to address. The goal is to provide the resources those maintainers need to better secure their software supply chains.

    As part of that effort, the Rust Foundation is adding a dedicated security team to help maintainers of open source projects built using Rust to better secure their software supply chains. That team is being underwritten by JFrog and the Alpha-Omega Initiative funded by Google and Microsoft which was recently launched by OpenSSF. JFrog last week announced it is joining the Rust Foundation at the Platinum level alongside Amazon Web Services (AWS), Google, Huawei, Meta, Microsoft and Mozilla.

    The first initiative for the security team will be to conduct a security audit and develop threat modeling tools that will provide the foundation for a set of best security practices for maintainers, said Rumbul. The team will also help advocate for those security practices across the Rust landscape, including the Cargo package manager and Crates.io directory projects.

    The OpenSSF has previously called for replacing programming languages like Java that are not memory-safe as part of a larger plan to secure open source software supply chains.

    In general, the Rust Foundation is committed to enabling Rust developers to achieve their scale, security and sustainability goals, said Rumbul. Given the early stages of the Rust programming language, there is no better time to start addressing security issues that application developers can’t ignore, she added.

    In the longer term, The Rust Foundation is also committed to providing developers with Rust security education and is also working to come up with a fair approach to certifying which projects have achieved an appropriate level of cybersecurity maturity, said Rumbul.

    It’s not clear whether developers are abandoning older programming languages in favor of a memory-safe language such as Rust. Rust employs a compiler to track the ownership of values that can be used once and a borrow checker that manages how data is used without having to rely on traditional garbage collection techniques.

    Of course, replacing trillions of lines of code that have already been constructed using a variety of legacy languages is a gargantuan task that might never be fully completed. However, as new applications are built using a memory-safe programming language, the overall security posture of an organization will steadily improve. The challenge, of course, is that the number of developers that know how to build applications using those languages is still relatively small.

    Nevertheless, there may come a day when the way applications are coded is a lot more secure by default than it is today. In the meantime, however, the number of vulnerabilities that exist with application environments is still too numerous to count.