Author: Alan Shimel

  • DevOps Chat: Serverless and Abstraction with Nimbella’s Anshu Agarwal

    DevOps Chat: Serverless and Abstraction with Nimbella’s Anshu Agarwal

    Anshu Agarwal has a tremendous record of working in startups that had successful exits. Now for the first time, along with her co-founders, she is actually founding the startup herself. Nimbella is a serverless platform that is cloud-agnostic and makes developing and deploying applications easy. Whether in a public cloud, private data center or both, Nimbella can help.

    In this DevOps Chat, we speak with Anshu about her own personal journey and where Nimbella is and what the plans are for going forward.

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

    Transcript

    Alan Shimel: Hello, everyone, it’s Alan Shimel of devopsy.kinsta.cloud and you’re listening to another DevOps Chat. Today’s chat actually features a company that’s just starting out here, but it’s a guest who’s had a rather long career in the tech space. As long as mine, even, at some point, but I’m sure I’m much older. Anyway, I’d like to introduce you to Anshu Agarwal. And, Anshu, if I messed up your last name, I apologize. Was that good?

    Anshu Agarwal: Thank you, Alan. You said it perfectly right. Thank you for having me today.

    Shimel: Thank you. So, Anshu, let’s start off – I referenced that you’d been in tech a while. Let’s give people an idea of your personal journey that brings you here today, even going back to Speedera and beyond, if you’d like, but if you wanna start with Speedera, that’s fine. But let’s give folks an idea of who you are, what your background is.

    Agarwal: Sure. Thank you. So I am an engineer by background and I moved into product management and marketing after I finished my MBA. And, after that, I joined a startup and then the startup bug never left me. So I joined Speedera, which got acquired by Akamai. Then I joined another startup, Ankeena, which got acquired by Juniper. Another startup, ConteXtream, got acquired by HP. And my most recent startup, Cedexis got acquired by Citrix, so I have been acquired four times. And, in all of those companies, I kind of delivered the success for other people’s ideas because they were all successful startups, got acquired by very, very large companies, so they were indeed – from value standards, they’re considered successful, but, for myself, I had never really done a company of my own.

    So, when I got the opportunity of just starting and being a founder of a cloud infrastructure, because that’s my background – I’ve been doing cloud infrastructure for last 15 to 20 years – there was no question that I wouldn’t do it. And we got started on this company – the company name is “Nimbella.” And it is in the serverless framework or serverless platform space. And we are kind of disrupting what serverless is, so – or we are providing what serverless promises to the developers. So that’s what we are working on now.

    Shimel: Excellent. You know, you’re way too modest and humble because, for many people listening, whether they’re in the valley or Boulder or Austin or New York or Boston or London or Bangalore or anywhere else in this world, having four startups that were acquired by companies like Akamai, HP, Citrix, and I forgot the fourth one – I apologize – a lot of people would call that a career. Right? I mean, whether they founded the companies or not, just being associated with four companies that had successful exits to large companies like that is something to be proud of and it speaks volumes as to either you’re really, really lucky or you’re doing something right. Right? So congratulations to you for that.

    So you’ve mentioned Nimbella and I wanna kind of share with our audience up front that Nimbella is – you have raised some funds for the company and there’s a great startup – there’s a great founders group involved. You mentioned, I think, one of your cohorts from Speedera; I think there’s two other founders in the group. But the company’s sorta still – I don’t wanna say stealth, but pre-product, let’s call it. Pre-public-product. So I don’t wanna put you on the spot. I’d rather talk, I think, if it’s okay, Anshu, about some of the problems you see and potential solutions that we see.

    You know, we live in a great time for developers and engineers. Internet time, right? We’ve gone from servers to hypervisors to containers. Now serverless. And serverless seems to be all the rage, but, like any new technology, it’s not birthed mature, right? It doesn’t come out mature; it doesn’t start mature. And so there’s gonna be growing pains. Can you share with our audience a little bit about what you see as some of the growing pains around serverless or what you’re hearing from people around that?

    Agarwal: Absolutely. Well, thank you for – this is a great question because it is definitely the best thing that’s happening for developers. The reason I say that is because what developers really want is to develop their business logic or develop the code and not worry about the infrastructure. And serverless promise is all about that, that you don’t have to worry about the infrastructure. You don’t ever have to worry about how it scales, how it is secured. Anything that requires the knowledge of infrastructure should not be a developer’s worry.

    But, in today’s serverless frameworks – and there are a few serverless frameworks and some are very popular ones – there is so much complexity still for the developers because they have to combine many services. And, for instance, they have to think about storage, they have to think about identity management, and they have to learn all these services and integrate. Not only that, the management and debugging is still an issue. And these are growing pains, as you mentioned. The serverless computing is still in a nascent stage and, therefore, it’s lacking all the abstractions that are needed for the adoption to accelerate into new markets and application domains.

    Not only that, serverless today, if you look at it, is used only for stateless applications, so you’ll see it in IoT applications, you’ll see it in reactive kind of applications only. It is not suited for long-running or stateful workloads. The reason being is because serverless today is serverless compute; it is not serverless storage. So that’s another problem. We may consider it as a problem or we may consider it as the limited adoption of the technology, but that’s something we have to address if we want this to be adopted in general, across all workloads. Then the –

    Shimel: I’m sorry. We may also consider it as an opportunity, right? I mean –

    Agarwal: Oh, absolutely.

    Shimel: Yeah.

    Agarwal: Absolutely. And that’s what we’re doing. And I’m gonna talk about Nimbella and how Nimbella is addressing it.

    Shimel: Mm-hmm.

    Agarwal: Another important aspect of serverless today is, like any new technology environment, there is serious vendor lock-in because, if you are using AWS’s Lambda serverless framework, you are programming to the nuts and bolts of Lambda. If you are using Google, you are programming to GCP, and so it is with Microsoft Azure. So, in a sense, you are programming to proprietary frameworks and, therefore, your code is not cloud-portable.

    So, tomorrow, if your company decides that, “Now we are going to move from AWS to Google,” you gotta rewrite the whole thing again. So that is actually, again, the serverless promise, and, therefore, vendor lock-in is very real, especially for the companies, actually, that choose not to go to public cloud because they’re part of regulated industry or whatever _____. They want something to be running in their own private cloud; these serverless frameworks are not an option for them. And then, say, you were able to write code for all different frameworks, but then the complexity of operations is there because you can’t monitor and observe at each level since these are proprietary frameworks across these clouds.

    So there are serious issues for widespread adoption and that’s where we come in. That’s the opportunity we looked at when we decided to create this company, is we want to create a platform, a framework, that is providing all the necessary abstractions so the developer is not to worry about how the infrastructure works, how to scale the code, how to secure the code. The code is just nebulous logic that they write. Then it is also suited for long-running, stateful, streaming workloads, such as AI/ML workloads. I mean, we have a greater adoption of AI happening in every industry. If we are not going to be able to handle AI workloads, we are missing a big market.

    And those are real, real problems and we are addressing it with Nimbella, you know, the technical problems. Then there are operational issues where you want cloud portability, so we are also addressing that part because we are providing a layer of abstraction and it’s open-core-based, so a developer can program the way they program the business logic and not worry about which cloud they’re writing.

    Shimel: Got it. Got it, got it, got it. So, again, I don’t wanna be uncomfortable or make you uncomfortable with what we’re gonna talk about, but, you know, I was at KubeCon out in Seattle last month – seems like a year ago, but it was only last month – and, surprisingly or not surprisingly, “serverless” seemed to be on everyone’s lips. Right? And maybe some people listening to this are saying, “Wait a second, Kubernetes is for containers and containers can run on bare metal, yeah, but they run on VMware or hypervisor as well.” What do you think the role of Kubernetes is in the serverless future? Fair?

    Agarwal: Kubernetes is a great technology. I really think it has great future. And serverless frameworks use Kubernetes or something else like that. And we were also at KubeCon. It was actually our first conference as an Nimbella person attending – one of my cofounders, who actually is the creator of OpenWhisk Apache, a serverless framework, he attended it. And he mentioned the same thing that you mentioned, that serverless was on everybody’s slide deck. Okay? It is something everybody is looking at; it is something everybody is kind of they have it on their roadmap, that they wanna work on it. They wanna look at it and see if it works for their environment.

    And Kubernetes is perfect, actually. It provides the platform needed because it is widely accepted these days and it provides the necessary environment, but, again, it should not be the burden of a developer to know how to run, work with Kubernetes. It should be the infrastructure serverless framework that provides that to the developer and the developer’s still only programming the logic. It’s not for the developer to worry on what environment, what container environment they are working on and what VMs are being used and what bare metal is being used. That’s all abstracted away for the developer.

    Shimel: Got it. Got it, got it, got it. So, you know, I’m sure there are people listening to us today who are thinking to themselves, “This woman has been in four startups and has had tremendous success.” And now I’m sure you’re a CEO, right, of Nimbella and you’re cofounder –

    Agarwal: That is correct.

    Shimel: Right? And I’m hoping there’s a whole bunch of women engineers out here or women entrepreneurs who are listening to you, saying, “Hey, if she can do it, I can do it.” And we don’t have a lot of time left, but I wanna address those folks there, that are near and dear to me for a lot of reasons. What’s your advice to them?

    Agarwal: Absolutely. If I can do it, they can do it. That is a very true statement. And, I mean, you said some great words about me, but I consider myself average successful person and, yes, I have been lucky that the four companies I’ve worked for had great exits. But being a founder and CEO is still very different from what I did for the other companies before. So, basically, when you are part of the company, other companies, you’re not bothered by operational aspects of the company. You’re not bothered by hiring for every possible function in the company. So the skill sets that I’m developing now, there is no other experience that could have taught me that, so, even though – I say, “Everybody can do it and anybody can do it,” but they still have to learn the art of running a company on the job. It just – there is no course. There is no education that can be given because you have to experience it.

    So, to all the women engineers that are listening, I would say, “If I can do it, you can do it. You just have to just get into it. You just have to dive into it and it will come to you. You will develop your advisors. You will develop the people who help you on the way because you won’t have all the skill sets, but you will know who to go to for what skill set, as you take that role.”

    Shimel: Absolutely. Absolutely. And, you know, women or not women, entrepreneurs – I’ve also founded and helped start my fair share of companies – I don’t know if it’s courage or just pure moxie, if you will, right? You just put one foot in front of the other, right, and you just keep moving forward. And you can’t boil the ocean, right, but you can – these things are incremental, right, and they’re evolutionary. They’re not _____ –

    Agarwal: Absolutely. You’re absolutely right. These are such an incremental thing and you may be not finding the best solution, but you are optimizing your solution, at every step, because you’re trying to handle so many things and, if you wait for the best solution to arrive, it may be too late. So you’re kind of optimizing the solution for whatever issue or whatever problem you’re handling, and you move on with that. And it’s just only time will tell how successful I am in the role, but this is my experience six months into this company, six or seven months into this company, and I’m still learning the art.

    Shimel: Absolutely, it is. So what do you – short-term future, where can we find out more on Nimbella or when will we find out more, do you think?

    Agarwal: Oh, absolutely. So there is some information on the website – very little information, I would say – but it gives you a flavor of what we are doing. Then, in Q1, this quarter, we are going to be releasing our developer playground, which is actually – because the buyer of serverless technology is the developer and developer experience is the most important thing, a developer has to feel one with the programming experience. And that’s the true serverless promise and we wanna deliver on that promise, so, in Q1, we are going to release that.

    And, in later quarter, in Q2, since I have mentioned private cloud and hybrid cloud, there will be offering for private cloud in Q2. So, as this quarter progresses, we are going to populate the website more with the content and we’re going to host more meetings like this and make it available to the developer community in general, our solution, and then, later on, for enterprise sites.

    Shimel: Great. Great, great, great. Anshu, when I started, I said, “These are only about 15 minutes. It’s gonna go so quick, you won’t believe it.” If I told you we’re closer to 20 minutes already, you’d probably say, “Oh, my,” but we are and we’re gonna need to call an end to this DevOps Chat. You know what? It sounds like there’s a lot going on here and, if we can have you back on, you know –

    Agarwal: Oh, that would be great, Alan. I really hope we can –

    Shimel: Yeah?

    Agarwal: I really hope we can get back when we have our developer playground because I’d love to talk more about it.

    Shimel: I promise you we will.

    Agarwal: Thank you.

    Shimel: Promise you we will. Thank you. Anshu Agarwal, founder/CEO of Nimbella, our guest here on this DevOps Chat. This is Alan Shimel and you’ve just listened to another chat.

    — Alan Shimel

  • Fourth Annual DevOps Dozen Winners Announced

    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 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, devopsy.kinsta.cloud Chat, AgileCXO and DevOps Enterprise Summit, as well as more than a dozen LinkedIn posts in 2018.

    Best DevOps Transformation

    capital oneCapital 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 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 devopsy.kinsta.cloud Article of the Year

    “Continuous Discussions, Episode 90: Gene Kim and DOES18 Speakers,” by Anders Wallgren won the Best 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 devopsy.kinsta.cloud and the rest of the MediaOps family of communities. If you have questions, please write us DD@devops.com.

    — Alan Shimel

  • DevOps Chat: Cloud Migration with nClouds’ JT Giri

    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

  • DevOps Video Chat: DevOps Testing with Ryan Lloyd of SmartBear

    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, 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 devopsy.kinsta.cloud. And we’ll talk to you soon, everyone. Have a great day.

    — Alan Shimel

  • DevOps Video Chat: DevOps Transformation with Tasktop’s Carmen DeArdo

    DevOps Video Chat: DevOps Transformation with Tasktop’s Carmen DeArdo

    Carmen DeArdo is well-known in the DevOps space mostly because of his work at Nationwide, where he was DevOps leader and technology director. In August of last year, Carmen moved to Tasktop, where he works with other DevOps luminaries Mik Kersten and Dominica DeGrandis, helping organizations along their transformational journeys.

    In this DevOps Video Chat, we speak with Carmen about his move to Tasktop and the culture shifts that are almost universal in embracing DevOps.

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

    Transcript

    Alan Shimel: Hi, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and welcome to a DevOps Video Chat. Today’s guest on our DevOps Video Chat is well-known DevOps personality, Carmen DeArdo, as well as huge Pittsburgh Steelers fan. Carmen, welcome to DevOps Video Chat.

    Carmen DeArdo: Thank you, Alan. Great to be here. Glad to be talking to you.

    Shimel: Absolutely. So, Carmen, to paraphrase a religious question, this one’s a little different than all other chats we’ve done before, in that we’ve always spoken to Carmen from Nationwide Insurance DevOps team, where you really pioneered a lot of DevOps – not only at Nationwide but set the tone and the course for a lot of DevOps journeys throughout the industry. But now you come to us as Carmen DeArdo as part of Tasktop.

    DeArdo: As you said, I always enjoyed, within the DevOps community, talking to other companies. You know, we talked a lot at conferences, where I was a reference customer for some other customer – companies, like IBM, and I was just really intrigued by Mik’s book, which I know we’ll be talking about, and some of the concepts that Tasktop was getting involved with because we were a customer. And I really liked their vision and now I’m here on the Tasktop roster, so to speak, working with customers to help them go through the kind of journey that we went through at Nationwide and also to bring in some of the concept of Mik’s book, which I think can take it beyond, to the next level of what we were doing at Nationwide.

    Shimel: That’s fantastic, Carmen, and I – first of all, I wish you a lot of luck in the new position, new sort of career path, and I’m sure you’ll do great because you’re just a great person with this. Well, you mention Mik’s book and I happen to have a copy of it here. It’s called Project to Product. It’s by Mik Kersten. And, not to brag, but I happen to have a signed-by-the-author copy of it, you know?

    And I will tell you, Carmen, I was fascinated with some of the concepts in the book and I’ve discussed some of these concepts with people, as part of my devopsy.kinsta.cloud communication, and it really is – this concept of moving from a project-centric IT environment, right, to a product-centric is really – I mean, it’s fundamental, in a lot of ways, right?

    DeArdo: Yeah, it is. So I think, you know, we were at DOES London and that’s where they galley copies of the book came out, so the official copy, I think, the coming out party, officially, I think is gonna be in the Vegas conference, and then the book will be available shortly after that to everybody. But – through IT Revolution, but it is a fundamental change and it was something even that Mik and I had been talking about and we had been trying to work through at Nationwide because, before I worked at Nationwide, I worked at Bell Labs for quite a while. And one of the things that struck me when I came to Nationwide was we went – at Bell Labs, we already had this concept of kinda like products, right, because you had your switches, you had your network control points, you had – so work really came to the team. And so we were always working on the next set, for example, way back when I worked on Advanced 800 features, and so we had a team that stayed together and the work came to us and we were very focused on our product, that 800 service concept and then the systems that we build.

    So I came to Nationwide, what struck me was almost all the work was done through projects and these projects seemed to have a life cycle, a lot of ’em, that got funded as part of the funding for that year. They started up. You brought all these people to the team. You went through the “norming and forming and storming” kind of parts of the project. And then, once they were done, the project dispersed and the people went. And what you would do – it was very difficult to do – was, if a project touched five or six systems, you would start to allocate – you know, we were using Clarity – two people, three people, a half a person, a quarter person, whatever you thought you needed from those systems.

    And so it was a very fragmented kind of experience because the project was temporal; the systems people were all separated and spread out among these projects. Sometimes, a person might be working on a half-dozen projects at the same time. And, you know, you were constantly forming in these teams and so one of the ideas of the product focus is you have a set of people that are focused on that product. They’re gonna live, eat, drink around that product. And it may be more than one team – we’d like to say it’s a two-pizza team that can solve the world’s problems, but we know, sometimes, it’s gonna be more than one team – but still their focus is on the product and now the whole idea of bringing them a continuous flow of work, you’re bringing it to this established product teams.

    And the other thing that came up with projects a lot was there was this tension between doing the feature work versus the defects and the risk items and some of the technical debt because project managers were very focused on “You have a budget. You have a set of scope. You’re supposed to deliver that.” So who wants to pay if there’s a vulnerability in a Struts library or making the next thing faster, right? Technical debt is always about – is really about investing to make the next thing go faster, so, if you don’t really have a long-lived relationship with what you’re working on, you tend, just because of the nature of business –

    Shimel: You make short-term decisions.

    DeArdo: Make short-term decisions. Right.

    Shimel: Yeah. I mean, you know, Carmen, that was one of the things I realized in talking to people, about shifting from a project focus to a product focus, and, to me, it was almost – I learned a lesson. I helped take a company public back in the dot-com days – ’99, 2000 – and the difference in how we managed the company as a pre-public, as a private company, to a public company just blew me away. Right? All of a sudden, we were managing in three-month cycles, right? ‘Cause we were managing quarter to quarter ’cause we had to just, you know, go to the street and tell them our results. And you start making decisions that ultimately led to the failure of the company, frankly, because we were making very, very short-term decisions that were maybe good for the short term but not for the long term.

    DeArdo: Right. And you know I’m a – you know, we talk about Deming a lot and Deming warned about things like that, right, about the short-term thinking and lack of systems thinking, but you’re right. It drives you that way because the market’s saying, “Well, what’s your next earnings per share? What’s your next report gonna be?” So it does take more – it’s a different way of thinking about things and, really, you’re more in it for the long haul. Now that’s not to say you can’t do things well in the short term because absolutely you can. You can apply all the DevOps practices we’ve talked about. You can run your experiments or ideas of what you think is gonna get value. You can get that feedback much more quickly.

    So you can still apply all the things that we’ve talked about and everything, over the last five, six years, but now you’re doing it for the benefit of that product and you can start to tie the business in with how the value’s actually flowing, right? Because, a lot of times, you don’t – a business doesn’t wanna go up and show ’em an Agile team board, with a bunch of different stories, if they can’t relate it to “What’s the value of what I’m getting through this value stream? Right? Where is my value? What’s going on with what I’m trying to do?”

    And, with that product focus, it kinda tears down that wall and opens up that black box of IT and says, “Okay, all the way from the idea through deployment, we’re gonna make this work visible and we can see it and we can make decisions and priority calls based on how we’re gonna deploy our resources. And it’s across the features, the risks, the defects, and the investment in debt items so that we can continue to make this product good, not just now but in the future.”

    So it seems subtle, but, actually, it’s a very different way of thinking and it even gets back into how things are funded. So I think, in the past, with Agile and DevOps, we stayed away from that left-hand side of the value stream, closer to the customer – we’re kind of in our comfort zone – but now it forces you to engage the business and really have them come along to the journey with you. So that’s another change, I think, in how this applies, versus some of the things we’ve done up to this point.

    Shimel: Good. Now – I mean, Carmen, I think you’re so right on with that, though, in that it sounds subtle, but yet it’s so fundamentally different. And I guess one of my biggest fears around it is people are so resistant to change.

    DeArdo: Right.

    Shimel: And, thought – you know, maybe that it sounds subtle will help sneak it in, right, as a Trojan horse or whatever, but to tell people that they’re gonna have to shift the way they think about this, about the way they go about doing IT in products, knee jerk is “No, we’re not.” Right? It’s –

    DeArdo: Right.

    Shimel: And that makes it hard.

    DeArdo: It makes it hard. And that’s an excellent point, Alan, and I think we’ve been talking about this since I joined, which it’s almost two months now, about the fact that, just like – when I was at Nationwide and gave some of the talks with Cindy and Jim, we talked about the journey. We even had that mountain which showed you climbing to the summit. This is a journey, right? And, if you start out with what you just said and saying, “Okay, you can’t even get started until you do all these things and they involve your business,” you’re right. You’re gonna lose folks right there because “Wait. I gotta change my organization. I gotta change how we do funding. I gotta change this.”

    So the way you have to present it and the way I think we’re looking at is we’re taking the customer on a journey. And that journey starts, really, with – and I  used to talk about this with you – thinking horizontally. Right? So, when you think of a value stream, a value stream starts and ends with the customer. And if you start to get people to think horizontally and the concept across that value stream and the artifacts that flow from your PPM, your portfolio planning, through your build cycle, through your deploy, and the fact that, in order to get flow, your tools have to be connected, which is where Tasktop essentially was started, was around this concept of connecting your tools, making your tools talk, synchronizing artifacts from tools so, when a defect is created in quality center, it can flow into the backlog of your Agile team. When an instance’s created in ITSM, it can become a defect; it can flow.

    So it’s really starting with this concept of “Let’s start with getting the tools talking. Let’s get your artifacts flowing.” And even – and this may sound heresy – even if those artifacts initially are really focused on the work of an initiative or a team or even a project, dare I say, you can still start to utilize the concepts in Mik’s book around the flow framework and see things like lead time, flow time, the flow efficiency, flow velocity. You can still see those things as part of this journey.

    Now I think, ultimately, yes, you need to turn the boat more to get that product focus, to get some of the things – advantages we just talked about, but you can start this journey, I think, from wherever you are, as a enterprise, and just take those incremental steps in order to get to the point where then you’re ready to experiment with one product. Right? And then you just wanna start with one product. Pick one product, get one business owner that is interested in this.

    And then, from that, you even call it maybe an “experiment,” get some results, and then that’s what starts to change the culture. Right? It’s not gonna be me talking or giving talks; it’s gonna be – you know, I used to joke about this at Nationwide, right? When I would go around to different areas and talk, that didn’t have near the impact of getting one team to actually do something and get results ’cause then that opened people’s eyes and said, “Okay, that is possible. It’s possible right here, right now, and I wanna create my own story.” So you’re absolutely right. It needs to be structured in a way that allows companies’ teams to go on that journey; otherwise, the impact of the change is gonna be too much and you’re not really gonna get any traction.

    Shimel: I agree. You know, Carmen, that was one of the first lessons I learned in business a long, long time ago, which is nothing succeeds like success.

    DeArdo: [Chuckles]

    Shimel: No one wants to jump on a sinking ship; everyone wants to be with the winner. And if you could show that you’re winning somehow, that you’re succeeding, you have upside, everything kinda flows from there. Right? People wanna be associated with that and they’re willing to tolerate and even embrace change, in some –

    DeArdo: Yeah. Absolutely. And, you know, and some of the – you know, you can’t just decide you’re gonna wake up today and change culture, right? I mean, you have to do things through what you’re talking about, right? Creating those experiences, those successes, those stories. Stories are very powerful. That’s what ultimately will change the culture, right? Sharing credit. Right?

    If it looks like – you know, at Nationwide, if it looked like, “Well, this is Carmen’s show,” that’s not gonna get anywhere. It has to be everybody’s show. It has to be Jim’s show and Jane’s show and Donna’s show and everybody’s show, where they’re now showing how they can be successful. That then really has the impact of changing the culture and showing people that, yeah, this is possible because that team on the fifth floor’s doing this, right? It’s not in this book. It’s not in this conference. It’s that team. It’s that team on the fifth floor and why can’t we do it?

    Shimel: Agreed. Agreed. So, Carmen, you mentioned you’ve been at Tasktop now two months. We spoke a bunch about the book, Project to Product, by Tasktop CEO, Mik, but the Tasktop people have really amassed a great Murderers’ Row lineup there. They’ve got you; they’ve got Mik. And I can’t –

    DeArdo: Dominica.

    Shimel: Dominica DeGrandis, of course. You know, that’s a lot of brainpower. Lot of brainpower over there. What else are you working on?

    DeArdo: Well, I mean, it’s obviously a pleasure. There’s a lot of – it’s a great company, it’s a great culture, and Dominica beat me over here by a few months, but to be able to collaborate with folks like Dominica and Mik and then just the whole community, right? Because they were folks that were already in the great community that has been built, that Gene’s built, other folks like yourself have helped build this whole community. I mean, yeah, it’s a pleasure. It’s an honor to be able to talk about these ideas. I mean, Dominica’s concepts of flow and visibility naturally just relate to what we’re talking about.

    I thought it was interesting, in the London talk, the London conference, I mean, you go to all these conferences and you can sorta see, over year to year, how things are going and what topics now are becoming more in the mainstream. And there’re a number of talks this year where flow was either in the title or key concept. Jonathan Smart talked about it; Fin had a talk about flow. So flow is kinda where it’s at, I think, now, as people are seeing, “If I’m gonna accelerate my delivery, become more responsive, I gotta understand flow and, as my ex-boss, Tom Payter, would say, where things aren’t flowing.”

    And so, with Dominica’s great work that she’s done with making work visible and concepts of flow, her book, Mik’s book now, I mean, yeah, it’s a great opportunity to be involved with just a great company, great culture, and great folks, to see how we can help other companies succeed in the marketplace.

    Shimel: I think it also speaks to the coming maturity of the DevOps marketplace, where we’re seeing sort of leaders kinda come together, community leaders come together and combining in ways that it’s sorta synthesis, right? _____ synthesis and I think it’ll lead to yet another wave of innovation, another wave of thinking about these things.

    DeArdo: Yeah, I agree. I mean, I think people like Gene have done a great job of bringing people – creating forums for people to come together and the community, as you know and as you contribute to, is very open about sharing ideas. Right? So, for example, I would use – Topo Pal, we both know at Capital One – I would use his example all the time at Nationwide, when people would say, “Well, we can’t do this. We’re not a unicorn. We’re a regulated industry.” I’d go, “Well, let’s see what Capital One has to say about this,” right? They’re a bank. They had a great presentation with auditing, where I think Jennifer Brady was the auditor that came up on stage with Topo and gave a talk.

    So it’s just such a great community where people are willing to share and – you’re right – that allows everybody to get better and the whole community is kinda propelling each other forward. So it’s really been a great blessing, honor to be involved, getting to know all these folks and getting to do this kind of work.

    Shimel: Absolutely. Well, Carmen, we’re about out of time, but I wanna wish you luck at Tasktop. I think they’re really, really lucky to have you. I’m sure we’ll run into you somewhere on the DevOps conference circuit and we’ll catch up in person. But congratulations on the move to Tasktop. You’ll make us proud, Carmen. Keep innovating. Keep leading. And thanks for being our guest today.

    DeArdo: Well, I appreciate the kind words, Alan. It’s always great talking to you and I look forward to keep the conversation going. Thank you very much.

    Shimel: All right. Carmen DeArdo – you know, Carmen, I forgot to ask, what’s your title at Tasktop?

    DeArdo: My title is senior value stream management strategist.

    Shimel: Carmen DeArdo, senior value stream management strategist at Tasktop, our guest today on DevOps Video Chat. Thanks, everyone. Have a great day.

    — Alan Shimel

  • DevOps Chat: Crowdsourced Continuous Testing with Rainforest’s Derek Choy

    DevOps Chat: Crowdsourced Continuous Testing with Rainforest’s Derek Choy

    Scaling your testing is the scourge of many software teams. While test automation and continuous testing have made great strides, it still is difficult to automate every QA test. Also, engineering resources who can script these tests are difficult to find. Enter Rainforest.

    Rainforest has a unique crowdsourcing solution to continuous testing. It combines crowdsourcing talent with automation to deliver a high level of quality assurance on a continuous basis.

    In this DevOps Chat, we speak with CIO Derek Choy as he explains to us why Rainforest in some ways can be the Uber of QA. As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Transcript

    Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. Today’s DevOps Chat features a first-time guest on DevOps Chat. He’s Derek Choy, CEO at Rainforest, or Rainforest QA, as some may know them. Derek, welcome.

    Derek Choy: Thank you. Just a little correction: I’m CIO at Rainforest.

    Shimel: What did I call you?

    Choy: Responsible for primarily the technical side of the functions here.

    Shimel: Did I call you “CEO”?

    Choy: I think you did, but I just want to make a little correction there.

    Shimel: You know, it’s 2019; that’s my prediction.

    [Laughter]

    Choy: I don’t know that I would support that prediction, but thank you. [Laughs]

    Shimel: Well, I _____ – CIO’s enough. But, anyway, Derek, thanks. Yes, it’s Derek Choy, CIO at Rainforest. So, Derek, you know what? I didn’t make the mistake on purpose; it was an honest mistake. Good. That leads us – why don’t we talk a little bit about Rainforest for our audience who may not be familiar?

    Choy: Absolutely. So Rainforest is a testing platform. What we do is we help our customers with their software testing. You know, as you know, we’re moving – a lot of companies are moving towards a rapid development cycle, CI/CD, frequent releases and stuff. Testing becomes much of a challenge for a lot of our customers because now they not only have to do testing, but they have to do it fast. They have to have accurate results and stuff.

    So Rainforest is actually a crowd-based testing platform that allows our customers to simply input test cases in plain English, so no Selenium or any sort of programming language, and then we can actually execute them as if they are automated test. We’re fully integrated into any CI/CD tools, like Jenkins or CircleCI and so on, so you can actually trigger a Rainforest test. Typically, we can return results in 30 minutes or so, and you can actually test across many different platforms, like different browsers, different OS’s, and the same for mobile as well. And so that allows our customers a wide variety of options, in terms of where they want to run their plain-English test cases and when they want to run it – it’s on demand. And we typically return results in 30 minutes, fully integrated into an automated release cycle.

    Shimel: Great. Excellent. And, Derek, how did it come to be that you became the CIO of Rainforest? Let’s hear a little bit your own personal journey.

    Choy: Cool. Oh, thank you. So I have been always involved in the product engineering side of things. I started off my career earlier with Accenture. Spent a number of years at eBay. And then my last company at Aria Systems, building SAS-based billing system, also running their engineering and product function. So, coming to Rainforest, I brought my experience and knowledge in this space, to help build the engineering and the product organizations. Now here, besides product engineering, I’m also responsible for our professional services team and our client success team. So essentially kind of helping build out product and making sure that our customers are successful in using that.

    Shimel: Absolutely. So, Derek, you know what? Here we are in December. We’re looking at 2019.

    Choy: Mm-hmm.

    Shimel: I probably have spent the last three weeks – if I tell you I’ve spoken to dozens of vendors and C-level execs at large organizations, and, to me, the real story of 2019, as well as what’s emerged as the story of 2018, is around – you know, you wanna call it “digital transformation” and “DevOps,” _____ say great, but, really, down to these two things: companies are – they need scale in what they’re doing today, right?

    Choy: Yeah, absolutely.

    Shimel: When we’re talking about data and computation and transactions or whatever the metric is that’s driving your company, everybody wants to do it at huge scale, like unprecedented scale that, 20 years ago, you would’ve went – you know, I’m just reminded of Carl Sagan saying, “Billions and billions of stars,” _____.

    Choy: [Laughs] Yes, that’s right.

    Shimel: That’s the scale. And the only way to achieve that kind of scale is automation.

    Choy: Yes. Absolutely.

    Shimel: So these are two kind of twins, co-joined at the hip – scale and automation.You can’t have scale, I think – well, you can’t handle scale without automation.

    Choy: Absolutely. Yeah. And – sorry.

    Shimel: Go ahead. No, no, go ahead.

    Choy: I –

    Shimel: You know, to me, that’s it right there. That’s the crux of it.

    Choy: Exactly. And, Alan, I would say that I’ve never been more excited, right, than where we are right now. I think we are definitely at a very exciting time and, just to kinda set the context and maybe kinda recapping a little bit of what you just said, right, the world is very different now, even compared to five years ago. Right? A while ago, you would hear companies having a quarterly release. Some would even have an annual release, if you remember, especially the bigger companies, right? You know, release cycle was a lot longer, takes a lot more time to get things out to the market. Today, release cycles are typically maybe in a month, right? Maybe two weeks and, in some cases, days or even multiple times a day. Right?

    And exactly to you – and the interesting thing is that the world has got accustomed to that and has come to expect that, frankly. Right? Think about the apps that you’re using. If they come back to you and say, “Well, you know what? We update our apps once every six months,” or something, you’re like, “Wait, six months? Wow, that’s unheard of.” Right? “I was expecting a weekly update or at least monthly or something.” So the world has actually comes to expect that.

    Now the challenge, exactly as you pointed out, is how do companies deal with that? Right? How can we scale our organization through automation, among other things, right, to make sure that we can keep up with that pace? I think that that is the challenge with a lot of technical leaders, is we understand what the companies are looking for, understand what the consumers and our customers are looking for, right? But how do we do that? Right?

    And there’re different aspects of it, Alan. I think that there is definitely a development aspect of it, right? How do we scale development? How do we do rapid development, Agile, sprint? You know, all these things. Things have evolved a lot over the last, I would say, ten years, in terms of faster development. There’s a lot _____ –

    Shimel: On the development side?

    Choy: Exactly. And there continue to be more evolution on that, which is super exciting. Now one thing that hasn’t really, at least in my opinion, gone as far in this particular context is testing. Right? If you think about testing, we’ve had automated testing for a long time – 10, 20 years, maybe even longer, right? We’ve always had manual testing, right?

    Now, when you think about testing, that’s – which is a critical part of the release cycle. Of course, right? You cannot push things out without some sort of testing at least, right? There hasn’t really been a lot of innovations and evolutions in testing. We’re still trying to do automated testing; we’re still doing some manual testing; we’re still doing it kinda the same way, so to speak. There’re new automated testing language, but they all kinda do similar things, right? And they all have similar –

    Shimel: Absolutely. And, Derek, let me stop you there for a second.

    Choy: Yeah.

    Shimel: To me, here’s the real crux in the issue.

    Choy: Yeah.

    Shimel: We talked about that we’ve certainly seen, let’s call it, a “revolution” in development acceleration, rapid development over, let’s say, 10 years. I’ll say even 20 years, right? _____ _____ _____ around for about 20 years.

    Choy: Agreed.

    Shimel: Do you consider testing part of development? Or did DevOps come along and say, “Wait a second, it’s all one continuity here, with development, testing, operations, security – you wanna put security next to testing, whatever – but it’s one continuum”?

    Choy: Yeah. It’s definitely – I completely agree with that. It is definitely one continuum, meaning that they are all part of the overall workflow, right, to make automation possible, to make a fast release process possible. You cannot do it without any one of those components, right?

    Shimel: No. But they haven’t kept pace with the changes that we’re in – what we consider when we talk development.

    Choy: Yes.

    Shimel: Where many of us think, you know, of coding.

    Choy: Exactly.

    Shimel: That’s the issue right there.

    Choy: That’s the issue, exactly as you pointed out, right? All the components of that whole continuum hasn’t really kept pace, right, with the developments that we’ve made on coding, right? On the actual coding of the product. And I think that that’s starting to show or actually has been starting to show, in terms of how other components of that, testing in particular, has been frankly dragging down the overall speed of being able to push things out faster and so on, so forth. Right?

    If you talk to – and you do that all the time. If you talk to a lot of CIOs and CTOs and so on, frequently, you’ll hear challenges with testing. Right? And most people will tell you, “Yeah, I’m okay. I get it going,” but very few people –

    Shimel: “It’s good enough.”

    Choy: Yeah, it’s just good enough, but it’s not great, right?

    Shimel: No, it’s not.

    Choy: Yeah.

    Shimel: And, Derek, I’ll go one further with you. What I see is this, is that, when we talk about testing – and _____ _____ the same thing with security, right? Is we’ve got twin challenges.

    Choy: Yes.

    Shimel: I can’t do it fast enough, so I’m constantly behind, running as fast as I can, but I can’t – just not fast enough.

    Choy: Exactly.

    Shimel: And then, number two, the train won’t wait for me.

    Choy: Yeah. Exactly.

    Shimel: If I can’t finish my testing, “Well, you did it good enough.”

    Choy: Yeah. “Let’s go.”

    Shimel: “We’ve gotta release. We’ve gotta release this hour,” or, “We’ve gotta release this week.” You didn’t do – dirty testing? That’s okay; it’s probably secure anyway. And, boom, out the door it goes, right? And that’s the dilemma, the enigma of testing, is “I can’t do it fast enough, but, if I don’t do it fast enough, they don’t wait for me.”

    Choy: Exactly. Right. And there is a reason for that. Exactly, right? Like we talked about earlier, because customers actually expect releases, right, whether you’re ready or not, right? They are expecting releases in a very frequent cycle. Right? And so companies therefore cannot wait. Right? It is not acceptable to go back to the customer and say, “You know what? My release is delayed and therefore you have to wait another week or two.” In the past, that used to be the common thing to do, right? Nowadays, that’s not acceptable.

    And so then what happen, exactly like you said, is that people compromise, right? They’re like, “Oh, you know what? Testing is not done. Okay, well, you know what? It should be fine. Let’s just go.” Right? “Security testing is not complete, but we’ve done a portion,” right? “Okay, well, let’s just go.” Right?

    The downside, however, is that – and you’re seeing it frequently; some people are just not paying attention to it – is that there is a high price to pay for that, right? You’ve seen a lot of security loopholes out there, right? And, yes, the release is out, right, but then at what cost, right? If people found a loophole and there is a data breach and costs companies lots of moneys and reputations and things like that.

    And equally with software quality as well, right? Things don’t work. Even bigger companies, you’ve heard companies like Apple, for example, struggle with that. Google, right, struggle with that. And they release something and people like, “Wow, this is junk,” right? “And I don’t want to upgrade,” and you hear that all the time, right? And it tarnish your reputation.

    Now bigger companies have, obviously, a lot more buffer to kind of weather these kind of quality problems, right? You know, whether you like it or not, you’re gonna continue to use Apple, right? Or Android or whatever. But then smaller businesses may have less tolerance for that, right? And customers of those businesses, if they’re not happy with your quality, they’ll move somewhere else.

    So I think it’s very important for technical leaders to figure that out and not just kinda brush it aside and say, “You know what? It’s not important. If quality’s not good enough, let’s just go. It’s fine. We’ll find bugs in production; we’ll fix it.” Personally, I don’t think that that’s the right approach and I think that it’s gonna hurt businesses down the road.

    Shimel: So you know what I call that? So that’s the double-edged sword of MVP.

    Choy: Yeah.

    Shimel: Right? ‘Cause you talk to these people and they say, “Don’t worry. We’re just doing an MVP. It’s a minimally viable product. We know it’s not 100-percent tested. We know it’s not a 100-percent baked. We know it doesn’t have everything, but we’ve gotta get an MVP out there, god darn it.” Right? [Chuckles] And so –

    Choy: Yeah.

    Shimel: And we appreciate – look, I’ve been – I founded, cofounded several venture-backed companies. I’ve been on pushing the VP of engineering, saying, “Hey, we promised our customer we had a new release coming out before Thanksgiving, man, and it has to get out. It has to get out. I don’t care if it’s fully tested. Get it out.”

    Choy: Yeah.

    Shimel: It’s not – you know, MVPs were being chewed to death.

    Choy: Yeah. I – [laughs]

    Shimel: So that “minimum” – that “M” in MVP keeps getting bigger and bigger and bigger. Right?

    Choy: Exactly. Right, exactly.

    Shimel: And more and more critical.

    Choy: Exactly. I think we continue to push the boundary of MVP. You know, I think that – and that’s really the challenge, right? So, you being kind of the leader of the business, right, you’re not wrong because customers really need it, right? “In order to move my business forward, I really need the release. I really need to get that feature out. I really need to get ahead of the market.” That’s not wrong. Right? And I think that that’s the needs of the business; that’s the market; that’s what people expect today. The challenge that we technical leaders needs to solve – CTOs, CIO, VP of engineering, VP of product – what we need to solve is “How can we support the business in doing that but also maintain the quality?” Right?

    And so, as a leader, in my opinion, going back to the business and say, “You know what? I can’t actually make your delivery date. You will have to wait another two weeks, four weeks, six weeks,” or something – that’s gonna be a tough sell, right? But, at the same time, releasing it without quality assurance, without security and all these stuff, is also not the right approach.

    So I think what we leaders needs to figure out is “How can we do better, right, in QA? How can we do better in security?” All these other things that are probably less mature than development itself, coding itself, right, how can we do better in these areas so that we can also support the business in shipping this MVP? Whatever the definition of this MVP is, right? We can support a business in shipping the MVP because that’s very critical to the business but, at the same time, maintain the level of quality and the level of security and, among other things, right, that we are proud of, right? That we want to have, right?

    And I think that that’s the biggest thing that we need to figure out in 2018 and definitely going into 2019, right? How fo businesses figure that out? How do we implement processes and tools and technologies that will allow us to do that?

    Shimel: Yep. So, Warren – Warren? I’m sorry. Derek, fantastic discussion. Let’s bring it home a little bit to Rainforest.

    Choy: Sure.

    Shimel: What can you do to help?

    Choy: Yeah, so Rainforest has a very – takes a very different approach to QA, right? You know, so the traditional way is, obviously, automated test with Selenium and all these different Appium, all these different technologies, or we can go manual testing and perhaps building an AMI offshore – that’s very, very typical as well. Rainforest looks at it and say, “Well, neither one are the best approach,” right? And therefore we come up with a testing platform, you know, that is powered by the crowd. And we allow our customers to actually put plain-English test cases on our platform. We can execute these tests without actually building an AMI offshore, but, at the same time, you don’t have to worry about the downside of automation, having to hire QEs and spend a lot of time writing Selenium scripts and things like that.

    And so we offer a solution that, at least we think, solves problems on both sides, right, and also allows you to hook it up into your CI/CD process so that you can actually push this MVP out in an automated fashion, fully kinda connected with all the rest of the continuum, right, and be able to actually ship code faster but with higher quality.

    Shimel: So let me ask, so, at some level, though, you are reintroducing or relying on human element?

    Choy: Right. Correct.

    Shimel: So why don’t you have the same scale problems that others do?

    Choy: That is an excellent question. So I would say that there are two elements, right? So, when we look at the human elements, we look at it from a crowdsourcing basis, right? So think about Uber, for example, right? If I were to hire my own team of drivers, that would be a little bit challenging, but then, leveraging the crowd and scaling it based on demand, we’re able to actually solve a lot of the human aspect of the problem. We can have testers that come in whenever they like to come in and we have enough testers to support the test that our customers would like to do. Right?

    And now the challenge there and probably a followup question then is “Well, but what about the quality of these people? Do they know what they’re doing?” Just like a Uber driver, right? How do you know that that guy actually drives well, right? So we actually developed a bunch of AI algorithms that actually analyze the work that they do and also take in feedback from customers, based on their former – the previous tests that they have done. And a combination of that with a lot of data mining and AI analysis helps our customers determine whether that test result is correct or not. If it’s not correct, we will engage additional testers to make sure that the tests are consistent and results are correct.

    So we have refined that algorithm over the years and now we have achieved a very high level of accuracy that, based on our data, is showing us that the accuracy’s actually higher than having your own manual QA team. And so you get better results, without actually hiring an AMI, either onshore or offshore. You can actually run your test on demand – typically, you’ll get results in 30 minutes or so. Right? And it’s fully integrated into your CI/CD cycle. And the best part is you can do all these things and achieve all these benefits without having to hire QEs to write automated scripts and having to maintain it, and so on, so forth.

    Shimel: Excellent. So, Derek, I get the outsource. I get the army of people doing it. But, on the back end, are you doing some automated testing as well?

    Choy: Yes, we are. And so what we’re also doing is we’re developing additional AI algorithms to actually learn from these human executions. So what we do is we have lots of human executions that are happening as we speak. In our environment, we have 80 million, 90 millions of tests that have already conducted on our platform, so what we do is we actually do machine learning through these data and learn from previous executions and develop algorithms so that, instead of actually having to send it to a human tester, we can actually achieve it with a robot.

    Very similar to the approach that Uber is taking. Today, human drivers are driving people around, right? In the back end, they’re developing these self-driving cars so that, in the future, we don’t really need a human drivers anymore. Very, very similar approach, from a QA standpoint. Today, we’re sending testers, but then, in the future, we’ll have these robots that will execute these tests based on what they have learned from these human testers.

    And tomorrow is already here for us today because we’re already doing that and a number of our customers are already using these automated AI algorithms. So they just need to write their test cases in plain English and they’ll see the tests executed by robots automatically, without having to worry about building automations or anything like that. So that’s kind of our approach to solve the QA problem.

    Shimel: So Rainforest, the Uber of QA.

    Choy: I don’t know that marketing will approve that line, but –

    Shimel: No, I don’t think _____ _____ –

    Choy: – personally, but, yes. Yes.

    Shimel: It does remind me – you know, when – you’re out in San Francisco, we’ve all been in venture-backed world.

    Choy: That’s right.

    Shimel: There was a period there where every pitch was “We wanna be the Uber of,” right?

    Choy: Yeah. Exactly.

    Shimel: Uber of this or the Uber of that and _____ _____ to be disruption, or crowdsource in this case, but fascinating take on solving an age-old problem.

    Choy: Mm-hmm. Exactly.

    Shimel: Interesting to see. Just – Rainforest is, what, about two-and-a-half years, three years old now?

    Choy: Yeah, it’s just a little bit longer. We’ve been – our total existence, probably about six, seven years. We’ve kinda pivoted a little bit at the beginning, so our current product is about three to four years old.

    Shimel: That’s when I think I first became aware of it.

    Choy: That’s right.

    Shimel: And, look, testing and continuous testing is such a – I mean, it’s a hot area. There’s a lot of different solutions vying in the market, but this one is really kinda unique, so it’ll be interesting to watch how it happens.

    Choy: Yeah.

    Shimel: Derek, as I promised you before we started, the time goes really fast here. We’re way out of time, but, hey, man, I wanna thank you for being a guest on DevOps Chat. And maybe we’ll catch up with you again in the new year and find out how things are going.

    Choy: That will be awesome. Well, thank you, Alan, and have a wonderful holiday to you and everybody listening. And, hopefully, I’ll talk to you again soon.

    Shimel: Absolutely. Derek Choy, CIO still, not CEO, of Rainforest. Thanks for being our guest on DevOps Chat today. Have a great holiday and thanks very much.

    Choy: Thank you. Buh-bye.

    Shimel: Buh-bye. This is Alan Shimel for devopsy.kinsta.cloud and you’ve just listened to another DevOps Chat.

    — Alan Shimel

  • DevOps Chat: Identity Management with ForgeRock’s Peter Barker

    DevOps Chat: Identity Management with ForgeRock’s Peter Barker

    Two megatrends for 2019 and beyond is scale and automation. The identity management space is a perfect example. Considering all of the IP-enabled devices (machines) coming online and the billions of people and their identities, managing these billions and billions takes systems that will redefine scale and, almost by definition, have to be automated.

    Enter ForgeRock. The company is a leader in identity management for both consumer brands, IoT devices and more. In this DevOps Chat, we speak with Peter Barker, chief product officer, about the challenges to scaling at this level and how important identity management is.

    As usual, the streaming audio 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. Got a nice chat lined up for today. I’m joined by Peter Barker, who’s the chief product officer at ForgeRock. Peter, welcome to DevOps Chat.

    Peter Barker: Hey, Alan, good to be here.

    Shimel: Thank you. Thank you for joining with us. So, Peter, let’s jump right into things ’cause time’s limited. ForgeRock is a company that I think a lot of people have probably heard of, but I don’t know if people are solid, you know, as a rock, on what exactly they do, so why don’t we start with that? Give us just a quick kind of “Who’s ForgeRock?”

    Barker: Yeah, so ForgeRock is recognized as the most visionary and market-leading identity and access management platform, and we serve the largest logos on the planet, solving a variety of use cases. We provide simple and comprehensive solutions for brands to serve their customers, with identity and access, to deepen their relationships with those customers. And as well to provide access management and identity solutions for employee and partner use cases as well, to really allow better productivity and connectivity in the employee base.

    Shimel: Excellent. And, Peter, I always like to ask my guest to give our audience a sense of your own personal journey. How did you come to be chief product office at ForgeRock?

    Barker: Yeah, it’s a great question and I think back on this journey I’ve been on for the last 25-plus years of my career. I originally started out on the customer side of the house in IT, doing systems development, application development for Kinko’s and FedEx, who acquired Kinko’s, but, later, the last 15 years, I’ve been in product companies, focused on enterprise software and security solutions. And that spanned mobile and mobile security, with good technology. I was at Oracle as well, running their identity and security business for a few years. And then, most recently, now with ForgeRock, over the last year, as their chief product officer.

    Shimel: Excellent. So, Peter, you spoke a little bit about ForgeRock’s mission and what’s going on, but one of the things that – I mean, it’s almost intimidating when we think about it. It’s just the sheer scale. You know, we look at ForgeRock and, I mean, you guys are doing everything from managing and working on identities of consumers coming to large consumer brand websites and applications, through to IoT devices. I mean, not to get all _____ and honest, but it’s billions and billions, right? I mean, it almost seems like an impossible job. How do you chunk that up? How do you go Agile on it? How do we manage it?

    Barker: Yeah, no, it’s – yeah, first of all, you’re absolutely correct. The world of identity, digital identity, is just exploding. It used to be, in the early days of this industry, it was around modeling identities of your employees and providing access and having governance around that access, but, as the world has shifted to consumer and business transformation around digital and having to know your customer across your digital channels, then scale started to explode in that direction because you have millions of consumers versus just thousands of employees.

    And now, in the world of things, where you have this entirely new economy that’s emerging, where things are interacting with the world on your behalf or with you, whether it’s smart devices, smart cars, smart payments, smart everything and the gig economy, it means that identity systems have to model the identities of all of those objects that are interacting in this new world we find ourselves in. And that is causing a massive need for scale.

    And, at ForgeRock, it’s been a really rich heritage and history for us to provide massive scale in our products. And we are, today, already solving some of the most demanding use cases globally, around scale and serving customers in this new digital economy.

    Shimel: A hundred percent. So let’s try to – Peter, you probably – I mean, as part of your responsibilities at ForgeRock, you probably have some metrics to put around this. Can you volunteer a little bit without divulging any _____ _____ –

    Barker: Yeah, for sure. I mean, right now, some of our largest customers are already scaled into the hundreds of millions of consumers and associated devices with those people. We have use cases defined right now with a lot of these customers that are pushing north of the billion-user mark – we’re proving that out in our labs – but, as we know, to meet the demands of scale, it really requires a new approach to the software deployment and how software supports the scale needs and becoming much more elastic and on-demand, as well as horizontally scalable, because it’s the only way that really, truly will continue to serve this need, as it continues to grow.

    Shimel: Sure. You know, Peter, I had an interesting conversation this morning with a CEO founder of an Israeli-based startup around AI. And what he was saying is the kinds of scale issues that you’re tackling at ForgeRock, it’s almost too big for the human mind to wrap around. Right? I mean, let alone at the speed. I mean, humans just can’t operate at that speed to conquer that scale. We just – it’s almost as if you need to invent or implement some sort of AI, machine learning, whatever you wanna call it, intelligence, that allows you to operate at that scale. And is that something ForgeRock is kind of building in, do you think, or is it still –

    Barker: Yeah.

    Shimel: Go ahead.

    Barker: Yeah, definitely. And we have a framework in our product called “Intelligent Authentication,” and it’s designed exactly to do what you’re describing, which is enabling our customers to continue to not only meet the current needs of scale, but the customers, they want to make the authentication and authorization function of their architecture be much more adaptive, much smarter, much more dynamic, to a conditional and contextual world that may exist.

    And, for example, our customers think about security and fraud pretty interchangeably. And if you just think about the scale problem around fraudulent activity, so, if you look at these large brands with hundreds of millions of consumers who they’re trying to provide services to, of course, there’s always some element of fraud that goes along with being in that type of business. And so they have to put in some very complicated algorithms and logic and what have you to continuously be evaluating whether a transaction that’s attempting to happen is actually fraudulent or, on the other hand, maybe it’s something going on from a malicious actor perspective, who’s doing something around security or attempting to breach.

    And so this is causing the sophistication of the techniques being used to go after these problems to really continue to elevate. AI and ML is a big part of that. Being able to integrate multiple services, who are all providing these functions into, essentially, a fabric that is evaluating the risk that’s occurring, and being able to do that at massive scale is how our customers are looking at this and they’re demanding requirements around that.

    And our Intelligent Authentication framework in our product really enables that to happen. We have the scale in the core engine. We have the framework to allow our customers to create these very sophisticated approaches to dealing with these problems that they’re dealing with, out there in the Wild West of their businesses.

    Shimel: Sure. Excellent. So, Peter, it’s December. We’re starting to look towards next year and everybody and their mother-in-law has a prediction and an opinion about what this next year’s gonna hold for us. What do you – if you had to make your best guess and place a bet, what do you think the big story is for ForgeRock and the whole identity community, in the next year or short term? Let’s say 18 months.

    Barker: Yeah, so I’ll just cover a few things that I think inform my answer. First of all, there’s some very interesting challenges that our customers are facing, that apply broadly within the market. First is really a skills gap. So, a few years ago, I started tracking a stat around cybersecurity job openings and how many of those are going unfilled and how many are projected to stay unfilled in the future. And the most recent estimate is that, by 2021, 3-and-a-half million cybersecurity jobs are going to be unfilled.

    And, if you think about that, that’s just a massive challenge for enterprises who are gonna have to continue to deal with and advance their security programs and their security capabilities, when there is a labor shortage, in essence, in the market. And what that’s requiring is vendors to provide solutions that increasingly automate their security program and to provide the security solutions in a much more automated way, so that’s one big area.

    The other is obviously cloud. You know, the most recent prediction by Gartner is that 75 percent of organizations, by 2020, will be running in multi-cloud or hybrid cloud environment, so that just keeps on marching on and forward, as we go on in time. And then, finally, our customers continue to wrestle with security and ease, where that balance between consumer convenience and security is always – it’s very delicate and it’s something that our customers are always trying to find the right balance for. And so they’re increasingly looking for solutions that both increase security but also increase the convenience for consumers.

    And so what all of that is really driving, from a prediction standpoint, over the next 12, 18 months, is our customers, they have many of the features that they really need right now and today. What they’re looking for, increasingly, is solutions to solve those problems. And so we at ForgeRock continue to innovate and deliver new, powerful capability, like Intelligent Authentication, as I talked about earlier, but the big, new element of the equation that customers have been looking for is “How can they transform their software delivery model to much more DevOps? How do they transform their identity program to be much more multi-cloud and multi-cloud approach, where they can be protecting workloads no matter where they are? And how can they do that in an environment where they have less people, less skilled people available to do the job and to do it in a much more automated way?”

    So we, on November 30th, we released a big, new release of our software, Release 6.5, which really addresses these three key things that we’re seeing with our customers. With that release, we’re now able to allow customers to dramatically increase their productivity and their competitive advantage and reducing their cost by deploying our software in these new methodologies.

    We’ve begun surveying our customers and, right now, the consensus is that customers can save as much as 25 percent on their implementation cost of software just by adopting our next release, which is a dramatic improvement over what they’ve been seeing before. And this release allows them, by providing some very simple cloud installation packages, to rapidly deploy production-ready software into a multi-cloud environment, in minutes, supporting hundreds of millions of identities. And so we’re just really excited and customers have been receiving this release very well ’cause it’s solving so many of these challenges that I talked about.

    Shimel: Absolutely. Absolutely. Peter, I know ForgeRock recently came out with some new announcements around product and so forth. Why don’t you share with us a little bit?

    Barker: Yeah. So I think, just continuing on with what I mentioned just a moment ago on Release 6.5, what we’ve done to really support the new deployment model that we’re providing to our customers is we’re giving our customers turnkey, complete DevOps-capable software to run in multi-cloud environment. And we’re providing not just images for our customers, but we’re providing all of the artifacts necessary to really do this successfully.

    That includes – we’ve standardized in Kubernetes for orchestration. We provide our customers the Helm’s Charts. We provide our customers not only that, we provide the reference architecture. We provide the reference configuration for them. We also do performance benchmarking and not only do the performance benchmarking but give our customers the performance testing tools and methodologies so that they can integrate that into the DevOps pipeline as well.

    And, finally, we give our customers all of the cost profiles of these various cloud providers – AWS, Azure, Google Cloud, and Red Hat, OpenShift are the environments that we’re supporting with this release. We’re dramatically accelerating what it takes for a customer to deploy these platforms to support the mega-scale requirements that we talked about earlier on this call.

    And the other thing we announced is that we have now surpassed 50 strategic partners in our trust network partner ecosystem. And what this does is allows customers to rapidly integrate some very innovative solutions around strong authentication or biometrics or identity proofing or risk analysis or fraud detection into their programs very rapidly because we’ve already pre-integrated, pre-certified, and pre-tested that they’re gonna work for our customers. So a very exciting release for us, here at ForgeRock, and, again, just having some tremendous response from customers on it.

    Shimel: Very cool. Excellent. Excellent. So, Peter, I think, when we started, I mentioned to you, once we start talking shop, the time goes. And we’re about out of time already, but I’m gonna let you have the last word. So I think we’ve educated some people; we’ve opened some eyes; we’ve talked about sorta what the issues, challenges are; and I’m sure there’re people listening saying, “I’m dealing with this challenge. I need this solution.” What’s the takeaway here? What’s the one thing people, if they’re gonna learn one thing, what do they need to remember out of this?

    Barker: Yeah, I think the one thing I would really encourage the listeners to think about, when it comes to identity, is, for employee identity, that’s a space that’s been very well supported and served for a long time now. But what we’ve seen is, as enterprises and brands are transforming their businesses to digital, they’ve taken identity – some have had good forethought around identity and really have put the necessary identity platform in place to support their transformation, but many have just sorta run ahead on their digitization. And they’re starting to discover that the way in which they’re supporting their customers – the customer journeys, in their digital channels, is just not seamless, and it’s because they didn’t think about the identity challenges that they’d be facing.

    And so the takeaway I’d really encourage is I think almost all brands on the planet, at this point, are in some stage of journey around digitization, digital transformation, business transformation to the new economy. And really take a look strongly at the need to bring in an identity platform to really support that because, if you don’t, you’ll find quickly that you’ll be underserving your customer experiences and your customer journeys. And, in this new world, customers really vote with their feet in the digital world, in terms of brands that they’re doing business with. And so we highly encourage folks to take a look at this.

    Shimel: Excellent. Peter Barker, chief product officer, ForgeRock, thanks for being our guest on this episode of DevOps Chat. Continued success with ForgeRock and we’ll have to have you back on soon to check in on the progress, but, in the meantime, keep us safe out there.

    Barker: I look forward to it, Alan, and thanks for having me today.

    Shimel: All righty. This is Alan Shimel for devopsy.kinsta.cloud. You’ve just listened to another DevOps Chat. Have a great day, everyone.

    — Alan Shimel

  • DevOps Chat: AIOps and APM with Unravel’s Kunal Agarwal

    DevOps Chat: AIOps and APM with Unravel’s Kunal Agarwal

    Unravel is making a name in the AIOps, APM and big data markets. In this DevOps Chat, we speak with Unravel CEO Kunal Agarwal about what makes Unravel a must-have for its customers. We also take a sneak peek ahead to what the near and not so near future holds for big data, AIOps and the tech scene in general.

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

    Transcript

    Alan Shimel: Hey, everyone, this is Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. Today’s DevOps Chat features Kunal Agarwal, CEO of Unravel or Unravel Data. Kunal, welcome to DevOps Chat.

    Kunal Agarwal: Thank you, Alan. Thank you so much for having me here.

    Shimel: Excellent. It’s my pleasure to have you here. So, Kunal, let’s get right to it. “Unravel” is the name of the company, correct? Not “Unravel Data.”

    Agarwal: “Unravel,” yes.

    Shimel: But yet Unravel is about data to a certain degree. I don’t know if everyone in our audience is familiar with Unravel. Why don’t we start there?

    Agarwal: Sure. We are unraveling the mysteries of big data, Alan. That’s why the name of the company.

    Shimel: Excellent.

    Agarwal: Everybody’s jumping on to big data apps, and what I mean by that is you may be doing something with machine learning, artificial intelligence, IoT, even big-scale data warehousing. And there’s just so many problems that can happen, running these applications at scale, that people just have not seen before. And this is a problem because of all these new systems and technologies that are coming about, such as Spark, Kafka, Hadoop, Cassandra, HBase, many, many more. And the complexity’s all about “Hey, how do I figure out why’s my application not performing well or if it’s failing?” And it’s usually a multi-tenant environment that these big data applications run on, which means there may be hundreds of users, thousands of applications, that you are creating every day and running them.

    And figuring it all out and making sure that they run well is a black art, so there’s a lot of trial-and-error that goes on into fixing these problems, finding the root cause of these problems. And that’s what we are automating, meaning Unravel, after it’s installed in your big data cluster, will be constantly monitoring and managing everything. And if there is an issue, Unravel will be proactive about it, tell you why that issue happened, what caused it, and then even take a step further where it would resolve those issues for you so that you can spend time creating all these amazing big data applications, rather than focusing on fixing all these systems- and application-level errors.

    Shimel: Mm-hmm. So, you know, I mean, there’s a lot there that we’re gonna dive into, but before we do, Kunal, just give our audience – ’cause I always find this fascinating. People wanna know “How do I become a CEO? How does one get to be the CEO?” Give us a little insight into your own personal journey on how you’ve come to be CEO at Unravel.

    Agarwal: CEO is “chief everything officer,” when you first start off. You gotta sweep the floors and you gotta raise the funds and you’ve gotta grow a team. There’s so many things a CEO’s role requires to do, especially in a young company, as you’re growing it. Today, now that we’ve grown to about 75, 80 people in total, across 3 different countries – we actually have offices here in the United States, one in London, and one in India – my job is becoming more about recruiting, more about getting the team together.

    And I think that’s, personally, for me, if that is taken care of, the entire company just hums and does well. Everything else is secondary for me at this time, but I do spend a lot of time doing marketing and sales and finance and product. So it really depends on the day, Alan, of what my job requires me to do.

    Shimel: Amen. You know, I’ve founded or cofounded three or four companies myself and even just running MediaOps, which is devopsy.kinsta.cloud and Security Boulevard, you are chief cook and bottle washer when you’re – you’re chief everything officer, as you said.

    Agarwal: Right.

    Shimel: You know, looking in your background, you’re a double-major graduate – electrical engineering, computer science master’s degree from Duke. I mean, you’re well positioned to be a CEO, people would say, looking at the background, but it’s – you know, you never know what’s coming out next as the CEO. If I had to ask you, Kunal, what’s kind of been the biggest surprise or biggest kind of curveball that you’ve seen in your time at Unravel that you think, “Geez, I didn’t think I’d be doing this or I didn’t think this was part of the job,” what would you say?

    Agarwal: Alan, actually, going to school and getting all those double-degrees does not help you at all becoming CEO.

    Shimel: You get it. I mean, you’re talking to someone who went to law school. I know all about it.

    Agarwal: Right?

    Shimel: Yeah.

    Agarwal: I wish there was a school for CEO, but you know what? The only school for being CEO and leading a company is actually leading the company because there’s so many things that you learn along the way. One thing, because we deal in enterprise software, there’s so many complexities to making a deal happen with a big company.

    Shimel: Mm-hmm.

    Agarwal: And I think that was one of the things that took me a while to grasp and make sure that we’re doing it right. And I mean all the boring stuff, like the contractual paperwork, all the legalities, going through info-sec requirements. All the operational stuff around making a deal happen. You know, when you’re in college and you’re starting to think about a startup, you think about the cool products you’ll make. You’ll think about the impact your product will have in the market and how so easily everybody will flock and come to you and get your product. [Chuckles] But it’s not that simple.

    Shimel: I wish it was.

    Agarwal: and it takes 9 months to 12 months to close some of these deals, so I think, more than the “surprise” factor, preparing yourself and making sure that you can drive efficiencies in all these different processes. I think that’s been one of the key challenges for us.

    Shimel: Absolutely. Absolutely. So, Kunal, if I’m a Silicon Valley VC, I’m looking at a company like Unravel, man, you’re playing in all the right places. Big data is certainly such a huge – I think, when we talk about things like machine learning and AIOps, really, they’re almost the children of big data – you couldn’t have those things without the big data, first of all – so you’re in the right place, obviously. The right time. This is a very happening kind of space. What is Unravel doing that is so – what’s the special sauce? What’s unique about it?

    Agarwal: Yeah, Alan. So, when we created this company – and by “we,” I mean myself and my cofounder, Dr. Shivnath Babu, who’s actually a professor of computer science at Duke University – we both met at Duke – and the problem we were trying to resolve is one of the most fundamental but also probably the most complex and challenging problem to solve, which is “How does one ensure that all of these big data technologies actually work and deliver on their promise?” And, you know, our approach to the problem was always “Hey, there will be a shortage of experts in the market. Even if there are experts, these problems will be requiring a machine to solve them on time and efficiently.”

    So we took the long path of actually creating not just a monitoring tool but a AIOps tool, if you may, which can decipher the problem, connect the dots, and resolve it for you. So it actually took us about three-and-a-half years to build this product or at least the first version of this product. And we moved west to start working with some companies – I lived in New York; he was in North Carolina – and we gave up our cushy jobs, moved to Silicon Valley, because you wanted to work with companies who were using big data tech at scale.

    And some of these companies, we still have advisors in, from Zynga, Rocket Fuel, Twitter, LinkedIn, and they really helped us understand the day-to-day issues that come up when you’re running these technologies at scale. And we took a lot of those learnings into our first product. So we were always about solving a core need that teams in big data tech would definitely need. And, you know, they always say, “Hindsight is 20/20,” right?

    Shimel: Yeah.

    Agarwal: But we always put a big bet that, “Hey, these technologies – Hadoop, Spark, Kafka, et cetera – will become mainstream and companies will start using this a lot more.” So what LinkedIn was doing five years ago, the biggest banks would start doing it now, and that’s where we are in the journey today.

    Shimel: Absolutely. And, you know, it’s funny, full circle, talking about that journey and what you’re doing. That’s how you become a CEO. It’s about being willing to take the risk, giving up those cushy jobs. Right? To do something that you really believe in. And I think that’s what separates CEOs from people who kinda look and say, “Boy, I’d like to do that,” but they don’t actually do it.

    Let’s talk about the market. We’re coming to the end of the year. You’re participating in our Predict 2019 panel, which will be December 18th event. You’re gonna be on the AIOps panel, looking ahead. Why don’t you give us a sneak peek? What’s kind of your take on what 2019 holds for AIOps and big data and so forth, Kunal?

    Agarwal: Well, yeah, Alan. So AIOps is an evolution of IT Ops or APM or DevOps, where you’re using machine learning to, again, understand all of the data – and this could be monitoring data, instrumentation data – that all these systems and applications are generating to draw insights from.

    Now, funnily enough, this is what our customers do with their data set, right? So with some of the biggest banks, some of the biggest insurance companies, some of the biggest health care companies, all Fortune 500. And our methodology of going about monitoring for big data stack was always the same, which is “Why aren’t we using big data technology on our data set, which is machine-generated data, to glean those insights and drive some prediction and actually make things simpler and more accurate?”

    So AIOps is also one of the use cases of artificial intelligence and machine learning. Now, just as I’ve said the industry’s evolving, what we predict to see is the evolution of AIOps, so Unravel, for example, is already on one of the end-of-the-spectrum places, where we actually make decision on behalf of the operations and the development teams, whether it is re-evaluating an application, whether it is making sure that your SLAs for your applications are being met, by moving low-priority jobs to a sub-optimized queue and high-priority jobs to a priority queue or killing bad applications in the cluster, all on your behalf, to make it more proactive.

    But what I predict is there’s gonna be an evolution in just the incumbent APM companies as well, where it’s not just about giving people a monitoring screen or even a native monitoring screen and saying, “Hey, check out all the information we know about an application,” but then I leave it up to you to decide and understand what’s amiss, what’s wrong, and how do you fix it. But I feel we’re already now in the correlation and the insights phase, which is now I can start to connect the dots, with these new software technologies that are out there. But, in 2019, we’ll start to also see some of these companies take the leap to be able to do automated root cause analysis, as well as guided remedies or automatic solutions, to get out of these problems as well.

    This industry’s evolving at a very fast pace, so I’m super excited. And it’s all about making sure that some of the biggest applications in the world, which millions of people actually rely on, all work like a well-oiled machine. And it’s all about guaranteeing reliability, which, at the end of the day, improves confidence of the customers using those products, which further fuels more innovation and more growth. So it’s an amazing cycle and AIOps is gonna be a very, very key part of it.

    Shimel: No doubt about it. No doubt about it. You know, in many ways, I look back on 30 years in IT and it really is a golden time to be alive, if you’re a developer or ops person or just in IT in general. Right? There’s the possibilities and the tools, and what’s in front of you is so exhilarating, right? I mean, I think back, if I was 20 years old now, 22 years old, coming into the –

    Agarwal: So you mean like 10 years ago, Alan?

    Shimel: Yeah, something like that. About 10.

    Agarwal: Okay.

    Shimel: About 10. And, I mean, just unlimited opportunity. I mean, that’s kinda almost the way I look at it. And, of course, it’s companies like Unravel, right, that are kinda letting these opportunities take shape and packaging them for people to run with. So great stuff. Specifically, Unravel – we only have a couple moments here left, but – so, Kunal, anything on the horizon with Unravel you wanna share with our audience?

    Agarwal: Yeah, Alan, absolutely. So, even in big data technologies, there’s so many to cover. We started our life off supporting Spark, Kafka, the entire Hadoop stack, some NoSQL systems, like HBase and Cassandra, and some newer NPP platforms. In 2019, we’re gonna further expand some of those technologies and systems that we cover, especially as we start to see more and more big data workloads move to the cloud.

    We’re also seeing a lot of our companies demanding a hybrid real estate management from the cliched “one pane of glass,” that “Can I see everything that’s in my big data environment, whether that’s on premise and on the cloud, together?” So Unravel is launching that support as well.

    And, last but not least, we are also creating a solution, from our product, which is directed towards helping companies move from their on-premise environments to cloud environment. So actually using Unravel as a migration project management tool, to help you assess, migrate, and then validate your migration. And, on the assess side, figuring out “What system should I get? Which instance type is best for my workloads? How can I keep under cost? What is the cost of running my big data workloads on the cloud?” to then validating and making sure that your SLAs are met, that you’re under cost and under time, and everything is flowing like a well-oiled machine.

    The way we look at it, Alan, again, the way to look at our road map and anything on the horizon is we are here to help our customers in the entire journey of big data tech, so, whatever they’re deploying today and they wanna use tomorrow, Unravel will be supporting that. And this is a natural evolution where companies are going from trying something out to getting something in production, first starting on premise and then going to the cloud, and those are all the shifts and transition points that we wanna hold the hands of the customers that we work with.

    Shimel: Excellent. Excellent. Well, Kunal, thanks for spending a few moments with us. As I told you, the time goes quickly.

    Agarwal: Yeah.

    Shimel: We’re way over time, but it’s okay. Hopefully, people have stayed on till now to listen. I wanna wish you lots of continued success with Unravel. We’ll be checking in on it. Again, a reminder: Kunal will be on our December 18th Predict 2019 virtual event and Kunal will be participating in the CEO panel, taking a look ahead at AIOps in 2019. So join us. You can register for that at predict2019.com.

    Agarwal: Thanks, Alan.

    Shimel: Thank you. Hello to all of our friends at Unravel. And that’s gonna make a wrap on this episode of DevOps Chat, everyone. This is Alan Shimel for DevOps Chat, devopsy.kinsta.cloud. Have a great day.

    — Alan Shimel

  • DevOps Chat: A New Take on Application Security with Portshift

    DevOps Chat: A New Take on Application Security with Portshift

    Portshift brings a new identity-based application security model from code to runtime. Cloud or on-prem, Portshift works. In this DevOps Chat we speak with CEO Ran Ilany and VP Business Ops Eran Grabiner about what is unique to the Portshift solution and why you should consider it for your own application security, especially for your DevOps teams.

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

    Transcript

    Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, Security Boulevard, and you’re listening to another DevOps Chat. In today’s DevOps Chat, we actually have a new company to introduce to our audience anyway and that company is Portshift. And I’m joined by two of the key folks at Portshift. We have Eran Grabiner, who’s VP of Business Ops, and Ran Ilany or Ilani – I mispronounce your name, I apologize – Ran Ilany, CEO and –

    Ran Ilany: Ilany.

    Shimel: Ilany, great. CEO and cofounder. Gentlemen, welcome.

    Ilany: Thank you.

    Eran Grabiner: Thank you, Alan. Thank you for having us.

    Shimel: Oh, my pleasure. So, Ran, you’re the CEO. I’m gonna let you kick off. A lot of people in our audience may not be familiar with Portshift. Fundamentally, what’s Portshift about?

    Ilany: So, fundamentally, Portshift is trying to solve – solving a problem which is a hard problem that wasn’t solved in the last couple of decades and was very much introduced as a solution, during early ’90s, with the firewalls technology. And now we’re moving to the cloud infrastructure, we see that the same firewalls that were used 20 years ago are not longer, I would say, valid, in order to run a application. And, essentially, there are, I would say, two to three reason that to that and I will let Eran elaborate about the reason of why.

    Grabiner: Yeah. Sure, so, you know, Alan, when speaking about the cloud, there are two things that fundamentally changed everything for IT folks and DevOps engineers. The first thing: you don’t own the infrastructure, so the level of network and infrastructure, you simply don’t control it.

    And, secondly, a lot of change through time in the world of compute. If – I don’t know – ten years ago, we had the monolithic application sit down in our data centers in the office, right now, when we’re in the cloud, our application is broken into many different pieces, many different _____ services. Everything is much more automated. Software is being updated on an hourly basis. And developers and engineers, they have much more power to do things with their software. So, because those two reasons that the old tools that we had, in order to orchestrate security in our network, simply doesn’t work.

    Ilany: Yeah, and –

    Shimel: Agreed. Ran?

    Ilany: And just to add to those points, there are two layers that essentially impose the challenge. The first one is the fact that, if you’d really like to, I mean, to use firewalls within the cloud environment, you really need to understand the network infrastructure. To understand the network infrastructure, you need to understand what is the application is doing out there in the cloud, and, in order to do this, you need to configure those IPs and those ports, which actually create a very, very close binding to the actual network infrastructure, for one hand.

    And, for the other hand, you obviously need to have this type of discussion between the security folks to the actual operation folks, which actually creates a lot of bureaucracy that was possibly valid, you know, 15 years ago in the data center, but, now we’re moving to the cloud and everything is automated with CI/CD, you need something else. Okay? You need to break the paradigm, at least from being tied to the actual network, from one hand, and, from the other hand, you need to make things to be much more fast and much more intertwined with the development life cycle. Which is essentially the primary objective that Portshift’s have put in as a target and as a solution.

    Shimel: Absolutely. So, guys – and, look, I’ve been in this a while myself. You know, when we first started with the next-gen firewall, right, and that was sort of the premise, is that we were gonna get the developers involved and application-aware firewalls and all that, but it didn’t translate to the cloud. You’re right. But, Ran, I’m interested, as the CEO/cofounder, so this is obviously a problem, right? How do we do this in a cloud environment, at cloud scale, at cloud speed and all of that?

    Ilany: Yeah.

    Shimel: How did this affect you personally or in your kind of journey to where you’ve got here today, where you recognized and said, “Hey, we gotta do something about this, that this is a problem looking for a solution here”?

    Ilany: Yeah. So, essentially, we understand that there is a problem that requires a solution, you know, while talking with customers. I mean, those are usually the No. 1 –

    Shimel: That’s the way –

    Ilany: Yeah, and –

    Shimel: – the best way to do it.

    Ilany: And we saw that there are – and we call it “the impossible tradeoff,” okay? They either need to be very, very fast – they want to run very, very fast in the cloud, from one hand, but then they have a security constraint. They really want to control, I mean, the communication between the application and where the application should run. And there, there is the where to be in the curve of being Agile and being secure every organization has to find itself, in this type of curve, and to find what is the level of security that it wants to enforce or impose.

    And this is, I would say, what led us to think of changing the paradigm or breaking the paradigm or making a solution that the customer will not have to make this type of tradeoff or make this type of decision and target to be both fast and Agile but also secure from the other way around _____ _____.

    Grabiner: And we basically looked at what’s going on in the cloud from the DevOps perspective and we saw that many things changed to be better, with automation, with CI/CD tools, and we ask ourselves why, with security, this is not happening? Why the workstation or the tools that the DevOps engineer is now using to deploy software, why security tools can’t look the same? Why they can’t be part of the same idea and the same work cycles? And this is what got us to think that we need to, in a sense, push security to the left, shift left, and take it to be something that is part of the DevOps life cycle and part of the CI/CD infrastructure of the organization.

    Shimel: Sure. So, guys, obviously – so we call this “DevSecOps,” right? Is part of it.

    Grabiner: Yeah, right. Yeah.

    Shimel: It’s something that I – you know, between DevSecOps Days and events we put on at RSA and so forth, it’s something we’re very involved in. My question for you then is, so it sounds like Portshift is really aimed at helping DevOps engineers, DevOps teams, developers, get more involved in the security or in the cloud firewall kind of paradigm for security. Is Portshift aimed then at the security team, the developer team, or both?

    Ilany: So I think – well, obviously, the focus of Portshift is not to try to educate Dev and DevOps to be security folks – this is obviously not the target – but think the good news is the fact that Dev and DevOps have the knowledge, okay? And the knowledge is where, essentially, they know their intention. They know where, essentially, they want to deploy the application and, essentially, who should talk to who, in terms of application containers or processors, depending, obviously, on your infrastructure. And this is, I would say, the basic assumption that the whole concept of Portshift is based on, okay? We actually take this type of knowledge, okay? We create from this knowledge or this attributes, we create the actual identity of the application, which is essentially a signed infrastructure or crypto-signature of those attributes. And we use those intentions that are described by DevOps, in their own natural language – I mean, a recipe in Cookbooks with, you know, _____

    Shimel: A Chef or a Puppet.

    Ilany: Yeah, of course. Or Ansible or Kubernetes, obviously, infrastructure. We use this type of information while creating the crypto-identity, in order to deploy those application or signed application in the cloud and enforce the actual security that we describe formally. And the whole point is, essentially, that those folks don’t have to change the way that they work, okay? The security is more intertwined with their own system, the CI/CD system.

    We leverage this type of information in order to create the security and the actual security folks will actually define guardrails. Okay? They will define operational environment in high level – the production environment, the testing environment, or the preproduction environment – where the actual application should run within. And the security will be sort of enforced and be visible automatically, without the pingpong, okay, or without the never-ending discussion between the security and the DevOps folks, which we all know it’s part of the problem, okay? It’s part of the challenge of securing the application in the cloud prams.

    Shimel: Absolutely. So I guess this – well, let me back up a sec. I just wanna make sure. Portshift, I know you work with AWS, obviously.

    Ilany: Mm-hmm.

    Shimel: Microsoft Azure, Google Cloud as well?

    Grabiner: Yeah.

    Ilany: Mm-hmm.

    Grabiner: We’re totally agnostic to the infrastructure.

    Shimel: Okay. And what – I’m curious ’cause this is something that we going back and forth on, back and forth on. The attitude of the developers, the DevOps teams. I mean, you never meet a developer who says, “Oh, I’d wanna make an insecure application or I want my stuff to be hacked,” right?

    Grabiner: No.

    Ilany: Mm-hmm.

    Shimel: And you’re right – they’re not security people, but they’re security-aware and they need to be security-responsible.

    Ilany: Mm-hmm.

    Shimel: Right? On the other hand, look, we all know security people who’ve said, “The developers will do what I tell them,” right? “And they’ll be secure when I tell them they’re secure.” But that doesn’t work either in this new world. Right? It’s gotta be together. So you talk about integrating with the CI/CD process. Give us an idea of how you work within the CI/CD process.

    Grabiner: Got it. Yeah, so, basically, what we’re doing, we are asking the developers, the DevOps engineers, to use a very simple set of APIs, whenever they are using their infrastructure as a code or whatever the tools that they’re using, to send Portshift the relevant information that we need, in order to identify the piece of application that they’re deploying. This information can be technical information about the build, the version, the namespace of the application, and other attributes, that will allow us to rip up an identity that is unique, for each and every one of the pieces of the application. So this is the first part, where we learn your application logic, where we understand who should speak with who, and we know your business.

    Now, when we take this identity and we move into runtime, we see all the different pieces and, first of all, we see them for sure. We know because we find them during CI/CD. If something didn’t go through CI/CD, if a developer deployed a container without asking, if, god forbid, an attacker is moving in the network, we would immediately see that because we signed the components during CI/CD. And we can see them. We can see them communicate. And now security folks and also DevOps engineers, they can easily define their agenda and their rules, based on their application logic.

    A simple example: if they want their billing app to speak with their financial database, something that can take days just to config because your application is broken into different pieces and you need to config security groups and make sure you did it right and so on, with Portshift, you would simply write this sentence. You would just say, in English, “I want my billing application to speak with financial database,” and that’s it. Everything will work from then on.

    Shimel: So it sounds magical, right?

    Grabiner: Yeah.

    Shimel: You know, I’m too old to believe in magic. What’s going on behind the scenes, though? When I write that, what’s actually happening behind the scenes?

    Ilany: Yeah. So, essentially, what happens behind the scenes is we have two phases for this identity bit generation. As eloquently mentioned by Eran, the first phase is done by offline, okay? We take this type of attributes, which are sort of the intention, okay, in the CI/CD. We grab those as attributes of the identity and this is essentially the description of the application – wherever the application should run, who should it talk to within the actual environment that we’re targeting to.

    And then we have the correlation with the runtime properties. Every process, every containers have runtime characteristics – for instance, the process ID, the UID, memory footprint, and stuff like that – so we combine all together the offline attribute that was created with the ICD, with runtime attribute. We sign them all together.

    And this essentially creates one unique entity that is running out there and this is what we’re using in order to enforce. We are transferring this type of identity in the traffic stream so that a conversation between two different application is, first and foremost, authenticated, okay, and only then authorized. Okay? This is what we call the classical “zero-trust” approach, okay? We’re not trusting the IP; we’re trusting the identity on the counterpart.

    And this brings another where we talked, I believe, a little bit about the operational benefits and the fact that it’s very Agile and useful for the Dev and DevOps and the security collaboration. But there is another very important advantage and it’s the fact that, now that we are not talking about an attack surface which are segments, network segments, we are talking about type of access. Okay? So, if an attacker, for instance, get into one of my workloads or one of my application, we are not losing the whole segment, okay? We are losing a single part.

    And now we have, I would say, less – we’re much less concerned from the extent that we are exposed, okay, because we are talking about only point-to-point access permitted. They’re not network segments, which are open and, from the attacker perspective, it’s like a dream come true. If I find a flat network and I get into your flat network in some miraculous way, then I can get into every resource or application that is out there.

    Shimel: A good target.

    Ilany: Yeah. And this is, essentially, the basic concept of the security perspective of identity-based access control between different applications.

    Shimel: Sure. Guys, it sounds fascinating. As I mentioned to you when we started, the time goes very quickly. We’re kind of at the end of our time.

    Grabiner: Yeah.

    Shimel: I apologize, but maybe we can continue the conversation. For people who are interested, Portshift, you can get more information at portshift.io. Correct?

    Ilany: Right.

    Grabiner: That is correct.

    Shimel: And you guys will be at AWS Reinvent, though –

    Grabiner: Correct.

    Shimel: – _____ _____ after. Will you be at RSA conference?

    Grabiner: Yes. We will also be presenting there, at a startup venue.

    Shimel: Oh, the Launchpad or the Sandbox?

    Grabiner: The – I think it’s called – I think it’s the Launchpad. Yeah, it’s where all the early-stage companies are. Yeah.

    Shimel: Yep. Sandbox – that might be the Innovation Sandbox. Launchpad is more for ideas.

    Grabiner: Oh, yeah.

    Shimel: I think you fit more in – yeah, we’re a big part of RSA, so, yeah, I just did a podcast with them about both of those, so little bit I know. Anyway – I’m sorry. Thank you very much for joining us and we will – if we don’t see you at AWS, we’ll see you then at RSA. Well, we’d like to probably hear more because this kinda fits right into our sweet spot. Ran, Eran, thank you for joining us on DevOps Chat today. Good luck with Portshift. This is Alan Shimel for devopsy.kinsta.cloud. Have a great day, everyone.

    — Alan Shimel

  • DevOps Chat: Container Security and Aqua 3.5 with Rani Osnat and Andy Feit

    DevOps Chat: Container Security and Aqua 3.5 with Rani Osnat and Andy Feit

    In just a little more than three years Aqua Security has set its mark in the container security space. With its major new release of Aqua 3.5, the company has again raised the bar with serverless and container encryption upgrades and feature sets.

    I sat down with the Aqua Enforcer himself, Rani Osnat, and “Boston” Andy Feit to discuss the details of this major release. Rani and Andy give us an inside peek.

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

    Transcript

    Alan Shimel: Hey everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. Today’s chat is a little bit about cybersecurity, container security, Kubernetes and a major new release coming out of our friends at Aqua, Aqua Security. I’m happy to be joined with the dynamic duo of marketing at Aqua, Andy Feit and Rani Osnat. Andy, Rani, welcome.

    Rani Osnat: Hi Alan, thank you.

    Andy Feit: Hi Alan, good to talk to you.

    Shimel: And just so people know, Andy, you’re joining us from Boston today. And Rani, you’re out in Israel. Is that correct?

    Feit: Yes. Yes. Today I am in _____ _____ [Crosstalk].

    Osnat: Right.

    Shimel: Modern technology. We have a worldwide panel. But guys, the big news is, Aqua just announced version 3.5 of their platform suite of tools. And you know, Aqua’s not a company that every single new time there’s a new release, and the DevOps mantra, you can’t get too excited about any one release. Right? Because there’s always a next one and a next one and a next one. But this is one to get excited about, huh?

    Feit: Absolutely.

    Osnat: We certainly think so.

    Shimel: So why should we be excited?

    Feit: Rani, you want to take that one?

    Osnat: Yeah, I’ll take this one. So, with every release we make, especially, and in the beginning of course everything’s new. But we’ve been in this space now for three years. Which is not a long time, but in this space it’s a very long time. And so now we’re at the point where we have a lot of large enterprise customers using our product. And we have a market that’s looking for innovation.

    And with every new release we try to balance these factors of, you know, offering something new that the market wants. But at the same time ensuring that our enterprise customers can make use of our platform, as they themselves grow their cloud native container implementations. So there is a maturity factor here as well as an innovation factor.

    And so on the innovation side, we’re introducing a few significant innovations. First and foremost, risk assessments for serverless functions. Which is a, you know, a kind of a sideways expansion for us into the serverless technology space, in addition to containers. Thinking that you know, what we see as, it’s basically the same teams and the same benefits that are gotten from containers people expect to get from serverless, it’s just another means to get the same end.

    And so we want to provide our customers with all the controls they need to address any challenges they have around securing those technologies. And it doesn’t matter if they use containers or serverless or both, or any sort of mixed environment. We also added something that’s innovative in the space, which is container encryption, and we can talk about that.

    And then on the side of enterprise scalability and ease of use, we’ve added quite a significant I would say rearchitecting of how we manage both administrative controls on our platforms and what users can do in terms of access. As well as the policy engine to make it a lot more scalable for multicloud, multiteam, multiapplication use.

    Shimel: Got it. Got it. Andy, did Rani leave anything out you want to add?

    Feit: No, I mean, those are the big pieces that are in the release. As he said. I mean, it’s very much being driven by our customer base and where they’re headed. And you know, in some aspects, it’s the technology elements. Like adding serverless. And in other aspects, it’s really about living with the solution. You know, as our customers, we now have customers that are we think the largest container deployments in the enterprise.

    We have some very large users and span of different industries. As they look to roll out, they’re finding they have multiple teams working on these projects. And they need to implement different levels of security. And in many cases, they’re implementing that on different technology stacks. And some are using containers, some are using serverless environments.

    And they may be using even different underlying providers of some of the infrastructure. Whether that’s tools for development or the cloud provider itself. And so we’re really, we’re becoming very heterogeneous in terms of what we need to support. And for our customers who, on the security side, are trying to look at that whole context and manage that whole context and have consistent policies, all our consistent reporting across all of them, and not be monitoring 17 different dashboards. It’s important that it be easy to do, to be able to see that whole network of activity. And that’s really what a lot of this release is about.

    Shimel: So guys, one of the things that you mentioned, both of you actually mentioned, was the serverless piece. And this is something that we are, we’re hearing a lot about from our readers and from people we speak to. You know, how quickly, and we live in crazy times, right? So the whole container revolution, if you backed up on hypervisors. And now, how quickly serverless is you know, gaining a foothold and people are building around that type of infrastructure.

    Osnat: Right.

    Shimel: Let’s, just baseline, what are some of the security challenges that you guys are seeing around this?

    Osnat: Right. So I’ll preamble that, you know, just add one more thing. There’s, you know serverless has been around almost as long as containers have, in terms of the, you know, its current incarnation of the use in the cloud. But, the use cases is quite different. And while it is gaining traction, the use cases are much more limited than containers. There’s a whole kind of religious war, you know, between the proponents of containers and the proponents of serverless. Personally I don’t believe it’s a zero sum game. I think that both are going to end up being used, and both are going to end up being used in hybrid architectures.

    Shimel: Yeah, I don’t think it’s either or.

    Osnat: Yeah, I know, but some people would like you to think it is. I don’t think it is. I think it’s both. And so we, but there are some fundamental differences between containers and serverless when it comes to security. First of all, most of the serverless workloads that happen today are cloud based and specific to a cloud provider, right? Mostly Amazon, because Amazon is the larger cloud provider in general, as well as in serverless specifically with Lambda.

    But basically you run those functions and it’s quite cloud specific. That’s one area of difference. The other is of course that you know, these are very small single-function entities that can run for a fraction of a second. So when we talk about run time security for serverless, for example, there is a lot less to do there than you have with containers.

    Containers are, there are applications that can run, they could run for a minute but they often run for a lot longer than that. With something that runs for a split of a second, there is really only so much you can do when it’s already running. So a lot of the stuff you need to do is before it ever runs. You want to make sure that what you’re running is actually something that is secure, that passed your policy, and that you know about, right?

    So when you look at the challenges, one of those is actually discovery. What functions do you have in your inventory, and what are you using them for? The second is ensuring that what’s in them is secure and not vulnerable, configured properly. And that also includes permissions. So, when you define for example a Lambda function to run on AWS, there is a set of permissions you can give it.

    And depending on how you configure it, this can be very liberal or not. And of course you want it to be less, the least liberal you can. So as not to allow it to do anything outside the scope of what it’s supposed to be doing. So right now we’re primarily concerned, and that’s also where our customers are, with preventive controls. Basically ensuring that you are, that when you run something you actually know what it is. You know that you’ve approved it. And you can run it safely. That’s the first step in what we think is the right approach to securing serverless functions.

    Shimel: Fair enough, fair enough. And back to what you said kind of right at the get go with the either or thing. It was the same arguments about, would container replace hypervisor type of thing. And I think what we see is the majority of people want containers on hypervisor.

    Osnat: That’s true. It’s –

    Feit: Yeah, and I would also add that the data centers with lots of VMware and hyper-v haven’t gone away yet either. And they won’t. They probably will never entirely go away. New development today is cloud native development. Most of your mobile customer facing development.

    It makes sense to do that in the cloud and as long as you’re doing new development, why not do it on the latest and greatest. But, and the flexibility that you get from doing something on containers or serverless or a hybrid approach of those, makes it a lot smoother, easier, scalable. You get all these wonderful benefits. But we don’t see people going in wholesale and saying, I must clean out this data center now. So I think that –

    Shimel: _____ [Crosstalk] throw out the baby with the bathwater. And people –

    Feit: Yeah.

    Osnat: Yeah. So I think that’s one thing that we did. The other, I think very interesting and innovative feature that we’re announcing is container encryption. And I want to explain the use case. So we work with, you know, we work with many organizations. For example, we work, some of our customers are ISVs, who create software for customers to use.

    And that software is proprietary IP that they’ve developed and invested in. And they often want to make sure for those reasons as well as for reasons of governance, to make sure only the latest stuff is being used, et cetera, that they have some control over where it’s running and who’s using it. And so one of the things we provide here is an ability to encrypt, you basically encrypt the container image when it’s built.

    And then in order to run it, you need to decrypt all its contents, so there’s basically a key that the customer will have, the end user will have. And that will decrypt the image as it’s running. And if you don’t have that key, the image will not run. So the container itself once it’s running is not encrypted. But up till that point, it’s encrypted and you have to decrypt it in order to run it. And then of course this prevents the sort of, someone reusing or forwarding your software and you can imagine various use cases except the ISV one where companies would want this sort of deep security control over their containers.

    Shimel: Sure. Sure. And I think it’s just the, you know it’s funny, Rani. I think you said right in the beginning that over the last three years, you know, the progress that Aqua has made, and the progress the whole industry has made in securing their containers. Like everything that’s come before it, right, with each new release, with each light bulb, _____ security we see like more polish being applied.

    So, to me this idea of container encryption is you know, maybe first we have to concentrate on just getting the containers to work in a somewhat secure manner. But now we can start thinking about next level, next, you know, how do we turn it up a notch? Things like container _____. What’s the word I’m thinking. Like the standard, the, you know, the container encryption becomes ubiquitous over time?

    Osnat: I don’t know if it will become ubiquitous. I mean, certainly today you have a lot of encryption happening with TLS and all the stuff, all the pipes that handle containers. But as for the code itself, you know, even in highly regulated environments, I don’t necessarily see everyone encrypting everything. But certainly there are some crown jewels that you will want to encrypt.

    And it’s especially those areas where you’re not talking about reusable components, right? A lot of the containers that our customers use are reusable based on open source components, that’s fine. You don’t need to encrypt your NGINX webserver container, right? That’s, it’s identical to the same, other NGINX containers people use. But if you have proprietary stuff, that’s where you want to, or something that’s especially sensitive, whether it’s for any kind of security, confidentiality reasons, or for IP reasons. That’s when you would want to use something like that.

    But what you said actually, you know, brought me to the other topic I wanted to talk about, which is how the use of these technologies has matured with some of the more leading or pioneering companies that we work with, which is why we’ve invested in these scalability, manageability features. So I want to kind of explain what it looks like in a customer environment.

    So when we started out, and we started out kind of together with the market, the companies we were talking to, even larger companies, would typically have one or two teams that actually use containers, right? And so, you were talking about isolated projects. And that’s one level of doing things. But as we move forward, you know, now we have customers that have hundreds of development teams working with containers. They make thousands of images on a daily basis, because it’s all in a CI pipeline.

    And it all gets, it all goes into this large blender where it’s being spit out at the end, through Kubernetes or mesosphere, basically through an orchestrator to a variety of delivery platforms, whether it’s OnPrem or cloud or a mix of both. And if you look at it from an enterprise perspective, what they want is a way for them to apply security policies but maintain segregation of duties. Maintain compartmentalization and multitendency models that they have. So what we’ve done is really change both our administrative access model as well as the policy engine to enable that.

    So basically, you’re talking about people who use the Aqua platform. They have one installation of the Aqua platform. But they can basically distinguish between what different teams can see and do, what different roles can see and do, and how those policies apply.

    I’ll give an example. Let’s say that you have an application that is PCI DSS related. Handling credit card transactions. And so it has to comply with certain criteria that are requirements of the PCI DSS standard. You want, and you’re, but at the basis you’re using some basic elements like, I don’t know, MongoDB or MySQL. That same MySQL image that you apply a policy to within the PCI contexts will have a different policy than in non-PCI contexts. So having contextual policy is important.

    So that’s one area. The other area is who’s got access to what. So of course the people who handle the PCI application, the developers, the DevOps team, will need to handle certain aspects of this. But they don’t necessarily need to control the policy. That’s expected to be done by the security and compliance team. And the same token, they don’t need to access, or other teams don’t need to access that PCI application.

    So we’re talking about a matrix that really separates who’s got access to what and what they can do with that access, according to the specific application or geographic location, or what cloud it’s on or what registry it uses. All of these parameters. So you know, we’ve done this and we have, now both of these models combine to basically give you this matrix that is, that has you know, dozens of parameters on each facet to basically determine who’s got access to what, and who can do, whether it’s view access or edit access or only access to the logs, for example, for auditors and so forth. And so, it’s really a step up in terms of enabling these large deployments to work in an enterprise environments.

    Shimel: Absolutely. Good stuff. Guys, I want to _____ two other topics or areas I want you to hit on. One specific to 3.5, one specific to the market. And we’re coming up on the end of our time. So you know, we hear about immutable infrastructure, and you know one of the advantages of a container environment.

    So how do you deploy, you know, now you’ve got a bunch of customers. They want to upgrade to Aqua 3.5. Talk a little bit about how do you actually upgrade or run out this upgrade deployment. Is it a question of throw out what you have and just stand up new? Because Aqua itself is containerized. Or is, what, give us a little insight, nuts and bolts if people want to upgrade. Do you know what I’m saying.

    Osnat: Yeah. So our upgrade process is you know, it is simpler because we use containers, right? So there’s nothing to install. You simply run the new container. We do have backward compatibility with our previous versions, so when there’s an upgrade path for anyone using older versions of Aqua to this version.

    We actually, we’re the last, we don’t, I mean, we release software more often than what some of our customers would like to follow, in terms of their upgrade schedule, right? And we don’t force them to do that. But in the last version, the last major release, 3.2, we actually had a lot of customers move to that. So we’re in good shape from that respect.

    And they can of course upgrade to 3.5 when it becomes available at the end of the month. So there’s really no, there’s nothing in particular they need to do except of course, we always, always recommend doing it in a test environment first. And then once you see everything works, you move that to production.

    Shimel: Excellent. Excellent. So let me add –

    Feit: There’s one more thing now I was going to jump in with, which is, we’re sort of talking about as our organizations of scale and especially if they have multiple teams that are working on different platforms and policies that need to be implemented. In some of these larger enterprises, it’s become very hard to really even see everything and know about it and track, you know, who’s running what and where, and who are these owners. And so one of the things that’s new in the product is a pretty slick interface.

    Probably that’s the prettiest part of our product right now. The dashboard’s always looked great. But you can now go in and do what we call workload explorer. And visually view all of your running workloads, whether they’re on Kubernetes or Docker or OpenShift, and you can see everything that’s running across a large distributed runtime environment. And drill down into them, and you can start doing things like highlighting those that are vulnerable or high-risk, and those that are PCI compliant can be coded to jump out, and you’ll see that much more easily.

    You can then do tabular mechanisms. Begin to filter. Show them only those running on this platform. Let’s say that there’s a vulnerability that’s exposed in a certain component. You can show me just those, and start drilling down and looking at them, seeing where are they running? Is this one on-prem? Is this one on the cloud? Which cloud provider is it running on?

    So you know, as companies have become multiteam, multicloud, multistack, it’s the matrix of what you’re looking at has become pretty complex. And as workload explorers, it’s a great way to just sort of move around in a large enterprise. See what you have and understand what you need to work on right now.

    Shimel: You know, and let’s not trivialize it. Let’s not belittle. I’m having a tough time with the word. Let’s not belittle it. You’re a hundred percent right, Andy. Today’s organizations are multi everything.

    Osnat: I agree.

    Shimel: _____ _____ distributed on so many different levels, that really, having a 360 degree view of, just of the lay of the land, where all this, how it all plays together. That in and of itself, someone could make a product out of. I mean, it’s crazy.

    Feit: It’s eye opening for customers. Just in the last, we’ve been working with this product for about a month or six weeks, with some of our early adopter customers. And some of our sales engineers have been implementing it in proof of concept environments. And when the customers see this map, and they, you start drilling down, they say wait a sec – where’s that running? Show me that one.

    They’re finding things that they didn’t realize they had because you can now visualize it and see it. You know, when it was coming in as yet another alert or a text field or you know, something coming in to your SIM system, that was one thing. You had to look at the logs and know the query to type. But when you see it visually and you jump in and start looking around, and says wait, what’s that?

    And people were, it was eye opening. Okay, I need to go talk to that person. Literally, people were discovering things they didn’t know they had in their environments. And that’s exactly how, in a big environment, this tool can be very helpful in organizing things and showing you what’s out there.

    Shimel: Absolutely, absolutely. Guys, that last question for you is not really 3.5 related but more mark related. You know, we seem to be undergoing a, well, it’s constant. But recently we’ve seen just more and more consolidation in the tech vector general within containers, around Kubernetes, you know, IBM’s Red Hat –

    Feit: Cloud, right?

    Shimel: IBM’s Red Hat acquisition, $34 billion. I mean, is the king of it. But we saw for instance, CA or Broadcom CA, whatever they call it now, spin on _____ for near a billion dollars. To Tom or Bravo. We saw, who, someone just bought, was it _____ just bought a –

    Osnat: Later insight, yep.

    Shimel: Container something.

    Osnat: Right.

    Shimel: I mean, at some point, consolidation to what Aqua’s been out here preaching for three plus years. How do you think that affects, I mean certainly now, 3.5, you’ve raised the bar again. Let everyone else try to catch up. But in this atmosphere, talk to us a little bit. What does that mean around Aqua? Or do you just keep doing your thing?

    Osnat: Yeah, that’s a good question, Alan. I mean really, I think you keep doing your thing. Because your thing is understanding where customers are headed and building solutions that address what they really need. We’ve tried to keep our eye on that ball. And we’ve been big pushers of the concept of supporting multiple platforms, from the early days.

    We were Docker first, but today we support all kinds of things including things, less broadly used technologies. But pivotal, and Microsoft containers. Supporting all the cloud. So you keep your eye on that ball with the goal of building a customer base that is satisfied and loves your product, is excited about working with you.

    And one of the things that’s important to us is our customers are going to continue to renew with us and retain. You know, we’ve only been around three years. But we look at, our largest customers are very happy and using us, and expanding their use of us. They’ve put us in a pilot two years ago, and now they’re in production and they’ve put us in production with five applications. And now they’re on 50 applications. So this is all good. We’re not very focused on hey, we must be acquired by some time or we must be public by some time.

    It’s, let’s build the right products, continue to see adoption. We’re growing very rapidly, both within our base and customers deploying more, and new names, new logos, that are using our solution. And that’s what’s important to us. And the market, you know, the market will be the market. If somebody says wait, I can’t let these guys get that much bigger. I’m going to try to snap them up. That may happen. But it’s not something that we’re really focused on. We’re focusing on building the business organically in the right way.

    I have to say, we’re all old enough to have been through the dot com boom. And you know, the craze that went on back then. And I think it’s important to keep level headed. We’ve been around for three years now. We’ve just crossed the 100-employee mark. Celebrated that. You know, we work with our customers, we’re happy about that. We keep our heads, you know, leveled and we keep doing the work. You know, someone comes along and offers $35 billion to buy us, like Red Hat, I’m sure the board will approve.

    Shimel: They might think about it as –

    Feit: They’ll think about it a couple of days, you know. But in the meantime, we’re trying to keep things sane.

    Shimel: I hear you. Guys, just one last reminder while I have you both on. I’ll see you both out at the TubeCon Native, cloud native, Linux foundation event, along with Red Hat, right? Sponsoring a Monday conference on container security. I think we spoke about it last time. And I just, I don’t want to mess up the date, but I thought it was December 9th, or 10th.

    Feit: Nope, December 10th. So it’s the Monday right before KubeCon starts, and it’s collocated with the event in Seattle. And you can register on the CNCF site when you register for KubeCon, or if you already did you can go back there and add on one of these collocated events. Ours is very focused on enterprise security, so it’s called KubeSec Enterprise Summit.

    So for larger organizations, facing you know compliance requirements and deploying containers in production, it’s a great way to learn what others are doing. We have a great lineup of speakers. We have, JPNC is speaking. We have Tinder speaking. We have Starbucks talking about their journey towards secure containers. We have Liz Rice and Michael Hassenboss, who wrote the recent book on Kubernetes security. Which is not even published in paper yet, it’s still an eBook, but it will be first delivered in paper form at KubeCon. We’ll have them in our booth, and they’ll be signing books there.

    So it’s kind of a great event that people can get exposed to all of these technologies, and hear from a lot of different people. We ran an open call for presentations, so we have everything from technology to compliance to best practices. It’s going to be a great event. We’ve got a couple hundred people already signed up. We only have room for 300. So, if any of your readers do want to attend, they should do that soon.

    Shimel: Absolutely. Well, I’ll be there as well. We’ll be reporting for it. Andy, Rani, we’re way over time as usual. I ____ _____, we’ll need to call a wrap here. Congratulations on Aqua 3.5. I’m sure it’s going to be a great benefit, and the customer base will really appreciate it, and we’ll look forward to seeing you in Seattle.

    Feit: Look forward to seeing you, Alan. It’s always great to talk to you. And share what’s going on with your listeners.

    Shimel: Thank you. Andy Feit, Rani Osnat, Aqua Security. This is Alan Shimel for devopsy.kinsta.cloud, and you’ve just listened to another DevOps Chat.

    — Alan Shimel