devopsy.kinsta.cloud

Tag: compliance

Health Care’s Shift to the Cloud via the Hybrid Cloud, Part 2

In part one of this series, we looked at how the healthcare industry has changed, requiring integrations and interoperability that were not previously needed.

Having established that the cloud is the way to go and that the hybrid cloud is the stepping stone hospital CIOs are comfortable with, we must ask how DevOps can help.

DevOps in Health Care

The legacy HL7 connection technology healthcare facilities use is a great example of how DevOps brings interoperability to health care and the hybrid cloud. “We have a cloud-hosted HL7 interface that can connect to any number of different hospitals and to our system as well. That’s something that would be very difficult to do without a cloud-based HL7 interface,” said Mayank Thanawala, CTO of HealthLoop, a provider of a cloud-based platform to automate follow-up medical care.

Another challenge hybrid cloud can address concerns the registries that track patient episodes and the bundled payment initiatives that health insurance companies use to pay the hospital systems, Thanawala noted. “The challenge is that hospitals have to get the patient data into the registries in order to receive payment.”

A hybrid cloud makes it easier to submit data to the registries because it provides an opportunity to connect to the registries using a system that already connects with the EMR system also and contains other data useful for registries and payments.

Thanawala illustrated registry solutions in the hybrid cloud. The Comprehensive Care for Joint Replacement Program is a large registry hosted by Medicare CMS. Hospitals need data such as diagnosis histories from medical records and patient-reported survey information to submit to this registry. “So, in an example of a hybrid cloud, HealthLoop is a cloud system that uses a web interface to ask the patients the questions and collect the data. Then we use this hybrid cloud-based HL7 interface to query the on-premises EHR (electronic health records) system for all the rest of the data, fill in the blanks, create this file for this registry, and basically solve the hospital’s problem,” he said.

How DevOps Speeds the to the Hybrid Cloud

DevOps and the move to containers have helped accelerate health care’s move to the hybrid cloud. “When you deploy a Ruby on Rails API in, say, a Docker container, because of how the container is configured it is going to take care of logging for all of the applications and transactions and putting those in a store that will keep the transactions for the seven-year period that HIPAA requires,” Thanawala said. This automation saves the hospital CIO the step of having the logging set up.

In the same way, if encryption of data both in flight and at rest is set up automatically in the container default configurations, that’s another matter the hospital CIO doesn’t have to worry about, he said.

If applications are set up as microservices in containers so that they already perform all these functions when containers are created or scaled up, the hospital and HIPAA requirements surrounding these activities automatically are met. “This lets startups like HealthLoop focus on building app functionality so we don’t have to worry about these other more involved matters,” Thanawala noted.

Even with health care’s complex move to the hybrid cloud, the modularity, completeness and singularity of applications in container technology as microservices make it possible to configure the containers, use them as building blocks and to build out efficient, scalable solutions in the cloud, he said. “It allows companies such as Catalyze, a medical systems integration and compliance organization, which we use to offer its products in a PaaS (platform-as-a-service) model using compliant containers so that we can simply deploy the containers and not have to worry about building compliance.”

Saving Time, Effort, Worry

HealthLoop’s story is a great example of how the automation and modularity of DevOps components such as containers and microservices can make or break new business opportunities, such as taking health care to the cloud and solving interoperation challenges.

July 29, 2016
The 3 Compliance Questions to Ask
As companies move to cloud, they require more certainty around export compliance.

Of the many complexities associated with cloud computing, export compliance laws arguably are some of the thorniest. From a legal and technical perspective, the export compliance laws currently on the books—as they vary from country to country—can make even the savviest and most experienced attorneys’ and engineers’ heads spin.

All enterprises must adhere to a variety of industry- and country-specific rules related to important security, data privacy, taxation and export controls. But these rules become especially murky around cloud services. For example, if a U.S.-based company provisions a virtual machine abroad, say in China, does it need to develop region-specific export controls?

Export compliance rules raise other, broader questions. For example, how do you retain agility while complying with the necessary regulations? And how do those regulations and controls vary according to workload? Like tax regulations, rules for collecting and distributing user data vary depending on location.

Not having the proper compliance protocols in place can have serious implications. Say your client is expanding into a foreign market and, at the last minute, they request a number of changes that have not been evaluated from a compliance perspective. Either the expansion is delayed, which could be damaging from a reputation and financial perspective, or the company runs the risk of being cited for compliance violations.

So, as more and more companies expand globally, how can they prepare to meet the compliance challenges stemming from cloud computing?

Three questions in particular are critical to answer when it comes to cloud export compliance.

Is it possible for companies to be both agile and compliant?

Increased business agility is perhaps the single greatest benefit cloud offers. Cloud computing facilitates rapid provisioning of resources, allowing companies to scale quickly and adapt to changing client and market needs. But what effect does export compliance have on cloud’s speed and flexibility? This type of unprecedented agility requires a re-think of how governance and policy enforcement is managed. Instead of manual checks, companies must transition to real-time policy enforcement and recording that matches the agility of cloud. This is a change to both culture and process—the rocky road where foundations can begin to crumble.

How do compliance rules vary from country to country?

Companies that operate internationally are subject to a number of rules related to citizens’ data protection, taxes, variations relating to workload, region-specific controls, paperwork and registration. When conducting cross-border provisioning, legal counsel is mandatory to establish best practices and to ensure compliance. Unfortunately, because the cloud is a relatively new phenomenon, legal expertise in this area is scant.

Further, even when there is some legal expertise, when it comes to uncertainty, the default answer from legal counsel is often, “No, we can’t do that.” Indeed, when there is a certain amount of risk and haziness around the law, the easiest—and safest—thing for legal counsel to do is to say it can’t be done. But that’s not helpful to a business.

What steps can companies take to prepare for these differing requirements?

There are three essential measures that companies can follow to help ensure their cloud services are compliant with global export regulations.
1. Identify: All software that could be subject to cross-border exports—either packaged software or homegrown code transferred between between countries—requires legal guidance and approval. So the first step is to determine the software being exported.
1. Register: Once you have identified the appropriate software, you need to maintain a registry. Whether an image or an automation routine deploys the software, it’s important that you have a clear record verifying what must be registered.
1. Record: Companies that employ cloud across borders may be required to keep a record of all export transactions. Many businesses make excuses why they don’t properly document these transactions—the virtual machines in question do not belong to them; their cloud software is publicly available; or recording export transactions is only mandatory when exporting to riskier markets such as China, Iran or North Korea. To protect companies from liability or legal action associated with cross-border data transfers, legal counsel often will suggest recording all cross-border software movement.
These steps are critical to the export process, and partnering with a cloud provider that can help clear up export confusion can ease the pain. Some cloud brokers and providers offer applications that track cross-border exports, which can save a number of headaches. They have tagging and metadata reporting systems in place ahead of time. These are necessary for security and privacy compliance anyway, so it can be leveraged across domains.

A good cloud platform provider anticipates a business’s needs and offers services that a company may have never even taken into consideration, such as tracking tools to keep tabs on software so that it can be easily reported. These companies have in-house counsel with expertise in cloud export and tactical, strategic plans (such as the metadata tracking) so you know what software is going where for how long and how often—data that can also help support audits.

Information is power, and the more you have, the more prepared you are to deal with thorny issues such as export compliance. Having a partner to guide you through the process—an experienced cloud platform provider with sound advice—can help arm you with the information you need to get to cloud quickly, safely and securely.

About the Author / Rodrigo Flores

Rodrigo Flores is Managing Director of Product Innovation, Architecture and Management for Accenture Cloud Platform. The Accenture Cloud Platform is a multi-cloud management platform that procures, provisions, orchestrates, manages and governs enterprise cloud resources.
June 10, 2016
Q&A: Quali’s Wrabetz on Security Testing
DevOps is the perfect storm of automated testing and development that should make secure software commonplace. Yet, there are hurdles to testing for security. devopsy.kinsta.cloud asked Joan Wrabetz, CTO of Quali, about security, DevOps and her laundry list of those testing challenges.

David Geer: Isn’t secure software important to DevOps?

Wrabetz: DevOps is a practice of continuously deploying applications into production clouds. In order to automate the deployment of applications into production, it would seem essential for security testing to be a part of that automated process. In fact, when talking with one financial services firm, they said that they don’t deploy continuously into production because they are concerned that to do so would break the law. They are required by law to ensure that applications comply with their regulatory and privacy requirements before they are deployed into production. The only way to do that is to perform security testing. Thus, in order to achieve continuous deployment, they would have to integrate security testing into their DevOps flow.

Geer: So, why isn’t security testing a core part of DevOps already?

Wrabetz: The reasons are both technical and organizational. Organizationally, security testing is usually handled separately from development or product release-oriented testing, often by a completely separate group. As a result, it is not necessarily associated with the application release process.

The technical reasons are related. Historically, security testing has involved reproducing the production infrastructure and network configuration as accurately as possible so that security vulnerabilities can be identified. Often, development and test teams working on DevOps do not invest in creating accurate reproductions of production infrastructure for their normal development and testing. So, they are not prepared to perform security testing as part of their normal DevOps flow.

Security testing at many financial services firms exemplifies both of these issues. These firms typically outsource their security testing to one of a number of service firms who perform that testing on their own networks or in the cloud. The outsourcing of the security testing process is a big inhibitor to incorporating security testing into a continuous and automated DevOps process. In addition, when we asked these financial services firms how well their outsourced security testing represents their real production information technology infrastructure, they really have no idea. Clearly, any testing that does not match the production environment is not helping to reduce the security risk that the organization faces.

Geer: What kinds of security testing do you feel is most relevant to DevOps?

Wrabetz: The type of security testing that is most relevant to the DevOps flow is application compliance testing. For this type of testing, new applications are inserted into a network that emulates the information technology production network as accurately as possible. Testing with load, traffic and disruptive events is performed to determine whether the new application or upgrade might open up a vulnerability in the production environment. That includes privacy and data protection regulations, security requirements and any other business compliance standards that the organization is subject to. This testing is performed before pushing any new upgrade or application into production to ensure that compliance requirements will be maintained.

Geer: What are some common problems with security testing as part of DevOps?

Wrabetz: There are some common problems that make this type of testing uniquely difficult as part of a DevOps process, and in many cases, much harder to perform than other hardware and software testing. For example:
- The tests must run in a configuration that exactly matches the current production configurations.
- Security tests are systemwide tests, not tests of a single piece of hardware or software.
- The tests must run with realistic traffic that simulates typical production traffic.
- Security testing must allow automation of setup, configuration and testing processes in order for it to be incorporated into a DevOps flow.
- Networks are large-scale and difficult to reproduce in a test.
Security Testing Critical

DevOps is in its infancy, but it won’t be forever. Now is the perfect time to surmount these obstacles, test for security and feed the results back into coding for security early and often.
May 26, 2016
Does DevOps Help or Hinder Compliance?

DevOps tools and principles have revolutionized IT across many industries in recent years. But companies saddled with requirements such as Sarbanes-Oxley (SOX), the Health Insurance Portability and Accountability Act (HIPAA), Gramm-Leach-Bliley Act (GLBA) and Payment Card Industry Data Security Standard (PCI-DSS), for example, tend to be more cautious when it comes to adopting cutting-edge solutions.

There are specific industries—health care and finance are two—that are strictly regulated and more reluctant to change. But even beyond those industries, there exist various compliance frameworks under which the rapid pace of change associated with DevOps may be seen as a risk. The flip side of that coin is that the agility and automation associated with DevOps actually might streamline and simplify compliance.

The DevOps and Compliance Challenge

Ken Cheney, vice president of Business Development at Chef, agrees. “Today companies are faced with increasingly detailed security and compliance requirements. For organizations in highly regulated industries like health care, financial services and the Federal space, detailed compliance can impede the ability to innovate.”

One of the biggest concerns DevOps organizations fear is that compliance and audit will create a “Wild West” ecosystem where everyone has access to all production systems and data. However, DevOps doesn’t have to automatically result in systems access chaos. In fact, the use of orchestration actually can lend a hand to making a more compliant organization where nobody gets direct access to production systems.

“Instead, mature DevOps organizations actually remove all direct administrative access to systems,” says Andrew Storms, vice president of Security Services at New Context. “The ability to make changes all go through a central orchestration tool, where access can be abstracted forced through a change management automation system.”

Better Compliance Through Automation

The consensus among DevOps experts is that DevOps does more to help compliance than hurt it. It isn’t so much a question of whether a regulated business should or shouldn’t adopt DevOps tools and principles—it’s more a question of how.

“DevOps tools and practices establish compliance through consistency. They help improve compliance by reducing complexity and variability within the environments,” notes Derek Weeks, vice president and DevOps Advocate at Sonatype. “For test and operations teams, configurations, tests and deployments can be automated to ensure execution is consistent. For development teams, consistent versions of binaries ensures use of compliant components, leading to more compliant applications. The automation capabilities of DevOps tools enable consistent, automated execution of compliant practices.”

Rather than conflicting with such initiatives, DevOps can be a crucial element in simplifying and streamlining them. “The key to making compliance an advantage is to specify compliance requirements as code, allowing it to be tested just like any other piece of code in the software development pipeline,” Chef’s Cheney says. “Previously manual verification tasks—often tracked through spreadsheets or other arduous methods—can now be proactively addressed as embedded tests in an automated workflow. Security risks are brought to the surface early for faster remediation, so out-of-date software is identified and updated quickly.”

Weeks concurs: “Not only does DevOps introduce more consistency and reduced complexity of operations, it also allows for fast feedback loops when things are identified as out of compliance. Waterfall cycle times that might have required weeks or months to fit changes or corrections into systems can now be achieved in a fraction of the time in DevOps practices.”

It’s important for DevOps organizations to think a bit differently when it comes to compliance, though. They may be forced to implement the same types of controls using different tools or slightly different processes to conform with specific requirements. But Storms notes DevOps ultimately is a huge benefit for achieving and maintaining compliance.

“Gone are the days of showing the auditor your physical paper trail of server build checklists,” he says. “Instead, businesses need to learn to work with their auditor to find new solutions that, in the end, actually enhance and optimize the process.”

Rapid change can seem scary to IT and security admins. The pace of DevOps may seem to be in conflict with achieving and maintaining compliance, at least at face value. Done properly, though, DevOps enhances and automates compliance to make it as streamlined and simplified as possible.

March 18, 2016
Chef rolls out some tasty new dishes

Chef has announced some major additions to their lineup today. We will look at each of these but in total here is the news from Chef today:

First of all the previously announced Chef Delivery is now in GA for everyone. Chef Delivery defines and manages the entire DevOps workflow. The diagram below is a good illustration of this:

According to Chef, Delivery, “provides a prescriptive process to automate changes to infrastructure, applications and containers in a single prescribed pipeline.”

Beyond the general availability of the previously announced Delivery, Chef also announced that they are moving into services in a big way. They are spinning up a new DevOps transformation practice to help enterprises adopt DevOps and transform their models. Justin Arbuckle, chief enterprise architect at Chef is heading up this new practice. I would assume they will compete with professional service organizations like IBM, HP, PWC and others in helping large enterprises transform and adopt DevOps practices. It is a natural move for Chef as it continues to mature along with the DevOps market in general.

Finally, Chef is going to roll out compliance as code, part of something Justin Arbuckle has spoken to me before of compliance at velocity. In order to bring this capability to market Chef has bought a smaller German security provider called VulcanoSec. VulcanoSec has done a good job of developing a shift-left security product that allows for continuous compliance. I am sure we will see the Chef team expand this as they seek to bring more and more security into the DevOps process and they see opportunity for improving the entire development/deployment environment to make it more secure. They will also have to integrate and work with existing enterprise security solutions.

All in all this is quite a series of announcements from Chef, which were made at the European Chef Community Summit in London. Chef has been a leader of the DevOps movement from the very start and they continue to show that they will continue to lead and innovate in bringing DevOps and everything as code to enterprises everywhere.

November 3, 2015
Upcoming SANS Webinar: Orchestrating Security in the Cloud
Organizations are increasingly migrating to cloud-based services to handle sensitive data and business processes, meaning security teams need to carefully review and understand what security controls are available to help protect them.

Given the pace of cloud adoption, security teams need to increase security automation efforts and employ tools that can better secure their cloud assets through improved visibility.

SANS is hosting an informative webcast on Wednesday, September 23, at 1:00 PM EDT (17:00:00 UTC) to present the findings from a new survey that examines the organizational use of public and private clouds and outlines best practices for assuring a robust security posture.

The webcast is scheduled in conjunction with the release of the highly anticipated SANS whitepaper on cloud security titled Orchestrating Cloud Security (PDF), written by analyst and network security specialist Dave Shackleford.

The whitepaper presents the results from a survey 485 IT professionals who use different cloud providers and service models for a variety of business needs, including collaboration services, email, managed services, backups for disaster recovery, and other common use cases for cloud services.

Although cloud services provide the functionalities businesses need today, the survey reveals that they also come with inherent security risks.

The SANS survey found that 40% of the respondents acknowledge they process sensitive data in the cloud, and are facing increasing challenges related to access control, configuration management, compliance demands, overall visibility, and the implementation of security controls.

New technologies are emerging as part of the security-as-a-service (SecaaS) model, which are security-oriented cloud-based services that integrate with provider platforms to protect data in cloud ecosystems.

“Although many controls are still managed internally, SecaaS is emerging as a viable means to enhance security in the cloud environment. Security teams should start considering the use of SecaaS options when designing and architecting cloud security models,” the SANS survey notes.

In the upcoming webcast, Shackleford will be joined by myself (Evident.io’s Andrew Maguire), Intel Security’s Margaret Diego, CloudPassage‘s Sami Laine, and Mark Painter from HP Enterprise Security to discuss:
- How organizations use the cloud
- What types of information they store in the cloud
- What concerns they have about data security
- How much they rely on cloud service providers and what difficulties they face
- What security and data protection technologies they use in the cloud environment
- How they manage cloud users
- And much more
The SANS survey clearly highlights and validates the challenges of cloud migration across companies of all sizes. Organizations moving workloads to cloud architectures such as Amazon AWS understand the flexibility and cost efficiencies gained – but often struggle with new best practices and the shared responsibility needed to maintain a secure cloud-computing environment.

The porting of traditionalsecurity technology and Agent-based solutions used in the past do not translate well to cloud environments, leaving customers with too much data and poor visibility into critical service configuration or controls that could eventually lead to compromise.

Webcast attendees will be among the first to receive the whitepaper. Join us Wednesday, September 23, at 1:00 PM EDT (17:00:00 UTC) for this timely and informative webcast!
September 23, 2015
DevOps Leadership Series: Gov Does DevOps

This past week, I had the opportunity to catch up with some more industry thought leaders at the DevOpsDays DC event in our nation’s capital. This was the first major DevOps Days event to feature a large audience of government participants. It was an awesome event and is certainly going to be on my must-attend list for next year.

First off for the series, I had the chance to chat with Nathen Harvey, the Community Director at Chef. Nathen also did a great job leading the organizing committee for DevOps Days DC.

In this episode of the DevOps Leadership Series, Nathen illustrates some recurrent topics he noticed at DevOpsDays DC. Nathen ensures us that government is ready for DevOps, enterprises are ready for DevOps, and small businesses and web innovators are ready for DevOps. Then he highlights how we need to create high velocity organizations that are safe, scalable, and humane for our teams.

https://youtu.be/hdUl8-d1za4

Next, I had the pleasure of catching up with Greg Elin, the Executive Director at GovReady and former Chief Data Officer at the FCC. What really stood out to Greg at the event was how many people already have their DevOps “sea legs.” He notes the number of different organizations that are comfortable with DevOps, and are familiar with its language and concepts.

https://youtu.be/XoZ4PGIAZx4

Finally, I caught up with Dave Johnson, Senior Technical Director at Ansible. Dave shares that “the market really is not dominated yet by any particular player in this (DevOps) space.” Dave explains when he first entered the industry he thought the IT world was dominated by open source and commercial technologies. However, when talking to the industry at large now, he found most the enterprises aren’t yet doing anything yet for automation, and most enterprises are still tackling their problems with humans.

https://youtu.be/ky51j1-fNsU

Next up in the series, you’ll hear from John Willis (Co-Author of the upcoming DevOps Cookbook) and Leon Fayer (Vice President at OmniTI).

If you have missed any of the other videos from this series, you can find them here. (We’re up to 15 so far).

June 22, 2015
7,600 Open Source Projects Per Company (and how it impacts DevOps)

That Supplier is Better For You

Since releasing the 2015 State of the Software Supply Chain Report, there has been a lot of great discussion across the industry on best practices for managing the complexity introduced by the volume and velocity of the components used across your software supply chain.

Today I want to focus on the huge ecosystem of open source projects (“suppliers”) that feed a steady stream of innovative components into our software supply chains. In the Java ecosystem alone, there are now over 108,000 suppliers of open source components. Across all component types available to developers (e.g., RubyGems, NuGet, npm, Bower, PyPI, etc.), estimates now reach over 650,000 suppliers of open source projects.

Source: ModuleCounts.com

However, like in traditional manufacturing, not all suppliers deliver parts of comparable quality and integrity. My latest research, the 2015 State of the Software Supply Chain Report, shows that some open source projects use restrictive licenses and vulnerable sub-components, while other projects are far more diligent at updating the overall quality of their components. Choosing the best and fewest suppliers can improve the quality and integrity of the applications we deliver to our customers.

While I am hosting a webinar next week to share many of the detailed report findings, I wanted to share a few of the more meaningful stats here.

Your 7,600 Suppliers

My research for the report revealed many new perspectives on “suppliers” across the software supply chains. First of all, I saw that the average large development organization consumed over 240,000 open source components last year — sourced from over 7,600 open source projects.

Average number of open source component downloads per organization in calendar 2014

On the surface, the huge reliance on open source projects is a great thing. Development teams have chosen to not write those pieces themselves, but have sourced the needed components from outside suppliers. This practice speeds development, enables more innovation, and ensures time-to-release goals are achieved. The use of open source is so prolific today, few of us could ever imagine reducing the use of those components and their suppliers in the future.

At the same time that we benefit from open source, our high paced, high volume consumption practices don’t allow us the time needed to do the due diligence on the suppliers or open source projects where we source our component parts from.

Average number of known vulnerabilities downloaded by organization in calendar 2014.

For example, of the 240,000 average component downloads in 2014, the same businesses sourced an average of 15,000 components that included known security vulnerabilities. In many cases, developers were downloading vulnerable component versions, when safer versions of those same components were available from the open source projects. While no one intends to download components with known vulnerabilities, the problem is exacerbated due to the lack the visibility into a better recommended version.

Fewer Suppliers, Less Context Switching

Choosing an open source project supplier should be considered an important strategic decision in organizations because changing a supplier (“open source project”) used is far more effort than swapping out a specific component. Like traditional suppliers, open source projects have good and bad practices impacting the overall quality of their component parts.

Traditional manufacturing supply chains intentionally select specific parts from approved suppliers. They also rely on formalized sourcing and procurement practices. This practice also focuses the organization on using the best and fewest suppliers — an effort that improves quality, reduces context switching, and also accelerates mean time to repair when defects are discovered. One industry example from the report describes how Toyota manages 125 suppliers for their Prius to help sustain competitive advantages over GM who manages over 800 suppliers for the Chevy Volt.

By contrast, development teams working with software supply chains often rely on an unchecked variety of supply, where each developer or development team can make their own sourcing and procurement decisions. The effort of managing over 7,600 suppliers introduces a drag on development and is contrary to their need to develop faster as part of agile, continuous delivery and devops practices.

Coming to Terms

When you come to terms with the volume of consumption and the massive ecosystem of suppliers you can source your components from, you quickly realize it is impossible to address this issue with a manual review process. Any organizations clutching to these outdated manual practices are will continue to be outgunned by the velocity by their software supply chains.

Just as traditional manufacturing supply chains have turned to automation, software development teams need to take the same approach by further automating their software supply chains. Information about suppliers and the quality of their projects needs to be made available to developers at the time they are selecting components. Information about the latest versions, features, licenses, known vulnerabilities, popularity of versions being used, and the cadence of new releases should be made available to developers in an automated way. Automating the availability of this information about suppliers can lead to better and fewer suppliers being used.

Be sure to read the full 2015 State of the Software Supply Chain Report for more information about open source suppliers and organizations sourcing practices. The report also highlights current and best practices being used in organizations that are managing their use of suppliers that feed their software supply chains.

To hear more about the overall report findings and industry best practices, please join me on Wednesday, June 24th (1pm ET) for our webinar.

June 19, 2015
DevOps Leadership Series: Gov Does DevOps (Part 2)

During my second day at DevOpsDays DC, I had the opportunity to catch up with a couple more industry thought leaders. First up, John Willis, (@botchagalupe) DevOps Days core organizer and co-author the upcoming “DevOps Cookbook”.

In this episode of DevOps Leadership Series, John highlights his first introduction to DevOps and the journey it has taken him on, and what about the current state of DevOps makes him excited. He says DevOps is really happening everywhere. Today large organizations and CIO’s of government agencies are now experimenting with DevOps at all stages. He references legacy companies that do not necessarily have “aggressive IT”, and how they now want to share their DevOps experiences.

https://www.youtube.com/watch?v=jU1O2bCU_hc

After that, I had the chance to chat with Leon Fayer, (@papa_fire) Vice President at OmniTI, following his DevOps Days DC presentation. Leon illustrates the things he found most interesting from the DevOpsDays Conference. He noted that a lot of people have started to pay attention to the monetary strategies, and how to monitor from top-to-bottom in a DevOps fashion. Leon was happy to see that people are now more generally interested in how to generate and collect data more accurately to solve their problems.

https://www.youtube.com/watch?v=kx4Y3P3Njro

June 17, 2015
DevOps Leadership Series: Compliance, Testing, and Rugged

This past week, I headed to London for the Rugged DevOps event, where I had the chance to catch up with a few more industry thought leaders.

First, I caught up with Gareth Rushgrove from Puppet Labs, who also runs the DevOps Weekly newsletter. In this episode of the DevOps Leadership Series, Gareth explains why the importance of security tests within DevOps practices is going to be a big topic for years to come. Gareth anticipates that “In five years time we will look back on this and ask ‘why were we not always doing this’?”

https://www.youtube.com/watch?v=ktpkmGv5gX4

I then caught up with Helen Beal, Head of DevOps at Ranger4, where she discussed the importance of DevOps and security. While the two ultimately need to work hand and hand, she voiced concerns about DevOps practices sometimes circumventing controls that are essential to a business’s safety. She also said that DevOps supports security in a number of ways: from making things consistent to relying on more automation.

https://www.youtube.com/watch?v=W4Zs1SSjGFs

Finally, I caught up with Justin Arbuckle, Vice President, EMEA & Chief Enterprise Architect at Chef. He discusses key trends he expects to see in over the next 9-12 months regarding compliance and security. Justin explains that compliance as a core driver of DevOps is something that will start to shape our conversations over the next year, whereas the two have previously been seen as contradictory. He believes that we will see that high velocity organizations are able to improve compliance continuously, and tells us to look out for the changing role of the security officer in 2015.

https://www.youtube.com/watch?v=ojEOqRJey2o

Next up in the series, I head to the United States Capitol, Washington DC, for DevOps Days DC.

NOTE: If you have missed any of the other videos from this series, you can find them here. (We’re up to 15 so far).

June 10, 2015