devopsy.kinsta.cloud

Category: News

DevOps Dozen 2019 Nominations Are Now Open
The DevOps Dozen awards are back and now open for nominations. This fifth annual DevOps Dozen honors the best of the best—the leaders and innovators in the DevOps community. This year’s awards will include 12 categories, including three new ones, with a winner chosen from each. As in years past, the top four to six nominees in each category will become finalists, who will be selected based upon the number of nominations they received. Nominations are made by you, the audience, and you can nominate up to two entrants in each category; however, you can nominate someone only once. In addition, everyone nominating will be required to provide their name and email address to help stem any potential ballot-stuffing. The winners will be selected by our esteemed panel of judges.

Last day to submit your nominations for the DevOps Dozen 2019 awards is Oct 10. Here’s where to vote: https://www.surveymonkey.com/r/devopsdozen2019

Who are the judges? This was tough. We couldn’t have anyone who might be eligible for an award. That disqualifies vendors, practitioners and many others. However, I think we have four great judges:
1. Alan Shimel, founder and editor in chief, devopsy.kinsta.cloud
2. Jayne Groll, CEO and co-founder of the DevOps Institute
3. John Willis, CEO and founder, Botchagalupe Technologies
4. Charlene O’Hanlon, managing editor, MediaOps Inc.
The 2019 DevOps Dozen Categories

So what are the dozen categories for the DevOps Dozen this year? That you can get on the site itself, but here they are as well:
1. Best DevOps Solution Provider
This category recognizes the best consultant/solutions provider in DevOps—those helping companies in their DevOps journeys.
1. Best DevOps Practitioner of the Year (New)
DevOps is a team effort and team success depends on the work of every member. However, there always are few who go above and beyond the call of duty. Their passion, energy and enthusiasm is contagious. This category recognizes these real humans of DevOps.
1. Best DevOps Solution Provider Executive
We want to recognize the top executive at a DevOps tools or solution provider—not an executive leading a DevOps transformation within a company. Nominees can be any C-level executive, GM or SVP.
1. Best devopsy.kinsta.cloud Podcast of the Year (New)
Which was your favorite DevOps Chat we’ve done this year? Check out our 2019 DevOps Chats on a multitude of topics ranging from CI/CD and testing to DevSecOps, Kubernetes, containers and more. Let us know which one you liked best.
1. Best DevOps Book / eBook
There are so many great DevOps books and eBooks that have been published in addition to “The Phoenix Project.” This category highlights that are the most popular and make a great read.
1. Top DevOps Evangelist
This category is one of our favorites. We are blessed in DevOps to have so many great evangelists who travel the world spreading the DevOps gospel. Nominees can work for a company in the space or not. This should be a really competitive category.
1. Best DevOps Transformation
This category recognizes organizations that are setting the bar in transforming their business through DevOps.
1. Best DevOps Transformation Leader
We want to acknowledge the key leaders driving the charge within organizations that have had the most success with their DevOps transformations.
1. Best New DevOps Solutions Company
This category seeks to recognize newer companies that have made an impact in the DevOps space and we believe will be tomorrow’s leaders. Nominees must be in the DevOps market less than 24 months.
1. Best DevOps Conference of the Year (New)
There’s an abundance of IT conferences throughout the year, and more are including a DevOps track or even focusing exclusively on DevOps. What tops your list of DevOps events?
1. Best DevOps Presentation of the Year
This category recognizes the best DevOps-themed presentation of the past year from any of the myriad conferences.
1. Best devopsy.kinsta.cloud Article of the Year
devopsy.kinsta.cloud publishes multiple new articles every day. Which was the best one? Let us know so we can recognize the author.

Thank you again for your enthusiastic response to last year’s awards. The full list of 2018 finalists and winners are available to view here.

Also, the product/technology-specific DevOps Dozen awards now will be part of our DevOps Tools Guide and Awards. This new initiative is our effort to create a comprehensive listing of tools and tools vendors to help end users better understand the DevOps market landscape, and to enable devopsy.kinsta.cloud to recognize the top vendors in each category through its annual DevOps Tools Awards. To be included in this year’s guide, please complete the survey.

There are so many great companies and people involved in DevOps that it’s always difficult to pick the winners. We know some worthy choices will not be voted tops in their category; however, acknowledging them in our awards process helps show how important they are in the DevOps space.

As stated earlier, the top four to six nominees in each category will be designated as finalists, who then can submit a presentation on why they deserve the award to judges@devops.com. Finalists will be announced the second week of November and the winners, who will be chosen by our panel of judges, will be announced in December.

If you have questions, send them to DD@devops.com. Voting for finalist nominees is open for three weeks, so don’t waste any time—nominate your favorites today. Good luck to everyone vying to be one of the DevOps Dozen 2019!

— Alan Shimel
September 4, 2019
Virtual Instruments Aims to Meld DevOps, ITSM Worlds

Virtual Instruments today announced additions to an IT management platform that leverage machine learning algorithms to identify application drift and dynamically right-size virtual machines.

Tim Van Ash, senior vice president of products for Virtual Instruments, said version 6.2 of the company’s VirtualWisdom platform is part of an ongoing campaign to meld the traditional world of IT service management with best DevOps practices using an AIOps platform. As part of that effort, Virtual Instruments last month acquired Metricly, a provider of tools for monitoring cloud costs in real-time.

The latest update to that platform also adds tools to monitors, reports, forecasts and alarms against the capacity consumption rate of any application, while a capacity forecast alarm now allows IT teams to specify how many days, weeks or months they wish to be notified prior to potential capacity exhaustion occurring on any one node or cluster.

Finally, Virtual Wisdom 6.2 provides access to updated VirtualWisdom Proactive Dashboards that provide access to Smart Charts, through which the AIOps platform now supports annotation, linking and smart naming in addition to topology views that are specific to a set of IT infrastructure or an application.

Van Ash said the Virtual Instruments approach to AIOps is that it allows IT teams to respond to changing application conditions in real-time and set granular limits on how much capacity can be consumed by any particular application. For example, IT teams can ensure that specific applications are given a Platinum-level preference that prevents any other application from consuming resources allocated to that application, he said.

In general, Van Ash said Virtual Instruments is pursuing an application-centric approach to AIOps that will make it easier for IT organizations to optimize IT infrastructure capacity dynamically. Rather being overly focused on utilization rates and tracking events, AIOps platforms need to be able to address the entire IT life cycle as it relates to the value that IT environment has to the business, he said, noting today many DevOps teams are building and deploying applications with little regard or actual control over the service levels those applications need to achieve and maintain. The goal, he said, is to provide a single platform through which DevOps and IT operational teams steeped in legacy IT service management (ITSM) models such as ServiceNow can collaboratively achieve a common set of goals.

A day of reckoning is coming for proponents of DevOps and IT teams that have built sprawling IT environments employing ITIL-based processes. Those ITIL-based processes are not especially flexible, but they have been employed successfully to roll out applications at scale consistently. Advancements in AIOps should go a long way to bring the two schools of IT management together by making it easier to bend the available IT infrastructure resources to the will of multiple application developers trying to share a common pool of resources.

In the meantime, no one should expect AI to solve their problems magically overnight. It takes a while for algorithms to solve all their IT headaches. However, the days when the relationship between developers and IT operations teams could be described as mostly contentious soon may be coming to a merciful end.

— Mike Vizard

September 4, 2019
Atomist Takes on Application Drift Management

Atomist today announced it is extending the capabilities of its software delivery automation platform to include drift management tools that make it easier to identify changes to code.

Now in beta, that capability is based on an open source project dubbed Org Visualizer, which makes it possible to clone an entire project hosted in a GitHub repository via a single click and then visually inspect it.

DevOps teams also can leverage a built-in Policy Manager to capture and track changes in code, define custom policies that automatically apply updates and automated actions and generate progress reports showing how close they are to achieving a target policy goal.

Atomist CEO Rod Johnson said the reporting tools provide a visual representation of what’s occurring within an organization’s codebase to make it easier to identify both overly complex dependencies and vulnerabilities.

The drift management tools are built on the software delivery machine (SDM) concept that lies at the heart of the company’s core platform, Johnson said. The Atomist platform is based on a domain model for software delivery constructed around an application programming interface (API) server and GraphQL, an open source data query and manipulation language. That approach eliminates the need to master, for example, complex YAML files to deliver software. The addition of the visualization tools not only make it easier to see what’s going on in the development environments, but they also make it easier to identify areas where technical debt in the form of bugs and vulnerabilities is building within an application development project, he noted.

The sooner those issues are addressed, the more probable it becomes that DevOps teams will deploy reliable, secure code, rather than needing to update it or roll back the entire application, Johnson added.

Although the Atomist platform is capable of working in any application environment, there’s a high correlation between organizations that have embraced microservices-based on containers and organizations looking to automate software delivery using the Atomist platform, Johnson said. Organizations that embrace microservices based on containers typically have a frequent need to update codebases in production environments, he noted, adding many organizations don’t know the impact that microservices updates have on the rest of the production environment.

In general, there’s been a lot of DevOps progress when it comes to automating continuous integration within the context of application development project. However, automating the delivery of software has proven to be a more elusive goal. As the rate and amount of code being developed continues to accelerate, it’s now only a matter of time before software delivery automation becomes a more pressing issue. Manual deployment processes prone to errors only serve to aggravate application development and deployment backlog at a time when business leaders are demanding IT teams become more agile.

At the very least, tools that enable DevOps teams to visualize the scope of the challenge ahead should help frame a realistic conversation about what’s truly achievable, given the current state of the codebase.

— Mike Vizard

August 28, 2019
Splunk to Acquire SignalFx to Gain APM Platform

Splunk today announced it will acquire SignalFx as part of an effort to extend its reach beyond IT operational analytics and into the realm of application performance management (APM).

Valued at approximately $1.05 billion, the deal to acquire an APM platform delivered as a software-as-a-service (SaaS) offering will expand and accelerate Splunk’s overall transition to a recurring revenue model based on cloud services, said Splunk CEO Doug Merritt during a call with industry analysts.

Splunk is currently on pace to generate over $300 million per year from the cloud version of its IT operational analytics platform. Splunk revenues for the second quarter were $517 million, up 33% year over year, with software generating $350 million of that total. However, as Splunk transitions to more of a subscription-based pricing model, the company has some financial management challenges. GAAP operating loss for the company’s second quarter was $87 million. However, non-GAAP operating income was $47 million, even though operating cash flow was negative $129 million. That cash-flow issue is a direct result of the transition away from a perpetual software license model based on the volume of data consumed by the Splunk platform. Overall, Merritt said Splunk is firing on all cylinders and is still on track to have 20,000 customers by the end of its fiscal year.

Merritt said once the deal is approved, sometime in the second half of fiscal 2020, SignalFx will provide a complementary set of services for monitoring legacy monolithic applications as well as cloud-native applications based on containers, Kubernetes and serverless computing frameworks. There are very few customers at this point who have not adopted cloud-native technologies, but for now they remain a small percentage of the overall number of application workloads being managed, he added.

The goal is to provide a suite of services that will enable IT teams to investigate, analyze, monitor and act on data in real-time, said Merritt.

Splunk is already widely employed by internal IT operations teams, many of whom already rely on a complementary APM platform. Splunk clearly expects organizations will prefer to acquire an IT operational analytics platform and an APM service from the same vendor. However, competition between APM platform providers is already fierce. That said, Splunk appears to be counting on increased demand for real-time application monitoring to differentiate SignalFx from rivals.

It’s not clear to what degree Splunk might converge the various services now being provided separately by both companies. It’s also not clear how or whether this deal will accelerate acquisitions of the remaining independent APM platform providers.

In the meantime, Merritt said SignalFx and Splunk’s earlier acquisition of VictorOps, provider of incident management platform based on best DevOps practices, will expand the amount of visibility Splunk has with application development teams.

Ultimately, acquisitions of smaller, DevOps-oriented companies by vendors that today are still more closely identified with legacy ITIL-based IT processes, such as Splunk, are only like to increase. What will be interesting to watch is whether the tools and services being acquired by those companies wind up being the DevOps tail that wags the proverbial ITIL dog.

— Mike Vizard

August 21, 2019
Puppet Aims to Automate Vulnerability Remediation

Puppet today unveiled Puppet Remediate software, which makes it easier to prioritize and remediate software vulnerabilities automatically.

Matt Waxman, vice president of products for Puppet, said Puppet Remediate builds on existing automation capabilities in the Puppet platform to make it easier for DevOps teams to focus on addressing vulnerabilities. Most existing approaches to addressing vulnerabilities rely on manual processes that often result in vulnerabilities not being addressed in an especially timely manner, he said.

To accelerate that process, Puppet Remediate identifies vulnerabilities based on their potential severity and then gives DevOps teams the option to automatically remediate all known instances of that vulnerability, said Waxman. Puppet Remediate combines infrastructure data with vulnerability data gathered in real-time from Tenable, Qualys and Rapid7 to prioritize vulnerabilities.

Puppet Remediate will not automatically remediate a vulnerability without the express approval of the DevOps team. That’s critical because in many instances the patch being applied still needs to be tested and vetted by the DevOps team, noted Waxman. Once approved, Puppet Remediate includes four pre-built tasks that allow DevOps teams to address more than 80% of the typical remediation workloads—importance because once a vulnerability is discovered, it’s not uncommon to find that same mistake has been made across many other software modules that have already been built and deployed.

Deployed using Docker containers, Puppet Remediate relies on an agentless approach to vulnerability remediation that adds minimal overhead to either a Linux or Windows application environment, Waxman said. He added the goal is to make it easier for developers or cybersecurity teams to deploy Puppet Remediate on any platform.

Waxman said the primary goal is to help organizations embrace best DevSecOps processes. In the absence of automation, the amount of time allocated to addressing vulnerabilities manually within existing applications often gets short shrift as developers race to meet deadlines for new applications. The irony, of course, is that each new application only serves to increase the number of potential vulnerabilities that need to be addressed. To restore order to vulnerability remediation process, Puppet is making the case for applying a proven IT automation framework to application security management.

It may take a while for organizations to fully embrace automated application vulnerability remediation, but it would seem that, given the chronic shortage of cybersecurity professionals, adoption of these types of platforms is all but inevitable. There simply are not enough skilled cybersecurity professionals available to participate in every aspect of the application development and deployment process.

At the very least, automated vulnerability remediation tools should inform developers of the mistakes being made most often. Over time, the number of instances of those vulnerabilities being discovered should decline as developers realize they are addressing the same issue repeatedly. Once that becomes obvious, hopefully that long-awaited teachable moment that eliminates that particular vulnerability from the application environment is finally at hand.

— Mike Vizard

August 21, 2019
Catchpoint Expands Network Monitoring Service Reach

Catchpoint has expanded the number of locations worldwide from which it is gathering telemetry data for its networking monitoring service to more than 825 sites.

Drit Suljoti, chief product officer for Catchpoint, said as applications continue to become more distributed, the worlds of DevOps and network operations (NetOps) converge. DevOps teams need more visibility into how network latency issues anywhere in the world are impacting the digital experiences of their end users, said Suljoti.

The Catchpoint monitoring service now extends to 200 cities worldwide, including 140 nodes in mainland China. In addition to monitoring critical backbone locations, Catchpoint has placed nodes in 133 public cloud locations and is now offering a free and seamless migration for companies looking to adopt a next-generation digital experience management (DEM) platform in place of Gomez and Keynote services from Dynatrace that recently were retired, said Suljoti.

In much the same way DevOps teams rely on a variety of tools to monitor applications, they also need access to a service that continuously monitors the networks on which those applications depend, Suljoti said. That requirement has become more critical as the number of latency-sensitive applications such as those based on microservices increases, noted Suljoti. As organizations depend on those applications to drive a variety of digital business processes, visibility into how the network is impacting the application experience of end users can easily degrade, he added.

Most organizations already have tools to monitor network performance within their own data center. However, creating the monitoring framework required to identify network performance issues across a global wide area network (WAN) would be cost-prohibitive for most organizations. When it comes to deploying applications that span multiple WANs, most DevOps teams are essentially blind.

It’s still not clear within many organizations who is responsible for monitoring WAN services. Historically, NetOps teams have held this responsibility. However, Suljoti said that as DevOps processes continue to expand and mature, there is a more collaborative approach emerging that incorporates network monitoring tools within testing frameworks that organizations create within the context of a continuous integration/continuous deployment (CI/CD) process.

In the meantime, pressure on existing WAN networks will only increase. In the absence of 5G services, the number of applications competing for access to bandwidth increases. Many organizations have no idea whether network service providers are really meeting the commitments they agreed to as part of the service level agreement (SLA) provided. As more application performance issues get traced back to the underlying network, frustration with the quality of network services is only going to mount. Before they can call network service providers to account, DevOps teams will need access to analytics that clearly show service level commitments are not being met.

Of course, that may only elicit an apology from the network service provider. At the very least, however, DevOps teams will be able to make a much more informed decision concerning how they want to route application traffic going forward.

— Mike Vizard

August 20, 2019
Virtual Instruments Acquires Metricly to Monitor Cloud Costs

Virtual Instruments has acquired Metricly, a provider of a software-as-a-service (SaaS) application that help organizations to optimize the deployment of cloud application workloads.

Tim Van Ash, senior vice president of products at Virtual Instruments, said Metricly employs machine learning algorithms to identify opportunities to improve performance and reduce costs. Those capabilities complement an existing VirtualWisdom platform from Virtual Instruments to apply machine learning algorithms to optimize IT operations, otherwise known as AIOps.

Virtual Instruments focused exclusively on enhancing storage I/O performance before extending the reach of its portfolio to include server performance. With the acquisition of Metricly, the company is further extending the portfolio to span hybrid cloud computing environments, said Van Ash.

Metricly, formerly known as Netuitive, provides analytics tools that are focused on helping organizations contain cloud costs.

Metricly CEO Bob Farzami said the company’s tools increasingly are being incorporated via application programming interfaces (APIs) into DevOps processes to provide visibility into costs, as the number of applications deployed in the cloud expands and increases. The acquisition of Metricly adds more than 50 integrations to open source DevOps technologies to the Virtual Instruments monitoring portfolio, which spans databases, messaging platforms, containers and cloud infrastructure services such as AWS Lambda, EC2, ECS, ASG, EMR, Microsoft Azure VMs and Load Balancer.

Those integrations are critical because as the number of services being made available on AWS increases, the visibility organizations have into their real cloud costs becomes more difficult to both discern and limit, said Farzami. There are already hundreds of cloud services on AWS. Cloud service providers often count on organizations to forget how many instances of, for example, virtual machines they have spun up, only to be presented with an unexpected bill at the end of the month. Those issues will be further exacerbated as organizations more aggressively employ multiple cloud platforms.

Many organizations are also seeing cloud costs rise over time as the volume of data being dynamically accessed by stateful applications increases. Once those costs reach a certain level, those organizations are realizing it costs less to repatriate those applications back on into on-premises IT environments. Metricly provides a mechanism through which organizations gain more visibility into their cloud costs in real-time, but also identify when specific cost thresholds are about to be reached.

It will be at least somewhere between five to 10 years before even the majority of application workloads are running in the cloud. Today, after more than 10 years, only about 20% of application workloads are running in public clouds. There are a whole host of reasons organizations still prefer on-premises IT environments, ranging from regulatory requirements and performance to cybersecurity and simple inertia. Wherever workloads wind up being deployed, however, the one thing DevOps teams can count on going forward is that someone in the finance organization soon will be asking more pointed questions about how much it costs to run that workload.

— Mike Vizard

August 16, 2019
CloudBees Advances Continuous Delivery

At the DevOps World | Jenkins World 2019 conference, CloudBees released an update to the continuous delivery (CD) platform it gained via its acquisition of Electric Cloud, signaling the company’s commitment to investing in a platform that’s employed widely in the enterprise.

CloudBees CEO Sacha Labourey said the rechristened CloudBees Flow builds on the application release orchestration (ARO) platform to further automate the last mile of a DevOps process.

Version 9.1 of CloudBees Flow provides a path to increased visibility into how a release is progressing, including the ability to view the inventory being deployed to a given environment and deeper insights into all the sub-pipelines that make up an overall release.

The latest release also provides more granular control over release pipeline execution, customizable dashboards within the platform’s Release Command Center and data archiving capabilities that make it easier to comply with regulatory mandates.

Labourey said that while companies that have developed commercial software-as-a-service (SaaS) applications tend to have very mature DevOps processes, most enterprise IT organizations are still defining the best DevOps practices they want to implement across their organization end to end. CloudBees Flow provides a continuous delivery framework for automating the deployment of applications at enterprise scale that complements the Jenkins continuous integration/continuous deployment (CI/CD) platform, he said.

Labourey noted the goal is to eventually unify continuous delivery processes across multiple platforms, including the ARO platform provided by Electric Flow, the Jenkins CI/CD platform and the Jenkins X and Spinnaker platforms that are optimized for building and deploying microservices-based applications on top of Kubernetes. As part of that effort, earlier this year CloudBees became a founding member of the Continuous Delivery Foundation (CDF), an arm of The Linux Foundation dedicated to foster best continuous delivery practices.

Most organizations that have adopted CI/CD platforms have seen varying degrees of success in taking advantage of continuous integration to accelerate the development of their applications. Continuous delivery, however, has proven to be a much bigger challenge. Organizations tend to struggle with everything from making sure they have the appropriate infrastructure resources available to support a new release of an application to debugging application code before and after it’s deployed in a production environment.

It may be a while before most enterprise organizations truly master DevOps processes end to end. However, given how dependent on software most organizations are, increased reliance on DevOps processes has become a prerequisite for any form of digital business transformation. As the volume of software being developed increases, the rate at which updates to applications are being made also increases substantially. Most organizations are not going to be able to keep pace with that rate of change by relying on legacy software development and deployment processes.

In many more cases now, however, the challenge organizations are wrestling with is not so much whether to transition to DevOps, but rather determining which DevOps processes to standardize on to satisfy the elevated expectations of business leaders anxious to provide customers with that next great application experience.

— Mike Vizard

August 14, 2019
CloudBees Harnesses Additional Cloud Bursting

At the DevOps World | Jenkins World 2019 conference, CloudBees announced that the latest version of its CloudBees Accelerator platform now supports cloud bursting to all three of the major public cloud service providers.

CloudBees Accelerator makes it possible to distribute the build, quality assurance and testing cycles across a large cluster of inexpensive servers. Version 11.1 further extends that capability into the public cloud by adding support for Microsoft Azure and Google Cloud Platform, alongside existing support for Amazon Web Services (AWS).

Company CEO Sacha Labourey said as organizations embrace multiple clouds for application development and deployment, continuous integration/continuous deployment (CI/CD) platforms will need to span hybrid cloud computing environments. Most organizations are not yet making use of multiple public clouds to develop an application, but they are increasingly relying on external cloud resources to augment the infrastructure resources they have available in on-premises IT environments.

In addition to providing cloud bursting support for Azure and GCP, version 11.1 of CloudBees Accelerator provides support for Android Q, a forthcoming update to the widely employed mobile operating system due out in the third quarter of this year. Other new capabilities include support for the SSL and TLS cryptographic protocols and improvements to out-of-the-box support for Windows, including the ability to distribute and cache Visual Studio projects.

Version 11.1 of CloudBees Accelerator also now makes it possible to apply CloudBees Electrify, a framework for optimizing the use of all available infrastructure in parallel, to accelerate build tools such as MSBuild and Scons. In addition, it provides improvements for the open source Yocto Project, an initiative from the Linux Foundation that streamlines the creation of Linux distributions for embedded systems. CloudBees Accelerator enables developers to at least triple the speeds of builds using BitBake build tools or Buildroot files and patches.

As expansion occurs in both the volume and types of applications that organizations rely on to build and deploy faster, the need to rely more on automation also is increasing. Many DevOps processes that organizations adopt initially have been crafted manually. As organizations become more adept, however, it becomes apparent there is an opportunity to automate a wide range of lower-level processes. Frameworks such as CloudBees Accelerator essentially provide a layer of abstraction that enables organizations to devote more time and energy to writing application code.

In fact, the next wave of organizations adopting DevOps is likely to benefit greatly from all the processes that the first wave of adopters helped automate by identifying best DevOps practices. It remains to seen just how automated the entire CI/CD environment can become with the rise of, for example, artificial intelligence (AI), but with each passing upgrade cycle, the accessibility of DevOps increases thanks primarily to advances in automation. Those advances not only make it easier to share best DevOps practices across an enterprise, but they also make it feasible for more organizations to embrace DevOps because the level of expertise required to master those DevOps processes declines.

— Mike Vizard

August 14, 2019
CircleCI Adds Security Orbs to CI/CD Platform

CircleCI has extended the reach of its automated package manager, known as orbs, to cybersecurity software that can be integrated into a pipeline constructed within the company’s namesake continuous integration/continuous deployment (CI/CD) platform.

Mike Stahnke, vice president of engineering for CircleCI, said extending orbs into the realm of cybersecurity will make it much easier for organizations to embrace best DevSecOps processes.

Designed to run on Amazon Web Services (AWS) and Google Cloud, the first set of orbs are being created by seven third-party cybersecurity vendors, including Alcide.io, NeuVector, Snyk, WhiteSource, Aqua Security, Anchore, Contrast Security, Probely and Twistlock, which is now part of Palo Alto Networks.

CircleCI has been making use of orb package managers to make it easier to integrate a wide variety of functions within a CI/CD pipeline. Thus far, approximately 900 orbs have been developed for the CircleCI platform. Stahnke said the goal is to give DevOps teams the option of employing orbs instead of having to manually implement tasks such as secrets management, vulnerability scanning or policy enforcement into DevOps workflows.

Stahnke said CircleCI doesn’t envision every element of a pipeline will become an orb; there will be instances where DevOps teams will want to exercise more granular control over some aspect of the pipeline. There are, however, going to be many situations in which DevOps teams won’t want to integrate the same functions manually over and over again.

CircleCI expects orbs will prove especially useful in advancing the adoption of best DevSecOps processes because many of the controls that need to be implemented are the same across multiple pipelines, said Stahnke. By making it easier to incorporate cybersecurity software within a pipeline, DevOps teams will not have to sacrifice speed and agility to ensure security.

Most organizations today are just starting down the DevSecOps path. Adoption of DevOps processes in many cases has been uneven at best. Trying to incorporate cybersecurity teams within those processes to ensure higher levels of security is the next great challenge. However, given the chronic shortage of cybersecurity professionals, cybersecurity functions within a DevOps pipeline somehow must be included automatically. In most cases, cybersecurity teams will continue to define policies and controls that increasingly are implemented by developers. Cybersecurity teams, however, still will need to validate that those controls have been implemented and tested before an application gets deployed in a production environment. Cybersecurity teams will then make developers aware of any vulnerabilities they’ve discovered and teams can decide to address them at whatever next stage of the development process they deem appropriate.

Of course, DevSecOps also means cybersecurity teams will have to learn to trust developers. Historically, that’s been problematic because many cybersecurity professionals have tended to view developers as the primary source of the cybersecurity problem. Nevertheless, the more vulnerabilities that get addressed before an application is deployed in a production environment, the better off everyone involved in building, deploying and securing that application will be.

— Mike Vizard

August 13, 2019