devopsy.kinsta.cloud

Category: DevOps Practice

  • Eradicating Developer Burnout With a Flexible Workforce

    Eradicating Developer Burnout With a Flexible Workforce

    Burnout can affect people no matter what their job role, but software developers are particularly vulnerable. Too often, businesses chase profits by chronically relying on heavy workloads delivered by employees in short turnaround times. Developers often undertake intense work and find themselves pushed to meet deadlines under great pressure over and over again. But without proper care, burnout is almost inevitable. After all, developers are humans first before they are developers.

    Programming is a cognitively stressful job that requires individuals to constantly solve complex problems. Working for hours on end day after day with no break is tough for anyone, and this pattern over a period of weeks is all too familiar for developers. 

    But slowly, the face of the workplace is changing. We are seeing a post-pandemic focus on employee well-being, and the current job market conditions mean that professionals have choices and the right to demand better care or even explore self-employment or non-traditional job paths (thanks, Great Resignation!). In this context, businesses are also thinking differently about how they work with talent to use workers more efficiently.  There is an opportunity here to lower the burnout risk facing developers for the benefit of employees and employers.

    Organizations Can’t Afford Burnout

    Developers are key to most digital transformation projects, so organizations can ill afford for their developer teams to suffer from burnout. This can significantly delay the rollout of new products, features or apps and slow down DevOps initiatives, which can’t progress without the tech teams responsible working consistently and productively. 

    This risk to developers is particularly high in the wake of the pandemic, with technical staff under additional pressure to play catch-up and deliver projects that might have stalled. During this period, there has been little consideration for employee well-being; a 2021 study found that 83% of software developers were experiencing burnout. It’s not just about writing code—technology teams also struggle with inefficient engineering processes, backlog and technical debt  and are more likely to encounter friction when trying to deliver work quickly, leading to a greater risk of burnout. 

    Low quality in-house software is also a point of frustration for development teams, with 83% of engineers reporting being concerned about software reliability in their organisation. Prioritizing the right tools for these teams is one way that businesses can help ensure projects run more smoothly. It’s a simple fix, but one that is frequently overlooked, though empowering technical teams is increasingly top-of-mind for businesses.

    Developers Aren’t Easy to Replace

    Great developers come with years of experience, learning their trade through practical problem-solving. They’ve never been easy to replace, but the state of the current global job market means it is more difficult than ever. This is inherently linked to developer well-being; some are changing jobs and moving to other companies in search of better working conditions while others are creating their own. For example, many are switching to freelance roles to gain independence and control of their own workloads. 

    However, freelancing can be lonely and admin heavy. Despite the improved flexibility, the lack of support can also lead to burnout. Talent clouds offer a potential solution to this through closed communities offering structured work for freelancers and regular interaction with peers. They have seen a surge in membership and have driven wider uptake of self-employment. In fact, 11.2% of developers were freelancing in 2021, up from 9.5% in 2020, as they sought to balance the freedom of freelancing and some of the perks of permanent work. 

    And that’s crucial. For a role that’s considered ‘always on’, the flexibility of freelancing to decide when or where developers work could be crucial to delivering quality, secure code. Without wasting hours a day commuting—that could otherwise be spent working or, crucially, decompressing from their intense workload—it’s been the option of choice for overworked developers all over the world. IT is the foundation on which modern businesses are built—giving the architects of these businesses some of this flexibility is a small price to pay to ensure their well-being. And, as a result, the timely delivery of products, projects, features and apps that accelerate digital transformation initiatives.

    It’s a Two-Way Street

    We’ve already seen how the increased workplace flexibility afforded to freelancers translates into better productivity and lowers the risk of burnout. Equally, 31% of developers worry about unclear goals and processes, so there is also something to be said for improving project management of digital initiatives to ease the burden on technical staff. In fact, 58% of devs feel that burnout is not inevitable, and that better working practices and management are key tools to its prevention.

    For businesses wanting to deliver projects quickly, harnessing on-demand workers from the increasing pool of freelancers means they can engage specialists depending on the type of work or coding language being used, but also that they are fresh to tackle each new challenge—a key concern among developers who have experienced burnout. Doing so via a private talent cloud also ensures that the burden of managing and vetting freelancers is taken away from the organisation and nixing potential concerns about bringing in external talent. 

    Eradicating Burnout

    Well-being is in the public eye more than ever. On one hand, developers should not have to face the high risk of burnout; on the other, businesses can’t afford to lose the talent fuelling their digital future. 

    Both parties can help solve the issue. Developers are taking professional well-being into their own hands by exploring freelance careers that give them flexibility. On their end, businesses need to consider creative ways to access talent. In part, this is about ensuring internal technical teams have the right support in place so they do not become overworked. It’s not easy to find this support in the current job market, but with developers flocking to freelancing, there is an opportunity to rapidly engage highly skilled workers on an on-demand basis at pinch points. After all, a well-managed workload significantly reduces the risk of burnout.

    We have the resources and available skills to eradicate burnout among developers—we just need to arrange them in the right way. 

  • 5 Best Practices for Software Development in the Hybrid Workplace 

    5 Best Practices for Software Development in the Hybrid Workplace 

    Over the years, software teams have gradually become more dispersed as technology advancements facilitated hybrid work and allowed teams to collaborate, create and innovate remotely. However, this trend accelerated and became more of a mainstream norm over the last two years during the COVID-19 pandemic, requiring newly dispersed teams to develop a more streamlined hybrid approach to the development process. 

    When seeking to implement a hybrid environment, it’s important for development leaders to consider how best to coordinate a distributed workforce across time zones, how to track projects effectively and ensure accountability. At Lenovo, these are considerations the Cloud & Software team has had to navigate since its inception due to the global nature of our business. To be effective in a hybrid environment, we adopted certain processes and tools that facilitated open communication and cross-collaboration no matter the location. After evaluating various hybrid methods, here are five best practices that stand out. 

    1. Adapt the development process to suit a hybrid setting

    In a hybrid work environment, it can be challenging to consistently bring the entire team together at a specific point in time to estimate work, refine issues or plan sprints. Coordinating between busy calendars and multiple time zones is an inefficient use of time, especially when many software projects are deadline-driven. Moreover, many developers are highly creative and want fewer coordinated meetings and more time to contribute when they want, at their own pace.

    To navigate these challenges, program managers can adapt the development process to be less regimented and more flexible. Facilitating such events as estimation, sprint planning and backlog refinement in an asynchronous manner within a virtual team workspace can allow all team members, no matter where they are located, to contribute, feel heard and seen and receive feedback from their teammates. Such programs can also enable an automatic way to log decisions and house required software documentation.

    2. Establish a single source (or tool) of truth

    Many organizations relate to the challenge of having project data spread across multiple tools. While the development team tracks day-to-day work in one tool, other stakeholders are tracking goals and team KPIs in an entirely different set of tools which can lead to misalignment, something that can be exacerbated in a hybrid environment.

    To overcome this challenge, development teams can establish one central location using a work management tool where past, current and future projects live and that all team members can access, reference and share. By leveraging this tool as a single source of truth, team managers can bring visibility and transparency to the development and program management processes while creating stronger alignment.

    3. Enable full transparency in decision making

    Our team at Lenovo follows a strict process of documenting the decisions taken throughout the development process and we make that documentation available for all team members to access within the team workspace. 

    This can be a beneficial practice for project managers that want to strengthen accountability. Encouraging such transparency enables team members and stakeholders to reference the reasoning behind a specific decision, especially if concerns arise later in the project life cycle process. The result is better alignment across the organization.

    4. Establish a facilitator for each ritual

    To maintain a healthy hybrid environment, assigning an owner to each Agile event can make all the difference. By serving as a facilitator, that owner would then be responsible for aligning everyone to a pre-meeting agenda and goal, allowing teams to prepare and review issues and tickets ahead of time. This added organizational step can result in a more streamlined meeting cadence and more productive discussions.

    5. Automate and leverage efficient tools

    Finding the right combination of tools to support a team’s specific collaboration needs is imperative to a successful hybrid development environment. Seamless and automated collaboration is the key, but there is no one-size-fits-all solution mix. Development leaders should consider tailoring their portfolio of tools around specific needs and look for programs that can help keep a dispersed team on track and synchronized (via direct messaging, ongoing team conversation chats or face-to-face virtual meetings, for example), as well as those that can ensure visibility and improve efficiencies. Whatever external programs are selected, however, should be hosted internally behind the company firewall and VPN for added security. 

    The modern workplace has changed dramatically in the last two years—in many ways permanently—with flexible, remote and hybrid work driving the greatest transformation of collaboration for software development teams across all sectors. By adapting to new hybrid development strategies, enabling transparency in decision-making and leveraging automation for greater efficiency, the development teams of today and tomorrow will be well equipped to more easily adapt to future disruptions in the workplace. 

  • GitGuardian Tightens Integration With GitHub to Secure Secrets

    GitGuardian Tightens Integration With GitHub to Secure Secrets

    GitGuardian has expanded its ability to secure code repositories by providing deeper integration with GitHub.

    Ziad Ghalleb, product marketing manager for GitGuardian, said the results of security scans are now provided in the context of pull requests alongside suggestions for remediating issues.

    The company also expanded developer onboarding options by adding an application programming interface (API) key provisioning mechanism integrated with its command line interface (CLI) in addition to making it easier to configure that CLI.

    Finally, GitGuardian extended support for role-based access controls (RBAC) to its platform so that team members can be assigned different permissions levels for incidents based on their role.

    GitGuardian makes it possible to scan source code to detect API keys, passwords, certificates, encryption keys and other sensitive data in a code repository in real-time. Developers building an application often make secrets easily accessible as plain text for the sake of convenience. However, when those applications are deployed in a production environment, developers often forget to delete these secrets. Cybercriminals know to scan for these secrets to make compromising an application environment easier.

    A recent GitGuardian report found a typical company with 400 developers would discover 1,050 unique hardcoded secrets when scanning its entire codebase. Each secret had 13 different occurrences, which meant the effort required to remediate those associated vulnerabilities would be considerable, the report noted.

    Secrets management is, of course, getting more attention as more organizations review their software supply chain processes in the wake of a series of high-profile security breaches. GitGuardian makes it simpler to achieve that goal within the context of a set of DevSecOps best practices by integrating with GitHub with a single click, said Ghalleb.

    It’s still early days as far as adoption of DevSecOps best practices is concerned, but it’s clear more responsibility for application security is being shifted left toward developers. The challenge is many developers still lack the tools required to make sure applications are secure before they are deployed in production environments.

    Naturally, the earlier an application security issue is resolved the less costly it is to fix. The problem with secrets management is cybersecurity teams are usually a lot more focused on discovering vulnerabilities than looking for instances of poorly secured credentials. Once an application is deployed in a production environment, it may be months before anyone discovers there is an issue—if it’s discovered at all. In fact, the number of existing applications running in production environments that have secrets management issues could be staggering.

    One way or another, it’s only a matter of time before more of those issues are surfaced. In the meantime, DevOps teams can reduce the number of applications that might have this issue by making it easier to discover secrets within applications before they are deployed in production environments. After all, the only thing worse than a secret being discovered by a cybersecurity team is having one uncovered by cybercriminals that use it to wreak havoc.

  • The Quest To Unify With GraphQL, The Modern Data API

    The Quest To Unify With GraphQL, The Modern Data API

    There is an ongoing trend in enterprise software: Using GraphQL as an aggregation layer to unify access to underlying data sources and REST APIs. Some call this the supergraph, and others refer to it as a meta layer. The idea is that by providing a more consumable layer to a wide range of internal sources, frontend developers are better equipped to access whatever data they need when constructing applications. But the quest to unify all data sources into a single schema doesn’t come without its share of trials.

    GraphQL adoption is steadily increasing, with significant large enterprises making up some of the early adopters. For example, Netflix engineers recently shared how one approach gaining traction is “GraphQL microservices (GQLMS) as a backend platform facilitating rapid application development.” As the use of GraphQL increases across a large enterprise, though, scalability and security hurdles present themselves. These include retaining proper authorization throughout multiple layers and mitigating the risks of an inherently open schema.

    I recently met with Hasura CEO Tanmai Gopal to discuss why GraphQL should be used as a middleware element to access and expose underlying datasets and APIs. According to Gopal, GraphQL is becoming the data API for modern applications—this could be a massive positive shift. However, the potential downside is around the time involved in integration. Thus, the key will be automating the integration of data sources so that developers and DevOps teams can focus on the apps and services they’re building instead of maintaining the data model itself.

    The Underlying Issue: Data Access

    “Data access is a bottleneck,” said Gopal. “It needs to be self-service.”

    On one side, there are data producers, such as databases, internal services and external SaaS services. On the other side, there are the clients that consume this data, such as mobile apps, web apps, microservices and APIs externalized for third-party developers.

    The problem, according to Gopal, is that the link between both sides is increasingly challenging to implement. It takes time to integrate with HTTP-based APIs and parse JSON payloads. The exchange protocols are dissimilar and you must solve for performance issues, caching and concurrency in data access. What’s more, the authorization context must be maintained for all data sources. These issues are exacerbated since not all developers are accustomed to the nuances of maintaining integrations.

    Frontend developers want to communicate with a centralized data store, but also need to mix and match various sources. At this point, Gopal explained, a data access layer is necessary to handle the communication between both sides. Such a layer requires some integration automation to truly get APIs to developers at the edge. And it also requires a simple, unified schema—this is where GraphQL comes in.

    Solution: A GraphQL-Based Data API

    “GraphQL is an absolutely delightful API to consume,” said Rajoshi Ghosh, co-founder of Hasura. “Using GraphQL as a data API can remove a lot of requirements of legacy knowledge of integration systems and how to securely fetch data.”

    The concept involves using GraphQL as an intermediary data API—this would consume all sources, whether they are RESTful APIs, GraphQL services, an Amazon Aurora database or a PostgresSQL-style database—and unify them in a more accessible, pleasing construct. To create a unified API over these disparate sources, a middleware solution must map API resources to logical models and methods and add authorization rules to logical models, explained Gopal.

    Although GraphQL enables developer agility, it’s the part in the middle that’s difficult to assemble. Building these connectors from scratch requires a lot of relearning and tedium to maintain, Ghosh said. And to truly cater to all data sources, organizations will likely need to craft custom plugins for legacy sources, he added.

    Solving Unified Graph Problems

    Data-driven initiatives are a common technology goal, but the breadth of data sources is rising. GraphQL can play an important role in uniting these sources and providing flexibility for frontend developers to call precisely what they need. A unified graph is thus a boon for developer experience but will be challenging to set up from scratch.

    Arguably, authorization is the biggest challenge when approaching GraphQL as an aggregation layer for multiple APIs. Any system that unifies multiple backend APIs must ensure that only the person with the correct permissions can access underlying data. A unified GraphQL layer must retain granular permissions that are endpoint-centric and unique to the specific caller.

    “Most enterprises don’t have a good authorization story,” Gopal said. Implementing authorization for data APIs is hard, Gopal said, as it’s unlike REST where the user ID can literally be specified within the URL request. These kinds of fine-grained attribute level entitlements must be recreated as a policy engine and applied to the graph API as well. For example, Hasura implements authorization by using a token that scopes the entire experience to the particular user.

    The Future of Unified API Strategies

    Looking to the future of this area, Ghosh noted that frontend stacks are becoming more robust and code in the backend is essentially becoming business logic deployed as serverless functions. And in this new reality of increasing abstractions, the role of modeling experts will likely become more important.

    Furthermore, GraphQL must go beyond read-only capabilities to embrace another trend—real-time. Although most GraphQL APIs retrieve persistent data, GraphQL-based data brokers must also evolve to implement streaming, said Gopal, as real-time data and event-based subscriptions are becoming more common.

    Today, you probably don’t need to unify all your sources into a unified data model all at once. This activity will likely be relegated to particular business domains or products to help them accelerate and demonstrate a proof-of-concept. But in the coming years, there will be mounting pressure to adopt a unified approach, Gopal said. “In a few years, if you don’t have a unified API strategy, you’ll have a massive problem.”

  • This DevSecOps Thing Is Real After All

    This DevSecOps Thing Is Real After All

    Whether you made it to San Francisco, California last month for RSA Conference or not, you don’t want to miss Tuesday’s DevOps Connect: DevSecOps Virtual Summit.

    On Tuesday, July 12, 2022, we are presenting a virtual broadcast of the sessions from our recent DevOps Connect: DevSecOps event at RSA Conference in June 2022. All of the great sessions will be available as well as some bonus sessions that didn’t make it to RSAC.  

    For me, this event was extremely gratifying because it served as validation that I wasn’t crazy all those years ago. When I started DevOps.com in 2014, I did so because I thought it would be great for security—back then it felt as though I was a lone voice crying out in the wilderness! Now, here we are in 2022 and DevSecOps is real. It is accepted, it is sought-after and it is changing the way software is developed, deployed and managed.

    When I put on the first DevSecOps event at RSA Conference seven years ago, it was a bit controversial. The idea of bringing together the security community with the DevOps tribe was like what I imagine peace treaty negotiations between two warring parties would be. The security folks said no one else cared about security. The DevOps people, like many other IT pros, claimed the security folks were just people who said no to all their initiatives. The lack of trust ran deep. But we kept at it—and while the situation is far from perfect today, so much progress has been made.

    This year’s event featured our best speaker lineup yet. Jim Zemlin, executive director of The Linux Foundation, kicked off the event by talking about open source and security—software supply chain, SBOMs and security, oh my!  Continuing the open source and security trend, CNCF executive director Priyanka Sharma presented a great session discussing cloud-native and DevSecOps.

    And you won’t want to miss two of my favorite sessions. The first involves my friend John Willis asking, “What would Deming do?” in his session at 11:30 a.m. ET. Given the current state of world affairs and the software and security market, what would Edward Deming, the patron saint of DevOps, say and do? John is a bit of a Deming expert himself, so his insights are spot on, I think. And second, Carolyn Wong (who is a superstar) talks at 12:00 p.m. ET in her session about pentesting at scale, pentesting-as-a-service and DevSecOps.

    But wait—there’s more! Chenxi Wang has a powerful session, delivered off the cuff, about the current state of DevSecOps, software supply chain security, investing and more; that’s at 9:55 a.m. ET.

    We’ll also feature two amazing panels: One is made up of the authors of a recent book, Reinventing Cybersecurity. The other features folks from Intel, Mitre, NIST and the U.S. Senate talking about security compliance with an emphasis on software supply chain security and SBOMs (see a pattern here yet?).

    And that’s just the tip of the iceberg—there is even more from this year’s event that you don’t want to miss. So, head on over and register—it’s free. Many of the speakers will be online, live, during their presentations to answer questions, network and offer their guidance. There are also exhibits and sponsor booths and other fun stuff like a yoga class and a DJ spinning great tunes.

    This DevSecOps stuff is real and you will learn a lot from these sessions. We can’t wait to see you there!

    While you’re at it, check out our upcoming CloudNativeDay Virtual Summit August 10, 2022, which is shaping up to be a great event, as well!

  • BMC Adds Support for DORA Metrics to Mainframe Tools Portfolio

    BMC Adds Support for DORA Metrics to Mainframe Tools Portfolio

    BMC this week announced it has added support for DevOps Research and Assessment (DORA) metrics within its portfolio of DevOps tools for mainframe environments.

    John McKenny, senior vice president and general manager for intelligent Z optimization and transformation at BMC, said the latest edition of BMC Compuware zAdviser now includes a DORA KPI Dashboard that aligns with the widely-adopted framework for measuring DevOps efficiency defined by an arm of Google.

    The DORA metrics track deployment frequency, failure rate, lead time for changes and mean-time-to-recovery (MTTR). Tracking those metrics is crucial for IT teams that have mainframes because they need to make sure applications continue to be deployed on the platform versus being usurped by another platform that is perceived to provide a faster alternative for builds and deployment, noted McKenny.

    BMC also added support for automated webhook notifications to its BMC Compuware Abend-AID offering. That includes diagnostic and root cause analysis to resolve defects in test and production faster. In addition, BMC provides a connector to the machine-identity management platform created by Venafi. That integration promises to eliminate certificate-related outages that can derail an application development initiative.

    In general, DORA metrics are being used to identify areas where DevOps teams can improve. It is up to each organization to determine to what degree those metrics will be used to coach teams versus enforce productivity mandates. However, given the overall shortage of available DevOps talent, few organizations are employing metrics to force DevOps teams to improve. In fact, there is no universal set of DevOps goals that every organization is trying to achieve. Rather, most organizations are trying to determine what set of DevOps best practices makes the most sense to implement given their own goals and internal culture. In the case of the mainframe, most organizations start with a few projects before they begin to employ DevOps more widely, noted McKenny.

    The metrics defined by DORA framework are, of course, only a subset of the total metrics that DevOps teams should track. BMC, for example, makes it possible to track tools usage to provide DevOps teams with insights into what tools may no longer be relevant or required, noted McKenny.

    Mainframe environments also have a long history of using waterfall-based approaches to building and deploying applications that many of them will continue to use alongside DevOps practices, depending on the type of application being built and deployed. In other instances, distributed applications built using DevOps practices are being integrated with mainframe applications that now need to be updated using the same workflow. The mainframe is no longer a platform that is managed in complete isolation from distributed computing environments.

    The major challenge is that many organizations using mainframes often overestimate how difficult it is to adopt DevOps  best practices, McKenny said. Regardless of the platform, there is no doubt the overall rate at which all applications are being built and deployed will continue to increase. The mainframe is proving to be no exception to that rule.

  • ERP Modernization: How Devs Can Help Companies Innovate 

    ERP Modernization: How Devs Can Help Companies Innovate 

    In this post-pandemic world, large enterprises are looking to streamline and improve business processes within a storm of marketplace constraints. Companies in asset-heavy industries such as oil and gas, energy, retail, or distribution and logistics have especially been working to reconfigure their supply chain processes to better manage inventory and operations. The focus in the market has shifted from supply chain optimization to supply chain resiliency, creating efficiencies that will help them best survive current delays and rising costs. 

    Breaking Barriers and Addressing the Talent Shortage

    The question is not simply whether companies need to modernize their business applications to increase efficiency and lower costs, but how to accomplish a necessary modernization in the midst of barriers like rising costs, supply chain disruptions and a severe shortage of developer talent. Developers and DevOps teams need to find ways to do more with less.

    The reimagining of business processes is an excellent strategy to reduce overhead and allow companies to become nimbler and more efficient, consequently helping them preserve or improve marketshare. Many large enterprises work in environments that use enterprise resource planning (ERP) software; systems that, over the years, have been subject to ongoing upgrades, patches and redesigns by developers and IT managers. This creates technical debt, which makes it difficult for many of these large-scale companies to migrate their business applications to cloud-based systems.

    Many of these ERP-based companies are facing pressure to update to more modern, cloud-based versions of their ERP platforms. But they must run a gauntlet to modernize their legacy applications. In a sense, companies that maintain these complex ERP-based systems find the environments are like “golden handcuffs.” They have become so complicated over time that they restrain IT departments’ innovation efforts, hindering their ability to create supply chain resiliency when it is most needed.

    To make matters more difficult, the current market is facing a global shortage of human resources required to get the job of digital transformation and application modernization done, including skilled ERP developers—especially those skilled in more antiquated languages like ABAP. Incoming developer talent is often trained in more contemporary languages like Java, Steampunk and Python. These graduates have their pick of opportunities and gravitate to companies that already work in these newer programming environments. 

    ERP migrations can be hampered by complex, customized systems developed by high-priced, silo-skilled programmers. Many enterprise leaders have a great desire to break out of these restrictions and modernize legacy applications with greater speed and at lower cost, and they need to do so with minimal downtime and disruption. 

    Leverage Low-Code Solutions to Modernize

    In a 2022 report on application development strategies, industry analyst Deepa Salem interviewed enterprise companies that used sophisticated SAP-based ERP solutions about their approach to software modernization strategies. More than 80% of respondents said they planned to upgrade their business applications in conjunction with a major migration of their ERP software platform to the latest, cloud-based version. 

    This tactic of implementing a new applications strategy in coordination with a major refresh is not surprising and presents an opportunity for developers to help these companies “clean house,” reducing the technical debt of their legacy environments at this well-timed juncture.  

    As an analogy, think about how people typically move to a new residence. Homeowners sift through their accumulated possessions and identify what’s no longer needed. They pack what is still valuable and essential. A low-code application process can help clean up existing ERP environments prior to migration, reducing complexity and long-accumulated technical debt while leveraging the system’s unique business intelligence. The tribal knowledge inherent in any legacy system is critical to retaining market differentiation. 

    With so much at stake, IT departments and developers should give serious consideration to using pre-built, customizable business applications, efficiently and rapidly created through a low-code development process. Deployment-ready solutions can help developers move forward with modernization projects that have been hampered or shelved due to a lack of talent to implement those jobs. They can accomplish more with less.

    With the right approach, ERP-based environments can be reconfigured to quickly establish more agile, streamlined and cost-effective business applications. Developers have a unique opportunity to help enterprises keep what sets them apart from the competition and surrender what no longer serves them. In this climate, this is not a nicety for enterprise customers. It’s about resilience—and even survival.

  • DevOps Is Not a Role — It’s a Culture

    DevOps Is Not a Role — It’s a Culture

    The full-stack developer is becoming increasingly rare these days. Due to the accelerating complexity of modern software development, programmers often specialize in specific languages, frameworks or levels of the software stack, such as frontend or backend.

    These same fractures seem to be occurring within DevOps, too. Nowadays, large companies no longer have one strain of DevOps—there are often many flavors of rapid deployment and various DevOps toolchains used across an organization’s development teams. DevOps now requires specific training in the nuances of each cloud service provider’s platforms, too, requiring specialists trained on individual cloud platforms, like AWS, Azure or GCP. The role is expanding and taking on new forms, with platform engineering and site reliability engineering coming of age.

    Therefore, companies should be viewing DevOps not so much as one specific role or a set of tools, but as a culture. I recently met with Sashank Purighalla, CEO and founder of BOS Framework, to gather insights into the evolving role and culture of DevOps. According to Purighalla, “DevOps is a combination of culture, practices, processes and tools.” Below, we’ll identify the challenges that come with introducing DevOps and consider the right blend of technology, human specialists and governance required to get the job done.

    The Challenges of Implementing DevOps

    One challenge of implementing DevOps is simply defining the position itself. “DevOps is not really a job,” Purighalla explained. Instead, it encompasses many aspects, such as CI/CD, provisioning, maintenance, and compliance, all of which now adopt a plethora of different tools. There is also overlap between CloudOps and DevOps, an ambiguity that makes it tricky to write a job description for a DevOps engineer.

    Various roles make up the teams responsible for modern cloud-native operations. In the same way that programmers have particular specialties, DevOps has specialized areas too. This segmentation might be based on the cloud vendor suite or the tools in use, such as familiarity with Jenkins, Docker or Kubernetes. Particular domains, such as DevSecOps or BizDevOps, may require dedicated focus as well. Purighalla shared some example roles that often exist in a modern CloudOps team:

    • Cloud architect
    • App architect
    • Security expert
    • Compliance expert
    • DevOps engineer for AWS
    • DevOps engineer for Azure
    • SRE for AWS
    • SRE for Azure

    Complicating things further, DevOps can transcend cloud-based systems and be applied to on-premises or edge network maintenance. Given the many possibilities, crafting a job description for a DevOps position requires “awareness of and vision for how you want to build the DevOps function in your organization,” said Purighalla. Unfortunately, most people don’t have a clear picture of where to begin, he said. Setting this roadmap will vary from sector to sector and require intimate knowledge of and context about the company and its technological assets.

    DevOps Shouldn’t Create Another Wall

    DevOps is a mechanism to deliver high-quality code more quickly—this business outcome has been the guiding principle since its origin. To get there, DevOps sought to place development and operations ‘in the same room’ to reduce friction. Yet, in some organizations, DevOps emerged as an entirely new role on an org chart. “In certain cases, it created a wall,” says Purighalla. “Developers can’t think beyond when they hand off code to the infrastructure team.”

    If this wall stays in place, it could further divide team motivations. Of course, building a healthy DevOps culture will vary from company to company and will require clarity about the end goal. But creating common incentives could include shifting left some security and provisioning responsibilities so developers have more perspective and can participate in DevOps.

    Another reason to embrace a DevOps culture is simply the talent scarcity in this arena. This is a problem facing businesses of all sizes. Startups may not be large enough to hire a DevOps or site reliability engineer, but are beginning to see the necessity of greater focus on reliability and compliance as a core business function, says Purighalla. Enterprises typically have multiple clouds and hybrid environments, which are challenging to find talent to support. Middle-market companies often lose out to the attractiveness of startups and the big bucks of large corporations.

    Outsourcing DevOps: Is It Ever a Viable Option?

    So, given that it is so challenging to find engineers, is outsourcing DevOps ever a viable option? According to Purighalla, “outsourcing is a good option if your company has pre-built solutions for clouds and if it’s able to give you similar capabilities without requiring ground-up custom work.” A cloud enablement solution could be used to reduce the barrier to entry but is never a replacement for an entire DevOps practice.

    The reason is that software programming is a creative engineering process. “I’ve never found an engineer that does the same thing every time.” People continue to experiment with a ‘build and fix’ mindset. This means that, in general, hiring external engineers is tricky as they don’t have intimate knowledge of the system at hand.

    Furthermore, a platform that applies a standard way of working with multiple cloud providers must be flexible and open to change, as backend infrastructure is constantly evolving. As such, DevOps must be viewed as something that’s much more continual and requires ongoing maintenance. It’s not something you can outsource once and be done with.

    “It’s becoming like accounting—you’ll fail an audit if you don’t do it,” said Purighalla. “Outsourcing needs to be viewed that way. You need to bring in a cloud enablement solution in combination with experts. You can’t have one or the other.”

    DevOps: Not Just a Role or Toolset

    Many assume that DevOps is just a set of tools. Instead, some experts argue that DevOps is more of a combination of varying roles, tools and processes. “DevOps started as a model—it’s not a tool,” Purighalla reiterated.

    In essence, it’s more of a culture than a specific job title. And when viewed this way, organizations can begin to eliminate silos, which DevOps ought to eradicate in the first place. With the right technology and collaborative spirit, a company can create a culture that meets the goals of efficiency that DevOps aims to achieve.

  • Dev Job Phisher Steals $540M | Patch OpenSSL NOW | Systemd Dev Joins Microsoft

    Dev Job Phisher Steals $540M | Patch OpenSSL NOW | Systemd Dev Joins Microsoft

    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: Spear-phishing causes $540 million loss, a high severity bug in OpenSSL might be “worse than Heartbleed,” and Lennart Poettering is now working for Microsoft. (more…)

  • Applying Automation to DevOps

    Applying Automation to DevOps

    In the book, “Life and the Art of Engineering,” author Haresh Sippy said, “Automation is cost-cutting by tightening the corners, not cutting them.” Today, businesses and organizations are constantly on the lookout for ways to improve productivity while reducing inefficiencies across their operations. Automation has emerged as the natural answer as it addresses these issues while enabling organizations to scale their operations.

    And this is a natural fit with DevOps, which aims to automate and streamline and accelerate the development process from code generation to application performance monitoring. Automation promises better results, greater efficiency and reduction or elimination of errors, but many organizations remain hesitant to deploy it in critical operational areas.

    But there are many benefits to DevOps automation that organizations shouldn’t ignore:

    • Consistency: The most crucial benefit of DevOps automation is consistency. The absence of human effort can remove errors because automation tools repeat processes in the same way, ensuring the development environment remains of consistently high quality.
    • Scalability: DevOps automation not only allows new code to be released quickly but in larger quantities, as well. Automation also allows teams to deliver multiple projects in multiple environments simultaneously, reducing manual processes.
    • Speed: One of the first visible benefits DevOps automation will bring to the table is the sheer speed of the product delivery process. DevOps automation streamlines the configuration process, the development environment and other aspects of deploying new software, making the process significantly faster. With DevOps automation, software delivery becomes less dependent on people. 
    • Flexibility: Flexibility can often be an overlooked aspect of automation. However, with DevOps automation, organizations can change and modify critical code based on new requirements and deploy these changes in real-time, rather than having to train the team to manage the operations based on the new changes. 

    Critical DevOps Automation Processes

    Once an organization is aware of the benefits, the obvious next step is to figure out which processes to automate. 

    While a core tenet of DevOps is to automate everything logically possible, that is a long-term goal. On a more immediate basis, organizations would be well-advised to focus on automating a few critical standard processes. 

    This will allow for a smoother transition as well as more efficient results. But the question of which exact processes to automate is a subjective decision that will depend on each organization’s unique needs and technological requirements. However, some fundamental areas that may benefit from DevOps automation in any organization include the following:

    • Software Testing: Any organization with a digital service or product to offer spends considerable time and human resources testing the new offering or updates before rolling them out. Naturally, automating the testing process would bring greater efficiency to the test results while significantly reducing any errors, especially human errors. Additional tests that may be automated include unit tests, smoke tests and UI tests. 
    • Monitoring: Most organizations understand how important it is to adopt a proactive approach to monitoring. A key aspect of DevOps is consistently reading, recording and maintaining crucial data from regular monitoring. By automating this process, organizations can further increase the extraction of valuable B2B data and insights while ensuring greater security against possible breaches and data theft. 
    • Infrastructure: Infrastructure management is a critical area that serves a vital role in ensuring things run smoothly. This includes networks or servers that are consistently in need of maintenance, configuration modifications and initial setups. By deploying an automated infrastructure, organizations can increase efficiency while freeing up valuable human resources to be deployed elsewhere. 
    • Continuous Integration/Continuous Delivery (CI/CD): CI/CD’s entire purpose is fast application development and delivery. By its very nature, this task is ripe for automation as it requires testing and monitoring every little change or modification. Similarly, automating the deployment phase of CI/CD would ensure the distribution of successful updates is carried out proactively the very second it is ready. As a result, organizations will see updates being rolled out more efficiently with minimal errors or bugs in the final updates.