devopsy.kinsta.cloud

Category: DevOps Practice

  • BMC Survey Surfaces DevOps Mainframe Progress

    BMC Survey Surfaces DevOps Mainframe Progress

    A global survey of 1,000 executives and IT professionals that rely on mainframes found 70% are now employing DevOps processes to build and deploy applications on the venerable platform, with 60% of those respondents now deploying applications faster. A full 80% of respondents also wanted to deploy mainframe applications faster, according to the survey.

    The survey also found that integration of IT processes across mainframes and distributed computing environments has increased, with well over half (57%) now sharing platform operations roles. A total of 44% reported site reliability engineering (SRE) as a shared role that spans both platforms.

    Applications developed in-house are being delivered faster than a year ago, reinforcing the mainframe’s business value, with 76% realizing value in under 12 months.

    More than half of respondents (53%) said their organizations is also implementing DevSecOps practices in a way that spans all those platforms. The top priority for organizations that have mainframes is security and compliance (67%), the survey also found.

    Nearly a third have also adopted artificial intelligence for IT operations (AIOps) across mainframes and distributed computing platforms. Survey respondents that have adopted both mainframe AIOps and DevOps reported they are gaining visibility into service issues 70% faster, with 41% improving uptime and availability, according to the survey.

    Finally, the survey found 95% of respondents still had a positive perception of the mainframe as a platform for running applications, with 62% reporting transaction volumes on the mainframe are increasing. More than half (55%) also noted workload volatility and unpredictability is increasing. A similar percentage (55%) also reported more than half of their data is on a mainframe.

    John McKenny, senior vice president and general manager for Intelligent Z mainframe optimization and transformation at BMC, said IT teams in a downturn are, as usual, trying get the most out of their existing investments. The thing that is changing most is the mainframe is now becoming more integrated with distributed computing environments as IT teams strive to achieve that goal, he added.

    In general, there’s still much work to be done in terms of furthering adoption of DevOps best practices in mainframe environments, noted McKenny. Each organization will most likely determine at what level to apply those practices based on the frequency at which applications running on mainframes need to be updated. There are still plenty of applications running on mainframes that might not need to be updated for many years, but as organizations embrace digital business transformation initiatives, the need to update mainframe applications more frequently has increased, noted McKenny.

    Regardless of the type of application deployed, it’s apparent that the days when mainframes were managed in isolation from the rest of a distributed computing environment are slowly coming to an end. A mainframe is, arguably, just another node for deploying applications. The one major difference is that, as platforms are considered, the mainframe is a lot more secure, said McKenny.

    The challenge and the opportunity now, of course, is as much about changing attitudes toward the mainframe as it is making the right DevOps tools available to the IT teams tasked with managing heterogeneous IT environments.

  • Endor Labs Applies Graph Analysis to Secure Software Supply Chains

    Endor Labs Applies Graph Analysis to Secure Software Supply Chains

    Endor Labs exited stealth mode today to launch a platform that applies graph analysis to identify the depth of dependencies that exist within an application.

    Fresh from raising $25 million in funding, Endor Labs CEO Varun Badhwar said the Dependency Lifecycle Management Platform makes it simpler for organizations to manage dependencies within applications that can involve tens of thousands of components.

    Existing software composition analysis (SCA) tools are not able to as accurately identify the dependencies between software components because they generate too many false positives, he added.

    To address that problem, the Dependency Lifecycle Management Platform provides the equivalent of a credit risk score for each component employed with an application environment, said Badhwar.

    Designed to run out-of-band within a continuous integration process, the Dependency Lifecycle Management Platform is currently being made available via a private beta program.

    On average, bout 80% of an application is made up of open source components that developers downloaded from a repository. The challenge is that many of those components have known vulnerabilities. The Dependency Lifecycle Management Platform makes it simpler to both identify those vulnerabilities during the build process and find components that might be impacted by a newly discovered zero-day vulnerability, said Badhwar.

    Overall, the Dependency Lifecycle Management Platform improves the productivity of both application development and cybersecurity teams by streamlining vulnerability management, he added.

    Having a full understanding of their dependency graph also lets customers generate and analyze accurate software bills of materials (SBOMs) as applications are dynamically updated, noted Badhwar.

    In the wake of a series of high-profile breaches, there has been increased focus on software supply chains. The challenge is most developers don’t have a lot of cybersecurity expertise and, even when provided with tools to identify vulnerabilities, there are simply too many alerts generated. In the absence of any context, most of those alerts simply wind up being ignored. In the meantime, the rate at which new applications are being deployed and updated isn’t slowing down, especially as more organizations embrace cloud-native applications that make it easier to rip and replace software components.

    It’s going to take years for organizations to implement DevSecOps best practices to teach developers how to build more secure applications, but that journey needs to begin with tools that make it simpler for developers to address issues before applications are deployed. The best way to combat application vulnerabilities is to make sure they don’t manifest themselves in code in the first place. Based on the number of vulnerabilities that continue to find their way into application environments, it’s apparent that the current processes being used to build applications are fundamentally broken.

    At this juncture, it will take years to fix the application development and deployment process, but as more secure applications eventually replace millions of insecure applications the overall security posture of organizations will steadily improve. The issue now is finding ways to achieve that goal before another known vulnerability leads to another major security crisis.

  • Distributed Systems: Turning Networking to Your Advantage

    Distributed Systems: Turning Networking to Your Advantage

    Whether it’s the office, the classroom, the store or the bank, a great many spheres of human life have moved online. Each day, we grow more and more used to consuming applications on demand that instantly connect us with the rest of the world. Our expanding appetite for the internet depends on an ongoing trend toward distributed systems, with most companies today spreading their information technology across hybrid and multi-cloud architectures that consist of small, independent and loosely coupled containers. Companies are scaling their applications by deploying more clusters of containers across an ever-broadening surface. There are four key lessons businesses can observe from the proliferation of distributed systems.

    Don’t Underestimate the Benefits of Distributed Systems

    There’s a reason why the trend toward distributed systems persists; they are chock full of benefits.

    Distributed systems are incredibly scalable, as they allow companies to scale applications by adding, replacing or removing nodes as necessary. New applications can be rolled out quickly and in multiple iterations, accelerating time-to-market. Codebases are smaller and easier to change. Distributed systems optimize developer efficiency and team collaboration because numerous teams can work on different parts of a system simultaneously.

    Distributed systems are highly resilient. When (and only when) built effectively, distributed systems will continue working even if a significant part shuts down, as traffic can be rerouted to functioning servers—just look at the resilience of the internet. Fewer single points of failure create more stability and fault tolerance.

    With so many benefits, it’s not difficult to see how distributed systems have enabled our connected, digital economy. Netflix is a prime example of how they have supported the growth of SaaS-based applications. Thanks to a complicated distributed system, anyone on Earth can access a massive library of movies, tv shows, and documentaries to stream whatever they want on demand, paying a monthly subscription.

    While Netflix is considered to be in the entertainment industry, we think of it as a technology company first and foremost because the success of its business model is based on the efficacy of its distributed system. Netflix’s platform is scalable, resilient, performant, efficient and therefore profitable because it is distributed.

    Know That Distributed Systems are Complex and Challenging

    Distributed systems are innately complex and therefore difficult to build and operate. They consist of many asynchronous components that must work in tandem with one another. As the system scales, it becomes even more challenging to understand, let alone operate.

    These challenges are hardly unique to Netflix. Any company that manages a distributed system at scale suffers because of the convoluted nature of distributed systems. Other internet giants like Spotify, YouTube and Twitter also grapple with compounding complexity. If you’re overwhelmed by the labyrinth that is your distributed system, take comfort in knowing that these challenges are (to an extent) unavoidable.

    Turn Networking to Your Advantage

    A distributed system is a set of computers, containers or any other nodes that connect to a network to communicate with other entities by passing messages. What truly allows distributed systems to be ‘distributed’ and to function is the network. This makes the network both a liability and an opportunity. Yes, even the best systems will fail at some point on various levels. There is no such thing as complete control in distributed systems, but that doesn’t mean you can’t turn networking to your advantage.

    Developers can efficiently manage their distributed system by prioritizing networking and employing the right tools across an architecture. Netflix has built exceptionally well-connected systems with servers deployed in thousands of locations worldwide that connect to the control plane in the cloud. If a server fails, traffic can easily be rerouted elsewhere. The distributed system is scalable, resilient, performant and efficient. Robust networking solutions give the team at Netflix visibility into and control over the application.

    Networking truly is the key to bolstering the advantages and overcoming the challenges of distributed systems. Invest resources in your network and it will take care of your distributed system.

    Aim for Simplicity

    Turn networking to your advantage by taking care when building a networking stack. The two most predictable pitfalls to avoid here are not choosing a stack that addresses your unique challenges and differentiators and selecting tools that are overly complicated for your use case.

    It’s all too common for companies building and managing distributed systems to adopt popular or default tools that come with their orchestration platform without giving their suitability much thought. It is never a good idea to copy-paste a networking stack seen elsewhere, assuming that what has worked for others will also work for you. It may, but do not blindly select the stacks everyone is talking about without giving them much thought.

    Many organizations followed the herd by adopting Istio, only to later discover that the service mesh is far too complicated and resource-intensive for their platform. While Istio’s numerous features are helpful for some, they quickly become burdensome. The trending tools are not necessarily the best for your use case.

    Some companies go the opposite route and build their own custom solutions instead of following the herd. Just as Netflix built Zookeeper for service discovery and Spotify built Backstage for API management cataloging, global companies with expansive distributed systems can benefit from the control offered by a custom tool. This option is expensive, time-consuming and not viable for non-tech or smaller companies.

    You’re (probably) not Netflix, so don’t try to be. You may think you have the same problems, but you don’t. Yes, distributed systems are always complex and full of challenges. But the complexity of distributed systems compounds at scale to such an extent that it becomes incomparable. Internet giants like Netflix and Spotify require the advanced features of complicated tools or custom solutions built in-house (and they have the means to invest in these resources). If your platform is a fraction of the size of Netflix’s, your distributed system relies on a far simpler network.

    It’s extremely easy to choose solutions that are overly engineered for your use case, but it’s best to opt for simpler alternatives. Start with simple solutions, gain control of your networking stack and then advance to another level of complexity later on. Gaining control of your network will allow you to tap into the benefits of distributed systems while avoiding some of the challenges. Turn networking to your advantage and make your infrastructure scalable by choosing simplicity over complexity.

  • Forget Automation: Why IT Should Take UX Cues From Fine Dining

    Forget Automation: Why IT Should Take UX Cues From Fine Dining

    As a college student, I worked at a five-star Italian restaurant where I learned the discipline and practice of customer service. The general manager knew exactly which corner to stand in to get a view of every single table during service. They would gauge diners’ experience according to how they were interacting, their microsignals, how much food was left on their plate and the way they glanced around the restaurant. What does this intense attention to detail and individual customer experience have to do with running a service-oriented technology business? Everything.

    The tech industry is notorious for automating processes at the expense of personalization, and that aversion can extend to building the relationships necessary to produce a successful end product. Understandably, some companies and their developers prefer to keep relationships with their clients strictly functional because these connections are messy, people are unpredictable and nothing ever goes completely according to plan. It’s a dance we have to do over and again with every new client and project. 

    For those of us who wish to function as service-oriented tech companies, keeping on top of client and customer experiences requires us to stay attentive and listen with active care. Just like the veteran restaurant manager, we have to constantly scan our environment for cues of satisfaction and dissatisfaction.

    Service is More Than an End Product

    Before opening every night, the general manager would make staff hold long pieces of string to measure the angles and distance between tables to ensure they were straight and the edges perfectly aligned. Then, after telling staff the evening specials, he would randomly quiz them about the menu. What color is a fava bean? 

    Seeing the value of such old-school standards left a deep impression and helped me embed attention to detail as a foundational practice across the board, from designing good UX to cultivating relationships. Creating a desirable environment is about successfully orchestrating a million tiny details and always looking for tweaks to make the customer experience better. 

    That seemingly omniscient Italian from my earliest experience in the restaurant industry also taught me that being empathic goes hand-in-hand with the hard-nosed realities of running a service-oriented business. They showed me how to take care of people, how to make them feel good and how to read body language. 

    It might be easy to stereotype tech companies as impersonal dispensers of products (and their developers as cogs in the machinery), but we don’t want to just take orders. Our job is to become strategic partners from the ground up for long-term success, and that requires constant care and continual adaptation. 

    Mapping the Client Experience

    We must be willing to redesign how we work with customers and end users over and over again—it’s always changing because expectations are always changing, and market norms are always changing. The moment that we stop trying to get better through small incremental improvements is the moment we stop being service-oriented.

    In the same way that a restaurant has a sequence of service that maps a diner’s journey from the moment they enter the door, we can architect a customer experience from every touchpoint. 

    In the sales process, it’s valuable to layer in different people to create more relationship touchpoints throughout an organization, so, in our case, a new client meets a member of our operations team and then somebody from our engineering team in order to ensure that they feel fully supported. Then, we set expectations in terms of communication as part of a scripted onboarding experience. In our review meetings, we seek feedback to determine whether we have under-delivered and course correct if necessary. 

    The other thing I learned from that Italian restaurant is that no mistake is irredeemable. It doesn’t really matter if you get it right or wrong the first time, it is how you respond when the unexpected happens that matters. Turning a situation around after making a horrible mistake—even sending out a cold steak—can breed even more loyal customers because it demonstrates that you really care.

    The Creative Heart of Service

    Despite the image of tech as cold and distant, it’s important to recognize that coding and development itself is creative and we should seek to nurture a healthy environment so that people can perform at their best. To that end, it makes sense to think of your responsibility as running the entire length of the chain, from employees to clients and, finally, to end users. Finding humanity in the work along each link is key to building successful partnerships. 

    In the context of building products, we must be creative to design seamless, curated experiences for end users. There are plenty of apps that sit on someone’s phone unused before ultimately being deleted. The only way to grab the attention of people that share the same interests and problems is by understanding their needs. 

    To that end, we must always be asking our clients: What is the easiest point of entry for the user? Creating a low barrier is a quick win that in and of itself is an onboarding experience and an opportunity to build trust. 

    Equally, what may make one customer happy may not actually have any resonance in the wider market. If customers were only hiring us to write code, we would only be interested in meeting their expectations. The goal is not just to build products, but successful products that establish or reinforce a client’s reputable presence in the marketplace. 

    Adding Value Through Relationships

    When we stand in our metaphorical corner of the room to observe the customer experience, we are consolidating data from products that have millions of users and harvesting insight. We are not interested in quick fixes. Customer service and a focus on the end-user experience means being oriented to what the market wants, not designing in a vacuum. We can then continue to build value over time.

    In the restaurant business, the little surprise at the end of dinner adds value because it is unexpected. A complimentary after-dinner liqueur with a pithy origin story is a point of detail at its finest. Creating a richer, fuller customer experience can set a tech business apart in an exploding marketplace. For my old mentors, paying attention to every nuance from the beginning to the end is what defines five-star service.

  • Five Great DevOps Job Opportunities

    Five Great DevOps Job Opportunities

    DevOps.com is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted as part of an effort to better serve our audience.

    Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers.

    Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role it tends to create an opportunity for others.

    The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and, naturally, the pay scale being offered.

    We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:

    Indeed.com

    Harnham
    Remote
    Senior DevOps Engineer
    $160,000 to $180,000

    Monster.com

    Riley Consulting Services
    Folsom, CA.
    Senior Full-Stack .Net Developer
    $150,000 to $180,000

    LinkedIn

    Flowhub
    Remote
    Senior DevOps Engineer
    $140,000 to $160,000

    Dice.com

    Northrup Grumman
    Aurora, Col.
    Senior Principal DevOps Engineering Lead
    $120,000 to $180,000

    SimplyHired.com

    OBMedia
    Remote
    Senior DevOps Engineer
    $120,000 to $160,000

  • Low-Code/No-Code Options Key to Bringing Web3 Mainstream

    Low-Code/No-Code Options Key to Bringing Web3 Mainstream

    Driven by cryptocurrencies and NFTs, Web3 is one of the most talked about technology industry waves in the last several years. But even with all the money it’s generated and the media coverage received, Web3 hasn’t yet gained the mainstream acceptance that Web2 has achieved. One of the main reasons for this gap is that blockchain-based technology continues to be complex, requiring developers to learn new languages and development environments as well as gain expertise in concepts like cryptography, hashing, oracles, zero-knowledge proofs, proof of work, proof of stake and more. And even once users understand that they then need to figure out how these pieces all fit together. The required time and money investment has slowed adoption by developers—until now.  

    Web3 is finally coming into its own, thanks in part to the abstraction provided by SDKs and APIs. This technology is making it increasingly possible for all developers, not just Web3 developers, to participate and innovate on this new wave of technology disruption.

    If you look at many of the providers in Web3 like Infura (ConsenSys), NFT Port and OpenSea, for example, and their growth, there’s been a significant movement from these providers over the past couple of years from simply providing nodes for underlying blockchains to now offering higher-level APIs. This translates into developers and companies no longer having to set up their own nodes to provide SDKs and higher-level APIs that rely on data indexers and pre-audited smart contracts to simplify token minting and reading from blockchains. 

    With the evolution of APIs and SDKs, developers using these programs no longer have to learn the intricacies of creating contracts on different blockchains, multiple developer tools, syntax and languages nor must they possess a deep understanding of these different blockchains. Instead, developers can rely on APIs that abstract the underlying complexity, easing the burden for developers who need only pass parameters like chain for indexing, token or smart contract IDs and other general-purpose information. These APIs will evolve into providing more low-code/no-code offerings with larger graphical UI components that developers can simply drag-and-drop to extract value as well as create DApps that can also be retrofitted into their existing applications or app infrastructure. 

    This evolution will be similar to the way the cloud evolved; look at AWS’ and Azure’s infrastructure-as-a-service (IaaS) as a current example. Existing apps could be lifted and shifted onto the cloud. This led to platform-as-a-service (PaaS) offerings with APIs that were cloud-ready; with developers’ latency, security and scalability needs augmented by low-code or no-code offerings. This is also similar to Microsoft’s Power Platform which used drag-and-drop operations on many cloud components, allowing integration and extensibility of the Microsoft platform in a short amount of time. This spawned a new generation of ecosystem players as the bar to participate and innovate in the cloud lowered; now every type of developer, no matter what their area of expertise, can take advantage. This also meant that the new technology was accessible for all developers to solve business challenges more quickly while significantly decreasing time-to-market.  

    You can already see this parallel in the Web3 world. A lot of the key players building developer tools are starting to target the business and technical decision-makers. They are talking about how easy it would be for Web2 developers to leverage their high-level APIs and SDKs (something that Web2 developers understand extremely well) to use Web3 technology to solve new business challenges. And they can do so without setting up expensive innovation organizations and looking for scarce (and expensive) Web3 developers. The next step in this evolution would be to extend these APIs for NFTs, analytics, streaming, MEVs, estimating gas and more to have no-code, automatically generated components that finally allow more Web2 developers to transition to Web3 and, as a result, bring Web3 into the mainstream.

  • Linux 6.0 is Faster, Cooler | Debian Goes Proprietary | Google Africa Region

    Linux 6.0 is Faster, Cooler | Debian Goes Proprietary | Google Africa Region

    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: Linux 6.0 promoted to Stable, Debian 12 will include closed-source binaries, and Google Cloud opens its first Africa region. (more…)

  • How to Prevent Turnover in DevOps Teams

    How to Prevent Turnover in DevOps Teams

    Turnover is all too common in software engineering. The Bureau of Labor Statistics 2021 report found that the average software engineer turnover is 57.3%. It’s a programmer’s market, and these sought-after folks might jump ship for a higher salary, better work-life balance, different team dynamic or perhaps even for a company with a better ESG footprint. Yet, constant changeups in a development team can stifle progress when there’s pressure to meet new digital demands and rapidly deliver new features.

    IT skills shortages can impede innovation across the board. But turnover can be especially problematic in the field of DevOps, as the practice relies on collaboration between teams and a shared sense of operational standards. Here, a gap in shared knowledge can impair ongoing platform maintenance.

    I recently met with Nathan Sutter, global VP of engineering at CoderPad, to examine the core reasons behind engineering turnover and look at specific ways to prevent it in DevOps teams. In a nutshell, he advocated for reducing context switching, giving both engineering and product teams a seat at the table and not underestimating your teammates’ flexibility.

    Reduce Context Switching

    Engineers like having ownership and pride around what they’re creating—take that away, and it can lead to burnout and even an exit from the company. The more you context switch, describes Sutter, the less you focus on building a core project and the less attached you feel to the code or architecture you’re creating. “Engineers like to build cool stuff, ship it, and use it,” he said.

    Context switching may occur for a couple of reasons. First, it may just result from poor planning, in which case engineering time is wasted. Secondly, context switching might arise due to legitimate emergencies, such as incident response or necessary bug fixes. Furthermore, enterprises traditionally ship operational concerns to a production team, thus increasing the number of applications a developer oversees and decreasing their role in ongoing maintenance.

    Instead, Sutter is a proponent of allowing developers to own everything about an application end-to-end. Essentially, the DevOps or infrastructure team builds the scaffolding and the application teams own the rest, such as writing Terraform configurations, Docker containerization, monitoring and alerts, and on-call assistance. In other words, you operate what you build and own the component throughout its entire lifecycle. This practice has already been embraced by full-cycle developers at Netflix.

    Specifically, in DevOps, the on-call cycles can be challenging when you have so many things to own. “When you have 25 apps to look after, something is always going off,” said Sutter. “This is an “exhausting, thankless and horrific way to work.” This imbalance can affect the work-life balance and decrease your time to focus on upgrading core infrastructure.

    Don’t Separate Engineering and Product Teams

    Another setback that might manifest itself in turnover has to do with inefficiencies caused by siloed teams. For example, suppose a product team spends months outlining a complex software design in a black box. In that case, they will most likely encounter many issues once the schematics are finally sent to engineering teams. Without collaboration between the two groups earlier on, organizations can increase time-to-market for new features and encounter frustration between teams.

    Instead, Sutter believes product and engineering teams should counterbalance each other and collaborate more in the product design phase. Whereas product teams can “skate where the puck is going” and identify trends in the market, engineering teams figure out how to technically implement these designs and build a sequence of work that’s scalable for the long-term. Of course, the other side rings true, too—engineers can overplay their hand and plan minute details too far into the future, described Sutter. This underpins a need for ongoing collaboration where both sides have a voice at the table.

    Don’t Underestimate Flexibility

    Even though software engineers like to have a sense of ownership, we shouldn’t discourage flexibility—people easily become bored working on the same thing for years and years. There’s also the fallacy of sunk cost to keep in mind, which states that we tend to value things more because we’ve put more time and effort into them. Thus, providing flexibility to pivot when it makes sense can increase overall satisfaction and output.

    Accordingly, flexible management is also crucial to embrace pivots when they are necessary. For example, if a project is well underway but an engineer identifies a new solution that is more elegant, team leads should be open to recognizing and acting on changes. But to realize this sort of relationship, trust and openness must be bidirectional, said Sutter. If engineers can’t express their ideas or are afraid to tell their boss they’re wrong, these important conversations can’t happen.

    A flexible structure is also necessary to attract talent that prefers more modern work-life balance. As big tech companies with multimillion-dollar commercial leases now want workers to return to physical offices, small-to-medium companies now have an unprecedented upper hand to attract and retain talent if they embrace flexible remote-hybrid working options, added Sutter.

    What Matters Most?

    The majority of developers working on open source projects are open to changing jobs in 2022, according to the EDB Open Source Talent Survey. Job satisfaction is challenging to wrap your head around, and each engineer may be motivated by various reasons.

    But having assembled and led many software engineering teams over the years, Sutter recognized an interesting change in the attitudes of what matters most to software engineers in their day-to-day job. Pre-COVID, software engineers were definitely interested in higher compensation, he said. After that, it was building something they’re proud of, team camaraderie, the worth of a brand name and a positive work-life balance. Post-COVID, compensation and other benefits are still just as valid. Yet, hybrid flexibility is often table-stakes—some are even willing to take a pay cut to obtain these benefits. This underscores the high importance of flexibility in managing modern software engineering teams.

    Executives and engineering leads have their work cut out for them when it comes to obtaining and retaining top talent. Yet interestingly, many roadblocks are not so much technical problems but people and organizational problems. As we’ve covered, reducing context-switching and placing more ownership on singular products could increase satisfaction. One of the tenets of DevOps is also de-siloing teams to increase collaboration. Reducing toil could also go a long way toward increasing satisfaction. Whatever your chosen strategy, it’s always good to “display openness and understanding to hear people when they’re not happy,” said Sutter.

  • Driving Organizational Success With the 2022 State of DevOps Report

    Driving Organizational Success With the 2022 State of DevOps Report

    “Ship it!”

    We have just completed the research and analysis for the 2022 Accelerate State of DevOps Report (SODR) and oh boy, do we have some interesting things to share! First, let me take a short step back for those of you that may be new to the DevOps Research and Assessment (DORA) and our annual report, the SODR. DORA is an academically rigorous research program that seeks to answer the questions, “What practices enable teams to be high-performing software teams? And how do these practices impact organizational performance?”

    Since 2014, we have surveyed 33,000 practitioners around the world spanning all major industries. The project is intentionally–and staunchly–tool- and platform-agnostic. The research builds on itself, and each year we seek to both evaluate previous findings and expand in other directions or areas of research. This is important to note because many of the core findings, such as “software delivery performance drives organizational performance,” have been validated year after year. I would encourage you to go back and read all the reports from years past.

    Security

    This year, we doubled down on our 2021 research into software supply chain security by looking at the technical practices that improve software supply chain security and the non-technical practices that impact an organization’s ability to excel at securing their software supply chains. We leveraged two frameworks to focus our research: Supply Chain Levels for Software Artifacts (SLSA) and NIST’s Secure Software Development Framework (SSDF). Below is a summary of some of our key findings in this area:

    • Shifting left on security is a broadly adopted practice. Our research shows that two-thirds of respondents are actively pursuing software supply chain security by seamlessly baking security into the development process.
    • Culture is the primary driver of security practice adoption. One might expect that technology is the primary driver, but our research showed that a generative organizational culture (eg. performance-oriented, highly cooperative, shared risk) leads to healthier software practices.
    • Technical practices around CI/CD predict success in security. Companies that use source control, continuous integration (CI) and continuous delivery (CD) have more established SLSA practices. These practices shift security left to the developers and ensure consistent security scanning.
    • Cloud enables secure software practices. The five characteristics of cloud computing as defined by NIST enable the successful adoption of software supply chain security which, in turn, predicts greater organizational performance.

    Our research showed that companies who prioritize and excel at securing the software supply chain experienced fewer service outages, anticipate fewer security breaches and demonstrate high levels of both software delivery performance and organizational performance. The data showed that through the use of modern practices like continuous integration, teams can improve their security posture and even amplify the positive impact these security practices have on software delivery metrics (MTTR, deployment frequency, lead time-to-restore service) and overall organizational performance.

    Culture

    We saw above that the biggest predictor of an organization’s application development security practices was the presence of a generative organizational culture based on shared risk and information sharing. We also see that elements of these types of cultures lead to higher overall organizational performance, as well. Our research showed that high organizational performance can be achieved by fostering environments that are:

    • Supportive: Teams that felt supported and that they had buy-in from leadership (e.g., more financial support, more allocation of resources, sponsorships, etc.) were associated with high-performing organizations.
    • Stable: Teams that did not experience much change in membership over the last 12 months were more likely to be a part of high-performing organizations.
    • Flexible: Organizations with higher levels of working flexibility around where work was performed–remote, in-person or hybrid–were higher-performing overall.

    We also looked at burnout again this year and expanded the scope to understand which elements of culture contributed to lower levels of burnout. We found that generative culture, team stability and work flexibility all contributed to a reduction in burnout among employees.

    Reliability

    In previous years, our research told us that those that excelled in technical practices also excelled at organizational performance. This year, we have more nuanced data about this topic. This year, we saw that software delivery does not predict strong business outcomes unless these practices were paired with reliability. Think about it–will a customer be satisfied with new features if the service isn’t stable? What is the benefit of pushing code quickly into a fragile environment? Reliability is an essential component of driving organizational performance through software delivery performance.

    We also see that site reliability engineering’s (SRE’s) impact on organizational performance is non-linear; reliability engineering practices often do not result in additional reliability or organizational performance until a certain maturity is reached. It’s important for teams to know this and approach their SRE practice as an investment. It will likely not be sparkly ponies and unicorns initially as you build the reliability muscle but, as you advance, high performance and success are likely.

    Cloud

    Public cloud use is up a whopping 36% over 2021, whereas companies reporting no cloud usage at all are down by 50%. The use of hybrid cloud is up by 25%. Unsurprisingly, the use of cloud computing was associated with higher organizational performance. In past years we saw that it wasn’t “using cloud” per se that led to organizational performance, rather it was the achievement of the five essential characteristics of cloud computing–on-demand self-service, broad network access, resource pooling, rapid elasticity and measured service. This year, we saw that cloud computing enabled things like reliability, continuous delivery and improved supply chain security which drive organizational success.

    Over 50% of folks who took our survey reported that they leveraged multiple cloud providers. We asked respondents what benefits they realized from using multiple cloud providers. Here are the top three:

    1. Availability
    2. Leveraging the unique benefits of each provider
    3. Trust is spread across multiple providers

    Given the fact that reliability seemed to be the key to being a successful software delivery shop as well as a successful organization, it is not surprising to see availability listed by almost 63% of respondents as a benefit derived from using multiple clouds.

    Summary

    Our research continues to progress and we continue to dig deeper and deeper into the capabilities and practices that impact your business. We see broad adoption on the topics of security and reliability which are both heavily anchored in culture. Good culture leads to success. Period. There is no magic culture button and it takes work, but it is very achievable. Start by defining organization-wide or line-of-business-wide goals and then just start continuously improving. Don’t worry about creating a three-year plan for improvement; create a one-month plan and just get to work instead. At the end of that month, evaluate your learnings, refine your focus and get back to work. With a commitment to hard work and continuous improvement, your investments should start paying off and, as an added bonus, you’ll have a better culture.

    We hope you have enjoyed these juicy findings as much as we have and we encourage you to read the entire 2022 State of DevOps Report.

    Also, please join us at dora.community to continue the discussion about these findings and to share and discuss your experiences on your journey toward excellent software delivery and operations.

  • The Whats and Hows of APIs: A New Developer’s Guide 

    The Whats and Hows of APIs: A New Developer’s Guide 

    For those who are new developers, you may not know a lot about application programming interfaces (APIs). However, it is likely that you’ve used them before as a consumer or an end user, whether purchasing online, using business communication software to reach colleagues or sharing images from a monogram logo maker on social media platforms, for example. It makes knowing about them helpful, regardless of if you plan to make and use one yourself or want to understand how the tools you use work. 

    Although coding and developer tools can be daunting for the outside world, we’ll put APIs into a language that new developers (and even non-developers) can understand. In this guide, we’ll cover what APIs are and the different types that exist. You’ll also learn how they work and how you can use them. By the end, hopefully, you’ll be more comfortable with APIs and know how they impact you and your business.

    What Is an API?

    An application programming interface is a piece of coding used by developers to communicate between different devices, systems, or applications. It allows information to be passed on—allowing procedures to be followed across multiple platforms. Depending on the API, this could be transferring data, images, videos, text, files and other content, or allowing developers to connect through the use of backend-as-a-service (BaaS) to link their apps to the cloud. APIs are often used in a business context and for personal projects or other purposes. 

    Generally, APIs are concerned with the raw information and passing this on to another program rather than the appearance or visual side of these applications. Another set of coding is used instead to build the aesthetic and usability of the interface, while the API tends to be less visible to users. Nonetheless, they form an essential part of our technology stack today, allowing systems to integrate and become more agile, making applications easier for users to navigate.

    Image sourced from developers.facebook.com

    For example, when you refresh your omnichannel communications application, a request is sent to the API to check other linked programs for new messages on your social platforms or calls to your 800 numbers for business. These programs inform the API of new communications and send the appropriate data across. The API returns this data to the application you are using, enabling you to read the messages from here or notify you of no new calls.

    Types of API

    1. Private

    A private API is used internally within a team, created by developers who work for the company or organization. It can help make highly personalized APIs for the needs of your business and adapt the API as and when needed. Private APIs can’t be used or worked on by external developers, as it is purely for your in-house team. These APIs tend to focus on aiding your company’s productivity and project management across multiple applications.

    2. Partner

    Alternatively, partner APIs are used externally with companies that your business collaborates with. Often, this transfers information between businesses, such as within an affiliate scheme or for external postage of online orders. However, APIs can also share and update files such as your release of liability contract or emergency procedure templates. Developers from both companies can improve the API system to effectively share data between partners. 

    3. Open/Public

    Because they are not restricted to usage by specific businesses, open APIs (also known as public APIs) can be used by anyone. You may need a subscription to give you access to the API depending on how frequently you use it, although there are other APIs that are completely free to use. Once you’ve sorted out your access, any software developer can use the API to make changes and transfer information more easily between various software for several purposes. 

    Image sourced from mailchimp.com

    4. Composite

    By taking the responses of multiple programs and streamlining these onto one platform, composite APIs are essential for business and personal use. Or, vice versa, a composite API allows you to make requests of multiple platforms simultaneously. It is helpful for omnichannel management, tracking customer interactions, online faxing and purchases across various platforms. These tend to require little input from developers and are set up for anyone to use.  

    How to Use an API

    • Choose Your API

    As you may have gathered, APIs can be used for several purposes. When choosing your API, look for something relevant to the business that helps you complete the tasks you already do. The software and tools you use may have recommended APIs to try, or there may be APIs that similar businesses use. Do your research to ensure your API performs the right functions and works with your rephrasing tool, calendar software or other add-ons you use. 

    If you’re getting used to APIs, you may want to start with a free option. It means that if it doesn’t work as you hoped, you’ve not lost anything by trying. Many APIs have a free trial period or a free subscription tier with the basic functions, so you can get a feel for the API and decide if it works for your business. When you’re confident in your choice, you can invest in the other subscription tiers that tend to allow for additional users and added functionality.

    • Find Your API Key

    An API key identifies you as the user, authenticating your actions using the API and tracking your usage. It is crucial to have, particularly with subscription-based APIs, as without it you may not be able to perform certain actions, or your users of the API may be limited. Even if your API of choice is free to use and publicly accessible, there still may be an API key to keep your information and preferences stored and linked between your platforms. 

    Image sourced from developers.google.com

    Your API key may be issued as you sign up for the service, so remember this and ensure those in your business who need it can access it. Otherwise, you may need to request or pay for an API key, although this should be clear when you sign up for your chosen API. To increase your API security and avoid your preferences being altered, keep your API key private and limit who has access to it. If your account is hacked, you may need to request a new API key. 

    • Read the Instructions

    It can be easy to overlook the documentation and instructions an API comes with, assuming you’ll get the gist through practicing and by actually using it. Although this may be true to an extent, you could be missing out on useful functions or not using the API as effectively as possible. Likewise, you could get yourself into a mess, not properly setting resource requests and limits, leading to more issues for your business when using the API in the future.

    Set aside time to read the instructions and documents for your API or divide the workload between your management team. You may discover it comes with setup instructions or useful tutorials you can use with the rest of your teams. As you introduce more people to the API, the instructions ensure everyone uses it in the same way. It prevents confusion for your teams and enables them to build their confidence with the API more quickly. 

    • Set Up Your Requests

    Depending on the API, there may be suggested requests for you to set up or you may have to create and code your own. Following the instructions from your API can help with this, allowing your in-house developers to reach their full potential within the API and informing you of the coding structure to use. Nonetheless, there are plenty of tutorials online covering how to set up your API requests without relying on coding expertise.   

    Image sourced from developer.paypal.com

    Just because a request is possible doesn’t mean it’s always relevant to your business. Consider why you’re using an API and what you want it to do once you’ve set up your requests. If you’re new to using APIs, start with a few basic requests and build on these as you gain confidence and experience, using CI/CD best practices to ensure it runs well. It allows you to become familiar with using each request and ensure it works in the way that you intended it.

    Are You Ready to Use APIs?

    As technology progresses and software is developed, having APIs in place is becoming more helpful. Being able to communicate between applications can streamline your virtual receptionist service, incoming video calls and outgoing messages, for example, as well as accelerate cloud-native application development. Having one place to make your requests and display information from multiple platforms gives you more control in managing your tasks.

    If you’re still new to APIs, you don’t have to start using them for everything immediately. Take your time learning to use them for specific functions, getting familiar with them, and enabling your teams to adjust to using them. From this foundation, add new APIs or requests as they’re needed, personalizing them to your business and the tasks you complete. Over time, you’ll gain confidence in using APIs and build a strong network of requests to run your business effectively.