devopsy.kinsta.cloud

Tag: Chef

9 more open source DevOps tools we love
A while back we ran an article by Tomer Levy of Logz.io about 9 open source DevOps Tools that we loved. Of course how can you pick just 9 among so many worthy choices? So we wanted to revisit the open source DevOps tools space and add another 9 tools to the list. In a few months we will be adding more open source DevOps Tools to the list as well. In the meantime here are 9 more must have open source DevOps Tools that we love:

1. Kubernetes is an open source orchestration system for Docker containers. It handles scheduling onto nodes in a compute cluster and actively manages workloads to ensure that their state matches the users declared intentions. Using the concepts of “labels” and “pods”, it groups the containers which make up an application into logical units for easy management and discovery.Originally developed and owned by Google,Kubernetes was offered to the Cloud Native Computing Foundation to seed other complementary technologies to enable a set of common container technologies. It is an integral part of CoreOS’s Tectonic product, in addition to being tightly coupled with Mesos and the Mesosphere DCOS.Kubernetes offers the promise of Google-like container usage for everyone. It seems no matter what the basic container technology we use, it is being used with many of the container-based PaaS stacks today

2. Chef – From the official what is: “Chef is a systems and cloud infrastructure automation framework that makes it easy to deploy servers and applications to any physical, virtual, or cloud location, no matter the size of the infrastructure. Each organization is comprised of one (or more) workstations, a single server, and every node that will be configured and maintained by the chef-client. Cookbooks (and recipes) are used to tell the chef-client how each node in your organization should be configured. The chef-client (which is installed on every node) does the actual configuration.

More than the above though, for many Chef along with Puppet Labs and Jenkins are the heart and soul of DevOps tools. Moving beyond its original configuration management mission today Chef represents the move to “everything as code” while still maintaining its open source commitment. Chef Delivery, Chef Compliance move Chef into the realm of a tool that is involved in the entire DevOps workflow.

3. Puppet – The Romulus to Chef’s Remus, Puppet Labs is one of the founding members of the DevOps movement. Built on open source and still fully supporting its open source heritage going forward, Puppet like Chef has moved beyond its original mission of configuration management and automation of single machines or instances to orchestration of your entire stack.

From Puppet’s open source doc, Why Puppet

Puppet has been developed to help the sysadmin community move to building and sharing mature tools that avoid the duplication of everyone solving the same problem. It does so in two ways:
- It provides a powerful framework to simplify the majority of the technical tasks that sysadmins need to perform
- The sysadmin work is written as code in Puppet’s custom language which is shareable just like any other code.
This means that your work as a sysadmin can get done much faster, because you can have Puppet handle most or all of the details, and you can download code from other sysadmins to help you get done even faster. The majority of Puppet implementations use at least one or two modules developed by someone else, and there are already hundreds of modules developed and shared by the community.

4. Maven – a Yiddish word meaning accumulator of knowledge, Maven was originally started as an attempt to simplify the build processes in the Jakarta Turbine project. There were several projects each with their own Ant build files that were all slightly different and JARs were checked into CVS. We wanted a standard way to build the projects, a clear definition of what the project consisted of, an easy way to publish project information and a way to share JARs across several projects.

The result is a tool that can now be used for building and managing any Java-based project. We hope that we have created something that will make the day-to-day work of Java developers easier and generally help with the comprehension of any Java-based project.
Maven’s primary goal is to allow a developer to comprehend the complete state of a development effort in the shortest period of time. In order to attain this goal there are several areas of concern that Maven attempts to deal with:
- Making the build process easy
- Providing a uniform build system
- Providing quality project information
- Providing guidelines for best practices development
- Allowing transparent migration to new features
5. Gradle – the yin to Maven’s yang, Gradle and Maven are much like Puppet and Chef. In this case though Gradle was born out of frustration with Maven and other tools. From the Gradle, Inc. site:

Gradle was founded by Hans Dockter who was working in Enterprise software development and ran into an intractable build problem. At the time he was using Apache Maven. After three days and nights of exhaustive research, he discovered that the problem could not be fixed with the tool at all. Hans vowed to cure this problem for himself, for his team, his company, and for developers everywhere. He was joined in this mission by founder CTO Adam Murdoch. After releasing Gradle the open source project out into the wild in April of 2008, Hans and Adam then hired all of the key contributors whom they met along the way. These included world renown Gradle experts from companies like Thoughtworks, Typesafe, and Pivotal.

Many developers and shops today use one or the other of these open source tools.

6. Mattermost (& Zulip) Today is all about ChatOps. In many organizations it is replacing email as the primary communication method between teams and even outside members now. While there are plenty of commercial solutions in this space like HipChat and Slack, there are some worthy open source tools available as well. One of the biggest advantages to these open source solutions is you don’t have to use a hosted version if you are worried about control, governance or security issues. You can install these on your own server and maintain yourself if that is your preference. Here are two of the leading open source ChatOps tools:

Mattermost – is an open source Slack alternative. The company behind it is a Y Combinator funded startup with founders who come from Microsoft Office engineering. Frustrated that in using a SaaS hosted chat program they were locked out of their own data unless they paid to use the app they set out to create their own self-hosted app and so Mattermost was born. Not sure where the commercial element ill join this, perhaps open core type premium features? Support? Time will tell.

Zulip – Acquired and then released as open source under an Apache license by DropBox, Zulip is a modern take on ChatOps. Not based on IRC and XMPP, Zulip features: Threaded group conversations, One-on-one and group private conversations, Persistence, History, Full-history search, Team presence and buddy list, Inline image, video, and tweet previews, Drag-and-drop file uploads, Stream-wide announcements, Emails for important missed messages, Desktop notifications, Audible notifications, Hotkeys, Emoji, Code, Lightweight markup, Message editing, Invite-only streams, Starred messages, Integrations, API, Mobile apps, Desktop apps

7. OWASP – A developers and DevOps best security friend, OWASP has become the place for web application security. Their mission is to make software security visible, so that individuals and organizations worldwide can make informed decisions about true software security risks. OWASP is actually an umbrella for a number of different projects including tools, lists (OWASP top 10) and groups. Their website says it best:

The OWASP Foundation came online on December 1st 2001 it was established as a not-for-profit charitable organization in the United States on April 21, 2004 to ensure the ongoing availability and support for our work at OWASP. OWASP is an international organization and the OWASP Foundation supports OWASP efforts around the world. OWASP is an open community dedicated to enabling organizations to conceive, develop, acquire, operate, and maintain applications that can be trusted. All of the OWASP tools, documents, forums, and chapters are free and open to anyone interested in improving application security. We advocate approaching application security as a people, process, and technology problem because the most effective approaches to application security include improvements in all of these areas. We can be found at www.owasp.org.

OWASP is a new kind of organization. Our freedom from commercial pressures allows us to provide unbiased, practical, cost-effective information about application security. OWASP is not affiliated with any technology company, although we support the informed use of commercial security technology. Similar to many open-source software projects, OWASP produces many types of materials in a collaborative and open way. The OWASP Foundation is a not-for-profit entity that ensures the project’s long-term success.

8. Zabbix (& Observium) – OK so lots of people have grown to hate Nagios. There are still lot of people who use Nagios too. That being said, we wanted to highlight some open source options in the network and application monitoring space. Two we like are Zabbix and Observium.

Zabbix – The basic work sphere of Zabbix LLC is development of open source software for monitoring of networks and applications. Apart from that the company offers a wide range of professional services designed to fit every customer’s unique business demands including implementation, integration, custom development and consulting services as well as various training programs.

Zabbix team’s mission is to make a superior monitoring solution available and affordable for all.

The company’s flagship product is Zabbix, one of the most popular open source monitoring software in the world. It is already used by a vast number of companies, who have chosen it due to real scalability, high and robust performance, ease of use and extremely low costs of ownership.

Observium – is a low-maintenance auto-discovering network monitoring platform supporting a wide range of device types, platforms and operating systems including Cisco, Windows, Linux, HP, Juniper, Dell, FreeBSD, Brocade, Netscaler, NetApp and many more. Observium focuses on providing a beautiful and powerful yet simple and intuitive interface to the health and status of your network.

Professionally developed and maintained by a team of experienced network engineers and systems administrators, Observium is a platform designed and built by its users. Observium Community is available free to everyone and recieves updates and features twice annually. Observium Professional adds priority access to daily updates and new features for a small yearly fee.

9. Cucumber – OK raise your hand if you use Cucumber. It is one of the best kept secrets in the business. I am constantly amazed out how many developers and DevOps folks mention this open source tool. It’s actually several tools as their are different versions for different languages with each one having a slightly different feature set.

For those of you who don’t know, “Cucumber has revolutionalized the software development lifecycle by melding requirements, automated testing and documentation into a cohesive one: Plain text executable specifications that validate the software.”

So those are our latest 9 open source DevOps tools we love. We know there are more. Leave comments with worthy choices for our next article.
November 9, 2015
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
DevOps Leadership Series 2015: Women & Diversity – a diversity of thought and contribution

Many of the leading minds and practitioners in the DevOps movement are women. I hope that comes as no surprise to you. DevOps has always embraced a diversity of thought and contribution. Case in point, close to 50% of the presenters at this year’s DevOps Days Boston event were women.

In this episode of the DevOps Leadership Series, we caught up with Jennifer Davis, co-author of Effective DevOps (O’Reilly 2015, $31) and software engineer at Chef. Jennifer discusses a greater diversification of what DevOps means. She sees more explicit efforts to expand DevOps into QA, security, DBAs, and other functional teams across the organization. Jennifer also discuss the benefit of re-setting one’s expectations on the meaning of certain words (e.g., agile, test driven development, audit driven development) to accelerate progress and remove roadblocks:

https://www.youtube.com/watch?v=B-zONUI5KQ4

We then sat down with James Meickle, Site Reliability Engineer at Harvard and member of the organizing committee for DevOps Days Boston. James witnessed distinct growth over last year in the diversity of companies in attendance — both from a size and industry perspective. James also discusses the importance of diversity that the organizing committee insisted upon as they planned for the event. If you are organizing your own DevOps Days event, be sure to have a listen:

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

If you missed part one of our series from DevOps Days Boston, be sure to watch these interviews from Beno Chapman of Constant Contact, Anthony Spring of Yieldbot, and Jeremiah Sullivan of Puppet Labs.

Want learn more from the leading minds in DevOps? You can find the entire library of 21 videos from this series on YouTube.

Special thanks to my colleague, Mark Miller for capturing these videos for us at the event.

October 1, 2015
DevOps Leadership Series 2015: Women & Diversity

Many of the leading minds and practitioners in the DevOps movement are women. I hope that comes as no surprise to you. DevOps has always embraced a diversity of thought and contribution. Case in point, close to 50% of the presenters at this year’s DevOps Days Boston event were women.

In this episode of the DevOps Leadership Series, we caught up with Jennifer Davis, co-author of Effective DevOps (O’Reilly 2015, $31) and software engineer at Chef. Jennifer discusses a greater diversification of what DevOps means. She sees more explicit efforts to expand DevOps into QA, security, DBAs, and other functional teams across the organization. Jennifer also discuss the benefit of re-setting one’s expectations on the meaning of certain words (e.g., agile, test driven development, audit driven development) to accelerate progress and remove roadblocks:

https://www.youtube.com/watch?v=B-zONUI5KQ4

We then sat down with James Meickle, Site Reliability Engineer at Harvard and member of the organizing committee for DevOps Days Boston. James witnessed distinct growth over last year in the diversity of companies in attendance — both from a size and industry perspective. James also discusses the importance of diversity that the organizing committee insisted upon as they planned for the event. If you are organizing your own DevOps Days event, be sure to have a listen:

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

If you missed part one of our series from DevOps Days Boston, be sure to watch these interviews from Beno Chapman of Constant Contact, Anthony Spring of Yieldbot, and Jeremiah Sullivan of Puppet Labs.

Want learn more from the leading minds in DevOps? You can find the entire library of 21 videos from this series on YouTube.

Special thanks to my colleague, Mark Miller for capturing these videos for us at the event.

October 1, 2015
Chef raises $40m and a full house
Big news today from Chef who announced a $40m Series E round of financing. This round and its size is indicative of the continued high demand of DevOps in general and for a leader in the space like Chef. The round was led by DFJ Growth. Existing investors Battery Ventures, Citi Ventures, DFJ (venture), Ignition Partners, and ScaleVP also participated. Other noteworthy new investors in this round are: Millennium Technology Value Partners & Hewlett Packard Ventures (as a strategic investment).

I had a chance to speak with Barry Crist, CEO, Chef. Of course Barry was very excited about the raise (what CEO wouldn’t be) but what really made an impression on me is that Crist was excited on several levels about this announcement:
1. While Chef didn’t need the capital right now, as Crist says, “the best time to raise money is when you don’t need it.”, The money came at a time when the global market for DevOps is exploding and Chef is exerting its leadership in taking DevOps to the mainstream. With more than half of the Fortune 50 using Chef, 80 percent of Chef’s exponentially growing revenue comes from enterprise businesses.
2. Chef has scored a rare double of both DFJ Growth and DFJ Venture investing in Chef. Having both arms of the well known investment house among Chef’s investors is both a testament to how much they value Chef and how well Chef has performed to date.
3. The strategic investment by HP Ventures represents one aspect of a deep and growing relationship between HP and Chef. HP is poised to be a strategic partner bringing Chef to its large world-wide channel. This investment speaks volume about HP’s commitment to this relationship.
4. A full house for Chef. With the HP investment, Chef now has deep strategic relationships with Microsoft, AWS, IBM and HP. This represents a “full house” of major technology partners and bodes well for Chef to continue its dominance as the leader in DevOps automation.
This was a series E round for Chef and I did not ask Crist what type of valuation this money was raised at. But one of the nice things about raising money when you don’t have to is that generally you can afford to be a little pickier and get better valuations when you raise money.

I had a chance to speak with Crist about his outlook on the VC and investment market. With many voices chiming in that we might be seeing a dip in investment and valuations in the tech market, Crist said he didn’t have a crystal ball. But all the more reason to raise this money now. If the market does turn those with cash in the bank and dry powder will be in the cat bird seat to leverage their capital for strategic purposes. We might very well see Chef as an acquirer of technologies to tuck in as they continue to grow.

In the meantime, a rising tide will lift all boats. This kind of investment and buzz in one of the DevOps market leaders should help other DevOps companies in their own capital raising activities. While few may achieve the heights that Chef is rising too, there is lots of room in the market for DevOps companies of all shapes and sizes.

Congratulations to Barry and the rest of the Chef team on this raise and looking forward to see what the future holds.
September 9, 2015
The Sea Change that is DevOps – How it all started: Part 1
Over the last 20 years, software has slowly taken over the world. Businesses that historically operated on 8-hour business days are now 24×7, navigating a global economy that never sleeps. The Internet enablement of everything has thrust what was originally an important support role into the lifeline of a business.

A decade ago, Agile software development methodology forced more pressure into the IT system by deploying software at an ever-increasing rate to the point it’s at today – where innovative companies can deploy new software multiple times a day. DevOps is at the forefront of addressing the question of how IT deals with these problems, but like Agile before it, there’s a learning curve.

In this two-part series, I will discuss how the IT world worked before DevOps and how development and operations teams united to adopt more Agile practices.

How things were

Before this sea change, a company would hire IT professionals who would purchase and configure servers, place them in a data center, copy mission critical software onto them and with some help from software engineering, get things running. After some quality checks, the IT team would lock down the datacenter controlling both physical and virtual access and “let things run.” The common way to provide stability was simply to not let anyone touch anything, as most problems have been (and still are) self-inflicted wounds. Keeping the system “static” kept a lot of problems from surfacing. The software was probably not more stable; you just didn’t find the problems as fast.

In this world, IT professionals had a feast and famine existence. If a new service deployment was happening (usually every 3 to 6 months) it was an all hands on deck activity reminiscent of a rocket launch. The same manual deployment would happen, along with software engineering, database engineering, etc. Data migration would occur, new software would be installed, and the system would manually be brought back up. In the event of a software problem, or data migration problem, the team could elect to rollback and bring the old software back up. If things went well, then again some basic end-to-end quality assurance would take place and the new software release would be unleashed on the world. More progressive companies would do this for part of the system, diverting traffic to avoid perceived downtime. It would often take an entire night to do a new service release, and companies generally did them at night because downtime was not unusual.

Then software development changed

The competitive landscape that the Internet created along with the now ubiquitous SaaS business model made companies recognize that their ability to innovate the product was a competitive advantage. A lot of companies had adopted Agile software development practices in response to the increasingly high failure rate of larger efforts. Part of Agile is creating smaller development efforts that get code functional faster, reducing the size of the endeavor. This is commonly referred to as a “software sprint.” This promise of innovating the product faster was very alluring, especially to Web 1.0 companies that were now in feature battles with more nimble Web 2.0 companies who had more quickly adopted Agile. It was becoming more and more evident that the problem was shifting from an issue of creating software fast enough to deploying the necessary code in an expedient manner.
The big problem was the deployment stage of the process. IT teams were accustomed to changing production systems every three to six months. This combined with a trusted model that largely kept software developers out of production systems, effectively nullified any Agile gains in SaaS businesses. In other words, half the product development cycle had been fixed with Agile, but the other half deploying the software had not yet caught up.

Operations as a changing landscape

Major changes were also occurring for operations inside companies, many of which were driven by the development side of the house.
- Virtual server technology started to get major traction within production environments. This allowed teams to treat servers as software. You no longer had to run the operating system and application on a physical server, you could run them on a virtual server (that ran on physical servers). The configuration of servers that, by hand, took an incredible amount of time, could essentially be defined once and then cloned, the same way you would clone a file. Deploying a new server was much easier, and a corrupt server could simply be deleted and reborn in minutes. All these virtual servers could be managed by a single piece of software called a hypervisor, with which creating a new “server” would take a minute, when it used to take weeks.
- Puppet and Chef were born. At the same time development organizations, recognizing this major problem with deployment, started addressing the production configuration problem with tools such as Puppet and Chef that essentially allow software and IT teams to codify the configurations of virtual and physical servers and deployments of new code. This allowed for repeatable processes that could be rapidly done and redone. No longer did your IT team have to install software by hand, instead they could code it.
- Continuous integration and delivery enabled software teams to use newly developed tools like Jenkins to do nightly software builds, perform unit tests of parts of the software and automatically deploy software into production. All of these tasks had been highly manual operations historically and fraught with mistakes and inconsistencies. Codifying these steps would give way to deploying software within minutes or seconds rather than days or hours.
Most importantly, all of these efforts were largely driven by the development of more progressive operations in the company. The operations side of most companies was never conceived as a “maker” culture; the handwriting was on the wall – operations had to change or it will would have become a victim of this revolution. I’ll take a look at some of the resulting changes in the second part of this series.
September 3, 2015
DevOps fast food: Chef on the AWS marketplace,

News from the AWS Summit in NYC today is that Chef is now available as a one click install on AWS via the AWS marketplace. While the ability to use Chef on AWS is not new (it is the leading configuration management tool on AWS), being on the marketplace makes both install and billing a one click deal. This should make it really simple to get Chef installed and running for anyone looking to leverage the many benefits Chef brings to configuration management and automation. Literally with one click install what could be simpler?

As part of this new arrangement not only will Chef on the AWS marketplace be available, but it will also be a featured offering. Chef and AWS already enjoyed a cozy relationship (they are both based in Seattle and there is a cross-pollination of personnel). This deal takes the relationship to a higher level. Both Chef and AWS are dedicating significant resources to marketing, sales and support of this initiative.

I know from speaking to AWS in the past and other marketplace vendors that AWS will often let partners list on the marketplace, but they don’t often then dedicate resources to roll out, marketing and support. Further, as far as I know Chef is the only configuration management/automation solution that is available via the marketplace like this. I don’t know if this will remain the case or for how long, but for now it is somewhat of an exclusive relationship.

I had a chance to catch up with Ken Cheney, VP of Business Development and Jay Wampold, VP of Marketing at Chef about this expanded relationship the other day. They both emphasized that this is much more than just listing Chef in the AWS marketplace. Some estimates I have seen have Chef deployed on something like 70% of AWS deployments. Ken and Jay believe that this number will continue to remain high and may even go higher as a result of the marketplace presence and the push from both Chef and AWS.

On top of their previously released expanded relationship with Microsoft via Azure, it seems Chef is putting a stranglehold on two of the largest cloud platform providers in the world. That doesn’t mean that other configuration managers don’t have presence on AWS or Azure, but Chef seems poised to be in a dominant position on these platforms.

As we see more enterprises continue to migrate more and more infrastructure to the cloud this presence will become more and more important. For now you can get Chef fast on the AWS marketplace.

July 9, 2015
SaaS: Building Tools for the DevOps-Minded

DevOps, Continuous Delivery, Continuous Integration and Continuous Testing are no longer just methodologies and development strategies — they’re all a part of a growing economy within the tech industry.

Great Software-as-a-Service (SaaS) companies such as Chef, Docker and New Relic have done an amazing job of spotting the trends early and building their tools and services around a new wave of development processes. Chef and Docker alone have reportedly raised nearly $250 million, and New Relic went public in 2014.

In fact, this very website is another example of how impactful these new development practices are — as several specialized news outlets have been born out of these revolutionary development strategies. So, not only has the DevOps methodology helped developers create better products, faster; but the process has opened opportunities for technical experts to share their experiences on sites like this, e-books, webinars, conferences and any other way people communicate.

On devopsy.kinsta.cloud, you’ll see the best articles on the web discussing how DevOps is defined in different organizations, why Fortune-500 companies are shifting old practices toward CD and the best practices of CI from industry experts.

In the race to be the most DevOps-friendly solution — no matter the niche — hundreds of startups have been founded and funded, which has only enhanced the toolboxes of thousands of developers. You’d be hard-pressed to find a good SaaS company that doesn’t offer integration with Jenkins CI, TeamCity or Chef, and that’s because not only should a SaaS product solve an important problem, but it should have minimum disruption of your current development process.

With all that in mind, Continuous Testing is one of the most exciting spaces in technology today. Continuous Testing is a process that aims to synchronize testing and QA with dev and ops, which ultimately yields better products more quickly.

There are several factors that make Continuous Testing successful in a team’s software development lifecycle — such as open-source collaboration solutions, test automation APIs and tools to track the historic performance of applications .

With the release of Load Impact Version 3.0, the global performance and load testing SaaS company has announced its latest feature that fits right in with the DevOps mindset: Performance trending.

Performance trending allows users to plot runs of the same test over time. That gives companies a clear view into data that locates patterns of performance degradation or improvement in order to easily validate code and infrastructure changes.

In the spirit of Continuous Testing, DevOps, CD and CI — performance trending improves users’ ability to gain both a low-level and high-level view into the performance of their systems. And with the increased number of tests run by DevOps professionals, performance trending yields valuable information for companies concerned with their application performance — which should be everyone.

Between devopsy.kinsta.cloud and plenty of great conferences and meetups around the world, it’s safe to say this economy of DevOps-minded tools will only continue to grow in the coming years.

July 1, 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
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