AI and automation can help ensure DevOps security doesn’t impact performance
The world revolves around software and internet-based applications—and speed is crucial. Users have very little patience for delays and will quickly jump to something else if performance lags. Organizations have embraced DevOps and containers in an effort to accelerate development and deployment of software and maintain a competitive edge over rivals. One of the biggest challenges, though, is how to identify vulnerabilities and detect security issues without significantly degrading performance.
There will always be some impact on performance. You are adding an extra layer of functionality—a layer of security intended to detect and resolve security issues. No matter how fast that detection is, it will still take more time than not having any detection at all. The goal is to implement detection with as little impact on performance as possible. You don’t want detection to be a bottleneck for your cybersecurity efforts, or a drag on performance in general.
Bridging the Gap Between Speed and Security
One of the defining characteristics of a cloud-based, containerized, DevOps environment is its dynamic and continuous nature. In an effort to streamline and accelerate business, organizations embrace continuous development, continuous integration and continuous deployment combined with continuous monitoring, continuous testing and continuous improvement—all of which require continuous security.
Real-time monitoring for suspicious or malicious activity is crucial. The internet doesn’t sleep, and attackers are constantly scanning and probing for vulnerabilities and weak links to exploit in your network and applications.
Security is important, but not at the expense of productivity. The challenge is how to bridge the gap between speed and security—and ensure you can detect attacks effectively without introducing undue friction. You need balance—security that provides necessary protection without defying the whole point of trying to streamline and accelerate business. In other words, security needs to become a guardrail rather than a roadblock for DevOps.
Improve Detection with Automation and AI
Real-time protection is necessary—but not all real-time security solutions are the same. How attacks are detected is as important—or more important—than just detecting them.
Why? Simple. Attack detection based on signatures or generic patterns such as a core rule set or regular expressions are not customized to recognize threats in the context of the application. For example, with a RASP (runtime application self-protection) solutions, even if the control points are good, the end result will be poor without the right context and detection techniques. This approach is also reactionary and leaves you exposed for some period of time. It is generally ineffective until the signature is developed, and the signature can’t be created until the threat is detected and identified.
Automation and artificial intelligence (AI) can accelerate the process and provide more effective protection with less friction. An AI-powered platform can learn from stateless traffic and deconstruct application logic to create application-specific rules—and update the rules dynamically without the need for human intervention. Using dynamic, application-specific rules rather than signatures and manual rules can result in efficient detection and an exceptionally low false-positive rate. An automated solution that leverages artificial intelligence also can protect without waiting for signature updates.
Modern Security for Modern Networks
The days of periodic scans are long gone. The network architectures and threat landscape today demand constant, real-time protection. Legacy detection techniques are cumbersome and can’t keep pace, but an AI-powered attack detection platform that is automated will be more effective for protecting a dynamic, cloud-based, containerized, DevOps environment.
Giving automation the power to detect crime and enforce punishment has ramifications, even for minor infractions
In November, I broke the law. I crossed over a solid white line to make a right turn at a traffic intersection. At the time I was unaware of my violation. I was on my way to a shopping mall in an unfamiliar part of town to buy my wife a gift for her birthday. My only defense is that I was following the instructions emitted from the map app on my cellphone. It told me to make a right turn. So I did. Little did I know I was being watched.
Automation enhances law enforcement capabilities
A few weeks later, I received a citation in the mail. The citation had photos of me, my car’s license plate and the car crossing the solid white line. Turns out, there were cameras at the intersection watching all traffic activity. I was busted. I was also a bit shocked: My experience getting a traffic ticket 10 years earlier involved a real police officer writing me up in real time. Now it was as if Big Brother was indeed watching.
In addition to the eerie feeling that goes with being charged with a crime anonymously well after the fact, I also felt baffled. The traffic citation did not list the amount of the fine I had to pay. The only information it provided was that I needed to go to the traffic court website to learn the details. So I did.
I logged into the website and entered my citation number. The site had no record of the ticket, but noted that it can take up to 30 days for an automated ticket to make it into the system. I felt powerless; I was charged with a crime, liable for a fine and yet didn’t know how much my transgression was going to cost me.
I decided to call the telephone number provided on the citation for more information. I dialed the number using the same cellphone that had gotten me into trouble in the first place. I was connected to an automated answering system. After navigating through various Yes/No and “enter the proper number” prompts, I learned that the system had no record of my citation. My only option was to wait 30 days for the systems to get their collective act together.
A month later, a formal citation did indeed arrive in the mail, noting the amount of my fine ($480) and options for payment. Also, the citation provided instructions to go online and pay the ~$500 required to attend traffic school, should I so desire. (Traffic school is an option in California in which you attend a one-day class about traffic safety and your violation is kept private from insurance companies. The result is, your automobile insurance rates don’t go up. Here in Los Angeles, a lot of professional actors teach traffic school as a side job. As you can imagine, traffic school can be quite entertaining. But, I digress.)
At this point, I was completely bewildered. I’d been busted for a crime I didn’t know I committed, by machines I didn’t even know were there. The only way I could get the details about my transgression was by interacting with other machines on the internet or on the phone. And, should I decide to plead guilty and settle matters, my first, best option is to do so via automation.
Still, the technology was failing me. I needed to talk to a person, any person. So I went down to the courthouse in Santa Monica. There I found a special window on the exterior of the courthouse building for processing traffic inquiries. (One of the nice things about living in sunny Southern California is that providing service outdoors throughout the year is a viable option.)
I waited in line. Finally, I got called forward to the window—which, by the way, was a pane of blackened glass. I had no way of knowing who or what I was talking to; all I saw was my reflection in the black mirror. A voice from the speaker at the bottom of the window asked me to state my business. I did. The conversation continued. The responses from the speaker seemed brusque, if not a bit preformulated. I started to wonder, Am I talking to a machine or a person? So I asked a random question, “How much is two plus two.” The voice in the speaker responded, “Sorry I am not programmed to respond to that information.”
Now I was really thrown. Was I confronting yet another piece of automation? After a minute or two, the voice in the speaker said, “I’m just messing with you. I get this all the time. They all think I’m a machine.”
It turns out that the voice did indeed belong to a human, and the human’s name is Dante Pipkins. Dante shared an interesting fact with me: Even though my violation was caught on camera, the actual OK to create the citation was issued by a human police officer behind the scenes. Go figure.
Thus, having been enlighted about the details of enforcing traffic law via camera, I finished my business by having Dante give me a date to appear in traffic court, before a human judge, to plead my case. I knew there was no way to proclaim my innocence. I had been caught red-handed. My intention was to throw myself on the mercy of the court to get a reduced fine.
The Power of Automation
Automation is a great thing. It empowers us. It saves us time and money. Without automation, there’s no AWS, Google, Azure, Digital Ocean, Netflix, Etsy, Shopify, Facebook, Instagram, Slack, Airbnb, New York Stock Exchange … the list goes on. Automation is more than a technological feature. It’s now a way of life. And, for those of us who work in DevOps, automation is fundamental—none of us want to go back to the days of manual deployment and guesswork system monitoring, to say the least.
Yet, we do walk a tightrope. As my recent travails with a very minor aspect of the legal system demonstrate, automation is becoming a key factor in everyday law enforcement. On face value, this might seem like no big deal, but consider this: Today, charging a citizen with a crime is still subject to some sort of human intervention. There are a lot of details to consider that go beyond the current capabilities of AI and machine automation. Human judgment is still the most reliable form of judgment. Yet, it’s time-consuming and expensive. Eliminating time-consuming, expensive tasks with cheap, fast, accurate machine-driven processes is a key motivator for using automation.
As automation becomes more familiar with the activities it is processing, it becomes an expert. And, as automation achieves expert status, it replaces human activity. Just think about detecting credit card fraud; these days, practically all of it is done using automation. While we still have a long way to go in terms of totally automated processes, automation is creeping its way into law enforcement. My recent experience is proof.
Now, imagine a world in which crimes such as tax evasion, financial fraud, embezzlement, regulatory non-compliance and yes, moving traffic violations are detected, reported and, most importantly, prosecuted using automation. Let’s go further: Let’s imagine that automation becomes the default method of prosecution. Imagine that the justice system becomes so automated that the defendant is presented with an offer to plead guilty to a sentence already predetermined according to an AI algorithm. Or, the defendant can choose to opt into a human interaction but will need to bear the burden of the increased court costs, very much in the same way that an automated audio transcription service charges extra for a human to do the work.
Is such a scenario possible? Well, think about this: My interactions around the traffic violation were conducted without me ever having once had to interact with a human being. I was guilty as charged and automation proved this beyond a reasonable doubt. Not only did the technology detect my transgression, but it also connected me to my car, thus making citation possible. Hence, there’s a good argument that, when it comes to automation-enabled law enforcement, the distance from catching misbehaving drivers in the act to actually going after real crooks is just not that far a leap.
So, what does this have to do with DevOps? When you scrape away all of the technological marvels, at some point there’s going to be someone in DevOps either creating, deploying or fixing the systems that make this all possible. It’s a big deal to give automation the power and technical wherewithal to enforce “the law.” As the feasibility of putting complex, comprehensive law enforcement systems into play increases, are we in DevOps going to consider such deployments as just another day in the CI/CD pipeline, or are we going to think through the game-changing impact of what we’re about to make?
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 DevOps.com 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, DevOps.com 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.
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.”
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 DevOps.com. 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.
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.
Thanks to everyone who voted and nominated candidates. Stay tuned for 2019 DevOps Dozen and, as always, thanks for supporting DevOps.com and the rest of the MediaOps family of communities. If you have questions, please write us DD@devops.com.
Edge computing is rapidly gaining momentum. Last week’s Linux Foundation news on the launch of LF Edge is one more sign of accelerating growth at the edge. What’s driving this sudden intense interest? It’s more than just the sheer number of edge devices or mounting concerns around interoperability and security. Pushing compute resources closer to the edge can save the cloud and networks from waves of ephemeral data.
The concept of edge computing certainly isn’t new. In years BC (“before connectivity”), there were plenty of edge computing boxes. These featured single-board computers designed to specifications such as VMEbus, STDbus, PC/104, CompactPCI, AdvancedTCA and many others. Processing happened at the edge as data arrived. Ethernet connections made administration and results-sharing easier, but very few architectures relied on shipping all the data into the network.
Of course, there was one big exception: a business model pulling all the data into the network. Telecom providers aggregated traffic from the edge into their core networks. As data traffic joined voice traffic, core networks grew with monstrous bandwidth and increased services. Core networks interconnected. Data traffic rose even faster, pushing the network into a cloud architecture. In years AD (“after distribution”), everything from the edge is now connecting to the cloud.
Much of the increase in data traffic came from the shift to video content. Users expect higher resolution video programming with the same lag-free performance. Streaming networks and quality of service (QoS) implementations have made great strides in content delivery. 5G infrastructure rollouts in progress will keep mobile a strong downstream contender.
What about upstream applications such as the IoT? Nearly the same terminology applies there. Devices gather data on the edge and transmit it to the cloud through a gateway. There are two key differences with most IoT applications, however. Real-time data may be lost if the streaming connection into the cloud is interrupted. Also, the fallacy of low bandwidth does not work at scale if all the data is transmitted. At some point—perhaps ten thousand, a hundred thousand, or a million or more sensors—an aggregate bandwidth problem develops.
Just as in the BC age, it’s time to rethink shipping all that IoT data upstream, instead taking steps at the edge. Cisco Systems has studied data trends extensively, producing its white paper, “Cisco Global Cloud Index: Forecast and Methodology, 2016-2021.” The company points to the IoT ushering in the “yottabyte era” very soon. Cisco estimates that 220ZB of data was generated in 2016 and projects that by 2021, there will be nearly 850ZB from people, machines and things combined.
Now for the interesting part: Cisco also estimates that as much as 90 percent of that data is ephemeral, short-lived data not useful to save. Even if only 10 percent of data is useful, it will swamp projected data center traffic by an estimated factor of four in 2021. Here’s Figure 24 from the Cisco white paper:
Edge computing, or its close cousin fog computing, allows two things to happen: It can pre-process ingested data, ironing out protocols and format differences such that everything arriving at the cloud is immediately ready for algorithms. Any savings in the cloud from not shuffling data before computation are valuable, increasing processing and network bandwidth availability. Parts of an algorithm could easily be farmed out toward the edge, perhaps decimating or filtering data before shipping it upstream for heavy analysis.
A bigger use for edge computing may be using algorithms to avoid shipping ephemeral data upstream altogether. Using generative models at the edge could make a huge difference in identifying useful data. Most of us have heard that no human can sit and watch hours and hours of surveillance video from multiple sources looking for one moment of a problem developing. Consider another example with an EKG monitor attached to a smartphone: While the patient is at home, at rest and unstressed, the EKG is in a perfectly normal range as learned by the application. Doctors are alerted when readings slip out of normal range, with raw data transmitted for observation if required. A similar example is waiting for a motor to fail while monitoring its operation.
Both the LF Edge initiative and work happening in the OpenFog Consortium are creating specifications for edge computing. These initiatives are aimed at interoperable, secure architectures where cooperative processing mines data. If items of interest can be extracted efficiently from useful and ephemeral data at the edge, loads on the cloud and networks would be lighter. Edge computing will likely detect exceptions more quickly, bringing people in to look at what is going on faster. The result will be more scalable IoT applications with better chances of delivering value from all that data.
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.
As always, there are interesting trends in DevOps, and I wanted to point out one that is starting to bother me: the “API economy,” and how it impacts DevOps decision-makers.
Traditional infrastructure—SAN, LAN, physical systems, etc.—were generally controlled the best from the command line. While there are a million of them, Cisco IOS is probably the one that you’ll remember best (or you stopped using to read this—just depends upon the shop). When large-scale automation started, these command lines became a bit problematic. After all, scripting was possible, but painful, and often had non-portable hardcoded values.
Virtualization, and later cloud—and even later SDN and NFV—all made this better, but on a layer over the top of (and normally not well integrated with) the physical layer. Years ago I bemoaned that we had doubled the workload of operations by re-implementing what was already implemented at the physical layer. So we were configuring the physical—even for cloud you have to get to the cloud—and then configuring the virtual.
Then “Software Devs as Kingmakers” came along, followed by “the API Economy,” and finally we started to see some serious attention paid to APIs by infrastructure vendors that should have done so long ago (some former employers of mine might belong in this group).
Here is the thing: There is a difference between having an API and having an API that is useful. When shopping for solutions, be they physical or software, don’t allow APIs to be a check box because it’s “the API Economy.” And don’t assume that an API useful to DEVops is what is needed to automate infrastructure. Monitoring APIs—particularly ones that provide you detailed information about an app as it runs—are useful to DEVops, and assuming you have tools that are or can be integrated, might provide value to devOPS.
But monitoring is not management. devOPS is increasingly automated, and increasingly needs viable APIs that can help them deploy/configure infrastructure. Vendors are responding, but the quality of APIs at this point in time varies widely. So make certain that evaluation looks at APIs available with an eye to suitability to task. devOPS needs management and might be able to use monitoring, while DEVops generally needs monitoring and has little use for management.
This is not 100% true of course, there are a billion different shops, most doing things in slightly different ways, but think of storage (because it can be done in few enough words to fit in a blog)… An app needs access to storage, ways to be notified of storage space limitations, and possibly to metadata. Operations needs to provision, migrate, backup, replicate… The list goes on. These all contribute to the availability and quality of the application, and are all DevOps, but the focus is different. And having a simple “number of blocks free” API will not help with the DevOPS needs even if it helps developers manage a piece of the application.
But we have more options than we ever did before! So fear not, just watch what your prospective vendors are doing, and check in with long-term vendors on occasion, too—because things are constantly changing, nearly always improving.
And keep rocking it. Presumably you are working this out already, knowingly or not, or you wouldn’t have time to read this blog.
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?
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, DevOps.com, 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 DevOps.com. And we’ll talk to you soon, everyone. Have a great day.
IT has long had a problem with hiring. I’m not certain where it started; most of us blame HR, and that’s probably incorrect, but gives us someone to blame. It’s that we post jobs with insane requirements. Sometimes this is done to keep the applicant pool down, but most of the time it is a simple case of throwing in the kitchen sink. We have laughed at advertisements that wanted applicants to have more years in a given technology than the technology has existed. The laughter was because someone quipped, “So what we really want is only liars to apply.”
But it doesn’t stop there. How many advertisements have you seen for a person to join an already good-sized team of developers, and the requirements include experience in every single language/tool the person might encounter—and sometimes ones the organization might use in a year or so? And DevOps, with its increase in toolsets and broadening complexity, make this problem worse.
If you want good DevOps team members, you have to focus your search. We’d all love to have unicorns who could do it all on day one, but those people don’t really exist. Even with experience in every single tool in your chain, they still have to learn apps and environment. Try to craft job requirements that focus on the couple of core tools, and then filter for ability to learn and adapt. Because the only certainty about IT at this point is that technology will be shifting, so focusing on the tools you are using today is pretty limited.
Role plays a part in this also. While we like to pretend DevOps is one thing, it is a rare application or portfolio for which there are not specializations on the team. If you are looking for someone who will lean more toward the DEVops side, do you really need them to be operational wizards with three years each in storage, networking and container management? Conversely, if you are hiring someone more for the devOPS side, do you need them to have expansive experience in Javascript, or do they just need to know who to call if it gets beyond their ability?
Maybe your company is one of those shops where everyone on team X is expected to be an expert at everything. Kudos for you, but there aren’t a ton of those people out there. There is a different mindset to DEVops versus devOPS, and even if unofficial, most employees lean one way or have a more proficient side. If a candidate fits the bill in an area you are weakest, consider training them on the job in the area you are strongest, rather than waiting for who knows how long for the perfect person to fill the open req.
And we still have a need for hardware specialists. I’ve said it before, but do you want your EMC (or Cisco or whomever) person to be a generalist, or do you want that person to make the infrastructure that underlies a huge chunk of your applications hum? Hire specialists for specialized skills, hire broad knowledge for app-spanning needs.
It’s been a problem for years, and only you can fix it. Call out overambitious job postings and make managers ponder what they’re actually looking for. You know you have a need, you know what the position will do. Help hone down postings so that they fit the actual requirements, not some blue-sky version of potential requirements.
And get the best people for the job. After all, you are going to have to work with them.
It is a truth which should be universally acknowledged that the most important skill for a customer-facing job in what we laughingly call “information technology” is a cast-iron ability to say no—and make it stick.
The misguided desire to please other humans by attempting to deliver on their every request has sunk more projects than any units mismatch or catastrophic misconfiguration—even more than the justly feared Friday afternoon deployment.
The key to success is an agreed definition of what success is, and how we will all know and measure whether we have achieved it. Let’s take the car as an example.
French Cars Have Always Been Weird
These days, we would consider a car to be woefully unfinished if it were lacking upholstered seating for at least four adults, a roof and windows to keep the elements out and some form of in-car entertainment—an FM radio as a bare minimum, probably a CD slot or USB socket as well. This is on top of seat belts, airbags, anti-lock brakes that are probably power-assisted and more lights and safety features than you can shake a stick at.
Nicolas Cugnot did not bother with any of these features. His design didn’t even have four wheels. It not only didn’t have an airbag in the steering wheel, it didn’t even have a steering wheel. It was controlled with a ridiculous tiller arrangement that unsurprisingly completely failed to catch on. And yet, his vehicle was a success by the stated criteria of the project: It made it much easier for the French army to haul ammunition around.
Nicolas Cugnot’s steam dray from 1769
Admittedly, he was also lucky enough to be constrained by the technology available to him. Even Louis XIV might have balked at adding a four-piece chamber ensemble to provide an appropriate musical soundtrack for the driver. But the key point is this: Monsieur Cugnot stuck to his brief, and concentrated all his efforts on the features necessary to achieve it.
Bringing Apple Into It
In somewhat more recent times, we have Steve Jobs (emphasis mine):
People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully. I’m actually as proud of the things we haven’t done as the things I have done. Innovation is saying no to 1,000 things.
One reason why Steve Jobs is so famous is that he actually said those thousand nos—often loudly, rudely and profanely. Steve stands out in IT because most technologists have an irrepressible instinct when faced with a question to start to speculate about it, bikeshed possible solutions, build a quick minimum viable prototype and, before you know it, you are armpit-deep in feeping creatures, all of which you are now somehow responsible to nurture and feed. Not being a technologist himself but more of an ideas person, Steve was perhaps better able to take a step back and focus on the end goal.
Let’s Get Concrete
Now, this should not be taken as a license to adopt all of Steve Jobs’ methods (Lesson One: Be a complete arsehole to absolutely everyone in your life), if for no other reason that even Steve got fired for it, and from the company he founded at that. When someone comes to you with a request for just one leeeeetle feature, you and I probably can’t get away with screaming “NO!” and slamming the door in the requester’s face. The polite and career-prolonging way to deal with the problem is to ask, “Why?”
Ideally, in the process of explaining the rationale for whatever the request is, some other solution to the problem will be identified. A good way to improve the odds of this happening is to involve other people in the discussion. Extending the audience in this way creates opportunities for someone to interject helpfully with something along the lines of, “but Carol, we have a perfectly good hammer over there; why are you trying to use a screwdriver to batter a nail in?”
Sometimes, you may need to adopt an iterative approach, which sounds impressive, but simply means waiting until the end of the first explanation, nodding thoughtfully, and then asking, “Yes, but why?” Among people who watch more television than me, this is known as the Columbo approach: “Help me understand, what is it you are trying to do here?” and just keep doggedly repeating the question. Eventually enlightenment will arrive—or the requester will get tired and go away, which is also a perfectly valid win condition.
This method will also help with the tricky situation where the most important question is the one which is not being asked. There is often an implicit question behind that one, where the solution is not to give a glib answer, but to think critically about the proposed or effective solution and ask the questions yourself: “Why are we trying to solve for this?” Or, “What is this thing you are proposing actually meant to do?” And finally, “What was the original problem, anyway?”
People have a tendency to focus on the issue that is right in front of them, even when the real problem is in an upstream step of the process. They observe or experience something about X as the identified problem, and so default to solving for X directly without considering the broader landscape. This leads to convoluted, inefficient and often high-friction solutions—Rube Goldberg/Heath Robinson machines (delete as appropriate to whichever side of the Atlantic you are on), where a simple connecting pipe is all that is required. An artillery piece will make holes in the ground, but there are a couple of collateral impacts you may want to consider—and maybe offer a spade instead.
All I needed was somewhere to plant some flowers!
Unfortunately even the Columbo Method is not entirely guaranteed to work, because on some rare occasions the underlying request is actually valid and cannot be summarily dismissed. This is when you bring out the big guns and start ranking the urgency of what was already agreed as the scope of the project (a nail hammered into the wall sturdily enough to support that lovely picture) as opposed to what is being requested (a fully motorized picture rail, capable of supporting up to 10 paintings on the scale of Guernica and turning them to optimize lighting conditions throughout the day while also keeping them out of direct sunlight). Nobody is saying that the second option would not be nice, but it certainly won’t be done in time for supper.
And that, children, is how you say No. Go forth, and do ye likewise, and may all your projects be huge successes. And, most importantly, not require me to come in and clean up after you.
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.
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: 
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.
three use cases in 
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 
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 
“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 
“
“
