staging-devopsy.kinsta.cloud

Category: Features

27-Factor Assessments Lead to Success With DevOps

October 2019 will mark the 10th anniversary of the first DevOpsDays, where the term “DevOps” began to catch on. In the world of information technology, 10 years is a long time and it is quite evident based on the amount of change that has transpired since then. To name a few, we have seen the maturing of CI/CD automation and many innovations such as application release automation, containers, cloud infrastructure orchestration, DevSecOps, DevOps database, DevOps governance and micro-services.

These innovations have become part of “mainstream DevOps.” This evolution is continuing with AIOps, machine learning, value stream management and others. Each of these innovations has made DevOps not only more powerful but also more complex.

As a consultant working on DevOps projects through their life cycle, I have learned that complexity can plague the success of DevOps within an organization. Complexity cannot be avoided, as DevOps is complex and will likely continue to be. However, the key to avoiding failure through your DevOps journey is to engage the complexity by using DevOps tenets to implement DevOps. Do not try to boil the ocean. Instead, at each leg in the journey, take inventory of where you are in terms of current goals, state and best practices. Fine-tune your direction and build your solution using proven continuous delivery methods.

The 27-Factor Assessment Model

A comprehensive yet efficient assessment of your current state is key for ensuring complexity has not gotten out of hand and the organization is focused on success criteria that meet the needs of the business.

I use a 27-factor assessment model. The factors are the cross-product of current best practices for three dimensions (people, process and technology) with nine pillars.

A Scope of the 9 Pillars

Leadership: Gain insight and understanding of your leadership practices and how leadership can improve DevOps adoption and performance.

Culture: Identify opportunities to improve cross-functional collaboration and communication across your organization.

Application Development (or Design for DevOps): A practical analysis of application development practices identifies improvements for your DevOps performance.

Continuous Integration: Analysis of branching and software integration workflows and tools identifies bottlenecks and improvements for builds and packaging processes.

Continuous Testing: Analysis of end-to-end software testing, verification workflows and tools identifies bottlenecks and improvements for accelerating testing while improving the coverage and quality of tests.

Infrastructure on Demand (or Elastic Infrastructure): Analysis of systems and services for orchestrating and hosting applications and DevOps workloads provides insights to improve performance and utilization of resources.

Continuous Monitoring: Analysis of end-to-end monitoring workflows and tools for applications, releases metrics and infrastructure provides improved visibility for all business and technical stakeholders.

Continuous Security: Analysis of security practices and tools identifies opportunities to integrate security practices into the continuous delivery pipeline.

Continuous Delivery/Deployment: Analysis of delivery and deployment practices identifies improvements for safer, faster and more efficient releases.

Each combination of pillar and dimension has associated best practices used to score relevance and current state relative a DevOps goal agreed by the organization. Here is an example of the continuous security pillar.

The 27-factor assessment for an application is an important input to a future state value-stream map workshop. The value-stream map is then transformed into a road map and implementation plan.

This assessment approach is thorough and yields results that are usually accepted by stakeholders because they are involved in the process at each step. The result is aligned to their priorities and goals and the solution road map is directly traceable to stakeholder inputs. The approach is flexible enough to evolve over time and can be customized to suit the priorities of an organization. For those that argue that 27 factors are too many and too complex, I must say the complexity of DevOps itself requires a comprehensive assessment approach.

Conclusion

In this article, I described a comprehensive, efficient and evolvable assessment approach that uses 27 critical success factors for assessing DevOps applications. While DevOps offers immense value for software development, delivery and deployment, a rigorous and thorough assessment with up-to-date best practices are essential to accomplish DevOps goals. Each organization is different and has different DevOps goals and requirements. The changes to the three dimensions vary according to the results of each DevOps assessment.

— Marc Hornbeek

June 24, 2019
Mainframes: The Cloud Before the Cloud

Here’s something to think about: Despite the fact that IBM stopped manufacturing personal computers in 2005, deciding instead to focus on higher margin business services, the company continues to produce mainframes and by all estimates will continue manufacturing them well into the future. The question is, why? The answer: because there is still significant demand for this type of hardware.

The fact is that a mainframe is a monster when it comes to computation and processing transactions. One mainframe can process 2.5 billion transactions daily. That’s the equivalent of 100 Cyber Mondays in a single day. To give you a clearer idea of the immensity of scale, keep in mind that Cyber Monday sales in 2018 were $7.9 billion. This translates into a mainframe being able to handle a bit more than three-quarters of a trillion dollars in transactions each day, which is almost twice the yearly GDP of Austria!

As I said, the mainframe is a workhorse. Yet, its power and potential are hidden from most people who work in the modern cloud. This is surprising because there’s a good argument to be made that, given its power and scalability, coupled with its support for a large number of concurrent users, the mainframe was the cloud before there ever was a cloud. However, the technology is practically unknown among younger developers, mostly due to cultural reasons and a lack of historical awareness. That more people are not taking advantage of the tremendous opportunities at hand is a misfortune. When it comes to mainframe computing, there’s a lot of interesting tech to be learned and a good amount of money to be made. It’s just a matter of increasing awareness to do this. A good place to start is to redefine the narrative.

Allow me to elaborate.

A Special Club

When mainframes appeared on the commercial landscape, few people interacted with computers and even fewer worked with them directly as programmers or system administrators. Just as in a modern data center, the machines were isolated in climate-controlled rooms to which few had access. Access to the actual physical machine was restricted to a special few. But unlike today, when restricted access is due more to security concerns because there are a lot more people around who are potential black hats, back then access was also restricted due to the exclusivity of the profession.

In the 1950s, 1960s and well into the 1970s, not just anybody could program or be a systems administrator. You could go to a technical school to learn to become a computer operator, which meant you could work at a terminal as a bank teller or travel agent. Or you could learn to become a data processing clerk and work in a back office at a brokerage firm. But to learn to program, you had to go to college. Then after college, you had to go to work for a company or organization that actually used computers in day-to-day operations. These were banks, insurance companies, major manufacturers such as General Motors and General Electric, airlines, very large retailers and government. Computing was a club and you had to be well-educated to get in and be well-liked by the organization to keep your membership. Yes, there were the outliers—Gates, Allen, Joy, Wozniak and Jobs—but for most people, the career path to being a programmer was college and then into big business or government.

As a result, computing had an air of mystery and magic to it. Remember, until the mid-1980s, most people had never touched a computer. It was the stuff of moon landings and election night predictions on network TV. Then the PC came along and changed everything. Within 10 years computers became commonplace. Even elementary schools had them—at least, those that had the budget and foresight. The power that business applications such as the spreadsheet program Lotus 1-2-3 brought to small business motivated even the dry cleaner on Main Street to plunk down the thousands of dollars it cost to buy a PC. The productivity boost was worth it. Also, since the dry cleaner actually owned the machine, the dry cleaner’s kid could learn to program on the box unencumbered, when it wasn’t being used during business hours. Remember, the Microsoft DOS operating system that shipped on every IBM-compatible PC came bundled with the programming language BASIC. You didn’t need to go to college to learn to program; all you needed was a book.

So, PC programming took off. Instead of having to go through the effort required to get into the special club the mainframe programmers belonged to, PC programmers started their own clubs and anybody could get in. All you had to do was show up. PC programming became a meritocracy. Also, it became extremely lucrative work. There were a lot of PCs being shipped and the appetite for applications to run on them was enormous. The unlikeliest of people, such as Lotus Software founder Mitch Kapor and his sidekick, Grateful Dead lyricist John Perry Barlow, became wealthy, thanks to the PC.

The PC became cool and programming for it became cooler. But there was a fact that got obscured as the popularity of the personal computer grew: Compared to the mainframe, the PC was a toy—a productive toy, a liberating toy, but a toy nonetheless, very much in the same way that a go-kart is a toy compared to a Formula One race car.

Feature for feature, the mainframe ate the personal computer’s lunch. The IBM System/370 Extended Architecture Mainframe released in 1983 was a 31-bit machine that could support up to 8MB of memory with a processor running at 38 MHz. By comparison, the IBM PC-XT, also released in 1983, was an 8-bit machine that shipped with 128KB of RAM and an 8088 processor that ran at a speed of 4.77 MHz.

But, as the saying goes, “You should never underestimate the value of cool,” and the PC was very cool. It got a lot of attention while the mainframe stayed hidden away in climate-controlled rooms in the basements of banks and insurance companies. Yet, the mainframe was more powerful, and whereas the PC was meant to meet the needs of a single user, a mainframe can service thousands.

Built to Scale Built from Inception

Mainframe computers from the start were designed to support hundreds (if not thousands) of users. However, more importantly, mainframes were and are designed to support millions of concurrent transactions. When you think about it, while it’s possible for a high number of user requests to exhaust CPU utilization in a typical commodity machine—which is the reasoning for being able to scale up CPU count by increasing VM allocation in the cloud-based computing cluster—the real burden on the CPU is not so much the request count but the computing burden that each request incurs. For example, one request getting a .JPG of a cat will incur nowhere as much burden as a request that needs to convert an audio file in .WAV format to MP3.

The need to alleviate request burden has been around since bank tellers working in the various branches of a big bank had to make deposits and withdrawals at the same time. Mainframe engineers addressed the problem decades ago. Technologies such as batch processing and message queues, which make computational activity asynchronous and are optimized to fully utilize CPU capacity efficiently, were and are commonplace in the mainframe landscape.

IBM’s 360 mainframes supported batch processing in its OS/360 system starting in 1964. Batch processing allows thousands of instructions to be performed on terabytes of data at pre-scheduled times (usually “off-hours”), all without human intervention.

Message queuing allows processes to take data in the form of a message stored in a message queue and perform computational activity according to the data in the message. Processing is performed independent of a request in an asynchronous manner. When processing is complete, a new message is created and sent on to another queue, where another process will do more processing or create a notification indicating that work is complete. IBM MQSeries was an early message-queuing technology first used in 1993 at State Street Bank well before the internet became commonplace.

The reason that support for user and transactional concurrency was possible in mainframes is due to a technology that is commonplace in today’s cloud environment but was unheard of among PC users back in the days when most data was exchanged between standalone PCs using floppy disks. That technology is virtualization.

Virtualization Takes Mainframe Computing to the Next Level

Today we take virtualization—the capability to have software simulate hardware—for granted. Without it, we couldn’t have native cloud providers such as Amazon Web Services, Google Cloud and Microsoft Azure. These services rely on virtualization to provide the segmentation and computational isolation required to meet the needs of the modern computing. Yet, as essential as virtualization is in the world of commodity cloud computing, putting a layer of virtual machines on a commodity PC is a fairly recent event in the history of computing. VMWare, VirtualBox and KVM became mainstream in the mid-2000s. On the other hand, virtualization has been part of mainframe technologies since the mid-1960s. Virtual memory appeared in the mainframe in 1965. Machine virtualization was introduced on the IBM 370 mainframe in 1972 and is still an important part of the mainframe computing experience today.

Every single person who logs onto the mainframe when working in a native mainframe operating system gets an identical address space. You can think of each address space as a standalone virtual mainframe system. These address spaces are created instantly and are protected from interfering with each other. Also, many companies create logical partitions of their hardware called LPARs (logical partitions). The logical partitions are controlled by a native firmware hypervisor called PR/SM (pronounced Prism).

The value that LPARS provide is a further separation between environments. This means not only can you separate users, but you can also create distinct computing environments such as those created when virtualizing X86 machines. For example, you can have a shared development environment as well as environments for testing, staging and production. You can allocate resources and security access to a particular environment based on need, just like you would in a data center full of commodity machines. This means you can configure production systems to be more secure and have higher execution priority and more resources such as memory. In fact, according to the U.S. government, from a security perspective, virtual machines created on the mainframe are considered distinctly separate machines.

LPARs running on the same hardware or different hardware under the native mainframe z/OS operating system can be linked together as a Sysplex for redundancy and to easily provide additional capacity. Dynamic Virtual IP Addressing (DVIPA) is used to dynamically route IP traffic across multiple LPARs in a Sysplex. This is analogous to being able to tie together a variety of web servers behind a load balancer or organize them within a Kubernetes cluster. Being able to tie computers together is an important feature for making systems scalable. Also, linking computers across geographic regions increases performance. It’s always faster to work with a machine that’s closer to you than one that’s further away. As mentioned earlier, being able to scale systems up and down is a key feature of cloud-based computing. Dynamic connection, which is part of mainframe architecture, is critical for scaling to work.

The important thing to understand is that the stuff we consider to be modern in terms of the machine virtualization that we rely upon to make the cloud work has been in play for years on the mainframe. Also, virtualization on the mainframe makes it possible for programmers and system administration staff to work in a variety of operating systems and programming languages as we’ve come to expect in commodity cloud instances. Machine virtualization allows mainframes to support Linux. Whether the computing environment is virtualized Linux or native mainframe, developers can code in Java, C/C++, Python, Perl and a variety of other languages, including something as new as Swift. But, then again, the mainframe was always intended to support many programming languages.

Even back in the ’60s and ’70s, programmers could write in COBOL, PL/I, job control language (JCL) and Customer Information Control System (CICS). Also, writing low-level code in Assembler has always been possible. Clearly, the versatility that modern developers enjoy programming in a variety of languages in a cloud environment has been part of mainframe computing for a while. Yet, the benefit has never been at the forefront of developer awareness. Maybe it’s time to change the narrative.

Changing the Narrative About Mainframe Computing in the Cloud

As I stated at the beginning of this article, IBM continues to make mainframes because there’s a growing demand for the technology—particularly as smartphones and IoT devices proliferate worldwide. Netflix might be spinning up containers on a commodity machine in a data center to let you view past episodes of “Orange is The New Black.” But when it comes time to pay for your Lyft ride using your iPhone, that credit card transaction will most likely be processed on a mainframe that’s providing service via some sort of API gateway.

There is little benefit to arguing that mainframes should or can be used interchangeably with commodity servers. That’s like saying a fleet of automobiles can be used interchangeably with a city bus. You can do it, but it doesn’t make much sense. Each technology has benefits that when used together, make the overall transportation system more efficient. The trick is to understand where and how the technologies fit together in the big picture. In this case, the big picture is the cloud.

The old narrative around mainframe technology is based on perceptions that are no longer applicable. The modern mainframe is no more centralized than the single building that houses a regional data center. In terms of programming languages, mainframes moved beyond FORTRAN and COBOL decades ago. Current mainframe virtualization technology makes it possible to run programs written in just about any programming language. And, mainframe emulators, such as ZD&T, make it possible to get the hands-on experience necessary to get familiar working in a mainframe environment.

The Perceptions of the Past are No Longer Applicable

The modern mainframe is a powerful resource that provides extraordinary benefits for cloud computing. The new narrative is that the mainframe is modern, adaptable and well-suited to accommodate a very high volume of transactions at lightning-fast speeds. And, it’s a good way to make good money.

As the current workforce (which is admittedly aging) approaches retirement, a new breed of mainframe developer will be needed to continue the work of making the mainframe a mission-critical resource in the modern cloud. In addition to understanding the essentials of mainframe computing, these developers will need to be well-versed with the modern tools and techniques that drive cloud computing. It’s an investment that I’ve urged many up-and-coming developers to make.

Putting It All Together

Let me share a piece of personal history: A while back I needed to do some programming. So, I went to my desk, logged into my system, wrote some code and ran it. It worked like a charm! I saved my work, finishing up just in time for dinner. A while later, it was again time to program. I went back to my desk, logged into the system and coded away. Just another day of slinging the code, right? Well, not really.

My first coding session was in 1975. “A while later” is today. Forty-four years have passed. Back then, I was working on a mainframe that was 50 miles away. Today, I logged into an online programming environment that was also miles away, maybe even halfway around the world. That’s how it is with cloud computing: The resources are any way at any time.

Interestingly, despite the passage of a significant amount of time, my current developer experience is not that different than the one I had decades ago. It’s still just me and a terminal. Back then, the terminal was a screen full of green characters. Today, my terminal is able to accommodate a variety of media and input devices. But, at the other end of the wire, who knows what’s going on? For all I know, I might still be connecting to the same mainframe I used back in 1975. Which is my point.

Much of what we consider new and wonderful about cloud computing today has actually been around for a while in mainframe technology. In many ways, the mainframe was the cloud before the cloud. And, it’s still a powerful resource for what we have come to know as modern cloud computing. Given its power, versatility, scalability and support for modern DevOps tooling, the mainframe is a perfect resource for today’s and tomorrow’s cloud computing infrastructure. It’s a computing resource that we’ll do well to take advantage of as we move forward in our development efforts on an increasingly connected planet.

— Bob Reselman

May 1, 2019
DevOps Chat: Chef Goes All-In on Open Source

In front of next month’s ChefConf in Seattle, Chef has announced a major refinement to its business model. Affirming and clarifying its commitment to open source business models, Chef will now and in the future release all of its software as open source.

In this DevOps Chat, we speak with Corey Scobie, SVP of Products and Engineering at Chef. He explains that Chef will be adding services, training and support to the open source software, as well as packaging all of this together.

For the full story, be sure to listen to the podcast and check out the video version of this interview below, along with coverage on staging-devopsy.kinsta.cloud.

[videopress nUXwRMxU]

Transcript

Alan Shimel: Hey everyone, It’s Alan Shimel, staging-devopsy.kinsta.cloud, and you’re listening to a DevOps Video Chat. Today’s DevOps Video Chat features Corey Scobie, SVP of Engineering, is it?

Corey Scobie: Product and engineering, yep.

Shimel: Product and engineering now at Chef. Hey, Corey, welcome.

Scobie: Thanks, Alan, happy to be here.

Shimel: I’m happy to have you here. Today is a red letter, big day in the history of Chef. You guys are announcing some pretty significant changes to the model is I guess what I would call them. Though, I don’t think the changes are as big as some may initially feel, but let’s go over them. I’m going to let you take the wheel here. Tell our audience.

Scobie: It is a big day today for us at Chef. We are announcing some changes to the way we both produce and ultimately distribute our software, which I think are really exciting. There’s a lot going on in the industry right now. As you probably know, Chef has been one of the marquee players in the open source software development community for some time. Part of the announcement that we’re making today that I think is most exciting, is we’re announcing that what we’re going to do is going forward, produce 100 percent of our product-oriented software in that open source model.

For us, that’s a change because we, over time, and through the addition of additional projects and additional software at Chef, had started following a little bit of an open source, open core path, which means that we had some proprietary software and some open source software, but when we got down to it and we thought about the history of Chef and the roots of what has made Chef such great software in the past, it really came down to collaboration. We realized the best way to make software is to make it in collaboration with the people that actually use the software, at the end of the day.

For us, that’s the big first talking point about the announcement is that we are committed to 100 percent open source software development going forward. We’re committing all of our software to open source repos and GitHub, and then ultimately attaching it and giving it to the commons with the Apache 2.0 license.

Shimel: Sure, so Corey, you know – so you’re talking to someone who has a bit of a history in open source, 20 years. I remember when the whole open core movement first came out. Look, Richard Stallman and that crew, they were really against open core, because they felt it was – it was almost heresy to the whole cathedral and bizarre open source kind of crowd, where if it’s open, it’s open. You can’t be a little bit pregnant. But, nevertheless, we’ve seen companies succeed with this open core or premium, where the core is free and there are premium modules on top of it, but it’s a slippery slope. In all honesty, I think Chef got caught in a little bit with that slippery slope with what’s truly open, what’s free, what is our proprietary that we make money from? I don’t know if the market really got it.

Scobie: Yeah, one of the things that is really tough when you’re following an open core strategy is drawing a very clean line between what is free and what is not free in the world of your technology offerings. For us, that got complicated and then even conflated further as we added more projects to the list. When we opened the InSpec project for security and compliance, when we opened Habitat for application automation, what ended up happening is we had multiple projects that were governed different ways that had different lines between the free and the core part of it. I think ultimately at the end of the day, had I been at Chef during that part of the journey, I probably would have made the same decisions, I’m guessing, but at some point you get back to this reconciliation point where it’s like, “Look. The best thing that you can do for customers if number one, you can collaborate with them, and number two, you can have a really, really clean line between what is free and what is not free in your world.”

For us, it becomes super simple with this announcement. What is free is all of the intellectual property that we’ve contributed to the commons in the world, and will contribute to the commons going forward. What isn’t free is all of the work we do to make a turnkey, enterprise-class, package that enterprise-class customers can pick up and distribute at hyperscale in their organizations, from that point.

Shimel: That brings us to the next thing, and of course this is always the issue. So if you’re going to make all the software and the IP open, well how the heck do you make money?

Scobie: Sure. As it turns out, we’ve got venture capital funding, investors that want to see us turn that into dollars as well. For what it’s worth, we’re feeling pretty good about the shape of the business right now. We just came off the best quarter of revenue we’ve ever had at Chef, prior to this business model, this model change around how we distribute software whatsoever. So we’re feeling really good about the shape of the business, but just the inability to have that simple conversation about what’s free and what isn’t. What we decided was as we’ve matured as a company, and as the space has matured in enterprise automation, what we found is the majority of our customers actually do want to have a very material commercial relationship with us.

Not only do they want the software, but they want the support. They want the content. They want the expertise. They want the warranties and indemnities that go with all of that. So for us, it was very simple. We realized at the end of the day, that the most — that there was a huge constituency of our customers who what they wanted from us was a very curated commercial offering out the other end. So we’ve decided that’s where we’re going to put our effort and our energy, and we’re going to trust in the open source world to fill in the gaps where that isn’t the offering that they want as well.

Shimel: We look at this model, Corey. Obviously, Red Hat’s the poster child for much of the open source world in that most of their software, if not all of it, was in fact open source. It was all in the packaging and the support, and that kind of thing. It sounds very much like that’s going to be the model, or am I wrong?

Scobie: It is – no – there’s a strong analog to what Red Hat has done in the industry as well. What’s interesting is I think that that is the antithesis of what we are seeing from a lot of the more recent moves in the open source industry where there’s a desire to become more proprietary in some cases, or in other cases to try and somehow bend, I think, the definition of what is open source software. For us, the core of it, we get back to the four freedoms, and freedom zero is about the freedom to use the software, but it’s free as in freedom. It’s not free as in dollars.

Shimel: Free as in freedom, or free as in beer, as we used to say, but Corey, to be fair to these companies that are – that we do see going another way, it’s because they didn’t cut it. They tried the Red Hat model, and for whatever reason, they didn’t cut it and they had too much pressure from their boards and the VCs and investors, and so forth. So they tried to take a path that was quicker to money. I’m not here to judge anybody’s – as someone in the Godfather once said, “Far be it from me to disparage what someone does for a living” –

Scobie: I hold the same opinion, Alan, by the way. I sit in judgment of nobody on the decisions that they make about what’s right for their business. I just know that for us, what’s right is to try and both honor the open source roots that we came from, and to also serve the commercial customers that were really knocking at the door and saying, “Look, this is what we want from you. We want even more engagement. We want even more value out of your commercial subscription.”

Shimel: Agreed. Before we jump into the next part of it, which is how it manifests itself within the Chef universe, I wanted to just tie a knot on this one, and mention that when we talk about this model, and you said, “Oh, we’re going to count on the open source community to fill in the gaps,” and one might say, “Well, what are those gaps? I think people have to realize what made Red Hat great was not just distributing Linux. It was that RHEL, and Fedora even before that. It was that package, that distro, that had everything you needed and wanted in there in a really easy to use – you didn’t want for anything else. It was all right there, nicely done for you, instead of running out and having to download different packages and distros from all over the internet, which is what held back Linux on the desktop for so many years. There wasn’t that one package that you could do that.

I think that’s what you’re referring to is Chef’s strategy going forward is to have that killer distro, with all the right packages in it. If you don’t want to pay Chef for that, and I don’t think at this point, though people like software that is free as in beer, and they get free as in freedom with it, no one denies that a company should be able to make a living, that a company should be able to make a profit, pay its employers, pay its developers, and go forward. So for people who either don’t have the money, or don’t have the inclination to buy the packaged product, they can get the open source components, and the community can work on giving you the glue, in essence, that puts these all together. Correct?

Scobie: Absolutely, for sure. Santos came out of that exact scenarios. The scientific community needed something that wasn’t going to be necessarily nearly as curated as Red Hat and Linux was, but they needed a platform for scientific computing, so CentOS was born and has a place in that world. I think our vision for that is exactly the same. If there’s a downstream project that is born of Chef InSpec or Habitat, we welcome it into the community, and we look forward to whatever innovations they bring, and we want to collaborate with anybody that wants to come and take that work out of the commons and create the derivative work out of it, that allows them to meet whatever their goals are. That is the freedom in free and open source software.

Shimel: Absolutely. I think one of the other things though, Corey, is when we look at Chef over the last couple years, we’ve seen the whole InSpec line of security functionality, and we’ve seen Habitat. Look, Habitat was an ambitious piece of – well, it was more than a piece of software. Habitat was an ambitious play, but because there was so many balls in the air and going off in different directions and open/closed, proprietary/not, people never – it wasn’t explained well enough to people. I spent the time at ChefConf so I understood Habitat well, but there’s maybe a thousand people at a Chef conference as opposed to millions of people in the world. I think it was really hard getting InSpec and Habitat, carving out their niche in the world, amidst this whole confusion around the closed/open, supported/paid for, free/not free.

Scobie: Yeah, that’s fair, and I think this really helps us simplify the messaging around that too. I will openly admit I think InSpec is an easier basic value proposition to parse, which is “Look, I need security and compliance in my organization and the right way to do that is express it as code”, so that should be fairly straightforward, and relatively noncontroversial. I think, with respect, to Habitat, what is interesting about Habitat is I agree with you, super ambitious project right from the get-go to redefine the abstraction of packaging and orchestrating the delivery of software in the world.

That’s – it’s huge that there’s a huge surface area associated with that. I think what’s interesting is that we’ve learned much – we’ve learned a lot over the last couple of years about how to help people in the mental journey of how to think about Habitat in the world, and how it relates to Chef, and having that foundation of understanding and knowing Chef, which tens of thousands, if not hundreds of thousands of people already have, the ability for them to jump to where Habitat plays becomes much easier in the world where we can talk about them collaterally and not independently of one another.

Shimel: Fair enough. I think that’s a great segue, Corey, to the next part of our conversation I wanted to have with you, and that is okay, how does this manifest itself down the line of Chef product and services? So we’re going to put all our IP out as open. I guess we should mention also, I think everything is being released under an Apache 2.0 license.

Scobie: That’s correct. Apache 2.0.

Shimel: Industry standard, GPL, Apache are probably the two biggest. How does this manifest itself? What changes does this mean for Chef’s products?

Scobie: On flag day when we release new products with new packaging and new terms and conditions, it’s an evolution that we’ve been going through for some time now, which is really to understand what the interface parts are between the three core engines that we have. So we’ve created an engine for infrastructure automation, which is the Chef project, and going forward, just from a purely – from a branding simplicity perspective, it’s going to be known as Chef Infra, which is I think is fairly straightforward.

Shimel: I’m sorry. Can you repeat that though? Chef…?

Scobie: Infra, as in infrastructure.

Shimel: I-N-F-R-A. Okay.

Scobie: Yeah, and then we’re going to have Chef InSpec, for security and compliance, and the state relationship between infrastructure and security and compliance are pretty – it’s pretty intuitive, which is that if I deploy an operating system, and I want it to be locked down in a certain way and secure and meet a certain set of compliance standards, then testing that on a continuous basis, managing the drift, and being able to automatically remediate any drift that’s happening there seems like a really obvious relationship. What’s interesting though is the relationship between infrastructure and application automation. This is where things get really murky, even for longtime Chef customers who have been wildly successful in using Chef as an infrastructure automation tool. If you go and talk to those customers, what you’ll find is that they’re doing about – 30 percent of what they’re doing is about infrastructure deployment provisioning and shaping, locking down configuration management.

70 percent of what they’re doing is deploying software on top of the operating systems in service of some application that’s going to come along at some point in time and need that – those software dependencies to be there. What we discovered, and this is really the genesis of Habitat, which I’m not even sure – we knew that what was happening in the space of Chef was not working at scale for us. That’s the reason that some folks at Chef went off and decided to create Habitat, but what we didn’t realize is why it wasn’t working as it was at the time. The reason is that there is a natural boundary for building systems from the bottom up in a layer cake approach. It doesn’t matter whether it’s Chef or Antival or Puppet or Kubernetes clusters or whatever, that there is a natural boundary layer, if what you’re doing is building systems from the bottom up.

So you have an operating system, and then you have system libraries, and then you have packages, and then you have middleware, and eventually you have an application. At some point that dependencies graph, the modularity of everything that you lay down, and the dependencies graph gets so complicated that there’s no possibly way you can manage understanding what the implication of changing component X is on all the other components that rely on X. So the beauty of Habitat and where Infrastructure, and where Chef and Habitat come together is that Habitat takes the exact approach. It says, “Look, what you should do is you should define an application, all of the application’s dependencies and all of the orchestration steps for that application to run successfully in any environment regardless of where it is.”

So by doing that, and by removing that layers – that bottoms up layers dependency, what we’ve really done is created an application stack, an enterprise automation stack is what we’re calling it where infrastructure and application automation marry together at a very, very clean abstraction level. The abstraction level is essentially, if you’re running software on the operating system that runs above the kernel, it should be defined by application packages and orchestration, and not by infrastructure packages and orchestration. Now, it’s architecturally it all makes sense, and it actually works really well in practice. Where it’s complicated is that organizationally, INO – traditional INO operators and other infrastructure groups have been tasked with more and more software deployment on top of their stacks. So this is a very paradigm-shifting idea. I think what is helpful for us is the enterprise automation stack allows us to create a framework and a template for how to do that in a way that helps customers adopt that methodology much, much quicker.

Shimel: Fair, fair. So we got Chef Infra. We have Chef InSpec.

Scobie: Yes, and Chef Habitat, Chef Habitat.

Shimel: Chef Habitat sits – I wouldn’t say it sits on top of them.

Scobie: Look, the stack is – we have trouble with this with our marketecture diagrams. If, what happens in the podcast now is you’ll throw up the marketecture diagram you’ll have, what you’ll see is a linear stack, but the state relationship between those three things is much more complex than can be defined in a diagram like that.

Shimel: _____ diagram, sure.

Scobie: Then on top of that, then there’s two other pieces to the portfolio. So we have Chef Automate, which is the observability layer on the top. Of course, if you have automation on all of these things, you want to be able to see across all of your pipelines, across all of your applications, across all of your systems. What is the state of everything that’s running? How has it been deployed? Is it in compliance or not in compliance, etcetera? So we’ve got this whole enterprise dashboard with automation up top. Then on the bottom end of the stack is we need to make it easier for developers to get started. So all of these engines are representative of either infrastructure compliance or application automation as code. What do you do as a developer? You download a bunch of tools. You get started writing code that are the artifacts that actually drive that automation. So Chef Workstation is the compilation of all of those tools and an easy way to set up your development environment to get going. That’s the entirety of the enterprise automation stack. It’s Chef Workstation, Chef Infrastructure – Chef Infra, Chef InSpec, Chef Habitat, and Chef Automate on top.

Shimel: And repeat for me, what all of these packaged together is the –

Scobie: Yeah, the Chef Enterprise Automation Stack.

Shimel: That’s the whole enchilada, so to speak. This is all packaged up into one coherent type of product, if we can call it that. Fair?

Scobie: Exactly. Yeah, one coherent distribution, absolutely.

Shimel: Corey, you know the news broke today around this. Some are saying, “Well, Chef is pivoting. Chef is this.” How do you view this? How do you and the other folks at Chef view this? Is this really a pivot? To me, it’s – I don’t see it as a pivot.

Scobie: Yeah, it’s not a pivot. I mean, first of all, I don’t think it’s – we’ve – you can question the effectiveness or the efficacy of our open source strategy in the past as we’ve meandered through different phases of that, but this is us staying true to the fact that we are an open source company, and so I think we’re leaning into the business model by which Chef was founded, and by which we’ve been operating for quite a while.

Shimel: I agree with you.

Scobie: I think from a technology perspective, we just have more clarity now in how to deliver the components and technology that have become critical to customers who are trying to solve large-scale enterprise automation problems. I don’t know that I would really describe it as a pivot. I think what we’re trying to do is use this as an opportunity to reintroduce people to Chef who maybe haven’t heard of the latest of our innovation in InSpec and Habitat, as an example, who maybe are not familiar with the work that we’ve been doing in the last three or four years. For us, it’s a little bit of a rebirth, but I wouldn’t call it a pivot.

Shimel: I don’t know if I’d call it a rebirth. So here, look, you’re in the forest.

Scobie: I am in the forest. There’s no question.

Shimel: [laughter] I’m outside the forest. To me, obviously a pretty – I’m more than a casual observer. To me, Chef was always an open source company.

Scobie: Always.

Shimel: I think in some ways, what we’ve seen with Chef over the last five years, I would characterize as growing pains for an open source company trying to come to grips with remaining true to its open source roots, while at the same time recognizing you took other people’s money, and that’s how – I lived that life for 20 years. You take other people’s money, they want – it’s a funny thing. They want to get a return on their investment. It’s like trying to serve two masters. It’s a hard – it’s a hard –

Scobie: Not only that, but look, the successful commercialization of any open source project or software company is how you actually create sustainable good in that community for the long-term. Obviously, you need participation from the community, but you also have to inject capital into that community if you want sustained innovation.

Shimel: You have to extract revenue as well though. That’s where I think it gets dicey. So when I look at InSpec and Habitat, I almost feel at some level, they were somewhat hobbled by having to live in this schizophrenic, open/not open, making money/not making money. Well, if it’s totally open, we’re not making money. How much do we put into this? There was just too much of this all over the place, where to me, this is just a clarification. Look, Chef is and will remain an open source company, and our value to our investors is that No. 1, we have this tremendous community around us who are users of our software as well as contributors to the community, but No. 2, we are now offering a proprietary, a for-profit solution that takes the best of this and packages it up nicely.

Scobie: Absolutely. Look, Alan, you make a great point. I would love to give a shout out to the community, because the Chef community is absolutely amazing. I know you’ve been to ChefConf. It’s an experience in and of itself. It’s hard to think of another tech conference that is as authentic and as welcoming and as diverse as ChefConf is, and it’s a bunch of people that come together every year, because they are passionate about solving the challenges of infrastructure management at scale, and application deployment at scale, and all of those things that Chef is interested in as well. So the community is a really key factor of it, but to your point is that there’s just this growing demand in the enterprise. We are the experts in figuring out how to do that in a really, really tight curated way. Of course, we’re going to take advantage of that market opportunity as well.

Shimel: Sure, we got the news out. Is there any part of the news we’re missing, Corey?

Scobie: No, I don’t think so. That really covers the announcements for today. I think the only other thing is we’ve got ChefConf 2019 coming up in Seattle May 20^th – 23^rd in Seattle. It’s going to be a great event. We also have a ChefConf for the first time ever, ChefConf coming to London at the end of June. It’s June 19^th and 20^th, I believe are the dates in London.

Shimel: Really?

Scobie: Yeah.

Shimel: You know I’ll be in London those dates. I’ll have to talk to you about it.

Scobie: Yeah, absolutely. We’d love to see you there, and we’d love to see others there as well. Yeah, so we’ve got a couple big events coming up where we’re going to showcase the latest of the innovation that we’ve had on all of the fronts, innovation, compliance, application automation, our enterprise consoles, all of that kind of stuff. so those are going to be fantastic events coming up. So other than that, we’re looking – we’re really looking forward to getting back to those community roots and really everybody being there together in the trenches together building the next generation of what this is all going to be.

Shimel: Cool. So now let me ask you a question. Put on your wizard’s hat. If we’re talking about ChefConf 2020 now, a year from now, this strategy, this road has been – this strategy has been implemented now. We’re going down this road. How does it manifest itself over the next 12 – 24 months you think?

Scobie: Look, we’ve been talking about that from a product strategy perspective, and I think we’ve got – there’s a lot of opportunity for us to do great work in pulling the pieces of the puzzle together, even more explicitly. We’re doing a lot of work with partners, so I anticipate that the ecosystem partners will be a big player in ChefConf 2020 as well. So we’ve been working with the likes of everybody from Microsoft, Azure DevOps, and the workflows there. We’ve got – we’ve been doing some product work, and continue to do product work with Amazon in the ops work for Chef Automate, managed and hosted to platform there. We’re quite engaged with GitHub because we’re seeing both GitHub and Artifactory and a lot of our customers in the DevOps toolchain and pipeline there. We’re doing some work with that. We’ve been doing a lot of integration with services now. So I actually think that the next phase of this is not just about the Chef parts of the stack, but how those parts of the stack connect with the rest of the ecosystem that is fast emerging in the enterprise automation space as well.

Shimel: Sounds cool. Well, Corey, we’re about out of time. I want to thank you for taking time on what’s a crazy busy day for you guys, to brief our audience on this. Congratulations to the whole Chef team. Tell Barry and everyone else, looking forward to ChefConf. Unfortunately, I won’t be at ChefConf in Seattle. I’m in Europe, but we’re going to have a full team there doing video interviews there and everything. John Willis, our partner at Digital Anarchist will be there, and Chris Reilly. So we’ll have plenty of Chef coverage from ChefConf. Like I said, I didn’t even realize the London one. We’ll try to get over there. I think that’s Tech Week in London actually, which is a pretty big week.

Scobie: Yeah, fantastic. Well, thank you so much, Alan. I appreciate you taking the time today as well. Look forward to seeing your colleagues at ChefConf in Seattle, and then hopefully we’ll see you in London in June.

Shimel: Absolutely. Hey, Corey Scobie, SVP Engineering and Product. I got it right.

Scobie: You got it right.

Shimel: You’re talking to us about some news coming out of Chef today, a little bit of a change in how they package stuff, but they’re still an open source company. Corey, thanks very much.

Scobie: Thank you, Alan.

Shimel: Take care. This is Alan Shimel for staging-devopsy.kinsta.cloud, everyone. Have a great day.

— Alan Shimel

April 2, 2019
When DevOps and Marketing Collide: Insights From Adobe Summit 2019
I attended Adobe Summit 2019 to research the intersection of DevOps and marketing. Below are insights from my interviews with leading marketing technology experts.

Is DevOps making its way into marketing? In a short answer, a soft “Yes.”

I recently attended the Adobe Summit, held March 26-28 in Las Vegas. This year emphasized digital customer experiences, and I was curious to take a peek into this world of marketing tech to see if DevOps was having any impact.

Many of the people I talked to described how marketing technology is adopting a more agile, DevOps-inspired mindset. But is marketing actually driving product change? While Adobe and proponents would like to have us think so, some are not as sure.

At Adobe Summit, I had some eye-opening meetings with professionals invested in digital marketing, retail and analytics services, most of which are using Adobe products in some form. In this article, we’ll highlight what they had to say on the intersection of DevOps and marketing.

What is the Role of DevOps in Marketing?

The need to break down data silos was a common theme among keynotes, sessions and throughout my meetings at Adobe Summit.

When large digital marketing agencies take on clients, for example, a common disability they find is a disparate and dysfunctional customer data storage system. In our meeting, Alex Kelleher, managing director at Deloitte Digital, noted, “Data needs to be available, and integratable. That is the first thing we typically fix for our clients—we’ll fix the data in silos, get it in the same place, and usually simplify it.”

Deloitte Digital’s process involves three D’s: first, they consolidate data silos, then build data-driven decisions, then deliver agile products. In doing so, Kelleher is seeing more and more developer practices making their way into marketing and sales.

“We’re seeing CMOs manage their teams as agile teams, recruiting agile and scrum masters,” he said. “That’s very cool for CMOs to be involved in … those worlds colliding is super exciting.”

Is DevOps Eroding Traditional Boundaries?

DevOps principles encourage shared knowledge and open communication between teams. Now, it appears such ideas are affecting how marketing technologists architect their teams and delivery cycles.

Rachel Lane, solution principal customer experience at Medallia, sees a trifecta of forces working in tandem. “Development, Ops, and Marketing must work together,” she said. “If one of those doesn’t link up, then we see extended lead time to launch, and it can become problematic.”

Medallia’s goal is to meet customers where they are to gather actionable feedback through push notifications, surveys, embeddable surveys, Net Promoter Score (NPS) systems and other means. Engrossed in this world of customer feedback, Lane reminded us: “You should never ask a question that you already know the answer to.”

Unfortunately, this still happens often. User data is often locked in silos and if multiple teams (sales, marketing, support engineers, etc.) are using separate user data repositories, customer interaction can suffer. Thus, user conversation data must be de-siloed and unified.

For Lane, having tight customer experience-driven feedback is critical for reiterating the overall product. However, customers typically hate filling out surveys. To decrease friction, she foresees more passive voice-driven feedback through home AIs.

Rearchitecting the Digital Footprint for Agility

By now it’s evident that unclear data initiatives and messy data storage can hinder digital transformation. So, what are organizations doing to de-silo and open up data?

Anheuser-Busch (AB) is a huge beer corporation, overseeing brands including Budweiser, Busch, Elysian and many others. Each has unique online eCommerce storefronts to sell ancillary swag, such as T-shirts, drinkware and other products.

With public-facing sites for hundreds of brands, maintaining data standardization across its product lists was a nightmare. Disparate data structures can also inhibit directing change from within, slowing corporate-led growth.

John Faviano, director of demand and integrated marketing technology at Anheuser-Busch, described how AB solved the issue by creating a consistent data structure from which all online stores can pull content from.

“We’ve standardized the tech stack in the last three years to enable the business to run more efficient … You have to think from a platform perspective, not a single siloed technology,” he said.

AB’s web APIs now grant incredible scalability, as the content is now delivered agnostic of client or brand. AB brands retain independent facades yet are fueled by a unified content storage and delivery process. “Our API strategy is a build-once-and-scale mechanism,” Faviano said.

Digitization with IoT and AI

Sreedhar Bhagavatheeswaran, SVP and global head of digital business at Mindtree, believes that every part of the enterprise needs to be digitized. He sees a wealth of untapped data that enterprises can leverage to transform user experiences.

Having built digital presences for big-name consumer brands including Marriott, P&G and Kellogg’s, Mindtree understands the advantages of using a DevOps approach for software cycles. Though it may require a cultural change, “The probability of project success in a DevOps environment is much higher than in a non-DevOps environment,” Bhagavatheeswaran said.

Release automation is integral to Mindtree’s process. Coding checks and CI tools such as Jenkins bring quick releases, enabling business teams and clients to see the impact on a daily basis. They also privilege API-fueled microservices designs for increased agility.

“From an agile program management perspective it gets challenging, but that is the nature of the beast,” he noted.

Bhagavatheeswaran is excited for the potential IoT has to evolve industrial, business and consumer-facing touchpoints. For example, industrial engineers could conduct remote servicing using digital twins of real physical equipment. He also described developing mobile IoT apps for his clients: Push notifications triggered by removing caps from makeup bottles, for example, could empower consumers with advice on how to apply makeup correctly.

To sum it up, Bhagavatheeswaran described our current paradigm with a simple, powerful sentiment: “The experience is at the confluence of edge, humanity and intelligence.”

Approaching the Developer Experience

But digital transformation doesn’t stop with open data, APIs and IoT. Developer experience (DX) has become an important factor in maturing countless digital services.

Jason Woosley, VP of commerce product and platform at Adobe, founded the Adobe-acquired Magento, which began as an open source project on GitHub, welcoming pull requests to alter product features (with the proper vetting in place, of course).

By investing in open source and developer communities, Magento over time reached a critical mass, democratizing how developers build online storefronts.

Woosley estimated that 50 percent of Magento code was built by third-party developers. One such feature is multi-source inventory, which, he said, accounts for 70 percent of the Magento code base. Naturally, he has a deep appreciation for the power of developer communities.

“You can’t buy a developer community. You can’t steer or create a culture,” Woosley said. “Code custodians are actually participants, and to deserve that role DX needs to be delightful and empowered.”

To improve the developer experience, Magento has hosted countless events, increased developer support staff, annotated its APIs, adopted GraphQL for extensibility, invested in optimizing developer portals and more. With the inclusion of Magento in Adobe Experience Cloud, more capital is available to further DX enhancements—something Woosley is excited about.

Wednesday March 27, 2019 in Las Vegas. (Jeff Bottari/AP Images for Adobe)

DevOps is Kicking Martech to Innovate

Deloitte Digital’s Kelleher noted that “nowadays, your competitors are any digitally active application,” regardless of whether they’re even in the same industry.

This means that a consumer will judge a mobile digital experience with an airline with the same scrutiny as calling an Uber or making a PayPal transfer. Users hold the same lofty digital expectations from any business, forcing us all to adapt dramatically.

Fueled by the relentless pressure from users, marketing technologies are adopting DevOps principles to improve their offerings in a few ways:
- Continuous releases: Martech uses DevOps strategies to release quickly. User-facing mobile app release cycles, for example, routinely adopt CI/CD.
- De-siloing: User data and consumer conversation information are being distributed with greater alacrity across enterprises, improving end UX.
- Open data initiatives: With web APIs, new platform-agnostic content distribution architectures have emerged. Development procedures are standardized across an enterprise, quickening the release cycle.
- Cloud architecture: By adopting cloud-based management tools, martech is improving the asset management condition of supporting many user-facing touchpoints.
- Developer experience: By embracing open source and supporting developer community, leading e-commerce groups are improving their offerings.
While marketing is critical to the whole, it may not be the No. 1 business driver. When I asked Bhagavatheeswaran whether marketing was really driving the creation of new tools, he responded: “Is marketing driving the tools? Are they influencing? Not quite yet. However, it has the ability to influence the developer’s quality. Probably not their job.”

Even if marketing is not directly influencing product development, we’re still seeing DevOps seep into traditionally non-technical environments, which is exciting.

It was eye-opening to enter the world of marketing technology to see firsthand how these institutions—such as Ansira, a 100-year-old company—are using agile means to streamline digital transformation initiatives.

With an emphasis on both creating and managing quality digital customer experiences, Adobe Summit 2019 shed light on many unique strategies being undertaken in the realm of martech.

Whether it’s leading the development of user-facing apps, overseeing expansive brand catalogs, using a cloud-based single source of truth for content management or building developer communities to reap huge R&D benefits, the intersection of marketing and technology has never required more strategic action than it does now.

— Bill Doerrfeld
March 29, 2019
Got DevOps Skills? A Look at the Upskilling: Enterprise DevOps Skills Report
IT recruiting is at an all-time high and organizations want T-shaped professionals with cross-functional skill sets to join their teams. While “T” represents an individual’s core competency, and the top of the T represents a broad range of related knowledge, there has been little clarity on which skills are the most important across a wide spectrum of possibilities—until now.

DevOps Institute launched the Upskilling: Enterprise DevOps Skills survey in 2018 to focus on the human element of skilling. The feedback from more than 1,600 individual responses echoed the notion that regardless of vertical, organizational size, geography or role, DevOps practitioners need data-backed skilling statistics. As the focus within the enterprise, DevOps community shifts from “What is DevOps?” to “How do we do DevOps,” this demand is more crucial than ever. After all, “how to” requires “know-how” and “know how” requires a new set of skills. But which skills?

According to DevOps Institute’s Upskilling: Enterprise DevOps Skills Report:
- Soft skills and technical skills are equally important
- IT operations knowledge received the most “must-have” votes as a functional skill in DevOps
- Cloud and analytical knowledge are the top technical skills
- DevOps Engineer emerged as the most popular job title (see below for figure N=812)
N=812

The report was developed in partnership with veteran research analyst Eveline Oehrlich, formerly of Forrester Research. This comprehensive data provides indications of which functional, process, technical and automation skills are “must-have,” “nice to have” and “not important.”

This is particularly significant for IT professionals who are confused about where to focus their personal skills transformations in their journey toward the “T.”

Should developers work on upskilling their testing, automation, process and/or security skills? Should operations professionals learn to code, test or explore more about machine learning and AI? What about project management and systems administration? The Upskilling: Enterprise DevOps Skills Report can be used as a snapshot of critical enterprise skills that are important to successful digital transformation.

The Upskilling: Enterprise DevOps Skills Report was released March 4 and is now available for download. On behalf of Platinum Sponsor Electric Cloud, Gold Sponsor CloudBees and Silver Sponsor Lenovo, industry influencers and international DevOps community, we hope this data will help shrink the skills gap and support the transformational goals of both individuals and organizations. We’re already looking forward to the launch of DevOps Institute’s Upskilling: Enterprise DevOps Skills Survey 2020 to continue meeting the demand for ever-evolving skilling trends in the DevOps community—stay tuned!

— Jayne Groll
March 11, 2019
DevOps Chat: Repos and Nexus Firewall Access, with Sonatype

There are really only two repositories of any scale for software components today: the Nexus repo managed by Sonatype and the Artifactory artifact repo managed by JFrog. Up until now they were separate and apart, and working with one was independent of another.

In a big move toward keeping DevOps open and secure, the Sonatype people have released a plugin that will allow their Nexus Firewall to work with Artifactory as well as Nexus.

This means that users of both repos can now use the Nexus firewall to make sure that components or artifacts they download are in compliance with the policies they have set up. They can make sure there are no known vulnerabilities to the version users are downloading to use. This is really a big deal and kudos to Sonatype.

In this DevOps Chat we speak with Wayne Jackson, CEO of Sonatype, and Brian Fox, CTO and co-founder of Sonatype, about what this means for the DevOps community.

Transcript

Alan Shimel: Hey, everyone. It’s Alan Shimel, staging-devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. Today’s DevOps Chat is breaking some big news from our friends at Sonatype. I’m really honored and happy to be joined by Sonatype Wayne Jackson and Sonatype CF – CTO, Brian Fox. I hope I didn’t mess that up, guys. Wayne, Brian, welcome.

Brian Fox: Thanks.

Jackson: Thank you, Alan. Great to be with you and great to be speaking again.

Shimel: Yeah. Well, Wayne, you and I go back just a couple years.

Jackson: [Laughs]

Shimel: Let’s not go and do a history thing. Let’s get right to the breaking news today, and that is kind of a major addition to the Sonatype – I know it’s a firewall. Do you still call it Nexus Firewall or is there a different name for it now?

Jackson: Yes, we – yeah, that’s correct.

Shimel: It is the Nexus Firewall. So before we talk about what the major addition is, let’s lay a little groundwork here. What is the Nexus Firewall? Brian, you’re the CTO, let’s give that one to you.

Fox: Alright, sure. Nexus Firewall is a set of capabilities that allow us to do analysis of components as you pull them into your supply chain through your repository and be able to match that against your policies to enforce things like architecture, quality, license, et cetera, and so specifically it’s intended to be able to stop components from coming into your supply chain when they’re known to be against your policy right up front. So you can stop developers from pulling in a component that has a known vulnerability or pulling in a component that has a incompatible license, those types of things. So that’s the role Firewall plays in the overall portfolio.

Shimel: Perfect. And, you know, let’s be clear; that – you know, a Nexus Firewall, if it’s in place the Equifax breach never happens for all intents and purposes.

Fox: Well, that might – what it doesn’t do – you know, it’s not gonna go back and take out the things you’re already input.

Shimel: You’ve already put in, you’re right.

Fox: Right. Certainly. If – you know, we still see lots of cases – I think we’ve done some of the studies recently that show organizations are still downloading the same thing that got Equifax attacked, right?

Shimel: Absolutely.

Fox: It’s the same version of Strut. So, Firewall would definitely stop that behavior, no doubt, and be able to prevent it from further propagating through your supply chain.

Shimel: And just a little shout out, Equifax is now a Nexus – a Sonatype Nexus customer, correct?

Fox: Yeah, that’s correct.

Jackson: Yes, that’s correct.

Shimel: So hope – well, at least it’ll prevent the next one, hopefully. So – but guys, so we understand what Nexus Firewall is now, and again, to put in context the importance of today’s announcement, Nexus Firewall worked when you were pulling components out of the Nexus repository up until now. Am I right or am I off base here, guys?

Jackson: No, that’s correct.

Shimel: And so the big news today is you’re expanding beyond the Nexus repository to offer protection from artifacts and code and so forth from other repositories.

Jackson: That’s right. It’s – you know, it’s an acknowledgement, and it may be the first one in this category, that just acknowledges that the DevOps world is heterogenous. You know, there are bunches of vendors and, you know, people within organizations make different decisions and we just acknowledge the need to provide universal protection.

Shimel: Absolutely. So Wayne, work with me here. It’s the Nexus repository, and with this new release out today you guys are also announcing support and protection for the Artifactory repository, correct?

Jackson: That’s correct.

Shimel: And –

Jackson: And between those two, you know, I’m not sure what the coverage is but it’s gotta be in the 90^th percentile of implemented repositories.

Shimel: I would agree with you. I think between Artifactory and Nexus it’s gotta be I would say high 90’s even, right? We’re not talking 91 or 92 percent. I think it’s probably way up there, and it’s certainly in the billions when you look at the amount of whether it be code or components or artifacts that are contained between the two of them. And Wayne, you hit on it before about the heterogenous nature of today’s DevOps world. It really is; it’s become Artifactory and Nexus as the two big ones.

But there’s another aspect to the heterogenous nature of today’s DevOps world and that is this whole notion of the software development life cycle, managing the software pipeline, the modern software factory; different companies are calling it different things but it all refers to kind of the way that software is being both written and assembled in – by, you know, modern IT departments today. Why don’t you guys expand on that a little bit.

Jackson: Yeah, I – it’s been fascinating to watch. As you know, I came from the network security world before Sonatype and had no grasp of just how much software was being written. As I’m sure you know, you know, one of the assets that we manage in the ecosystem is this thing called Maven Central, and last year we served 142 billion download requests, and so – and that’s just in the Java ecosystem and, you know, other ecosystems like NPM are just as big.

Shimel: Yeah.

Jackson: And so as we started looking at the patterns in these download requests we started to see this weird disconnect. You know, the disclosure of a vulnerability had almost no impact on usage patterns, and that led us to thinking about, you know, why that might be and how we might think about solving these problems more systematically, and it dawned on us that we had a massive supply chain problem. You know, where the producers of things didn’t have a very effective mechanism for communicating to the consumers of those things because there were just millions and millions of projects that had to be monitored. And so, you know, we started looking at the works of Edwards Deming, who was the guy that transformed Toyota from being a textile manufacturer to the world’s most efficient automobile producer, and it really wasn’t all that complicated. You know, you have fewer, better suppliers, you use the highest quality parts, maintain transparency throughout the system, and don’t pass defects downstream.

If you can do those four things, lo and behold, [laughs] producing cars becomes a lot easier. And, you know, we concluded that those exact same principles applied perfectly to software where, you know, to your point, you know, now all of a sudden these software development functions, especially in the more modern organizations, look like a software factory, and so let’s use fewer, better projects, let’s use the versions of those projects that don’t have security defects, that have the kind of license that matches our distribution model and, you know, let’s build a model where we know [laughs] what’s in the system. And if along the software factory assembly line we discover that there’s an issue, stop it there. You know, don’t pass it downstream.

So anyway, so it’s a model – you know, I’m a little bit of a car guy so it [laughs] certainly works for me, but it feels like a model that’s right.

Shimel: I agree. It absolutely does. And even before you mentioned Deming, and of course it’s obvious, I was thinking third-party suppliers just like we do see in the automobile industry. But what’s interesting is as you referenced, the sheer magnitude of the numbers here – you know, 142 billion – think about what that means. I mean it’s just an incredible, incredible amount of downloads of usage and everything else and, you know, it doesn’t take many bad apples to spoil the party for everyone, obviously. You know what’s interesting though, guys? Again, getting back to the DevOps community, the DevOps market today, Sonatype is very much – you know, who you are and what – it seems to me anyway – you know who you are, what you are, where you play and how you fit into this.

And I think that’s in contrast to – you know, we’re in a little bit of a time of upheaval in the DevOps spaces as the market matures and vendors are jostling and trying to – I think some of them might, you know, even be going through an awkward teenage phase, you know, where they’re trying to figure out who they are and what they’re gonna be when they grow up. You know, what – Wayne, you’re the CEO there – what’s the vision for Sonatype? Are you kind of comfortable in your own skin now and what is that role?

Jackson: Yeah. I think we are comfortable in our skin. I think this embrace of software supply chain management is who we are, it’s who we’re going to be, it’s sort of a unique position to take in the DevOps category, and it allows us to play very nicely with the vendors that are all a part of the assembly line, you know, whether it’s Artifactory or CloudBees or any of the other vendors. And so being able to produce information that gets translated into knowledge that, you know, automates decision-making with regard to supply chain integrity, I think is a good spot for us.

Shimel: I agree. I mean and not only is a good spot I think it’s a pivotal role to play at this – you know, as we see the continued maturation of the market and, you know, it’s all wrapped around the digital transformation and everything going on. Brian, you know, your background, you were an early chair of the Maven Project. You’ve been in this opensource, you know, world for some time, and Wayne did too coming from the Sourcefire Snort folks, but what’s your take as we see this, you know, maturation? I mean at some level it’s gotta be – I would imagine it’s gotta be encouraging to see cross – like, you know, being able to protect across different repositories, whether it be Maven and Java or Artifacts or what have you, right? It’s gotta feel like we’re making progress. What do you think?

Fox: Yeah, I think so. I mean our approach since we kind of went down this path, what, 2012 or so is to take an approach that sits above all of the tools, because we recognize from the early days when we were doing a lot of Maven training and consulting and we had the privilege I guess to go to companies and see lots of horrifying processes and all the ways in which attempts to make this better inadvertently made things worse, and we recognize that it requires a sort of across-the-life cycle approach, which means you can’t solve the problem just by adding features to, you know, the repository or the CI. And frankly, given that we were building Nexus Repo Pro back then – I mean we still are, but that was our main product back then – adding it as features on top of the Repo would’ve been the most natural thing for us to do, but we understood through all of that learning that that wasn’t going to be sufficient.

It required integration to the Repo and to the CI and to the build and to the release automation tools, et cetera, et cetera, right, to be able to most effectively nuance the process of the components that flow through that, because you may choose to respond to a policy violation differently when something is about to actually be pushed into production versus something that’s just happening in your – you know, on every commit CI build. And so for that reason, being able to integrate into all of these tools, including all of the different repos, is just natural. It’s a natural evolution of the approach we’ve been taking the whole time.

Shimel: Got it. So, I guess the next question is now that we have – you know, between the two repositories we’ve got high 90 percent of the market – how do we get 90 percent coverage with this Firewall product, right? I think we’d all sleep better. You know, what is the key, guys, to getting more people to realize this is kind of a no-brainer that they need to get done here, right? I mean what do you think is preventing us from really seeing this?

Fox: Culture. Culture and history. I think there’s a history of application security tools specifically that, you know, are prone to false-positives just by the way they worked and led – and a history of bad approaches, like I was talking about before, that tried to force bad tools onto development that ultimately led to rebellion or disuse and gear grinding, and so in some ways the security tribe I think has become a little bit afraid to engage development in a lot of organizations, right? So they very much try to work at the end of the process, try to produce lists. We know that those things tend to get ignored, that they don’t usually have a profound effect on what’s happening, and so the organizations that are really successful are the ones that, you know, can set all of that history aside and still work together in a DevSecOps type of way and, you know, look at the problem holistically and understand that, yeah, actually it makes sense. If we can stop the bad things from coming into the process to start with we don’t have to chase them out later.

The security guys don’t have to track it in the list and the Dev guys don’t have to go rework it, right? And so, you know, that’s kind of the approach that we’ve been trying to take, that all of these different constituents have an important job to play in the success of a business and it works best when [laughs] they’re all working together, not working against each other and throwing grenades over the walls.

Shimel: Absolutely.

Fox: And so really, you know, the biggest hurdle to adoption in most places just simply is that culture and the history of disdain and things like that.

Shimel: Yeah, I agree, Brian. And guys, I’m gonna tell you something. Here’s a private theory that I’ve been working on and I’m gonna be speaking about it in the months ahead. You know, we’ve worked really hard – Sonatype more than most any other vendor I can think of – to advance the cause of DevSecOps. You know, Derek and Mark on your team and myself have been putting on DevSecOps events at RSA for the last five years now, and we do it in Singapore at RSA and we go all over the world with this DevSecOps thing. And recently, in the last couple months, I’m starting to see sort of a bifurcation in how security is dealing with DevSecOps, right?

I’m seeing some companies that are embracing the Dev sides of things, and let’s call that DevSec. They’re working with developers to make the code more secure and make sure that pre deployment and everything is tested, everything is secure, and we release really tight, good quality, right? Security is synonymous with quality, and let’s call that DevSec. Then there’s another group of vendors, Brian, that are dead into what you’re talking about, right? They’re almost afraid, intimidated, or just fed up with dealing with developers, and they’re really focusing on the post deployment aspect of things here, right, and let’s call that SecOps, because they want to work more with the Ops folks, post deployment, you know, monitoring and that kind of thing.

And I’m not saying that there’s not a reason to do that or it’s not right to do that – it absolutely is – but when we start looking at it as DevSec and SecOps, we’re committing the same mistakes that we did to begin with and we’re losing that it is DevSecOps for a reason. It’s Dev and Ops and Sec all working together. We can’t say, “Oh, we’re gonna work with the Ops guys but not the Dev guys or vice versa.” It’s gotta be everyone’s in it to win it. And I –

Fox: Completely agree.

Shimel: But I’m – yeah – but I’m seeing security vendors now kind of, you know, taking sides here on this. I’ve recently done a few podcasts – and some of them are new companies that are launching or coming out of stealth and RSA, and they’re growing this distinction that they’re SecOps, not DevSecOps, or they’re DevSec, not Dev – and I think it’s a huge mistake, a huge mistake.

Fox: I think that’s largely led by the constituent. If you go and talk to the security guys, that’s what they’re gonna tell you that they want, right? It’s part of that history.

Shimel: Yeah.

Fox: You know, so if you allow yourselves to be pulled directly in the direction of what people want based on their perceived understanding of just how things work and that’s the way it’s always gonna be, that’s I think where you end up, so you have to buck that trend a little bit and say, “Guys, it doesn’t have to be this way. It can be better.” But we have to work together to do it, right, and we have to think about things a little bit differently. You know, and I have many conversations – you know, it’s happening more and more as AppSec and OPSEC is becoming more generally aware of the opensource component, you know, risk. They’re starting to come at the problem, but unfortunately they’re just trying to add more data to their existing process, and I have to remind those guys all the time that developers are picking new components all the time, they’re picking new versions of those components all the time.

They’re not only doing it because you handed them a list of vulnerable components or a list of CVEs and said, “Fix it or else,” right? So wouldn’t it be nice if you had a process and a set of tools that could support them in that behavior so they don’t come on your list later? [Laughs] Right? And a lot of times that is like a shocking realization to that tribe, right, and that’s that culture that I was talking about. It’s a big challenge.

Shimel: Agreed. And look, our work is not done, right? That’s what that means to me. We still have more work to do evangelizing DevSecOps and making sure people under – take a whole holistic aspect to it, and it goes back, Wayne, to what you were talking about in terms of the pipeline and the software, you know, automation and pipeline kind of thing, is it’s not bifurcated at the pre deployment versus post deployment juncture or junction. It – DevSecOps is about the whole thing from end to end.

Jackson: Yeah, the organizations that can think about this holistically are just bound to be more effective and more efficient and, you know, to your point about evangelism, I mean one of the things that we’re going to see, and I think we are seeing, is that the most highly-performing organizations are the ones that are getting it.

Shimel: Yeah.

Jackson: They’re the ones that are gonna be leveraging software to more effectively differentiate their business. [Laughs] And at some point, unless you want to lose, you’re gonna have to start thinking about the ways that these, you know, forward-thinking, advanced organizations are doing what they do to make themselves better every day.

Shimel: Absolutely. And you’ll have winners and losers, and look, that’s capitalism and that’s the market dynamics at play, right? You can adapt or die or not, right? I mean it’s up to you. Guys, we’ve spent a lot of time talking, you know, about this at a macro level. Brian, if you don’t mind, I’d like to get a little geeky on you and ask if you can explain to our audience at a nuts and bolts level really what’s going on with the Nexus Firewall.

It’s software, right? It’s not an appliance, per se. Where does it sit, how does it intersect, how do you set policies in it? You know what I’m saying? Let’s give our audience a little bit of a…

Fox: So our Nexus platform is kind of composed of maybe three parts. At the core is a piece of software that you run on prem or in your cloud that we call the IQ Server, and this is the thing were you define your policies, it’s the database of all of the components and which applications they’re used in, the dashboarding, the reporting; you know, all of that type of stuff occurs within the IQ Server. The IQ Server works with services that we have in our cloud to provide the real-time information around the components and the security and the licensing and all that type of stuff, right? So that’s a real-time feed, it’s not a data dump that you have to download periodically.

And then there’s all of the plugins, the plugins that go into all of the places I mentioned before; your build, your IDE, your CI, your repository, your automation tools, et cetera, right? And so what we’re talking about here is we’ve added a new plugin that plugs into JFrog Artifactory. So when a component is being proxied from an external repo, such as Maven Central, the plugin will do the analysis of the thing being requested, it will understand what it is, work with the IQ Server to understand if it’s in compliance with the policy or not, and the depending on how the policy is configured it can either allow it, it can quarantine it, or it can just outright block it, right? So that’s the same capability that we’ve had for a couple of years now inside of the Nexus repository, so it replicates that functionality for our JFrog users.

Shimel: Fantastic. Wayne, how are we going to market with this?

Jackson: I get that question asked to me a fair bit, and we have a very multifaceted go-to-market model. You know, we still have folks that are very senior out in key regions that are evangelizing, because this is still an immature market, but increasingly as the market’s maturing are starting to lead with product and product capabilities in our marketing function. So, a mixed model, but one that we think aligns with where the market is in terms of its maturity, you know, that will change over time.

Shimel: Understood. Guys, we’re almost out of time. If it’s okay I wanted to return back to the DevOps market in general. Wayne, you know, you and I kind of saw the security industry mushroom, right, from let’s say early 2000’s through even 2008, ’09, ’10, you know? I – and we now have both – and have both seen the DevOps market mushroom, you know, from 2013, ’14 to today. It’s only been four or five years. And, you know, we touched on it earlier with companies trying to kind of jostle for where they are, what they do and how they fit into this brave new world. You know, put on your visionary hat, if you will. Where’s this going? Where is it – you know, is there a logical sort of conjunction of security in the DevOps? And if so, what does that mean for the broader market? What do you think?

Jackson: I disagree with you a little bit in that – with regard to DevOps having mushroomed. I think we in the industry kind of feel like it has because now all of the sudden people are starting to use our words back at us, but I think in terms of, you know, DevSecOps being a mainstream thing that’s just a part of how people work is still a bit away, and I think, you know, the work that you’re doing, I think the work that we’re doing and other vendors in this space is still enormously critical because even organizations that aspire to DevSecOps still need help. It’s not an easy thing to embrace and implement, as you know, and so there’s still some work to do, which I think is cool.

Shimel: Yeah. Well, it keeps me going every day and gets me up. And you’re right, you know, we tend to forget that we live in a bubble. When you’re a hammer, everything looks like a nail, right?

Jackson: [Laughs] Right.

Shimel: When you’re talking DevSecOps all the time people tend not to look at you and say, “What are you talking about?” So, you know, we kind of breathe our own exhaust, if you will. But there is, there’s a lot of work to be done, even – forget DevSecOps – even in the basic DevOps level, right? When you – a lot of companies have dabbled in DevOps but how many are truly end-to-end DevOps, right, and that number I’m gonna guess is well – is below 20 percent, probably closer to 10 percent.

Jackson: I think you’re right, I think you’re right.

Shimel: Yep. So our work is still in front of us. But hey, you know what? It wouldn’t be fun if it wasn’t, right? I mean that’s what keeps us –

Jackson: [Laughs]

Shimel: Anyway, guys, when is this new plugin for Nexus Firewall available?

Jackson: More or less now.

Shimel: Okay.

Jackson: I think the official release date is March 1, but yeah, happy to show it to anyone who’s curious to see and very proud of the technology.

Shimel: Absolutely. And they can get more information at Sonatype.com?

Jackson: That’s right.

Shimel: Fantastic. Wayne Jackson, Brian Fox, CEO and CTO, cofounder of Sonatype, respectively. Thanks for being our guests on this episode of DevOps Chat.

Wayne Jackson: Thank you. It’s been our pleasure.

Fox: Thanks for having us.

Shimel: Always a pleasure. Always a great time, guys. Okay, this is Alan Shimel for staging-devopsy.kinsta.cloud. You’ve just listened to another DevOps Chat. Have a great day, everyone.

[End of Audio]

— Alan Shimel

February 28, 2019
Fourth Annual DevOps Dozen Winners Announced

We are pleased to announce the 2018 DevOps Dozen honorees. When I launched the DevOps Dozen, I hoped they would grow to reflect and recognize the best of the best in the maturing DevOps space.

This year, there is no doubt in my mind that the winners are unsurpassed in the DevOps community. In fact, the whole process of nominations was open; from the the public making the selections of finalists; the judges and the criteria they used, it really does represent our best efforts.

Congratulations to each and every one of the winners in the 12 categories. It is quite an accomplishment to make it this far into the process. But congratulations not only to the honorees—all of the finalists should be proud to be part of such an impressive list.

Since the nomination process was opened, our team has gone through thousands of votes to pick out the finalists in each category. It was not an easy task, as we couldn’t automate (DevOps) it; we had to do it by hand. Also, many thanks to the judges for making the hard calls and thanks to everyone here at staging-devopsy.kinsta.cloud for helping out.

So, without further ado, here are the 2018 DevOps Dozen winners:

Best DevOps Open Source Project

Jenkins X is the winner of the Best DevOps Open Source Project for 2018. Jenkins X enables developers to take advantage of Kubernetes to develop cloud-native applications without having to learn the intricacies of Kubernetes. Developers can quickly establish CD best practices and cloud development by using the Jenkins X guided workflow that takes full advantage of GitOps, or environments managed as code. The power of GitOps allows developers to easily define, manage, deploy and scale environments with full history and traceability. Jenkins X leverages and packages many other open source projects of the Cloud Native Computing Foundation community around Kubernetes such as Knative, Helm, Prometheus and Vault, providing automatic integration with them and saving users the trouble of integrating all of these components themselves.
Learn more: https://jenkins-x.io/

Best DevOps Commercial Solution

JFrog Artifactory from JFrog is the winner of the Best DevOps Commercial Solution for 2018. JFrog Artifactory is the world’s only universal repository manager, with more than 5 million developers worldwide supporting development organizations across more than 4,500 global enterprises, and supporting all major packaging formats (more than 25), build tools and CI server. In 2018, JFrog Artifactory also won an Innovator award from IDC and the Firestarter award from 451 Research. Artifactory integrates with your existing ecosystem, supporting end-to-end binary management that overcomes the complexity of working with different software package management systems, and provides consistency to your CI/CD workflow. Artifactory is available in OSS and commercial versions, supporting hybrid development and deployment across the enterprise. Learn more: https://jfrog.com/artifactory/features/

Best DevOps Solution Provider Executive

The voting in this category actually resulted in a tie between two of the leading CEOs in the DevOps space. Sacha Labourey is the CEO and founder of CloudBees, the company powering the continuous economy by building the world’s first end-to-end system for automating software delivery. Sacha is also a member of the board of advisors and an investor at Codenvy (formerly eXo Platform), as well as a board member and investor at Wallix. He is praised as being a visionary with a strong understanding of technology and business. Sacha is experienced in open source, cloud computing, software development and more.

Shlomi Ben Haim is co-founder and CEO of JFrog. He brings more than 20 years of experience in building profitable, high-growth information technology companies. Shlomi is a recognized visionary in the DevOps space, having now guided a company from its inception with just three co-founders (along with Yoav Landman and Fred Simon) to a privately held, global DevOps company with a billion-dollar valuation. With the releases of JFrog Xray and the JFrog EnterprisePlus platform in the last two years, Shlomi continues to foresee market dynamics and push JFrog forward to deliver next-generation solutions.

Best DevOps Solution Provider

Electric Cloud was recognized for the third year in a row by Gartner as the leading solution in Application Release Orchestration, scoring highest in three out of three use cases in Gartner’s 2018 critical capabilities for application release orchestration. In Q4, 2018, Forrester ranked Electric Cloud as a leader in the newly released report, “The Forrester Wave™: Continuous Delivery and Release Automation (CDRA).” Additionally, ElectricFlow has been selected by EMA Research as a Top 3 enterprise software product in its new report, “EMA Top 3 Enterprise Decision Guide for Artificial Intelligence (AI) and Machine Learning (ML).” The report provides pragmatic guidance to enterprises on how to optimally benefit from AI and ML and continuously release better software. Electric Cloud is also the founding partner of DevOps Enterprise Summit USA.

Most Innovative DevOps Solution of the Year

CA Brightside is the winner of the Most Innovative DevOps Solution for 2018. CA Brightside is the first cross-enterprise DevOps solution designed to greatly improve the productivity and efficiency of development teams to control, script and develop for the mainframe like any other cloud platform. CA Brightside is also a foundational element of the Open Mainframe Project’s Zowe initiative, the first open source project for the mainframe which strives to attract a new generation of IT administrators to mainframe platforms and make it easier to include mainframes within the larger scope of an integrated set of DevOps processes that span multiple platforms. CA Brightside is designed to make it easy to integrate the mainframe into enterprise DevOps workflows by allowing development teams to control, script and build for the mainframe just like they would for any other cloud platform through the use of familiar open source tools such as Jenkins, Gradle and IntelliJ via a command line interface (CLI). Learn more: https://www.ca.com/us/products/ca-brightside.html

Best DevOps Evangelist

Chris O’Malley, Compuware’s president and CEO, is the Top DevOps Evangelist for 2018. Chris is a highly vocal, incredibly passionate evangelist for DevOps and, more specifically, Agile and DevOps on the mainframe. Having led the Agile transformation at Compuware, he speaks from the heart. No other executive in the industry comes close to exhibiting the energy Chris brings to every engagement, whether it’s a customer meeting or a LinkedIn update. Chris is unwavering in his commitment to make Compuware customers successful and believes DevOps on the mainframe plays a critical role in facilitating that success. Since late 2014, Chris has spearheaded an effort to educate the marketplace on the benefits of DevOps and Agile on the mainframe, as well as create a new generation of mainframe software that speeds this effort. Chris’ extensive media coverage and social outreach in 2018, included more than 25 articles, blogs, interviews, podcasts and conference presentations. Check out a few of his recent posts on ZDnet, Forbes, InformationWeek, eWeek, staging-devopsy.kinsta.cloud Chat, AgileCXO and DevOps Enterprise Summit, as well as more than a dozen LinkedIn posts in 2018.

Best DevOps Transformation

Capital One was the judges’ choice for Best DevOps Transformation for 2018. As one of the most well-known brands in America and among the top 10 largest banks in the nation based on deposits, Capital One offers a wide range of financial products and services to commercial clients, small businesses and individual consumers, both online and in-person at branch locations. The company was founded on the vision that the power of information, technology and testing could be harnessed to bring highly-customized financial products directly to consumers. The thousands of software engineers, testers and other professionals in the Capital One software development organization are making this vision a reality. Beyond their financial success and size, Capital One has a well-known and well-deserved reputation in the tech industry for being one of the most innovative and open source-friendly enterprises in the market.

Checkout this Case Study: Capital One Invests in Continuous Delivery to Automate Software Development Pipelines

Best DevOps Transformation Leader

George Swan is the winner of the Best DevOps Transformation Leader for 2018. George is director of Engineering Solutions at Autodesk, where his responsibilities include modernizing and optimizing Autodesk’s development and deployment capabilities using CI/CD solutions and best practices. George spearheaded the Engineering Solutions team tasked with modernizing the development and deployment solution based on CI/CD methodologies. The team built a source code solution using GitHub Enterprise and a binary management solution using Artifactory. Next, Autodesk standardized on CloudBees Core for orchestration and began implementing secure, automated Jenkins Pipelines. These pipelines enabled both continuous integration and more frequent deployments with shorter lead times via continuous delivery. Swan and his team delivered amazing results: “Productivity increased up to 10X. There is a team within Autodesk that saw a 10X improvement in productivity when they adopted CI/CD. If we can replicate even a fraction of this across the engineering organization, that will have an incredible impact.”

Checkout this Case Study: Autodesk Powers Cloud Initiative and Faster Releases with CI/CD

Best New DevOps Solution Company

ShiftLeft Inc., winner of the Best New DevOps Solutions Company in 2018, is an innovator in application-specific cloud security, delivering the industry’s first fully automated security-as-a-service (SECaaS) solution that understands the unique security needs of each version of each application and creates custom security and threat detection for it. With ShiftLeft, DevOps can make threat detection part of their CI/CD process. ShiftLeft’s approach allows teams to both protect their applications immediately and enhance the security posture of their code. The company was founded by a team with extensive backgrounds in security and cloud infrastructure who were early innovators of technologies such as sandbox, next-generation firewall, next-generation electronic payment network and fraud modeling, as well as several open source initiatives. Headquartered in Santa Clara, Calif., ShiftLeft is backed by Bain Capital Ventures and Mayfield. For more information, see https://www.shiftleft.io/.

Best DevOps Book/eBook

“DevOps for the Modern Enterprise,” by Mirco Hering of Accenture, won the Best DevOps Book Award for 2018. In his book, Mirco, a thought leader in managing IT within legacy organizations, lays out a road map to success for IT managers, showing them how to create the right ecosystem, how to empower people to bring their best to work every day and how to put the right technology in the driver’s seat to propel their organization to success. But just having the right methods and tools will not magically transform an organization; the cultural change that is the most difficult is also the most impactful. Using principles from Agile, Lean and DevOps, as well as first-hand examples from the enterprise world, Mirco addresses the different challenges that legacy organizations face as they transform into modern IT departments. Mirco’s book is also featured by BookAuthority in the list of “26 Best New DevOps Books to Read in 2019.” View on Amazon.

Best DevOps Presentation of the Year

“Project to Product: Practical Realities at a Large Scale Enterprise,” a 30-minute presentation at DevOps Enterprise Summit London 2018, is the winner of the Best DevOps Presentation for 2018. The presentation featured Carmen DeArdo, currently working as senior VSM strategist at Tasktop, and Nicole Bryan, vice president of Product at Tasktop. Carmen DeArdo was the DevOps technology director at Nationwide Insurance, where he was part of the leadership team implementing DevOps practices and technologies across the 20+ IT areas at Nationwide. He is considered a DevOps industry leader, speaking at conferences and writing regularly on these topics at staging-devopsy.kinsta.cloud. He is also regularly interviewed by analysts (e.g. Forrester) and technical publications such as TechBeacon for research and articles. He has presented at previous DOES U.S. conferences. Check out Carmen’s Reflections from DevOps Enterprise Summit 2018 as well.

Nicole has more than 20 years of experience in software and product development, focused primarily on bringing data visualization/infographics and human factors considerations to the forefront of Agile and DevOps. She is passionate about increasing representation of women in technology and improving how software is created and delivered—making the experience enjoyable, fun and even delightful.

Best staging-devopsy.kinsta.cloud Article of the Year

“Continuous Discussions, Episode 90: Gene Kim and DOES18 Speakers,” by Anders Wallgren won the Best staging-devopsy.kinsta.cloud Article of the Year Award for 2018. Anders hosted Gene Kim and several speakers from the upcoming DevOps Enterprise Summit Las Vegas (DOES18) conference to talk about DevOps, the conference program and emerging conference theme of next-gen operations and infrastructure.

The panel of DOES18 speakers included Cornelia Davis, senior director of technology at Pivotal; Damon Edwards, co-founder and Chief Product Officer of Rundeck; Mik Kersten, CEO of Tasktop; Tom Limoncelli, SRE at StackOverflow.com; Gene Kim, founder of IT Revolution and co-author of “The DevOps Handbook,” “The Phoenix Project” and “Accelerate”; and Electric Cloud’s Sam Fell and Anders Wallgren.

Check out the blog to find out the top takeaways from their discussion.

Thanks to everyone who voted and nominated candidates. Stay tuned for 2019 DevOps Dozen and, as always, thanks for supporting staging-devopsy.kinsta.cloud and the rest of the MediaOps family of communities. If you have questions, please write us DD@devops.com.

— Alan Shimel

January 30, 2019
DevOps Chat: Cloud Migration with nClouds’ JT Giri

Moving to the cloud is becoming a must for many companies if they want to grow beyond their current footprint and be more innovative. But for many companies—especially those in the SMB space—their transition to the cloud is hindered by a lack of knowledge and experience, which often results in difficult migrations that sometimes just aren’t successful.

Since its inception, nClouds has helped organizations of all sizes move to the cloud successfully. Its experience as an AWS Premier consulting partner and its well-architected approach to cloud migration helps companies get the most from their infrastructure by engaging with the cloud, whether they’re adopting a hybrid environment or going all in on cloud.

In this DevOps Chat, JT Giri, nClouds founder and CEO, and I speak about the triggers that push companies to adopt cloud, some issues companies face in their decision-making and infrastructure’s role in an increasingly cloud-based IT world.

As usual, the video is immediately below, followed by the transcript of our conversation.

Transcript

Alan Shimel: Hey, everyone, it’s Alan Shimel, and you’re listening to another DevOps Chat, or in this case, perhaps, watching a DevOps video. Happy to be joined here by my friend J.T. Giri, who is the CEO and founder of nClouds. J.T., welcome.

J.T. Giri: Hey—good morning, Alan. Thanks for having me.

Shimel: My pleasure, nice to have you here. J.T., let’s first of all say Merry Christmas, happy new year.

Giri: Thank you, and you.

Shimel: Yeah, it’s been an exciting—we were talking off camera, off mic—it’s been an exciting quarter for you. You’re a new time dad and moving homes and at the same time, nClouds’ business seems to be just booming along with everything else associated with Amazon Web Services and the cloud. So, congratulations.

Giri: Thank you. Exciting times.

Shimel: Yeah, it is. So, J.T., I wanted to talk a little bit about—you know, there’s people listening to this or watching this who are saying, “You know, I wanna be like Google,” or, “I wanna be Facebook” or, “I wanna be one of these unicorns in that I wanna harness the cloud. You know, we have our servers in a closet here or a data center or a third-party data center, but we’re not really cloud. And everything seems to be in the cloud. We wanna move to the cloud, but you know, we’re only maybe 250, 500 employees. How do we do that, right? Do we need a helper, like an nClouds. Do we need to update everything? Do we throw out the baby with the bath water and start new?”

I want you to tell us a little bit, sort of, what’s the typical sort of customer journeys that you see when you guys engage?

Giri: Yeah, absolutely. So, Alan, you know, we’ve talked in the past. I’ve been migrating companies to AWS ever since EC2 was in beta. And, as I would migrate these companies, people would realize that they need someone to manage it, right? So, that’s how, sort of, nClouds came to be. And as you mentioned, this has been an incredible year for us. We doubled the size and revenue and the number of people.

What we were seeing in an SMB type of market, when companies migrate or when they try to migrate to AWS, they still need to follow—obviously, they need to follow best practices because cloud or AWS is constantly changing, and the skill set is just not there. So, that’s where we come in play. We can make sure that your infrastructure is well-architected. We take an approach of migrating in a way where you’re really taking advantage of the cloud—so, for example, using containers, things that are really gonna help you to harness the power of cloud. And then, for most of our customers, you know, we’re providing 24/7 support. And when we see people try to do this themselves, they get a bad taste of cloud. They’re like, “Oh, this is not for us. We’re not really innovating fast.”

So, that’s why, Alan, we’ve been very successful, because there is a huge gap in SMB type of companies. There is a skill gap and just experience. We bring that to the table, and it’s been incredible. We’re able to add a lot of value.

Shimel: Sure. So, J.T., early on there, you said something about when an organization needs someone to help them manage their cloud migration—when does an organization recognize that they need someone to help them? What’s sort of a trigger point? You know, as, again, we spoke off camera a little bit—is it when someone dives in the pool and says, “Oh, my God, I can’t swim, it’s too deep?” Or is it, before you dive in the pool, a prudent person hires a swim coach, you know what I mean?

What are sort of the trigger things that people should see as a red flag or as a trigger event that says, “Hey, man, I should be getting some help, here”?

Giri: Yeah, that’s a great question. So, basically, it depends when the companies come to that realization that we need some outside help, right? Sometimes, it is that they will try to do the project themselves, or in other cases, they realize that they really want to just focus on delivering value to their customer, right? They really wanna just innovate fast.

So—and they see how they can just stay focused on that, and that’s something we do incredibly well. We have a build—we build systems and processes together where our key focus is to make sure the customer can deliver value to their customers fast and we want to make sure the infrastructure is not getting in their way.

So, you know, it’s just, this is becoming more and more popular, like, DevOps as a service, where companies are reaching out to partners like nClouds to help them with DevOps related tasks, like, with the migration, setting up CI/CD pipeline, becoming an extension to their team, so they can focus on their core business, right? And, you know, it really depends when they—sometimes, they come to that realization pretty fast, or sometimes they try to do things themselves, and when things don’t work out, they try to use someone like nClouds.

Shimel: So, J.T., generally, one of the hardest things in life is learning when to ask for help.

Giri: Right.

Shimel: And that includes cloud migrations and everything else. At the SMB level, mid-enterprise level, you don’t have an elaborate or as big a structure as, let’s say, you do with a large enterprise where you have layers and layers of management and hierarchy—a lot of the organizations you deal with are rather flat in their management structure.

So, who is it in the organization who finally kinda raises his hand and says, “Wait a second, I think we should engage in some professional help, right? I think we should being in some experts to help us.” Is it the CEO, CIO, someone lower than that? What’s your experience?

Shimel: Yes, normally, CTO, VP of Engineering type of person. And also, you know, as you know, we became a premier partner with AWS last year. So, AWS is—Amazon, it’s no secret that they’re very customer obsessed. So, they will—Amazon, when they’re speaking to a customer and if they see the customer is struggling, they will introduce someone like nClouds to help them out with the migration or just modernize their infrastructure. And sometimes, you know—actually, many times, they can come in with funding where they will offset some of the costs.

So, for a customer, it’s just like a no-brainer to see if we can have some external experts come in and fix up the infrastructure or streamline the infrastructure. So, you know, the conversation, normally, we do get a lot of business directly from people reaching out, like, “Hey, we need DevOps help,” but we also get a lot of business directly from AWS where they identify this customer needs help, and we get involved that way.

Shimel: So, I’m just gonna bring up two questions. The first one is on track with what we’re talking about. So, now the CTO or CIO or an executive says, “Yeah, we’re gonna bring in nClouds,” whether AWS referred it or is partially subsidizing it or what have you, but, “We’re gonna bring in nClouds or some other type of help”—is there any sort of pushback or resistance normally with, you know, when you’re dealing with people? The—not first responders, but the individual contributors who feel like, “Hey, man, I don’t wanna be replaced. I don’t wanna be outsourced. I don’t want to give up my cheese to some outside company who’s helping us” or, if so, how do you overcome that? How do you work with an organization like that?

Giri: Yeah, so, normally, there’s not a pushback, Alan. So, I was actually re-reading “The Venus Project” yesterday, and I was just reading the story of Brent, right?

Shimel: Mm-hmm.

Giri: So, when you’re talking to these customers, some of these guys are on their honeymoon with their pager with them, right? And then, when you’re coming in and you’re saying, “Hey, we’re gonna help you out with 24/7 support so you can get your life back” or, you know, “We’re gonna help you to streamline this DevOps work which you never really got the opportunity or time to work on, we’re gonna help you out with that,” right? And it’s incredible.

Sometimes, maybe the initial impression might be the same as you describe, like, “Hey, are you gonna take my job?” But as they understand the value, they normally are super happy. And another thing we do, Alan, in most of our engagements, we do this assessment called architected assessment where we’re coming in and we’re just reviewing your infrastructure to see how well you’re architected, and after that assessment, we give you, like, a roadmap, like, what are some things you should focus on the first month, and what are some things you should focus on short term and long term? And the assessment goes over cost, security, reliability, performance, and operation excellence.

So, you know, we can get, in the short-term road map, we can show some quick wins where the customer sees the value and they also get confident in our ability, so that’s sort of the path that works really well for us right now.

Shimel: Got it. J.T., another thing you mentioned is that nClouds is a premier Amazon partner. And, you know, in today’s world, we throw out platinum and gold and these sort of levels all the time—but really, within the Amazon hierarchy, a premier partner has sort of, they don’t hand that out like candy. Talk to us a little bit about what’s entailed in being an Amazon premier partner.

Giri: Yes. It’s a top tier status with AWS and in order to get there, like you said, there is only 25 premier partners in North America, and you have to show case studies, you have to show the training path of your employees, and you also have to have multiple competencies, like, we have DevOps competency, we have migration competency, and we’re also the well-architected partner.

And it’s just very subjective. You know, if you work closely with Amazon, even if you hit all the check boxes, they want to make sure that quality is there for premier partners. So, they look how you work well with your customer, what does your customer experience looks like, because that’s what Amazon cares about that as well.

So, you know, it’s just very hard to get to this status, and we’re honored to be at this level right now. This is great.

Shimel: Yep. So, J.T., let me go next kind of where I want to take this, and that’s—you know, two or three years ago, migrating a company onto an AWS, or it doesn’t have to be AWS, migrating a company onto the cloud, you know, you set up some virtual instances, maybe they had some separate storage, stuff like that, EC2 kinda stuff. But, you know, I just got back from Seattle a couple weeks ago from KubeCon and CloudNativeCon—Reinvent was the week before that. And certainly, Kubernetes and containers are kind of really quickly, quickly, quickly changing the landscape, here.

You know, are you seeing that as well? And what does that mean for—typically, SMB businesses are not leading edge or bleeding edge, right in [Cross talk] option?

Giri: Yeah.

Shimel: What are you guys seeing?

Giri: Yeah. You know, it’s very interesting. Who would’ve thought that the infrastructure we built a couple years ago would be considered a legacy infrastructure, you know? People using EC2 instances and an auto scaling group in Amazon’s world will kinda be called outdated right now.

So, we’re seeing incredible push and a lot of sort of initiatives on our customer side where they wanna go containers, pretty much like 90 percent of our engagements are around containers. Because it’s a no brainer, right? It makes the CI/CD pipeline much easier. You know, most of the time, containers are automatically integrated with scaling, so you can really binpack your resources, it has impact on your cost. So, you know, this is just—it just makes the infrastructure far more streamlined and far more easier to manage.

And as I mentioned, Alan, I’ve been migrating companies to Amazon and EC2 from the last 10 years, and I’ve been managing infrastructure as long as I’ve been migrating. So, it’s just, when I’m building infrastructure right now, it’s a no-brainer to build something using Kubernetes or on AWS we use EKS or—you know, depending on what the customer wants to do, and we had a customer the other day where they were saying, “I just wanna focus on delivering product to our customers, so what is the easiest way?” We use Fargate for them. Depending on the customer requirement, we’ll go Kubernetes, but long story short, it just makes a lot of sense these days to build infrastructure on containers, because they really streamline how you manage it in the long run. It just makes life easier.

Shimel: And that’s even at the SMB level?

Giri: Oh, absolutely, yeah. I mean, because the needs are the same. You need CI/CD pipeline, you need a way for you to scale infrastructure, you need a way for you to run batch or cron job type of jobs. And when you go with something like containers, you get there—like, you know, you don’t have to build home grown tools to facilitate these things. You know, containers or EKS or Kubernetes, they allow versioning when you’re deployed or auto scaling is sort of built in, you know, you can schedule batch jobs.

Just, it’s a no-brainer, you know? If you’re building out infrastructure, you should definitely explore containers each time, and that’s what we try to do every time. And it’s just incredible, the amount of success we’ve had before and after.

Shimel: Sure. So, as we sit here at the dawn of a new year, if I would’ve asked you in early 2018, do you think Kubernetes and containers would be one of the major stories of the year, I don’t know if you would’ve said yes or no. But as we sit here in the dawn of 2019 and we project ahead—let’s say I interview you and everything’s all well and at the end of next year, the end of this coming year, 2019, we sit down and talk about, “Well, what’s 2019 really show?”—what do you think are the big stories this year, J.T.? What do you think, coming down the pike, especially—I’m not talking about the world view. For nClouds and for your customer base, what do you think is really big for you in the coming year?

Giri: Yeah, so, I think in general, the application modernization will continue. We continue to see that trend, and this is also going to be big in SMB. So, we will continue to double down on AWS. It’s been an amazing partner. Our core values, our partnership is based on shared goals, so we’ll continue to kinda double down on that relationship.

And we’ll continue to utilize this well-architected framework. It helps us to assess the customers when we’re onboarding and it helps us to manage the customer, like, every time the customers were managing, we continued to run a well-architected assessment to make sure they’re well-architected, and they continue to stay well-architected.

And, yeah, I mean, just continue to focus on SMB, AWS, continue to align with well-architected framework. We also just spun off another company, it’s called nOps, and basically, it just helps to make sure the customers are well aligned with well architected framework, and it’s available on AWS Marketplace. So, we’ll continue to invest in that, because that solution has been incredible, nOps. A lot of our customers are seeing value in that, so, we are actually working with Amazon to give that solution to other partners like nClouds who can use it to manage their infrastructure to make sure the infrastructure is well architected, and we are also offering it to end customers who can use that tool to assess their infrastructure and continuously stay in compliance with well-architected framework.

Shimel: Excellent. You know, nOps, that’s something we’ll have to discuss on our next chat, J.T.

Giri: Yeah, absolutely.

Shimel: Well, you know what? We’ve been on almost a half hour here, so, unfortunately we’re about out of time for this one. J.T. Giri, CEO and founder of nClouds, thanks for being our guest on DevOps Chat.

Giri: Thank you so much for having me.

Shimel: My pleasure. Best of luck to nClouds this year, best of luck to you personally with your family and everything else, you know, it’s gonna be a busy year for you, my friend.

Giri: Absolutely. Thank you. Thank you.

Shimel: Alright. Hey, J.T. Giri, nClouds—you’re here with Alan Shimel on DevOps Chat. You’ve just listened to another chat. Bye bye, everyone.

— Alan Shimel

January 25, 2019
IoT, Not People, Now the Weakest Link in Security
Do a quick search on “people weakest link” and you’ll see a raft of articles in which cybersecurity experts and computer scientists point to employees or end users as the biggest vulnerability. No doubt, people do silly (or outright abusive) stuff and open the door for a variety of enterprise security problems. Spoiler alert: There’s this technology called the Internet of Things (IoT) and it’s a bigger security risk than people ever were. The new theme of this rapidly changing IoT security story is data integrity.

Increased cybersecurity risk is due in part to the variety of environments IoT applications touch. Most at-scale IoT deployments use some form of a three-tier architecture, with edge, gateway and cloud components.
- Edge devices are those connected sensors and actuators touching the real world. They are usually small, low-power devices often running a wireless protocol such as Bluetooth, Thread, ZigBee, Z-Wave, sub-GHz, low power wide area (LPWA) networks, cellular IoT technology, Wi-Fi or other protocol.
- Gateway devices are hubs that groups of sensors connect with. One big role of the gateway is to translate the various protocols from edge devices into Internet Protocol (IP) for transmission into an enterprise network. Gateways also perform a key role in provisioning edge devices securely. Smartphones running Android or iOS often serve as a gateway for consumer IoT devices. For industrial IoT devices, multiprotocol gateways typically are built on a small form factor computer running a real-time operating system or Linux. Edge computing or fog computing architectures use enhanced gateways for more algorithm processing.
- Cloud platforms are very familiar to most enterprise developers. In IoT apps, data from the edge arrives for processing, storage and presentation. Algorithms can run on a server cluster or in a distributed computing framework such as Hadoop or Apache Spark. Business intelligence and predictive and prescriptive analytics also reside in the cloud.
In our practice, we see many IoT cybersecurity issues that can be mitigated with proper attention to two areas. The first is shutting down simplistic endpoint attacks by using basic connected device security measures. Avoid edge devices that ship with a well-known default password or PIN—compromising those defaults can be as easy as a battery pull and a factory reset. If a device uses encryption, make sure it doesn’t use a hardcoded key that, if cracked, compromises an entire family. Look for edge devices using over-the-air (OTA) programming allowing for security updates over a long life cycle. As more device developers gain IoT security experience and provide the right features, closing these basic weakest links is easy.

Now, for the more startling weakest link. When the IoT application runs, is the data any good? According to a just-released survey of 950 IT and business decision-makers, only about 48 percent of companies are confident they can detect an IoT security breach. (BTW, don’t get me started on blockchain; it’s one tool, not a panacea.) A lot can happen before your people get involved. By then, it may be too late.

Data integrity needs constant monitoring during at-scale IoT deployment, not just during pilot. An easy way into an unprotected IoT network is to add an unauthorized edge device at a gateway, then use it to access other devices. Gaps in end-to-end encryption are also easy exploits. Untrustworthy public cloud elements are also bad news—a big reason we recommend hybrid cloud architecture. A private cloud layer gives you more control over algorithm performance and data stream security. Presentation and archiving can be left to a public cloud layer.

Bad data can come from either a compromised or faulty device. It propagates quickly across a system, and when an unwitting user at the presentation layer runs a business intelligence tool on it, the bad data could cause issues. How do teams hunt down vulnerabilities and faults that lead to corrupted data and results?
- Hire a penetration tester, preferably a contractor removed from your day-to-day development who can objectively assess your architecture during pilot and reassess it during deployment.
- Ensure your architecture can tolerate edge device or gateway failures without ripple effects in algorithms; in other words, protect the application from prolonged operation on bad data streams.
- Before turning AI loose on automated decision-making, consider an AI-based IoT security analytics tool to spot anomalies and quickly bring people into the loop.
- Retarget at least part of your cybersecurity experts to ongoing data integrity efforts and help them stay abreast of IoT technology and trends.
This all sounds like a good job for DevOps, doesn’t it? You know what to do about people; now you’ll need to work magic with devices. The long-held security axiom that people are the weakest link is no longer true when IoT applications run unattended all the way to presentation. There are a few exceptions when people have more interaction at the edge, particularly in the medical device arena. Generally, we’ll see bigger and bigger IoT applications with more data, more processing and less interaction with people.

If someone on the IoT says there’s a security hole you can drive a truck through, they may mean it literally. Data integrity measures will be critical for DevOps teams moving forward. Do you agree? What types of data integrity issues are you seeing in IoT applications?

— Don Dingee
January 23, 2019
DevOps Video Chat: DevOps Testing with Ryan Lloyd of SmartBear

The testing landscape in DevOps is a big one, with lots of established players feeding the machine. SmartBear is one of those companies. The force behind Swagger, SoapUI and others is perhaps not as well-known as its brethren in the DevOps testing space, but it cuts a wide swath. And, with its recent acquisition of Zephyr, it’s about to get wider.

In this DevOps Chat, we speak via video with Ryan Lloyd, VP of Products at SmartBear, about the Zephyr acquisition and the DevOps testing and test management space in general. As usual, the streaming video is immediately below, followed by the transcript of our conversation.

Transcript

Alan Shimel: Hey, everyone, it’s Alan Shimel, staging-devopsy.kinsta.cloud, Container Journal, Security Boulevard, and we’re here for a great interview, hopefully, with Ryan Lloyd, VP of products for testing and development at SmartBear. Ryan, welcome.

Ryan Lloyd: Thank you. Great to be here.

Shimel: Great to have you here. So, Ryan, before we jump into today’s news that we wanna discuss, I wanted to just quickly kinda do a level-set. SmartBear is a company I think most people have probably heard of it, but they may not be 100 percent sure of the full breadth of the SmartBear portfolio. So why don’t we talk a little bit about who is SmartBear and what are the kind of products and services you guys offer?

Lloyd: Yeah, absolutely. So SmartBear software is a company with a lot of history and if you don’t recognize the company brand, it’s very likely that you recognize one or more of our product brands, so we are the company behind some of the key product brands like Swagger, SoapUI, CrossBrowserTesting, TestComplete, so quite a diverse portfolio of products focused on helping our customers who’re building software. Help them build tests and monitor their software applications.

Shimel: Great. So, Ryan, big news out today is SmartBear had made another acquisition. You guys have acquired Zephyr. Is that correct?

Lloyd: That’s right. Yeah, we’ve announced our intent to acquire Zephyr, a company in a similar market space as us.

Shimel: So it’s a similar market space, but let’s get specific. What does Zephyr do?

Lloyd: Great. So Zephyr is a collection of tools for testing and specifically focused on the area of test management, managing the process of testing.

Shimel: Great. And you mentioned an intent to inquire – acquire, so I guess that means it hasn’t yet closed, but you’re both private companies and I would imagine it closes fairly quickly.

Lloyd: That’s right. We expect in the next 30 days, subject to the usual regulatory approvals.

Shimel: Yep. Fantastic. So, you know, Ryan, one of the things I read in the background around this one was that one of the big pluses here is Zephyr’s presence within the Atlassian, the Atlassian ecosystem, and SmartBear actually is already a big player in that Atlassian ecosystem. Well, aren’t they?

Lloyd: Yeah, so we have a couple of products that have plug-ins to the Atlassian ecosystem. I mean, the reality is 60, 70 percent of our customers are using Atlassian’s tools. They’re pretty dominant in the area of software teams, for managing some part of the software development process, so it’s a very strategic and important ecosystem for SmartBear as a company. And, certainly, Zephyr improves our ability to reach that ecosystem of users and make sure that they’re aware of all of the tools and capabilities that SmartBear can offer.

Shimel: Yep. And, Ryan, you know, 60 to 70 percent use Atlassian. I’m gonna imagine the overwhelming majority are using Jira and then maybe Jira Plus.

Lloyd: Jira –

Shimel: Correct?

Lloyd: Certainly, Jira is probably the most prevalent. Confluence gets tagged on with Jira quite a lot. And then BitBucket, actually, is also becoming quite popular as well. BitBucket, GitHub, GitLab – they’re sort of three of the same, in terms of enterprise solutions for developers.

Shimel: Got it. So I don’t wanna turn this into being about Atlassian and their products, but, obviously, they do have a big ecosystem. There are a lot of third parties, such as SmartBear and Zephyr, who move a lot of services and product via that marketplace. But let’s talk a little bit similar, but where’s the overlap? Or is there any overlap between what Zephyr and SmartBear’s offerings are about?

Lloyd: Yeah, so SmartBear offers a broad portfolio of products and, certainly, a couple of the products we have, pre-acquisition, were in this test-management space. What Zephyr brings to the table, though, is a solution that is natively built around Jira and delivered through the marketplace. So what that means, to be delivered through the marketplace, is it’s a native Jira solution that Jira administrators and customers can install directly from within their Jira instance. So it provides a very seamless extension of their workflows, within Jira, to handle some of these test-management scenarios, which we think is really important to teams that are trying to consolidate their processes and have a unified approach to that.

Shimel: Excellent. I guess one of the issues – and, with your title and your responsibilities around VP of products for test-and-dev, just in a number, how many products are there in test-and-dev now, within SmartBear and then if we add the Zephyr suite to the mix?

Lloyd: Yeah, so we had five products in that portfolio. Today, Zephyr brings three additional products into that portfolio, so we’re now up to eight products in our test and development business, as well as a range of products in our other business unit, around API.

Shimel: You know what? That’s a lot of products to be managing, huh?

Lloyd: It is. I mean, SmartBear has grown a lot over the years, through both acquisition of companies and building new organic products and bringing them to market. It’s pretty exciting time for us. We’re, pre-acquisition, at about 450 employees globally, so it’s an exciting time to be part of this company.

Shimel: Absolutely is, man. So, you know, another not necessarily unique but another kind of factor you have to play into the SmartBear – and I don’t know about Zephyr as much – is that some of your solutions have open source kind of versions out there that you guys help manage the open source communities around these, as well as the commercial versions of the products themselves. Correct?

Lloyd: Yeah, that’s right. I mean, core to our business is really a couple of philosophies. One is we wanna be open and interoperable with all the tools that are part of the ecosystems that software teams are using. And so, in some cases, that means commercial opportunities to partner with companies like Atlassian; in other cases, it means we want to be a part of an existing open-source ecosystem or help build up and nurture an open-source ecosystem. So, certainly, when we brought SoapUI and Swagger into our product portfolios, that was all about really taking that existing organic ecosystem, where developers and testers are going through tools, and helping build and nurture and develop that ecosystem.

Shimel: Excellent. So what kind of special challenges – you specifically, right? You own the products; you’re VP of products here. What challenges does that pose for you, having these open source kinda versions and tools and communities. I mean, you don’t wanna burn them, right? Because, ultimately, you kinda bite the hand that feeds you. So let’s talk about that. What does that – how does that manifest itself with you?

Lloyd: Yeah, certainly. I think there’s a brand and a culture that exists around open-source products and I guess it’s our responsibility, as stewards of those brands, to really continue to nurture that community. And that means we’ve gotta make balanced decisions about where we choose to add features to the open source products, versus where we commercialize some of those features, so there’s a constant balance there and kind of evaluating and making sure we’re engaging with the community.

And then, more broadly, beyond just our open-source products, I think one of the biggest challenges in the software tools space and market is the interoperability that’s required between tools these days. You know, developers and testers, they’re demanding practitioners. They want their tools to work together and there’s a huge diversity of tools out there in the market. So, as a product manager, that’s what keeps me up at night, is making sure all these tools are compatible and working to support these complex workflows.

Shimel: Absolutely. I mean, one way of looking at it is, if there wasn’t such a big market, there wouldn’t be all these tools.

Lloyd: That’s true.

Shimel: Another way of looking at it is also that it presents a tremendous opportunity for consolidation and for one or a few products to emerge as true market leaders. And then you’ll see it kinda – you know, you’ll see the amount of products in the market kinda consolidate. You know the old saying, “If you’re not – you’re either leading, following, or get out of the way,” right? If you’re not top-three, you gotta ask yourself, “Do you wanna stay in that market?” But, you know, when we talk about the testing market – and, in DevOps, we talk about continuous testing – it certainly is a huge, huge market here.

Lloyd: Yes, it is. And it’s one that’s continually evolving and shaping, right? So there’s traditional test tools that have been around for a decade or more, and then there’s sort of emerging products that are coming to market. And I think it’s how all these work together and evolve to support the change in workflows and, yeah, even just organizational changes within environments.

Shimel: Yep. So another area of the testing space, Ryan, that I’m interested in personally is security and security testing. And it’s really funny when I – you know, 20 years ago, when I was into security, when I first got into security, info-sec, QA was here and security was there and never the twain shall meet, right? But now we’re starting to see security become synonymous with quality – that’s the “Q” in QA.

Lloyd: Yeah.

Shimel: And so security testing and other kinds of testings are starting to merge. What do you guys see with that at SmartBear?

Lloyd: Yeah, I think what’s driving a lot of that is the Agile workflows that teams are adopting, so, as they increase the pace of trying to deliver and release software, they’re being forced to evaluate quality and security earlier in the life cycle and more from the context of the development team, rather than having a separate, isolated team that deals with that downstream or after the fact.

Shimel: Correct.

Lloyd: So I think that’s the driver, so definitely a lot of demand for your Agile workflows to support testing by design and security by design. From our perspective, I think that opens up some unique opportunities for adjacencies and areas that SmartBear can continue to expand to in the future.

Shimel: Yeah. I mean, so, you know, what you’re describing is almost the classic “shift left.” Right? As we start shifting testing, security and security testing, left early into the development life cycle. But it’s also the reality of it’s been called the “modern software factory.” Right? It’s an assembly line and is a production line, for software, and where traditional QA, traditional testing, security testing, where they fit into that life cycle has shifted left.

But also is – you know, where we used to think, oh, QA was going away and security people were gonna give up control of security. Not the case. They’ve become more important, right? But also highly automated where they can be and clearly defined as part of this factory, if you will.

Lloyd: Yeah, it’s really just about reshaping the responsibilities and improving the collaboration across the whole unit or team that’s now responsible for delivering iterations of software.

Shimel: So, Ryan, then – so that begs the question then, “What does that mean for you as a product manager?” Right? Where you used to sell to a QA engineer or security testing sold to a security person, but now your audience includes the guys using Jira and BitBucket and a bunch of other tools. It’s not just Atlassian, obviously. So you have new customers to serve and to service. Now how do –

Lloyd: Yeah, that’s absolutely right. Yeah, so, over the last several years, we’ve been focusing on how to modernize our portfolio to support those sort of emerging needs, both the process change that’s going on with our customers and the persona change that’s happening in many instances. So the acquisition of Swagger is a great example of us providing tools that help developers earlier in the life cycle, so, where we had SoapUI to help with API testing from a QA perspective, Swagger aims to solve some of that further upstream by enabling more collaboration around the definition of those APIs to begin with. And, oh, by the way, making sure that interoperates with SoapUI, so you get leverage out of that API definition to generate some of those tests, automate it, and it triggers sort of a seamless workflow and thread.

And so we’re continuing down this path of modernizing our portfolio. We acquired CrossBrowserTesting about two years ago, to help companies address some of the modern types of applications that they’re looking to test, integrated more deeply with Selenium, which has become hugely popular in sort of the developer organizations, to drive automated Web and mobile testing. And then, with Hiptest and Zephyr, again, it’s furthering our relevance for those software teams that are on that journey.

Shimel: Excellent. Ryan, last kind of issue I – or not issue – it’s not an issue at all – but the last area I wanted to talk to you about was so you’ve got five. There’s three more coming in. And that’s just test-and-dev; you have an AP kind of silo as well within SmartBear. How do you – I mean, I’ve been in the boat not quite as many as you, but, when you have so many different products and then a company name, how do you brand? Right? Do you continue branding the individual products? Do you throw SmartBear in front of all of them, but some of ’em already have names that may be, in fact, bigger than SmartBear, as you said in the beginning? Again, as a product manager, you have to think about that a bit. You know, what’s the right answer there, if there is –

Lloyd: Yeah, so I think SmartBear is going through a bit of a transformation, in that regard. You know, as I said and as you pointed out, we’ve had very strong product brands up to this point. We wanna continue to nurture those product brands, so no intent for those to go away because we love the high-velocity, try-buy model we have around our products, where developers and the practitioners can find the right tool for the job and get started.

But we’ve gone through an exercise on how we can integrate our products in the right way, so like the Swagger, SoapUI example I provided, to create those sort of interesting workflows. And we’re building up the SmartBear Academy, our SmartBear community, our big user conference, to help elevate the SmartBear brand and create more awareness of the portfolio of products we have – how they work together, how they fit into the ecosystem. And I think we’re just at the start of that journey right now. We’ll see a lot more, as we launch into the year next year, around what we’re doing from a brand perspective to galvanize the company and all of the great products we have.

Shimel: Excellent. Well, Ryan, we’re about out of time, but, first of all, congratulations on the Zephyr announcement and anticipated acquisition here. It’ll make for some good times. And continued success with SmartBear and everything you guys have going on.

Lloyd: I appreciate it. All right. Great talking to you, Alan.

Shimel: All right. Ryan Lloyd, VP products, test and development, for SmartBear, on SmartBear’s acquisition of Zephyr, here on staging-devopsy.kinsta.cloud. And we’ll talk to you soon, everyone. Have a great day.

— Alan Shimel

January 21, 2019