devopsy.kinsta.cloud

Category: Features

  • Styra Unfurls Cloud Service for Implementing Compliance-as-Code

    Styra Unfurls Cloud Service for Implementing Compliance-as-Code

    Styra, Inc. today launched an authorization service based on the Open Policy Agent (OPA) software that can be invoked via an application programming interface (API).

    Torin Sandall, vice president of open source for Styra, said the Styra Run cloud service will make it much simpler to embed enterprise-grade authorization capabilities within applications. Today, developers spend too much time building, maintaining and operating their own authorization platforms to manage permissions across multiple applications.

    In addition to enabling developers to access pre-built OPA logic, Sandall noted the service also offloads storage and global replication of end-user permissions data to a cloud service.

    The service itself currently runs on Amazon Web Services (AWS), but Styra plans to make the service available on other cloud platforms in the future, he added.

    OPA makes use of a general-purpose policy enforcement engine that developers can embed within applications using the Rego language. OPA is now being advanced under the auspices of the Cloud Native Computing Foundation (CNCF) and is gaining traction among cloud-native application developers. OPA provides a means to enforce compliance-as-code across a wide range of microservices that now routinely access a wide range of distributed data.

    However, Styra Run should make OPA more accessible to a wider range of organizations, especially those that are looking to shift responsibility for security and compliance further left toward developers as part of a set of DevSecOps processes, noted Sandall. Developers that don’t have a lot of compliance expertise can now rely on a cloud service that enables them to focus more of their time and effort on writing code, he added.

    The arrival of Styra Run also comes at a time when more organizations are reviewing their software supply chain processes in the wake of a series of high-profile security breaches. It’s not clear to what degree compliance and cybersecurity teams have developed an appreciation for OPA, but as more organizations embrace compliance-as-code, the pressure on those teams should decrease as those applications are inherently more secure than legacy applications.

    There will, of course, be some developers that prefer to embed OPA into applications themselves, but a cloud service accessed via API will be the path of least resistance for most developers building software-as-a-service (SaaS) applications, said Sandall. The issue may simply be making developers aware that another low-latency option exists; one that doesn’t require them to deeply master the Rego programming language for the sole purpose of achieving compliance, he added.

    Regardless of approach, the general expectation going forward is that applications will more easily be able to meet a wide range of compliance mandates without requiring IT teams to deploy and maintain dedicated compliance infrastructure. As such, there may soon come a day when any application that doesn’t use some type of compliance-as-code framework will simply be rejected out of hand.

  • CodeLogic Toolkit Increases Visibility Into App Dependencies

    CodeLogic Toolkit Increases Visibility Into App Dependencies

    CodeLogic launched today a toolkit that enables developers to scan binaries, runtime application behavior and database connections and then leverage graph technology to identify connections and dependencies in real-time.

    Brian Pierce, CodeLogic CEO, said the goal is to make it simpler for developers to identify the relationship between application elements to increase overall productivity and simplify the addition of new members to an application development project.

    In general, most developers add code to applications without really having much visibility into how that code might impact other components. The toolkit created by CodeLogic is an extension of the company’s existing continuous software intelligence (CSI) platform that employs server software to store and process data collected via its agent software. The goal is to make it easier for developers to directly consume those insights via a toolkit they can access directly from within, for example, an integrated development environment (IDE), said Pierce.

    As applications become more complex in the age of microservices, it becomes more challenging to understand all the dependencies between application components. Developers require greater visibility into applications to better manage the break/fix process that inevitably occurs when new code is added to any environment. The CodeLogic CSI platform provides an automated impact score for methods, classes and the overall health of an application as code is developed to provide that visibility.

    That information also plays a critical role in enabling IT teams to understand the implications any newly discovered vulnerability might have on the application environment, added Pierce.

    Overall, the level of technical debt that organizations accumulate over time saps developer productivity, he noted. The more difficult it becomes to add code to an application environment the less likely it is that developers will enthusiastically make the effort, said Pierce. Before too long, the number of updates made to an application environment starts to decline, he noted.

    Developer productivity has become a major issue simply because the number of applications that organizations now want to build and deploy is exceeding the financial resources they have available to hire or contract developers. The more time developers spend studying how an application has been constructed the less time there is to write code and drive innovation. In fact, the more frustrating it becomes to add code the more likely it becomes developers will move on to a company with much less friction involved in building and deploying applications, said Pierce.

    There are many senior IT leaders that also need visibility into application environments before approving projects. Many IT teams discover that there are multiple projects or other teams writing duplicate code or replicating existing functions. Regardless of the reason, more developers are voting with their feet when they feel their time and effort is not fully appreciated.

  • Rezilion Launches Vulnerability Prioritization Platform

    Rezilion Launches Vulnerability Prioritization Platform

    Rezilion today announced general availability of a platform that enables DevOps teams to better prioritize remediation efforts by identifying which vulnerabilities both run in memory and actually impact a class or function that can be executed.

    Liran Tancman, Rezilion CEO, said the biggest DevSecOps challenge organizations face today is that the bulk of vulnerabilities that developers are tasked with remediating don’t constitute a significant cybersecurity threat.

    Rezilion has created a searchable proprietary next-generation vulnerability database (NGVDB) that identifies which issues impact specific classes and functions. That capability enables DevOps teams to de-prioritize close to 95% of software vulnerabilities, said Tancman.

    In addition, the Rezilion platform will surface remediation suggestions that lower the amount of disruption and/or cost, he said. A fully-automated remediation capability, for example, will automatically upgrade and test vulnerable software components and packages within a continuous integration (CI) pipeline that were found to be exploitable. In the longer term, Rezilion is also working toward surfacing remediation suggestions that might be addressed using an alternative to patching, said Tancman.

    The Rezlion platform is also integrated with IT service management platforms such as ServiceNow and project management tools such as Jira to make it easier to address vulnerabilities as part of existing workflows, he added.

    Most developers today are simply overwhelmed by the number of vulnerabilities that cybersecurity teams routinely ask them to patch, noted Tancman. The goal should be to enable developers to focus their limited time and effort on remediating the vulnerabilities that truly matter to ensure application security, he said.

    In addition, developers need to have more confidence in the fact that the patch they are being asked to make won’t break their existing applications, added Tancman.

    Vulnerability prioritization is, of course, at the heart of the long-standing divide that exists between DevOps and cybersecurity professionals. Spreadsheets filled with long lists of vulnerabilities are regularly created, but there is usually no context provided in terms of how severe a threat any given vulnerability poses. As a result, developers would allocate a small portion of their time to applying patches that are prioritized based on intuition and level of complexity rather than severity.

    Naturally, developers are going to allocate most of their time to creating new applications and features. For any DevSecOps initiative to succeed, it’s critical to ensure optimal use of the time allocated to remediation. Cybersecurity teams will continue to compile lists of vulnerabilities, but that list can now be triaged in a way that causes the least amount of friction.

    In the wake of a series of high-profile security breaches, there is now more focus than ever on securing software supply chains. The challenge is to find a way to better secure applications both before and after they are deployed in a production environment. There will always be vulnerabilities that are discovered after an application has been deployed. However, just because a vulnerability exists, that doesn’t mean it’s exploitable. The trouble with application security today is that, all too often, remediation efforts turn out to be a waste of time.

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

  • Planview Outlines VSM Strategy After Acquiring Tasktop

    Planview Outlines VSM Strategy After Acquiring Tasktop

    Planview this week announced it completed its acquisition of Tasktop, a provider of a value stream management (VSM) platform that enables DevOps teams to align their efforts more closely with strategic business goals.

    Louise Allen, chief product officer for Planview, said the goal is to tighten integration between the Tasktop VSM platform and the project management applications that Planview already provides to software development teams and business executives.

    It’s still early days as far as adoption of VSM within DevOps workflows is concerned, but as more organizations realize how dependent they are on software, they need to better align application development projects with their strategic business goals, said Allen. VSM platforms make it possible to analyze data collected from various DevOps tools and enable business and IT leaders to, for example, visualize how a delay to one project might impact revenue goals for an upcoming quarter.

    Given the current weakness in the overall economy, organizations are looking to more precisely understand the impact software development decisions will have on the business, she added. As part of an effort to address that requirement, Planview will also make it easier for its applications to consume data that was originally created in Tasktop, she explained.

    VSM enables more organizations to function like a software company—aligning application updates with revenue goals. As the number of digital business transformation initiatives being launched increases, organizations are finding they need to operate more like a software company that either manufactures something or provides a service.

    The concept of value stream management traces its lineage back to lean manufacturing methods, which called for each step of a manufacturing process to be continuously measured. As software development has evolved from being a craft to an automated process using DevOps best practices, there is growing appreciation for the value of monitoring things such as the impact of missed software development deadlines on the business.

    At its core, a VSM platform will automatically convert metrics collected from a DevOps workflow to track a set of key performance indicators (KPIs) defined by the business. Once those metrics are gathered and KPIs established, organizations are then able to apply advanced analytics to align the resources needed to achieve a strategic goal by, for example, devoting more developers to a specific project. The data collected via a VSM platform can also then be shared with business intelligence (BI) applications that business leaders typically use to manage the business.

    It’s not clear just how hard business leaders are looking for deeper insights into how software development initiatives are progressing, but at the very least, DevOps leaders need a simpler way to understand all the dependencies that exist between initiatives. Otherwise, they risk missing deadlines simply because no one realized a delay that occurred in one project had a cascading impact across multiple other initiatives. Regardless of who consumes the data generated by a VSM platform, the need to increase visibility across the software development life cycle had never been greater.

  • 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…)