devopsy.kinsta.cloud

Category: Features

DevOps Security in Spotlight as Gartner Names vArmour Cool Vendor

News Reports vArmour CEO Eades Nabbed $41 Million Ahead of Trump Presidency

In May, Gartner named 2016 Cool Vendors in several security categories. Given the focus of this column, I was interested in several of the companies chosen for the designation, especially those named in the Cool Vendors in Cloud and Emerging Technology Security 2016 report. Interestingly enough, only vArmour, one of the new-era cloud security and visibility providers, was noted for supporting security in DevOps environments.

Click to Tweet: Cloud Security #CoolVendor @varmour noted by @Gartner for #DevSecOps, datacenter vis. The latest @devopsdotcom: http://ctt.ec/uSRLd+

In the report, analysts Joerg Fritsch and Brian Lowans wrote:

Supporting the vision of a software-defined data center, all of the capabilities of the vArmour platform are exposed and consumable programmatically via APIs, providing support for highly automated and DevSecOps-type development workflows.

The analysts also noted vArmour enables application-aware microsegmentation anywhere, from the data center to the cloud and all hybrid points in between. They also highlighted its capabilities that extend security to virtualized environments and containers—security anytime and all the time. Pretty cool, indeed.

The report provides deep validation for a message vArmour has been pushing since its emergence from stealth—visibility. While many security vendors have interlaced the keyword into their marketing content, this report makes the claim for vArmour all the more true. According to the report:

vArmour’s distributed security platform combines a scalable fabric with advanced security analytics that offer full visibility from a deep packet inspection engine. This deep visibility enables other cool use cases, such as network-based threat detection and the visualization of workload traffic. This is required in environments where the workload, the network and the security policies are interacting much more closely than we have been used to in traditional environments.

Validation from firms such as Gartner can carry heavy weight among buyers, especially among deep-pocketed enterprise influencers. I’ve had conversations with C-level security execs at numerous mega corporations in the past who have stated point-blank that they won’t approve expenditures for any technologies that aren’t noted in recognized industry reports.

vArmour also announced recently the closing of a $41 million round led by Redline Capital and Telstra. This D round lifts the software-defined security provider’s total investment to $83 million.

In the official company release, vArmour stated it will use the capital for “global expansion and to accelerate worldwide software distribution of its Distributed Security System (DSS) through strategic partners in Asia-Pacific, EMEA and in North America.”

Although the Presidential race wasn’t mentioned in the release, it was reported by CNBC’s Ari Levy that the real reason CEO Tim Eades sought funding now was in anticipation of a Donald Trump presidency. Eades was quoted in the CNBC story as having said:

It really does matter what people think of the U.S. as we lead up to the election,” said Eades, a native of the U.K. who moved to the U.S. 18 years ago. With Trump, “the conversation he’s had around Mexico, trading abroad, his position on immigration — everybody outside America looks in and says, `What’s going to happen?’

Levy continued:

With Trump having closed the gap on Clinton in the polls less than six months before the election, Eades said it’s definitely time for start-ups to be padding their cash positions. He isn’t comforted by the fact that Trump is a businessman himself.

To most reading this, vArmour being named a Cool Vendor and handily raising $41 million likely isn’t coming as a surprise. Starting with Eades, the company has an impressive cybersecurity and business leadership pedigree, especially when it comes to startups that are shaking up security thought and practices around the data center, cloud and DevOps movement. Eades is even viewed as a thought leader—likely one of the reasons why he is an occasional guest on global news shows such as Fox and Bloomberg, where he has been called to provide expert analysis on everything from cyberwar to breaches to investment.

His vision to extend security to the rapidly growing trends of DevOps, cloud, containers and automation is certainly smart, as these are directions most enterprise IT organizations are headed. Said Eades in a company issued release on the funding:

It has been an amazing 18 months since we launched our company. We now have hundreds of customers adopting the vArmour Distributed Security System on a global scale, including some of the world’s largest telecom companies, banks, healthcare, retailers and U.S. government agencies. We believe Gartner’s ‘Cool Vendor’ recognition further validates the positive impact and true value we’re providing our customers. We’re offering them the industry’s simplest, integrated data center and cloud security solution to prevent, detect and remediate advanced persistent threats inside their network.

June 17, 2016
Q&A: CNCF on Instilling a DevOps Culture, Part 1

The Cloud Native Computing Foundation (CNCF) is a non-profit comprised of some 49 industry participants that have come together to drive development and adoption of cloud-native applications and services. The CNCF is uniting such giants as Google, IBM, Intel and Cisco Systems to distill a collection of container technologies that end-user companies deem praiseworthy to reach its goal.

The CNCF intends its membership to represent end users (the CNCF website lists one end user, Goldman Sachs), cloud and container technologies, online and IT services, and academic institutions.

On behalf of the CNCF, Craig McLuckie, its Governing Board chair, and Brian Grant, its Technical Oversight Committee representative, weigh in on leading the DevOps transformation and instilling a DevOps culture in this two-part Q&A.

DevOps.com: How is the CNCF specifically involved in leading the DevOps transformation by instilling the DevOps culture, in the industry or in member companies, for example?

McLuckie: We believe that at the heart of the DevOps culture is the need to reduce the friction and, indeed, the barriers between teams that build an application and the teams that run an application. Developers learn to think about an application as a living service that evolves continuously and rapidly to meet the evolving business needs. Operations is there to deliver the tools and environment needed for them to successfully drive their application.

DevOps.com: Why do developers need an environment that is safe to change? What kind of change? Safe how?

McLuckie: Safe change has many potential meanings: The first kind of “safe” is about creating deterministic behavior in operations. Does the system handle a change correctly every time? If I make a change to two systems, will they have the same state? How about to 1,000 systems? It’s important to focus on creating strong determinism by removing the moving parts in a production deployment.

The second kind of “safe” is about being able to validate that a change is good—not just in pre-production environments, but in the actual production environment—with a simple and deterministic rollback. It is important to make it trivial to replicate environments, and offer a way to run a simple experiment in production (e.g. route 1 percent of my traffic to this new version) with the option to deterministically roll forward or backward without effort.

A third kind of “safe” is about being able to ensure that every change is deliberate. One of the problems we often see in production systems is “configuration drift” that isn’t driven through any kind of formal process. This should be addressed by creating a strongly declarative toolset that makes every change deliberate and trackable.

DevOps.com: How do you recommend providing these things that developers need? How do you help provide them?

McLuckie: There are multiple issues like data, security governance and applications that need to be addressed. Additionally, companies want to deliver apps with high velocity. How do you solve all of this? A vendor-neutral organization that can harmonize emerging technologies is important for facilitating cloud-native. Given the large number of players in the marketplace with competing approaches, having an open source way to solve this is also important.

Grant: Cloud-native infrastructure enables self-service and “hands-off” operation, including provisioning, deployment, scaling, healing, discovery, monitoring and more, with relatively little marginal effort for specific applications. By supporting open source projects such as Kubernetes and Prometheus that provide such functionality, the CNCF hopes to democratize high-velocity application delivery, which was previously achievable mainly by web-scale companies.

DevOps.com: How does this align with instilling a DevOps culture?

Grant: In a DevOps culture, operators are both partners and customers of the developers. Developers take responsibility for meeting operational requirements: security, reliability, availability, scalability, efficiency, actionable monitoring and logging output, necessary configurability, compatibility with the production environment, etc. Cloud-native infrastructure provides mechanisms developers and operators need to facilitate and capitalize on those capabilities.

Stay tuned for part two of the CNCF interview.

June 14, 2016
DevOps Chat: Nathen Harvey, Chef

I recently had the pleasure of catching up with Nathen Harvey of Chef. And I do mean catch up. As VP of community development, Nathen keeps up an amazing pace of visiting Chef communities around the world. In this role who better to understand what DevOps practitioners are seeing? Nathen and I spoke about several things including Chef’s security and compliance capabilities. Below is the streaming audio of our conversation and below that is a transcript of our discussion to follow along.

Enjoy!

Alan Shimel:                Hi. This is Alan Shimel for another DevOps Chat here on DevOps.com. Today’s guest is Nathen Harvey, VP of Community Development at Chef. Hi, Nathen. How are you?

Nathen Harvey:           Great, Alan. How are you doing today?

Alan Shimel:                Good. Nathen, I’m going to bet that most of our audience already knows who Nathen Harvey is and what your role is at Chef, but maybe for the few who are unfamiliar, why don’t you give our audience a little bit about what it is you do as a VP of Community Development at Chef?

Nathen Harvey:           Yeah. I get asked that question a lot, Alan, and I’ll tell you that the real definition is this. There are two parts to it. The first being VP of Community Development means that none of my code runs in production and that makes the world a much safer place, if we’re being honest.

Alan Shimel:                Okay.

Nathen Harvey:           The second thing is before I joined Chef I did actually have code that ran in production. I actually managed a bunch of production infrastructure. So when I moved from an operations role into a community management role, the thing I like to say about that is I put down the pager and I picked up the bar tab. Oddly though, I’m up at 3:00 AM either way.

Alan Shimel:                Yeah. Well, I think that’s just part of today’s work environment, where everyone is up it seems at 3:00 AM, depending where you are in the world.

Nathen Harvey:           But joking aside, it’s really about going out and meeting with our community and helping fuel the love of Chef, helping folks in companies large and small get better at automation, get better at dev-ops, get better at great software development and infrastructure practices.

Alan Shimel:                Yeah. And, Nathen, you’re not kidding about seeing people the world over, too, as part of your role, because I follow you on Twitter, I follow where Nathen is speaking, and whether it be a local meet-up group or a Chef users’ group or a conference or customers, you literally are traveling the world constantly.

Nathen Harvey:           Yes indeed.

Alan Shimel:                Yes, preaching the Chef message. Nathen, I wanted to focus our talk a little bit today around one of my favorite subjects, security, infosec, whatever you want to call it. Chef has become one of the leaders and has been for some time – one of the leaders in security within the dev-ops movement, if you will.

I had the pleasure of becoming friends with Justin Arbuckle a year, year and a half ago. Justin was out preaching – what was it – compliance at Velocity or something? I may be mistaken.

Nathen Harvey:           That’s right, compliance at Velocity. You bet.

Alan Shimel:                You know, for a long time and it resonated with me. Then of course I think Chef made an acquisition, a European company who sort of had a compliance vulnerability scanning for code.

Nathen Harvey:           Yes.

Alan Shimel:                And now you guys have really kind of laid down the gauntlet on this and really put the pedal to the metal in talking about why it’s important to do this and why it’s important to do it earlier. I don’t want to steal your thunder. Can you give our audience a little bit of your opinion on why it’s important and what should be done?

Nathen Harvey:           Yeah, sure. Look, Alan, in a traditional way of developing our software we all fall under some sort of regulatory burdens. We all have auditors or other security controls that we need to make sure are implemented within our production systems, and the traditional way of doing that, at one point in your development workflow you might introduce a security scan into the development workflow itself before you go to production, but usually that ends up just being a blocker for moving flow, moving change across your organization.

So you’ll oftentimes pull that security scan out and then just start scanning your production systems. But for me, scanning the production system is kind of like the oil light on your dashboard. When it comes on, it’s too late. You have to have solved that before you get into the production environment.

So at Chef, really we look at our roots with automation and our ability to fully customize and fully automate the buildup and the maintenance, configuration management of your infrastructure over time, your infrastructure and your applications. We say that we need to make sure that we’re always in compliance, but it’s also very important for us that we start to adopt more of the development workflow, more of the software engineering principles.

One of those principles of course is that we should do test-driven development. Well, why not take those controls and those audit controls that you have to enforce and move those directly into the development workflow? You certainly see many cases where you’re doing, say, static code analysis during your continuous delivery pipeline or during your continuous integration. But what about moving that even further back and doing not only static analysis of your code, but also actually testing what does the running application actually look like? Is it exposing ports that it shouldn’t? Is your infrastructure configured properly? And can you do that on the developers’ workstations, move that -? We like to say you’re moving compliance to the left. If you think about your change flows from left to right, from your developer’s workstation all the way out to production, how do we get and start thinking not about how to scan the production environment better, but instead how to start making those controls into your developer’s workflow?

Alan Shimel:                Yep. Nathen, as a security person that’s almost radical to me. I will tell you, having spoken to many security people about this, we actually put on a DevSecOps day, a Rugged DevOps day at the RSA conference last year in San Francisco and Justin spoke there. A lot of security people, this makes them very nervous, believe it or not, Nathen, because it’s not them doing the scan. We’re going to ask developers to scan their code on their workstation, while I’m not there to see it, right, or not there to make sure that the code is right?

Nathen Harvey:           Right, right.

Alan Shimel:                Go ahead. I’m sorry.

Nathen Harvey:           Let’s look at that. In the past, and I understand where these security folks are coming from, but if we look at today’s enterprise and the way that software is built today, security folks want to be the ones that are doing all of the scans, that want to be the ones that are making all of those assessments. On the one hand that’s fine. They should absolutely be involved in those assessments. But, frankly, if it’s the security team only that’s responsible for that, it’s simply not going to get done. The security teams aren’t big enough; don’t have enough capacity to keep up with the rate of change. They’re going to become a blocker in the enterprise and that’s going to become a real problem.

So it’s really that security professional’s goal or the way that they need to look at this is, first, automation makes their job much, much easier. Not only can we remediate things that are found much, much faster, but we also gain consistency and things like that.

But if we can then partner with the development team, with the engineers that are building out those systems and get them to think of security as a first level concern and compliance as a first level concern and start being partners with us, like we’re partnering with them, we’re not abdicating our responsibility to them. Frankly, some of the scans that the security team is going to run in the production environment, they’re still going to run those, but what we’re going to find by giving developers better tools to run those scans sooner, to ensure compliance earlier in the process, that those scans are going to find fewer and fewer vulnerabilities, and those vulnerabilities that are found we’re going to be able to address and remediate much, much faster.

Alan Shimel:                And I might add, Nathen, not only much, much faster, but much, much cheaper. I mean I’ve seen studies where it’s something like 10x to 100x cheaper to take care of a vulnerability or a compliance issue at that shifted left stage, where it’s still on the developer’s workstation rather than on some cloud instance. Right?

Nathen Harvey:           Absolutely. That may feel radical, but it’s really just we’re going back to our roots. I mean we’ve known for decades that fixing a bug in the development process is much less expensive than fixing it after that bug has been released into your production environment. The same is true for a security control or a compliance control.

Alan Shimel:                I agree. I agree with you. Nathen, I have another issue I wanted to touch on with you, and that is some people get hung up on the compliance, the C word, so compliance versus security. They’re not synonymous, right?

Nathen Harvey:           They are not. They are not at all synonymous, no. I think that compliance – Alan, let’s think about this. You have a CEO at a company who has to sign off and agree to – have auditors come in and assess whether or not they are compliant. Frankly, when an auditor walks in the building, there are many, many organizations who say, “Our number one objective when the compliance person walks in, when the auditor walks in is to get them to sign off on our audit and leave as quickly as possible. I don’t want them meddling in my business. I want to get them out of here.”

Alan Shimel:                Yep.

Nathen Harvey:           So with that approach, what we really do is try to make sure that we can run compliant systems, and compliance is there so that we can assess whether or not we are secure, but security really needs to – it’s a different mindset than compliance. Compliance sometimes is the easier place to start. I want to make sure that my audits are passing. When I have audits that are passing, I can sleep at night knowing that my audits are going to pass. Then I can start to look broader at the system in terms of: am I actually building a secure system? But, frankly, security is the foundation and compliance is what sits on top of that.

Alan Shimel:                Yes, absolutely. Nathen, the other thing I think that really has enabled – and maybe it’s a little bit of a chicken or an egg kind of issue – does this enable them or they have enabled the compliance issue? Developers are taking to heart the fact that security is everyone’s responsibility, and the fact of the matter is it starts with them. Right?

Nathen Harvey:           Absolutely. Alan, we’ve seen similar things in the past. Look at QA teams, where developers have said, “You know what? We’re going to start doing test-driven development. We’re going to adopt some of those practices.” And the QA teams get nervous, “That’s my job.” The problem with having it be someone else’s job is you’re not going to do it. You’re not going to be concerned with it.

So, really, just like our QA professionals are now partnering with the devs, the security professionals and compliance officers are now partnering with the development teams. Frankly, that’s what dev-ops is all about. It’s about this working together towards those common goals and getting there as quickly as we can.

Alan Shimel:                Yeah, absolutely. And it’s good. It’s good on so many levels to have the security team integrated with the devs, to be working closely with both dev and ops, dev-ops, and making it happen because, frankly, that’s what attracted me to dev-ops to begin with, was the promise of being able to do that instead of being the appendage at the end of the Rube Goldberg kind of –

Nathen Harvey:           Absolutely. Alan, what you’re really looking at there is we’re talking about a partnership. So there are some cultural or some workflow changes, some partnering that we have to do across the organization. The thing that helps enable that also is the tooling. The tooling definitely matters and the two, culture and tooling, are there to reinforce one another.

So with Chef, we have a new open source language called InSpec and that’s the tooling that allows the developers to actually write these compliance controls, execute them locally. Frankly, it allows them to write them in a way that’s delightful, in a way that a developer understands, that a business analyst can look at those tasks and understand exactly what’s happening.

Then with Chef compliance we also introduce those same compliance controls into our own scanner capability, where you can scan against your production environment, find vulnerabilities, go back into your automation code, remediate those, and watch that remediation happen across the entirety of your pipeline.

Alan Shimel:                Fantastic. Nathen, as I had told you earlier, before we started recording, our time is limited, but for folks who maybe want to find out more about compliance scanning, more about Chef’s capabilities in this area, where can they go to get more?

Nathen Harvey:           For sure the place that they can go is www.chef.io/compliance. Again, I just want to stress that the scanning capabilities are absolutely important, but really what we need to do is shift our mindset and think about: how do we start writing tests for those controls and do those early on in the process? Not that scanning should be an afterthought, but we really do need to focus on that beginning stages of our development process.

Alan Shimel:                And automation, automating that is key. Nathen, we’re almost out of time here. Unfortunately, it always goes too quickly. But I wanted to ask you one last question, which we usually ask our guests here on DevOps Chat. That is one book, if you had to recommend one book to our listeners that they should read maybe over the summer or in the near future, what book would that be?

Nathen Harvey:           I would recommend Lean Enterprise: How High Performance Organizations Innovate at Scale. It’s a book by Jez Humble, Joanne Molesky, and Barry O’Reilly.

Alan Shimel:                It’s actually on my bookshelf. Cool. I love it when someone suggests a book I’ve read actually. Very cool, Nathen, and it is a great book. Jez’ Lean Enterprise book is great as of course is the Continuous Delivery book.

Anyway, Nathen, we’re about out of time here. So I wanted to thank you for being our guest on DevOps Chat. Continued success with your globetrotting VP of Community Development role at Chef, and continued success to Chef in general there. It’s one of our favorite companies in dev-ops and we love what they’re doing.

Nathen Harvey:           All right.

Alan Shimel:                And maybe we’ll get you back on again soon.

Nathen Harvey:           Yeah, that sounds great. Thanks so much, Alan.

Alan Shimel:    Okay. This is Alan Shimel with Nathen Harvey, VP Community Development of Chef for DevOps Chat. Thanks and we’ll see you next time.

June 9, 2016
Black Duck Targets Open Source Code Security Flaws

Open source platforms and projects offer a wide variety of benefits for organizations and developers, but they also can introduce vulnerabilities if you’re not careful. That’s why Black Duck has released Security Checker, a free tool based on its Hub open source security tool to help you identify those vulnerabilities so your applications will be secure.

One of the advantages of open source is also a potential concern. Open source software has benefits from community cooperation and collaboration. More eyes and more hands contributing to the development allow for faster evolution and greater innovation. However, when all of the code is available to the public, and any developer can add or change the code, it also is an opportunity to introduce problems.

While theoretically it is possible for a malicious developer to intentionally add vulnerabilities or exploits, the collaborative nature of open source projects actually makes it less likely. Any obvious attempt to insert malicious code would be detected and thwarted by other developers. The communal nature of open source development is not infallible, though, as evidenced by recent major revelations such as Heartbleed.

Open source projects that are active and properly maintained address these issues fairly quickly. The problem, however, is that organizations and developers need to be able to easily determine whether their existing applications are affected and apply the appropriate patches and updates. There also are many open source tools that are not being actively developed or supported, which means known vulnerabilities may be left unfixed.

Security Checker from Black Duck can help minimize exposure to these risks and give organizations and developers an opportunity to address any known issues. The tool is a drag-and-drop solution that allows you to scan code contained in an uploaded archive file, such as a .tar or .zip file, or in a Docker image. Security Checker then generates a report that shows identified vulnerabilities and security issues.

A recent report from Black Duck found that 67 percent of audited applications contain known open source security vulnerabilities. More than a third of the vulnerabilities identified were classified as “severe.” The most notable finding, however, is that 10 percent of the applications surveyed still contain the Heartbleed vulnerability, which was discovered in April 2014.

“Applications represent the greatest level of risk on the security threat landscape, and we expect that Security Checker scan results will provide an ‘a ha moment’ for many open source users,” said Black Duck CEO Lou Shipley in a press release statement. “Their findings will focus attention on the need to regularly review application code to ensure it’s free of known open source vulnerabilities.”

The process of scanning and generating the report takes about 15 minutes, according to Black Duck, which also noted the maximum file size Security Checker can scan is 100MB.

June 6, 2016
Open Source Is the Secret Sauce of DevOps

DevOps is a relatively recent phenomenon—especially compared to the world of open source. While DevOps and open source are two entirely separate things, though, the reality is that it’s difficult to separate the two at this point. Many open source projects rely on DevOps tools and principles, and DevOps depends heavily on open source applications as both the glue that binds it all together and the engine that keeps everything moving. A new report from DevOps.com, “DevOps and Open Source,” digs in to understand the symbiotic relationship driving the next generation of IT.

“DevOps and Open Source” examines the role of open source in DevOps, whether DevOps can succeed without open source, the unique challenges of leveraging open source tools, and the benefits of open source partnerships with large corporations such as Microsoft and IBM. The report also includes a list of some of the most widely used open source tools for DevOps, including Chef, Puppet and Docker.

Leveraging open source tools gives organizations and developers much more flexibility and control. Because the underlying code is available, it provides an opportunity to customize it to fit unique scenarios or to create the necessary APIs to integrate the open source software with other tools. The fact that there is no single vendor that “owns” the software also means that organizations and developers can build on open source tools with the confidence that the apps will not arbitrarily disappear one day.

You can definitely develop or use open source applications without embracing DevOps, but is it possible to do DevOps effectively without using open source? “Maybe,” says Randy Kilmon, vice president of Engineering at Black Duck. “But who would want to do it that way? With so many great open source tools and components out there, deliberately shunning them would be a mistake. Besides, there is a piece of open source somewhere in your stack, whether you know it or not.”

That statement seems to be more true with each passing day. The growing momentum of DevOps and the mainstream acceptance of open source software form a powerful partnership that is transforming how applications are developed, deployed, monitored and maintained.

“Organizations want to advance their technology practices and stay ahead in very competitive industries, and do so in a mindful way,” explains Jose Miguel Parrella, senior product marketing manager of Cloud Platform Marketing for Microsoft, in the report. “DevOps can help reconcile the organizational needs, add value to the business, streamline the IT value delivery process and leverage open source innovation.”

The report sums up with this: “The simple fact is that the fundamental concept of DevOps—the culture shift organizations embrace to change how teams cooperate and collaborate so that projects can be delivered more effectively and efficiently—more or less requires a dependence on open source tools. A DevOps environment is too fluid and evolving to sit idly, waiting for a commercial vendor to develop a product with just the right set of features and capabilities.”

The report is available for download here.

June 1, 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. DevOps.com 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
Echidna Takes DevOps to E-Commerce Site Creation

The Echidna e-commerce firm installs and evolves e-commerce platforms, providing ongoing development so its clients can leverage e-commerce experiences to the satisfaction of their customers. “We apply carefully selected user experience technology, marketing and analytics abilities to our clients’ strategic goals to do this,” taking what it calls an “anti-Big Bang” approach to continuous deployment, says Mike Pierce, CTO of Echidna.

“Traditional e-commerce deployments were often Big Bang deployments that people developed on the basis that they had to pressure the business leaders into feeling like they had only one chance to pack as much scope as possible into a large software development project. That approach voids any practical innovation,” says Pierce. With that mindset, it can take years to finish e-commerce sites, and e-commerce companies can go out of business by the time they actually finish such a site, since it would be far out of date by then.

Echidna sees continuous deployment as one piece in a much larger agility play designed to ensure that businesses compete in digital economies, now and in the future. Continuous deployment is the ultimate goal of DevOps, an approach that enables the business to innovate fast enough to maintain the business’ sharp marketplace edge through acute, turn-on-a-dime competitive dexterity. “In order to do this, continuous deployment helps companies learn to develop high-quality software and deploy it on a rapid, reliable and repeatable schedule,” says Pierce.

Continuous Deployment Timelines and Challenges

Depending on the client, its needs and the features in the pipeline, Echidna deploys software to each e-commerce platform from monthly to daily, and at intervals in between those extremes. Echidna seeks to increase the degree of automation of each deployment over time. The challenge is that with so many different clients and platforms, Echidna must achieve its automation victories for each customer individually, solving similar and unique issues. “We are finding our greatest success using PaaS (platform-as-a-service) e-commerce platforms like Four51 because it eliminates a lot of the administrative overhead that is typical with deployments to on-premise platforms,” says Pierce.

The development model Echidna follows to deploy e-commerce sites affects each software component, even though components deploy at different times. “Payment system modifications require significantly different testing—more testing—and we must deploy them much less often than other components. Marketing components don’t need as much regression testing as other software modules and so we can deploy them much more quickly,” he says.

The most difficult software to move into continuous deployment in an e-commerce platform are the components that integrate deeply into enterprise systems. That is why Echidna advises business customers to use DevOps methodologies to deploy their enterprise production software at accelerated rates. When they do this, Echidna potentially can speed its deployment of the e-commerce platform components that are enmeshed with those production systems.

The Four51 Path, Through Jitterbit

Echidna connects Four51’s OrderCloud to the Jitterbit iPaaS integration server platform, a point-and-click integration tool. “This enables us to streamline further integrations and data exchanges with many of the disparate systems in an ecosystem,” says Pierce. Echidna sees increasing continuous deployment orchestration opportunities as more and more third-party application vendors become compatible with these kinds of integration tools.

Four51 enables an ecosystem of connected digital services and applications where e-commerce uses numerous disparate systems that exchange data and facilitate work streams in the enterprise in question, Pierce says. “As these systems eliminate disparities and we align them on the central integration and deployment standards that we use, there will be increasing opportunities to introduce clients to lean development practices like continuous delivery and continuous deployment.”

Conclusion

Continuous deployment is miles apart from what information technology is used to, especially where manual change management and change control are concerned. But once Echidna exposes its customers to continuous deployment, their managers, C-levels and boards soon begin to witness the accelerated software innovation continuous deployment provides and how this makes information technology—and the business—more nimble, both technologically and competitively.

May 25, 2016
Continuous Delivery and Deployment: A Tale of Two Models

EnerNOC (Energy Network Operations Center) is an energy intelligence software provider with more than 1,300 employees in its Boston headquarters and international locations. The public firm helps global customers to efficiently consume energy. “Our mission is to change how the world uses energy, helping customers to improve profitability and visibility for better decision-making and sustainability by focusing on how they buy energy and when and how they use it,” says James Nichols, principal engineer and cloud architect at EnerNOC.

A regular user of Splunk (the company uses other DevOps tools and platforms as well, including AWS and Oracle), EnerNOC has fully automated monitoring in its perpetual drive to move past continuous delivery and on to continuous deployment.

Embedded in EnerNOC’s story of why it uses continuous development and continuous deployment models is a chapter on its move to fully automated monitoring.

EnerNOC DevOps Models

EnerNOC’s DevOps model is in constant transition toward full automation. Currently, it has fully automated deployment, fully automated monitoring and semi-automated quality assurance (QA), which pull the company’s continuous development approaches.

A change to “builds on commit” of smaller applications within the legacy software monolith at EnerNOC came hand in hand with further automation, targeting what the company calls “trustworthy continuous deployment,” Nichols says. That was the crux of EnerNOC extending itself into deployment automation.

Wherever the model is not fully automated and continuous in deployment, it remains continuous delivery. “Most of the variance between the approaches is due to aspects of the delivery pipeline that still have manual processes; these parts are usually comprised of the remaining manual testing procedures,” says Nichols.

Change Control Necessitates Two Models

EnerNOC develops and maintains mission-critical software that must pass through a change management approval process. This process includes communications within and across the company and customers, as well as user acceptance testing. This is where the manual testing comes in. Only at the end of this approval pipeline can EnerNOC pass the software baton into the hands of production.

Due to EnerNOC’s tightly yoked systems and the manual testing, change control remains, along with a mix of continuous development and semi-automation with fully automated continuous deployment. “DevOps is a cultural movement as well as a technical one, and so the existing model could evolve with the organization’s quality and maturity evolutions,” says Nichols. If the manual testing and the relationships between systems give way to more fully automated testing and more amenable relationships, QA could more closely embrace full automation.

Monitoring Challenges/Achievements

EnerNOC’s application diversity includes hybrid software with a foothold in the Amazon cloud, in EnerNOC’s data centers and on-premises. “We use three tiers on top of Oracle in the data center. In AWS, we use a combination of big data, cloud-friendly and serverless technologies,” says Nichols. Business transaction data traverses many machines that belong to service groups’ stakeholders. “The distributed, decentralized architecture makes troubleshooting, performance management, security operations and production operations challenging,” notes Nichols. Better monitoring was the answer.

EnerNOC wanted to offer nontechnical users easy access to systems-level monitoring data with transparency into the many systems through a single pane-of-glass dashboard with readily available system notices and troubleshooting abilities. “We would use Splunk to do this and then feedback everything we learned from using Splunk into driving our DevOps and engineering processes into the future,” he says.

The EnerNOC DevOps performance team built the dashboard that accompanied the Splunk service, ensuring it would register the performance metrics that are of value to the organization. The performance, product management and development teams maintain an awareness of the metrics and receive the related alerts. “The development team incorporates the ongoing metrics early in the development life cycle to improve application performance,” says Nichols.

EnerNOC first applied Splunk to web logs for operational capacity planning, then used Splunk to give the Ops team transparency into the function of its new real-time data product that was working in production. As new products came on board, the organization added them to Splunk to provide Ops teams with dashboards, at the urgent request of Ops team members.

Current Status: All Systems Good

EnerNOC applies Splunk to test and production systems for views into consistency and acceleration. “Splunk is our primary alerting infrastructure for low-level system metrics like CPU utilization as well as for complex business transactions that span multiple systems,” says Nichols. Splunk has eyes on application health, cluster state across machines, expected systems tasks and suspect or known-bad system behavior, as well as the presence or lack of any significant event.

May 20, 2016
Building DevOps Careers: One Man’s Journey, Part 2

In Part One of this two-part series, we introduced former SlideShare and LinkedIn software engineer Sylvain Kalache, who shared his career growth within the two companies. In this second part, we’ll look at San Francisco-based The Holberton School of Software Engineering, which Kalache co-founded to better prepare students to work in a DevOps world.

School Founder, Still a Coder

Kalache still uses much the same coding skills in his new role as he did as an engineer. “I still manage machines, the ones that host our website and intranet and the iMacs that students use,” he says.

The Holberton School of Software Engineering founders removed every manual step possible, using software to automate the admissions process and any process that they could. Even in the classroom, automation rules: Computers automatically review student work on projects.

“Computers test that students’ code works as expected by simulating user interaction, checking syntax and assessing how fast the code executes. For infrastructure in code, computers check for stability, response times and security breaches. By using multiple ratings parameters that are linked to specific skills, the computers collect detailed data about the strengths and weaknesses of each student,” says Kalache.

“We have a lot of our own secret sauce in software automation running the school for us,” he adds. “This requires all the technical skills I used in my coding days including designing, building, configuring, testing, deploying and maintaining software and systems.”

Teaching Methods

The Holberton School of Software Engineering engages students in building each skill they will need for careers in software engineering through use of industry-standard teaching methods. “Methods include deep learning in building features into software products and classical teaching in clear, documented code,” Kalache says. “We have a team of 150-plus mentors who make sure our curriculum is up to date and in sync with what the industry actually does and who coach and share their knowledge with students.”

The Holberton School of Software Engineering uses fully practical methods with no formal teachers or lectures, only mentors. “Mentors are like managers in a workplace. I mentor, coaching students in their learning journey and giving advice when there are issues,” he says.

Students engage in peer learning, working collaboratively on software projects, which encompass the skills they will need to demonstrate in their careers. Successful completion of projects, including solo projects, is proof of attaining the required skills. “Students must defend their projects before mentors with mentors ensuring that every student can present and explain the technical aspects of the project; if even one student can’t explain it, then the group fails on that project,” says Kalache.

“We teach problem-solving and how to learn new skills because there will constantly be new technologies and concepts for our students to understand and master in their careers in the tech world,” he adds. “Professionals who cannot adapt and retrain themselves will quickly fall out of date with technology.”

Readying Students for Careers from Day One

The Holberton School of Software Engineering prepares students to be ready to work when they start their careers. “Graduates of other programs whom I have spoken with have no idea what it is to ship code to production and run a production environment. They are used to academic projects that teachers correct for them,” Kalache says. “That is not how it works in the industry.

“Even boot camps and universities provide minimal practical experience that will make job hunting difficult,” he continues. Smaller organizations don’t have the money to pay someone to learn before starting them working in production. Thus, he says, startups need to execute fast using professionals with mature skills. “Though our students will fail and struggle, they will do it at the school, which will have a much smaller impact than doing it on the job,” says Kalache. Students are exposed to creating, shipping and working with code in production for two years before graduation.

What’s more, real, workday DevOps requires effective communications skills. “Whether it is to introduce the last tool you built, explain what happened during an outage or convince your managers that your solution to a problem is the right one, you need to have oral and written communications skills,” says Kalache. As such, the school runs students through a series of exercises in public speaking, technical writing and documentation, as well as post-mortem communications when dissecting an outage, prepping them even further for their careers and the world beyond the classroom.

May 19, 2016
DevOps Chat: Gene Kim, DevOps Enterprise Summit London 2016

I recently had a chance to sit down with author and researcher Gene Kim about the upcoming DevOps Enterprise Summit in London (DOES). This is the first DOES out of the US and Gene and team are planning to make it a great success. Below is the audio of our conversation and below that is a the transcript of the conversation.

Of course if you are thinking about attending DOES London, you can also attend next week’s DevOps Connect: CD Summit/Jenkins Days and receive a full credit towards a DOES London ticket. A great 2 for 1 sale. BTW, Gene mentions the DevOps Enterprise YouTube channel in our discussion. Here is the link for it: https://www.youtube.com/channel/UCkyYEVVmT9vQ4yPBR4ciFUA

Enjoy!

Alan Shimel:                Hi, this is Alan Shimel, DevOps.com here for a special DevOps chat with Gene Kim, bestselling author, researcher and DevOps personality. Hi, Gene. How are you?

Gene Kim:                   Doing great, Alan. Oh, my goodness. How about a researcher who loves studying high performing technology organizations.

Alan Shimel:                Okay. Hi, I’m here with Gene Kim, a researcher who loves studying high performing technology associations and writes a good book.

Gene Kim:                   Ah, love it. So much better.

Alan Shimel:                All kidding aside, Gene, it’s a pleasure to have you on our show again. And we’re here to talk about the upcoming DevOps Enterprise Summit, London for 2016.

Gene Kim:                   I love it. In fact, this has been so fun. It’s our first year in London and so it’s been amazing. Sort of tapping you know the network to find great DevOps transformation stories in large complex organizations. But you know after just a lot of hard work on behalf of the entire programming committee, you know I think it’s shaping up to be just a fantastic conference.

Alan Shimel:                Yeah. I mean I had a look earlier today at the speakers announced and you know part of me was really happy that I knew a lot of the names of who are these speakers and part of me was really happy that I didn’t know a lot of the names, right. Because you always want to hear new stories and from new people. So I think there’s something for everyone there. But Gene, you know what I’ve had the pleasure and honor of being on a program committee with you for the RSA Rugged DevOps event we do every year and so forth. But a lot of our listeners may not really understand what goes on behind the scenes and how do you get great speakers. Would you give our listeners just a little bit of like pull back the curtain a bit and talk to us about how you always come up with great speakers?

Gene Kim:                   Yeah. You know in fact, so let me first acknowledge the amazing programming committee that we have. One of them is Owen Gartner who is part of the DevOps initiative at Barclays Capital. Ben Grinnell, he’s at North Highlands Consulting Firm. There’s Marco Swindell from Accenture. There’s Benjamin Wootton from Sendachi Consulting. And then two committee members from the U.S. DevOps Enterprise Summit, which is Damon Edwards and John Willis, who are both a part of the DevOps movement from the very beginning. So the job of the programming committee is really to shape and to kind of form the vision of the conference and shape the talks to help achieve those objectives. And I think what’s been different about the DevOps Enterprise Summit is that you know we really aim to create a vendor neutral conference that really focuses on the technology leaders who are driving DevOps transformations in large complex organizations.

And so it means that with some rare exceptions, you don’t have a lot of the speakers from the DevOps community speaking because they’re not you know in large complex organizations. And so you know the challenge really was to find these amazing stories out there of people driving these audacious transformations in you know very conservative organizations. And you know for that you need people who aren’t just well networked in the industry and in the local market. And so you know we spent, my goodness, five, six weeks just you know scouring our rolodexes, brainstorming about all these – this is where we’ve heard about DevOps transformations going on and then actively reached out and you know vetted them just to gain some assurance that you know they weren’t just talking a good game, but they actually had _____ to show for it.

So you know as a first year conference, you know there was just a tremendous amount of work that went into that.

Alan Shimel:                Sure. And Gene, you know to me it’s obvious why London, right. You know when we look at our own Google Analytics here at DevOps.com, London is the second biggest city from an audience perspective for us. But I’m curious, why did you pick London?

Gene Kim:                   You know it was because that was actually one of the feedbacks that we got from our speakers and attendees, that you know because we’ve had the DevOps Enterprise Summit now going into the third year in San Francisco on the West Coast of the United States, that is a very long way to travel from people in the UK or from the European continents. So you know the ask was, hey, can you hold it somewhere in the European Union, whether it’s in the UK or in the EU. And so we were actually considering London, the Netherlands and there might have been a couple other options, but ultimately we decided to do it in London just because that’s where our network was. And when I say the network, that’s where the program committee was and that’s where I think our network was strongest. Which was very important because I think it gave us the best chance for succeeding and generating you know the right programming, the right speakers and so forth, the right transformation stories.

Alan Shimel:                And you know what, I’ll reiterate it. London is a fantastic town. The DevOps scene there is just happening. Not to date myself and sound all groovy, but it’s a happening scene and it’s a vibrant dynamic DevOps community as well. So I think you couldn’t have picked a better place to do it in, Gene.

Gene Kim:                   You know it’s just a huge center of economic activity. You have a huge financial services industry. You have basically every type of you know industry vertical that are operating, you know in and around London. So, yeah, I agree, it was a great – and also where so much of the progressive DevOps activity is going on within government agencies. Like the UK.gov, the UK Digital Services, all that pioneered inside the UK government.

Alan Shimel:                Absolutely. You’re a hundred percent right there, Gene. So, Gene, listeners who are listening to this, maybe they haven’t quite decided if they want to go to does London or not. Give me right now, have all the speakers been released or announced at this point or no?

Gene Kim:                   No. And we’re about 60 percent announced.

Alan Shimel:                Right.

Gene Kim:                   But I can certainly share with you the talks that I’m super excited about.

Alan Shimel:                Go ahead.

Gene Kim:                   You know one of them is Ron van Kemenade. You know so he is famous for his work at ING as the Global CIO. And so many of us in the DevOps community were aware of the ING DevOps Days that was held in 2011. In fact, that was probably the event that kicked off the first Target DevOps Days and the first DevOps Days at Capital One. You know it was such a novel concept. And so Ron van Kemenade as the CIO, will be talking about you know their journey when ING back in 2011 was very much like Parts Unlimited and the Phoenix Project. You know it was certainly very different from the organization they’ve become where they’ve created a world class technology organization that is widely admired. And so I’m excited that he’ll be talking about his role as the technology leader and to tell the whole inside story of how that transformation happened. And I’m particularly excited that I’ve asked him to share you know in his mind, what does it mean to be a technology leader. You know it’s not about picking Cassandra over Redis, versus Zookeeper, versus NoSQL, versus you know MySQL, right.

So what does it mean? I think that’s not well understood and certainly not well understood by me. You know there’s a talk from Robin Hughes from LV. So that’s the Liverpool Victoria Insurance Company. So multibillion pound turnover company. So again, an organization that’s been around for over a century and you know this is just a phenomenal DevOps transformation that was really driven by the operations team. And Robin Hughes will be telling the story about how they transformed one of the largest business applications inside their portfolio and enabled developer productivity. So I think that’s great. Anthony Collard, he’s the Deputy Director at HMRC. So that’s the Majesty’s Revenue Collection. So in the US we would call it the IRS, Internal Revenue Services. And you know they have over 60 scrum teams now working to help make life better for tax payers. Whether it’s the people at home or within businesses. And it’s just an incredible story about genuine innovation and creation of phenomenal efficiencies that you know haven’t been typically associated with the way government operates.

In fact, I was so inspired by it, I actually wanted to voluntarily pay UK taxes just to reward these amazing efforts.

Alan Shimel:                Don’t count me in on that one, Gene. Thanks. But it’s good for you. Let me also just throw a couple of other names that I recognize and got me all excited. One is actually a friend of mine that I’ve worked with, Jonathan Fletcher over at Hiscox.

Gene Kim:                   Right.

Alan Shimel:                I don’t know how much you know about Jonathan, but he’s brilliant. He’s not the – I don’t want to say the suit, but he’s not the title who leads the entire DevOps transformation there. But that person relies on Jonathan to make it happen. ‘Cause I’ve looked at that organization. This guy, I love listening to him talk about what they’ve done there.

Gene Kim:                   And it’s another phenomenal story. Another insurance company.

Alan Shimel:                Yep.

Gene Kim:                   And I think what makes them so remarkable, so obviously they’re a multibillion British pound turnover company. But again, over 100 years old. And yet they’re growing at 30 percent in certain market segments.

Alan Shimel:                Yes.

Gene Kim:                   When that’s happening its putting tremendous pressure on the technology organization, you know for them to deliver what the organization needs. And so here’s an incredible effort initiative, where they – and this one is driven by kind of an operations platform and architecture that is enabling development teams to respond quickly to the market and scale with demand. Yeah.

Alan Shimel:                Yeah.

Gene Kim:                   I love that Hiscox story.

Alan Shimel:                Yeah. No. The thing about Hiscox is you know though they’re UK based most of their business is on the continent. You know they have a large presence for instance in the Caribbean as well as the Western U.S. So this is a global organization dealing with regulations and I mean its insurance. I don’t want to tell well, too much on them and Fletcher, Jonathan is a tremendous, tremendous talent. I’m sure it’s gonna translate into a great presentation. Another one Gene, that I wanted to highlight if you don’t mind me stealing a little bit from you, is Gareth Rushgrove, you know who’s at Puppet now. But you know Gareth, besides curating the DevOps weekly newsletter, you know he has a great security background like we do, Gene. And I can listen to him all day.

Gene Kim:                   Yeah. And what’s great is that maybe not so well known is that he was part of the early UK.gov effort.

Alan Shimel:                Yes.

Gene Kim:                   Where he had to deal with all of the regulatory and compliance bodies inside you know a very powerful central government, as well as the intelligence agencies. And so the fact that he was able to span those boundaries and earn the trust of those agencies and essentially help define kind of the next generation of security standards and strategies, is just a really inspiring one. It’s just a really neat guy.

Alan Shimel:                Yeah. He’s a rock star. I just wanted to mention two others Gene and they’re from DevOps San Francisco who are I guess coming over to London. And that’s Jason Cox from Disney and Rosalind Radcliffe from IBM. Just two brilliant people and I just appreciate brilliance. So you know looking forward —

Gene Kim:                   I love them both.

Alan Shimel:                I’m sorry what, Gene?

Gene Kim:                   What I love about the conferences if you take a look, this is like a great cross section across you know almost every industry vertical. So you’ve got Unilever from you know the consumer goods on the financial services. You have Barclays from _____ –

Gene Kim:                   – insurance companies. You’ve got Pearson Publishers. News UK is another publisher. Thomas Cook Group does retailing and travel services.

Alan Shimel:                Yes.

Gene Kim:                   Zurich Insurance. You know actually I never realized we have so many insurance companies. So we have 26 speakers announced. You know I’ll tell you another part of the programming committee is that a lot of these we handpicked from people from our own investigation. But then we also had I think it was about 80 submissions through our call for presenters. And so you can imagine how challenging it is when you have only 25 speaking slots, of which over half had already been taken.

Alan Shimel:                Yeah.

Gene Kim:                   You can imagine the vigorous debate about you know which talks really need to be a part of the programming. And I just very much appreciate you know the candor and the fact that everyone had the best interest I think for the attendees in mind as we were trying to figure out how do we create the best program for the technology leadership community around DevOps.

Alan Shimel:                Yeah. And debate is a kind word. Gene, let me –

Gene Kim:                   Yeah.

Alan Shimel:                – pivot a little bit ’cause we’re running low on time. So we’ve got this great lineup of speakers. We’ve hit a bunch of them and there’s more yet. But okay, if they attend DevOps Enterprise London, what are they taking out of it. Give me three bullet points. What are the three lessons? What are the three most important things they’re taking out of their attendance at this event?

Gene Kim:                   Yeah. I think the most important thing is that they are going to hear transformation stories of organizations that look like them. So I think in the DevOps community we’re very used to hearing stories from you know Google, Amazon, Facebook, Etsy, Netflix and so forth. But if you’re in a large insurance company that’s been around for over a hundred years or a government agency that’s been around for five hundred years, you know they don’t relate very well to those unicorns. So to hear how those same type of technology transformations have occurred in large complex organizations, that is the mission of the conference is to share 30 minute experience reports where each speaker shares what business problem were they trying to solve, where did they start and why. What did they do and what were their outcomes and what do they still not know how to do and what are they looking for help with. So, yeah, I think what I’ve heard over and over again is that you know these stories, when you go to this conference you’re surrounded with people just like us, right. Or rather just like me.

I think the second thing that they’ll hear is that they’re achieving the same sort of outcomes you know in these large complex organizations that we’ve only typically seen in the unicorn organizations. But there’s an element to me that has a tremendous amount of significance and meaning is that each one of these leaders, even though they were given some degree of air cover, I mean it’s as much true for the London conference as for the two previous conferences in the U.S. Each one of these leaders I think wildly exceeded the air cover they were given. Essentially putting themselves into some degree of personal jeopardy. And so when you ask why would they do that? What you see that each one of these speakers have in common is that if they have a sense of utter clarity and conviction that the capabilities that they’re creating for their organization are needed in order to win in the marketplace, let alone survive in the marketplace. So there’s kind of this other dimension of just the hero nature of these stories that I just find so inspiring. And it’s been an honor to help chronicle.

Alan Shimel:                Excellent.

Gene Kim:                   Oh, and I guess the third dimension is like to see the value they’re creating. And I would suspect that in the London conference it’s going to very much match the U.S. conferences, where we’ve observed that one out of four of the speakers at the DevOps Enterprise has gotten promoted in the last three years. Many of them more than twice.

Alan Shimel:                What a great metric.

Gene Kim:                   Yeah. This is a reflection of you know I think the value that they’re creating is being recognized by their organizations and they’re being asked increasingly to try to replicate that across a broader portion of the organization and help elevate the state of the practice.

Alan Shimel:                Fantastic. Well, if that’s not enough to get them to attend to DevOps Enterprise, London, Gene, I don’t know what is. But we’re almost at the end of our time here and we’re gonna have to wrap up. I just want to quickly mention for our DevOps.com audience, that we will be out there and working with Robin and Todd and the team on setting up an interview area where we’ll be doing interviews with many of these speakers when they come off stage. And much like we did in San Francisco last year and also just hearing some great insights and stories from these folks.

Gene Kim:                   Yeah. By the way, I’m hoping you’ll post in the show notes, I actually love the DevOps.com interviews that you did. And so we have them all on the YouTube channel, where you can actually see all of your interviews Alan.

Alan Shimel:                Yep.

Gene Kim:                   As well as all the DevOps Enterprise talks from the years past.

Alan Shimel:                Absolutely.

Gene Kim:                   So I think it’s just a phenomenal resource for anyone who’s interested in this topic.

Alan Shimel:                And that’s the DevOps Enterprise Summit YouTube channel.

Gene Kim:                   Correct. Yes. And the link will be in the show notes.

Alan Shimel:                Fantastic. I’ll put it in there. And I’ve actually featured many of them over the months on DevOps.com. You can find articles and embeds and links to it as well. But Gene, let me let you go because I probably took up more time than I was supposed to. I apologize. We’re really looking forward to a smashing DevOps Enterprise Summit in London.

May 18, 2016