staging-devopsy.kinsta.cloud

Author: Mitch Ashley

  • DevOps Chat: CI/CD Scalability Lessons with CircleCI

    DevOps Chat: CI/CD Scalability Lessons with CircleCI

    The software development tool needs of a two to three person team can be much different than those of a large enterprise. CI/CD is a common approach nearly all software teams establish. But what needs of a larger software organization do you adopt early on and which simply add more complexity than benefit?

    Rob Zuber, CTO of CircleCI, began tackling this problem in the mobile space and then moved to CircleCI to help create what is now a well established SaaS-based CI/CD offering to software teams of all sizes. Join us on this episode of DevOps Chat to take away some valuable CI/CD lessons for your organization.

    Transcript

    Mitch Ashley: Hi, everyone. This is Mitch Ashley with staging-devopsy.kinsta.cloud, and you’re listening to another DevOps Chat podcast. Today, I’m joined by Rob Zuber, CTO of CircleCI, and our topic is software innovation at scale. Rob, welcome to DevOps Chat.

    Rob Zuber: Thanks so much, Mitch, it’s great to be here. Thanks for having me.

    Ashley: Would you start by introducing yourself, tell us a little bit about what you do and tell us a little bit about CircleCI.

    Zuber: So, I’m Rob, as you said. I’m the CTO here at CircleCI. I’ve been with the company almost five years now, and I’ll talk a little bit about how I got here once I talk a little bit about what CircleCI does. I think that’s probably the right order.

    So, CircleCI, our big focus is helping every software engineering team be better at what they do. So, be better at getting software from their sort of concept and idea to value delivery in the hands of their customers. So, we sit between the collaboration element and the production deployment element by really being the delivery pipeline. So, we help you take your software from the point that you’ve, again, had an idea, started to write, to making sure that works well, making sure everything everybody’s doing is working well in concert and getting that into a production environment where you can start to realize customer or business value confidently, quickly and being ready to move onto the next thing and to drive value for your customers.

    Ashley: So, this is a pretty big space, a lot of folks in it. I mean, people can download Chef or Puppet or Jenkins and—you know, we could go on and on about different tools within sort of that CI/CD pipeline chain.

    But tell us a little bit about where you uniquely fit into the market.

    Zuber: Yeah, so, a lot has changed in the market over the time that I’ve been here, unsurprisingly—not just at CircleCI, but in the market in general. We’ve seen a lot of people come and go, a lot of companies either snapped up into larger organizations, but maybe they weren’t going to be focused, necessarily, on CI/CD standalone or just not reach sort of critical mass as an organization.

    And the market has also shifted, and what we see now is a lot of people trying to maybe add CI and CD as an extension of something that they’re doing, but not treating it as the core business that they focus on. So, that’s the real thing that separates CircleCI is our focus on CI and CD as a core of what we do. Every day when we get up and get to work, that’s what we’re focusing on, and not tying you into—you know, you’re using this CI and CD capability because it’s part of this other package that you maybe want or don’t want, and really being the choice in this space and giving developers the opportunity to pick the best tool that they want in every different part of their flow, if that makes sense.

    Ashley: Let’s peel back the onion a little bit more. I know that—I mean, it’s a very complex process and CI/CD and all the tools you might use, if I understand correctly, you don’t take a “let’s try to be everything to everybody,” but more of a platform approach with workflow and then you can plug in various tools as part of that workflow package and you pack things into orbs for configuration management, et cetera.

    Can you give us a little bit more detail and meat on the bone about that?

    Zuber: Yeah, that’s exactly right. Well, we believe it’s kind of hard to be wrong about this, I guess, that our customers are software developers, right? And so, they are more than happy to create the capabilities they need if we give them the tools to do that. And orbs is one of those such tools.

    So, it’s basically about realizing that many of our customers are very capable, they’re solving very similar problems, and giving the opportunity to share that, to reuse pieces and then to build. Some of those problems that they’re solving are building integrations with best in breed components of things that we don’t necessarily provide, right? So, that might be something like, I guess, anything from vulnerability scanning or connecting into security systems through to how you do integration with your eventual deployment target, right?

    Ashley: Mm-hmm.

    Zuber: And rather than trying to solve all of those problems and say, “Well, you need to deploy,” like, we’ll also build a cloud and you can deploy to that cloud, or we’re also gonna build all of the tools for all of these parts of your system. We basically give you a really central and easy to use pipeline, effectively, or workflow is the term that we use for it, and the ability to plug into that, those capabilities, right? So, by leveraging orbs which our partners build, you know, to get access to their systems, community members have built, and we’ve built, basically to give you access to the richness of the ecosystem, if you will, using that to really tap into those additional systems, but the ease of central management of all that. So, you have great clarity about what’s happening in your delivery process.

    Ashley: And I understand congratulations are in order. Recently, you had your series D, 56 million led by Owl Rock Capital and NextEquity Partners—congratulations.

    Zuber: Thank you very much. Yes, it’s very exciting.

    Ashley: So, with great power comes great responsibility. What are you gonna do with that money? [Laughter]

    Zuber: Yeah, that’s a great question. I mean, honestly, a lot of it is very much continuing on this trajectory, right? Like, we believe in what we’re doing, we believe we’re doing the right things and we have the success to show for it, but in every one of those areas, we can do more, right? So, we’re continuing to invest in engineering and product development, clearly to add capabilities. I mean, part of that is really building around those types of integration models like orbs that we talked about.

    Also, taking one of the key areas that we’ve really had—well, I guess just through our success over the years, because we’ve been around for about eight years as a company—we’re sitting on a lot of deep understanding of how software engineers are building. We have thousands and thousands of customers building tens or hundreds of thousands of projects. And so, we see that, right? We see the flow, we see what works for them, what doesn’t work.

    We see whether they—basically, the rate at which they’re able to deliver software, the kinds of tools they use, how the ecosystem is supporting them or not, and being able to take all of that rich data and turn it back to our customers as value for them to really help them be better. Like, moving away from just a tool—I mean, a great tool, but really, a tool that not only moves your code through, but helps you understand how you could be doing better and where your opportunities are for improvement. Or, honestly, at the other end, it’s always worth mentioning, if you’re doing great and you can invest your time and energy in something else, because things are really stable and working well, right?

    So, that’s a place that we’re making some investment for our product with that perspective, and then again from a, I guess, the extension that we talked about and just investing everywhere that we’re already investing in core CI and CD. I mean, over the time that I’ve been with CircleCI, the entire process of software delivery and how we package and build product has fundamentally changed, and I expect that to continue to happen. I mean, the pace at which we move in this market is a little crazy sometimes.

    And so, we need to continue to evolve to support how software development is getting done in order to be, really, the best tool, as we are today, for software delivery.

    Ashley: And I should know this, probably—are you running the jobs that you’re seeing in the cloud or is a lot of this on prem for customers? How do you get access to that [Cross talk]?

    Zuber: Yes, great question. So, we offer both. We have a cloud platform, which is, the majority of our customers use that, and the majority of the builds that we’re running are on that platform. We do have an on-prem solution as well for very large customers with complex cases or specific needs where they’re interested in deploying the software and operating it themselves.

    Yeah, and so, one thing I was gonna say about that change, and tying it back to kinda orbs and being able to integrate with other systems that we’ve talked about, we’ve been evolving to support the change in the market, but also evolving to have a more flexible platform because we see this constant change, and not wanting to play catch up or try to stay ahead of it all the time, but rather, create more flexible tools that continue to evolve with changes and how people do software development and give our users and our customers the ability to use the platform in ways that they see fit or best meet their needs as we continue to evolve.

    Ashley: That certainly makes sense why you focused around the orb strategy and investing in CLI and APIs. Are you also focusing on onboarding?

    Zuber: Absolutely, yes. So, I think the key to this for everyone is time to value, right? Like, CI and CD can be a complex system—

    Ashley: Mm-hmm, very.

    Zuber: And it depends a little bit on the size of your org. But, as I said, when we talk about those small little companies starting out, I mean, they just want something that works that will get out of their way. And so, it’s that sort of gradual growth with you as a team to meet you where you are.

    So, if you have a simple application and you’re really focused on finding product market fit, then it should take as little effort as possible to get up and running and just make sure that you’re delivering with confidence so you can focus on those iterations of your early—I always talk about it in terms of companies like startups, but it might just be an early project, right, in a larger organization. Those small new projects are a great place to try out new capabilities, new tools, new processes.

    And so, supporting you to get up and going and realizing that value very quickly, but again, as you get to large organizations, you need to be able to roll in more and more capabilities. But getting up and going quickly and really getting those moments where you recognize, “Okay, this is actually changing how I’m working and this is really valuable,” that needs to be very simple, and so, we’re constantly investing in making that as simple for as many different kinds of teams, of projects, code bases, tech stacks, again, as they change, we want to cover as many of those as possible.

    Ashley: You’ve talked about startup companies and startup projects, but I know, also, you focus on enterprises. Those can be very, very different—drastically different in terms of customer requirements, issues, scale that you have to solve. What are some of the challenges that you’ve both run into, encountered, and also feel like you’ve addressed pretty well in those two different communities?

    Zuber: Yeah, that’s exactly right. I mean, I like to think of it as a continuum. I don’t know, maybe that just makes me happier than two really distinct communities, right? And I think that one of the things you see in enterprises that are succeeding is seeing the types of approaches that smaller companies take, right? But, of course, you have to take that and figure out how to make it work at your scale.

    Ashley: Mm-hmm.

    Zuber: To your point, we absolutely have a very large number of very large customers, about a third of the Forbes Cloud 100. So, really large, influential, but I would still say—that particular group, tech forward companies. Meaning, coming from a background where their software development was always central. You mentioned transformations previously, so we also play in a lot of those. But it’s a different space, right, of companies that are trying to reimagine how they build versus companies that have grown to scale, sort of always thinking about software development.

    But many of the challenges are similar, right? Just the pure scale. And so, that scale comes in multiple different forms. It might just be the total volume of jobs that you’re running, and the growth of our cloud platform over the years has been remarkable, and we’re constantly working to figure out what’s the next order of magnitude, the next order of magnitude, how do we continue to support that as we just continue to go through this growth, which is fantastic, but also exciting, I would say, from an engineering perspective.

    Ashley: Mm-hmm.

    Zuber: So, there’s kinda pure scale on just a job perspective, but the things that get more interesting and that we’ve really invested in are, for example, the complexity of workflows, right? So, if you have a lot of different systems that all need to be either validated together or have dependencies that need to be understood as they flow through the CI and CD process, or maybe a large set of validations that you do beyond just testing. So, that might be—again, I mentioned security scans earlier, linting. You know, all of the kinds of gates and processes that get put in place as companies get larger and being able to manage those independently against a very large code base with a large number of contributors.

    Again, that might not be total number of jobs, for example, but the complexity of those definitions scales itself, the number of developers contributing—that scales. And so, orienting the product around those kinds of scaling points has been something that we’ve had to do as our customers have grown, as we’ve brought on large customers where we’ve really invested a lot of time to make sure, particularly in a cloud environment, which is where—there’s an additional layer of value, for sure, for our customers, because they don’t have to think about any of the management, right? They come in with very, very large workflows, and the capacity is all available. And when they’re quiet, they don’t have to worry about additional machines being online or wastage or anything like that, because we’re managing all that for them.

    Ashley: Mm-hmm.

    Zuber: And so, doing that for this large blend of customers, some of whom are quite big and driving a lot of work, is something that we’ve really figured out.

    Ashley: Well, thinking about, you mentioned continuum, which is a great way to think about it, too—why don’t you share with us a couple lessons that you’ve seen customers learn, maybe you’ve learned yourself, running your own product development and software development process. As people go from that continuum of, “I’m just getting involved in CI/CD,” using a product like yours, obviously, there’s great features and stuff, we all know that, that you all have—but what are some of the lessons that they learn as someone goes from, “I’ve got a development team, we’ve just implemented CI/CD,” kinda getting up to this point? The next scale issue that we tend to run into is X and then kinda what happens after that.

    What’s that maturity lifecycle look like?

    Zuber: Yeah, I really like the word maturity that you used there. Because I think that a lot of times, when we think about this, we think about the growth of companies at scale, we spend a lot of time talking about tools. And of course, you know, it’s easy to look at CircleCI and what we do and think about it as a tool. But ultimately, the biggest challenges are gonna be shifts in culture, right? So, process how you think about getting work done, how people interact, definition of roles and responsibilities.

    I mean, everybody starts out in a—well, everybody—when you start a company in this space as a tiny little, maybe you’re like three people, five people, whatever, roles tend to be pretty loose, because everybody’s just trying to get done whatever needs to get done, right? And one day, you’re the DBA and the next day you’re the barista making sure everyone else has enough coffee to get work done, right?

    And as you grow, there’s parts of that that you really wanna keep—absolutely, right? Like, the focus on the mission and being really clear about where you’re trying to get to. But, it becomes more challenging for everybody to do everything, right? You actually need to have some clear boundaries and understanding.

    So, that shift in culture that is like—what are the parts that we keep? Or one of the ways that I often describe it, and we, you know, for our own part, as I said, have gone from about 20 when I joined to 250 and still growing. One of the things that I always look for is what was the intent, and then how do we implement that now at this next level of scale?

    Ashley: Mm-hmm.

    Zuber: And I think that applies to your tooling and your process and everything else as well, right? So, we have always been a very transparent company. And so, transparency when you’re five, 10, 20 people is usually about just kind of making sure everyone knows everything that’s happening. But when you get to 250 people, it’s about really being clear about what’s happening, but being able to define that message and convey it in a way that’s not just this firehose of information or an overload for everyone, right?

    And I’m trying to shift that back to sort of technology and where you were going with this—even though I believe it’s ultimately, it’s these underlying cultural pieces. When I look at people building software, I see, for example, people looking to large organizations—you know, Google, Facebook, Netflix—and saying, “Well, they build software like this, so that must be right.” And again, it’s important to look at the intent, right?

    So, yes, you probably wanna have a CI and CD pipeline, because it’s gonna get a lot of stuff out of your way, but I would guess that when you’re starting out, you probably wanna have a very simple application, because you don’t know yet what your business is, whether you have a business, what the fit is.

    Ashley: [Laughter]

    Zuber: So, this is like, this argues for the monolith, right? Everybody, ultimately—not everybody—many people ultimately say, “You know what? The monolith isn’t scaling with our organization. It doesn’t match our ability to follow our intent. Our intent might be autonomy or ability to work on disparate areas of a product separately, stuff like that.” That works, actually, really well in a monolith at a small size, because you have so much shared understanding.

    Ashley: Right, right.

    Zuber: And at some point, maybe you say, “Okay, this isn’t working any more, we’re gonna start breaking out services”—kind of a natural evolution that many companies go through. But, again, people look at that at the beginning and say, “Oh, well, that’s where we’re gonna end up. Let’s just do it out of the gate” and bring in a lot of overhead and complexity that’s unnecessary for their size, and ultimately end up, I would go so far as to say failing, because they create sort of a technical overhead or burden that’s not in line with where they’re at as a business.

    Ashley: Mm-hmm.

    Zuber: And so, if I were to pull out the underlying lesson in all of that, it’s like—find the intent in what you’re doing and then determine the implementation that’s right for your scale. And then, I guess the other big lesson if you’re going through scale at a high enough rate, recognize where you are on that curve and recognize that it’s changing, right? Because it’s easy to think that things are gonna stay the same and the system that you have is gonna be a great system for a long time.

    But if you’re growing quickly, this applies to your software, it applies to your team structure, to how you manage your organization. You need to be aware of that change.

    Ashley: Yeah, I believe that when we talked about developing software, what organizations are really doing is learning how to create software, and that’s what we—or the team, the organization is in the process of doing, and then there’s that evolution on the maturity curve.

    So, you, whether you’re the QA person, the DevOps person, the developer, the architect, et cetera—it’s about all that function so that you can think of it as running a football play or a soccer play or a baseball play. You’re learning to function and operate as a team to create software. Do you agree, disagree?

    Zuber: Yeah, I think it’s quite on point. And the reason that I think this is really fascinating, I know this is very—speaking of side tangents, my earliest days before I got really into software development, I actually spent in a factory. I was a process engineer. And the great thing about a factory is, we would build tens of thousands of the same thing, every day. And so, refining the process was about refining the process for building the same thing.

    But in software development, you basically never build the same thing twice, right? I mean, you might get hired into another company and someone’s like, “It’s great that you are here, because we need you to build basically the same thing that you already built.” But it’s this constant discovery, right? You’re constantly in a design phase of trying to figure out how do we go about building this thing that we’ve basically never done before? And of course, there’s prior art out there and all those things, but we have to map that then into our specific domain, our specific team and constraints.

    And so, a lot of that is figuring out—okay, we know that we need to do a thing and we have some basic sense of that, but how do we map that into our process? And you certainly described it as our model for building the software as opposed to just thinking about building a thing.

    Ashley: Well, we’ve run out of time. Rob, we should just grab a beer or a coffee and finish this conversation in about three hours.

    Zuber: I’d love to. Perfect.

    Ashley: [Laughter] Sounds great. Well, thank you for being a guest on the podcast. This is Rob Zuber, CTO of CircleCI. Appreciate you joining us.

    Zuber: Yeah, thanks so much for having me. It was great fun.

    Ashley: It’s been a pleasure. And also, thank you to you, our listeners, for joining us. This is Mitch Ashley with staging-devopsy.kinsta.cloud, and you’ve listened to another DevOps Chat. Be careful out there.

    — Mitchell Ashley

  • DevOps Chat: Phoenix OSS Framework with DockYard

    DevOps Chat: Phoenix OSS Framework with DockYard

    Stateless application architecture is the current de facto approach, right? Not necessarily. Stateful applications communicating over TCP sockets can and are successfully built even in today’s age of cloud-native applications.

    Our guest on this episode of DevOps Chat is Chris McCord, creator of the Phoenix open source software, and architectural engineer at DockYard. Chris came up as a developer using PHP, Java and Ruby. When he learned that WhatsApp was built using Elixir, running on the Erlang VMs, Chris was intrigued. What’s needed is a developer-friendly web framework for creating web and mobile applications.

    Chris started the development of the Phoenix Framework in 2011 and saw adoption pick up in 2014/15. Fast forward to today, Chris is an integral part of a vibrant community of developers using Phoenix to create web-oriented, mobile, embedded and real-time applications that can support large transaction server volumes with less code.

    Join us as we talk with Chris McCord about Phoenix, why he created the open source project which today expands into Phoenix LiveView, and the Phoenix Frenzy developer challenge (winners to be select in early-to-mid October.)

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

    Transcript

    Mitch Ashley: Hey, everyone. This is Mitch Ashley with staging-devopsy.kinsta.cloud and you’re listening to another DevOps Chat podcast. Today I’m joined by Chris McCord, architectural engineer at DockYard. Our topic today is Phoenix, web framework for Elixir. Now Chris is also the creator of Phoenix and he’s also an author, so I think we’ll have plenty to talk about today. Chris, welcome to the podcast.

    Chris McCord: Thanks for having me.

    Ashley: Great to have you. Would you start out by introducing yourself? Tell us a little bit about what you do and also what DockYard does.

    McCord: Sure, yeah. So as you mentioned, I’m the creator of a web framework called Phoenix. It runs on the Elixir programming language which runs on the Erlang virtual machine, and I’m sure we’ll get into what all that means for maybe some of the audience that isn’t familiar, but essentially what I do apart from building the framework is work with DockYard to build out full stack projects for our clients, so that’s anything from Fortune 100 companies to startups, and we use Elixir to power all the solutions for these clients. We also do design and UXD, but as far as my focus it’s really focusing on backend systems and building out scalable platforms.

    Ashley: Certainly a big need these days with all the applications that we’re creating and need integrating and scaled. So let’s jump into your work and I’ll start first with what is Phoenix and maybe a little bit of background on Elixir for folks that don’t know what that’s about, and Elixir/Erlang.

    McCord: Yeah. Phoenix is kind of like the de facto web library of framework for Elixir, and so the quickest synopsis is Elixir is a programming language which runs on the Erlang virtual machine. So Erlang is a language that has been around for over 30 years now. It was actually developed in the ’80s by Erikson to run telecommunication systems, so they kind of built this niche language to solve a very specific set of problems in the ’80s, and meanwhile the programming community at large focused on object orientation, single-threaded languages. Fast forward to today, where we kind of have Morris Law in effect and we’re starting to add more cores to keep up with the CPU speeds, all of our traditional languages have kind of suddenly hit a wall where it’s like suddenly we can no longer count on our programs doubling in speed every year. We have to add multiple cores, but most languages weren’t made for multicore age.

    It turns out the specific niche set of problems that Erlang solved in the ’80s actually maps perfectly on the multicore age, so I think we had this kind of nugget of innovation in this Erlang virtual machine kind of sitting there largely unnoticed, and then the creator of Elixir José Valim came in in 2011 and kind of recognized this innovation and building modern language with some kind of features that programmers are used to basically in these mainstream languages and build a language on top of the Erlang virtual machine. Elixir was birthed on top of this niche virtual machine, and not that Erlang has had its own successes—you know, we’ve heard about like WhatsApp with their $20 billion acquisition. They’re running 10 million users per server and I think they supported that with like 30 engineers total.

    Ashley: That’s amazing.

    McCord: So yeah, that’s kind of the heritage and has what allowed Elixir language kind of takeoff much faster I think than what a typical new language would be, and then of course I was able to come in and literally stand on the shoulder of giants and build a web framework on top of Elixir, which gives us all these amazing, scalable features.

    Ashley: So exactly the metaphor I was thinking, we all stand on the shoulders of giants. That’s one of the great things about our industry is what’s old is new again and we build on the successes of the past. Talk a little bit about why did you embark on creating a web framework on top of Elixir? Were you working on a project and saying, “Hey, I keep building the same code over” or “I have friends that have the same kind of need, maybe I should go build something”? What was sort of the inspiration for creating Phoenix?

    McCord: Yeah, so for me my background is like Java and then PHP and then Ruby, but for the previous, let’s say, six or seven years, before I got into Elixir I was doing Ruby professionally and I was loving it. Doing a lot of Ruby on Rails, for folks that are familiar with that framework.

    Ashley: Ruby’s a great language. Love it.

    McCord: Yeah, and I had a lot of happy clients. And as kind of the web evolved to this more real-time connected nature we had more and more requirements, and the more and more types of applications I wanted to build were real-time connections, showing live updates on a page, doing things that you would expect to be able to do or that we expect to be able to do as users on the web today. I was hitting walls with Ruby. I was trying to make libraries to support kind of real-time applications and things just were very brittle and weren’t scaling well at all, so that’s when I started looking around to say like, you know, if I could pick a language to write kind of like real-time applications in, what would I pick? And that’s kind of where I discovered Erlang and WhatsApp had just been acquired, so I kind of saw how they were running millions of users per server and that’s where I said, “How are they doing that?”

    I want to be able to do that. And that’s when I discovered Elixir, and the creator of Elixir, José Valim, had come from the Ruby community so I kind of remembered that, oh, you know, he went off and created this language; maybe I should go see what he was doing. That’s kind of what sparked my interest and then I fell in love with Elixir and I said, “The only thing I need to do is write a web framework so I can build all my client applications in this,” so that’s kind of what started the whole thing.

    Ashley: Isn’t it interesting, if I remember right, in Ruby I think libraries are called gems or packages of libraries, so that experience there, so how do I something like that in this new language that you’re working in, and it will eventually lead you to creating Phoenix. What a great story.

    McCord: Yeah, exactly. And it was kind of under this promise of platform, right? So I guess with any technology you kind of take a leap of faith and I dove in reading the Erlang WhatsApp, millions of connections per server, and then assumed that we could do that. So long story short, two years—or once we reached 1.0 in Phoenix we did benchmark and our real-time layer we benchmarked up to 2 million connections on a single server.

    Ashley: Wow.

    McCord: Yeah. We were only limited by—we had to spin up like 45 servers to send that amount of traffic and we just ran out of connections, so we weren’t limited on the server. We could’ve pushed it further. So it’s kind of been an interesting history, kind of taking this leap of faith, assuming what you read about a technology is true and assuming that you can actually easily achieve or it’s achievable by you personally and then kind of went through and showed that we can scale to millions of users, so it’s been a really interesting and fun ride so far.

    Ashley: Very nice. Well, and if I understand you started this around, what, 2013? I think the first sort of public or production-ready release 1.0 was about 2015, so it’s been in the community for a while. I’m sure it’s matured since then. What’s the state of Phoenix today?

    McCord: Yeah. So we’ve been 1.0 since 2015. I think my first commit was 2013. Elixir was started in 2011. It didn’t really hit any kind of usage till 2013, so once Elixir went 1.0, which has been—it was before Phoenix 1.0, so 2014, maybe? So we’ve seen pretty stable and large adoption since then in the language and the framework, so Elixir itself and Phoenix are still on one-dot whatever release and neither the language or Phoenix, we don’t—we have no plans for a 2.0. I mean at some point in the future there will be a 2.0 but we don’t have—we have a couple deprecations but there isn’t like something on the horizon where you’re like, OK, now I have to rewrite everything. So our goal is basically a stable core at the language level and the framework level, and we’ve had companies come in and we tout like a Bleacher Report. It’s one big example we always point to because a lot of people know who they are, so that’s Sports News website. They have like 80 to 100 million visitors a month and they’re built almost entirely now on Elixir and Phoenix. So we’ve had companies come in and build on top and seen really great success so far.

    Ashley: Are there any particular kinds of applications that are particularly well suited for Phoenix, like a web application like you mentioned a sports site? It might be delivering a lot of video content or photographic content, or is there other applications more transaction oriented like processing payments or whatever it might be through a web framework? What’s the best kinds of apps that really take advantage of Phoenix?

    McCord: Yeah, so I mean the most basic answer is anything connected to a TCP socket [inaudible due to crosstalk].

    Ashley: That’s a lot of stuff. [Laughs]

    McCord: Right.

    Ashley: That’s a lot of things. [Laughs]

    McCord: Basically, all of the above to what you said as far as anything web-oriented, anything with like notifications. So the Bleacher Report started with their adoption of the push notifications to users and then Pinterest has not all their stack, but the notification layer of Pinterest is written in Elixir. So we see a lot of companies doing kind of these message broker style use cases, but I think anything connected to a TCP socket, whether it’s a web server, orchestration layer for your platform, stuff outside of what we would consider like the web is still gonna be a great fit, but I think the biggest adoption we see so far is more web-oriented just because I think that’s the biggest market share developers, right?

    All of us had to do something web facing but we have a broader reach beyond that and that’s not even to talk about—we also have—Elixir can be used in the embedded space, so you can actually do Elixir and the entire Erlang run time into like a 16-megabyte Linux image and run it on an embedded device and you have all of these benefits. So it will work equally well on like a Raspberry Pi Zero up to a 100-core server, and that’s the most exciting thing for me.

    Ashley: Interesting. Is Phoenix more well suited to a stateful kind of application or stateless or does it make a difference really?

    McCord: Yeah, so stateful applications are—I mean it’s the thing that we’re able to do that no one else is able to do, or do well, as far as these mainstream frameworks. So we can still do stateless HDP just like anyone else, and we can do that incredibly quickly and scalable, but the reason that brought me into Elixir was we can actually build stateful applications with connections that stay live. You know, we don’t have to throw away these stateless connections and try to fake some state, so that’s basically why I built Phoenix. We call our real-time layer channels. It’s similar to like a Socket.IO. So basically it’s an abstraction over web sockets, and it’s what I wanted to do and that’s what brought me in, was the ability to hold these real-time connections.

    Anything we build today is ultimately a chat app, right? Whether it’s Twitter or Facebook or all these things we’re trying to build. You need some kind of real-time nature, you need to be able to push updates to users, even if it’s just to show like a notification count on the header bar of a website. That’s way easy to do if you actually had a conversation going with that connected client versus trying to have like long pulling or take it over stabilization ___.

    Ashley: Well, it’s interesting with the cloud and that’s really kind of brought stateless application design architecture to the forefront, but if I recall, Erlang’s really well suited to doing stateful kinds of applications and large volumes of it, so it sounds like that’s part of what attracted you to this environment.

    McCord: Yeah, exactly. Yeah, the whole stateless, serverless approach is interesting to me because it’s like it’s the opposite of what we’re able to excel at in our platform, and what we’ve seen is like—maybe just one example. Someone was paying $16,000 a month on AWS Lambda and they rewrote that in Elixir and they’re paying like $40.00 a month now.

    Ashley: [Laughs]

    McCord: So I do think that, yeah, there are merits to these stateless platforms, but I think it’s under the guise of what the alternatives were prior. So if your platform alternatively was mostly stateless then having someone else handle your stateless concerns and scaling makes a lot of sense, but you can now build a stateless. I think we kind of turned that whole idea on its head and we say, “Well, we can just run all this on a few servers and it’s going to scale for the lifetime of our business,” then that’s way less complexity and way less than these other solutions.

    Ashley: Interesting. Now I think you also just recently concluded a talk. Was it Phoenix LiveView? Was that the name of the conference? I think it was the challenge that you did.

    McCord: Yes. It was ElixirConf.

    Ashley: ElixirConf, that’s right.

    McCord: I talked about Phoenix LiveView, yeah.

    Ashley: What was your talk about there?

    McCord: So I presented LiveView last year at ElixirConf and it was kind of like a proof of concept, and then we’ve been working on it for a year and I really presented how far we’ve come in a year. So last year it was kind of prototype, had some promise, and this year it’s practical use cases and the kinds of efficiencies that we’re able to get and even how we’re able to beat kind of traditional single-page applications using Phoenix LiveView.

    Ashley: Cool. There was this thing called Phoenix Phrenzy, too. I think it was a challenge that came out of it, correct?

    McCord: Yeah, so the Folks at DockYard put their free time together and helped get this contest site together, which is really just a contest for the community to put examples of Phoenix LiveView together, kind of to one compete with each other and also to kind of grow a broader awareness of the platform outside the community. So yeah, Phoenix LiveView allows you to build we say rich, real-time applications with server-rendered HTML, so you don’t have to write any JavaScript yourself and you’re able to get kind of these interactive applications in much faster time and much less complexity than what you would probably be used to. So the competition is a way for people to kind of showcase their work and what’s possible.

    Ashley: And how are the winners selected of the competition? Is there a board that you’re a part of or how do you decide this is the best of the best?

    McCord: Yeah, we have a handful of judges. Quite a few members of the Phoenix core team are judges as well as a few members in the community. So I think we’ll just go through and kind of vote on our favorites and whoever gets the most votes wins.

    Ashley: What’s the prize? Is there a grand prize other than the recognition?

    McCord: Bragging rights. [Laughter] Yeah. In the future we will look into prizes. If anyone’s ever run a competition like this you immediately get into some legal waters trying to award prizes, especially with different geographic and age restrictions, so really it was a matter of trying to make sure we can do a competition without waiting months on the legal process, but maybe in the future. But for now it’s just global recognition.

    Ashley: Well, I think there’s something to say for attaining some Phoenix street cred, so I think that’s [laughs] probably worth it itself.

    McCord: PhoenixPhrenzy.com—Phrenzy with a P-H—is available and anyone can join, and like I said, for me it’s just really neat seeing people build things with LiveView, so I think people should give it a shot if they’re at all interested.

    Ashley: One of the great things about the opportunity to talk to you, Chris, is it’s very cool to be able to talk with someone who had this idea, created this framework, wrote books like “Programming Phoenix” and “Metaprogramming Elixir,” et cetera, that you’ve created. You have this contest speaking about Phoenix at ElixirConf, so you really kind of built a career around doing this but it’s something that you kind of birthed, what, five, six years. That’s got to be a great feeling of satisfaction for you.

    McCord: Yeah, it’s been a very interesting ride. You know, when I started this I didn’t have any plans for where it was going. It was kind of—I always wanted to be involved in opensource from the altruistic side of things where I was using opensource libraries and frameworks so I felt like I was taking and not giving back. So when I got into Elixir it was more like a passion project, right? You know, I wanted Phoenix to be successful but I had no idea if Elixir itself would even be successful, so as things kind of took off, yeah, it’s just so interesting to see it grow, and especially from—you know, there’s a whole other conversation in here that we don’t have time to have, but as far as like burnout and once Phoenix became popular and people were using it and then I suddenly was like, oh my gosh, I have to maintain this, right?

    Ashley: Look what I created. Uh-oh. [Laughs]

    McCord: So anyway, so it went from—you know, fortunately I was able to find a sustainable path from there, because I was working full time at work and then working full time at home on open source, so I think had I not found DockYard where DockYard hired me to spend the majority of my time on open source I would probably be living in the woods somewhere. So fortunately I was able to find a sustainable path to opensource development. That’s a very hard bridge to cross I think for a lot of maintainers.

    Ashley: It is.

    McCord: So fortunately for me I was able to, yeah, cross that bridge successfully and it’s been mutually beneficial for myself, the company, and the Elixir community.

    Ashley: Well, kudos to DockYard for doing that, for finding the kind of synergistic relationship with you to allow you to do so much work on it and continue that work. Speaking of that, what’s the future of Phoenix? What do you see coming down the road in the next six to 24 months? What’s gonna happen?

    McCord: Yeah, so I think LiveView, it’s probably where the biggest hype is because, like I said, you can build an equivalent feature application for some single-page app but with probably like 10 times less code and 10 times faster to market because you don’t have to write all this JavaScript and we can do it in a scalable way. So I encourage folks to check out my keynote at ElixirConf if they want to see more about how I can make those claims, but we talked about our optimizations. So I see that kind of being at the forefront for the next year or so as far as what’s happening in the community.

    Ashley: Do you see—

    McCord: But beyond that for the framework itself we’re—go ahead. Yeah, I was gonna say beyond that we’re going to add like telemetry and metric integration in the framework so you’ll be able to at a glance see what’s happening in your system, so that’ll just be built into the framework where you can see—you know, if your system’s slow you can exactly pinpoint what’s going on at the framework level and your application code level and can diagnose issues. I think that’s one of the bigger features that’s coming that is not yet in place, but outside of that I think we’re going to grow organically around kind of this real-time applications, whether that’s with channels or Phoenix LiveView.

    Ashley: Fantastic. Well, definitely an enjoyable conversation and I feel like we could talk for a couple more hours. I’d love to sit down and grab a beer with you sometime, but thank you for being on the podcast. It’s great to have you here, Chris.

    McCord: Yeah, it’s been fun. Thanks a lot.

    Ashley: Well, to our audience, you’ve listened to another podcast and we’d like to thank Chris McCord who’s, you know, not only an architectural engineer at DockYard but of course creator of the opensource project Phoenix and author, thought leader, and great problem-solver, so it’s great to see good things happening with Phoenix. So, thanks for joining us, and of course we’d like to thank you, our listeners, for joining us today. This is Mitch Ashley with staging-devopsy.kinsta.cloud and you’ve listened to another DevOps Chat. Be careful out there.

    — Mitchell Ashley

  • DevOps Chat: Holistic Kubernetes and Cloud-Native App Security, With StackRox

    DevOps Chat: Holistic Kubernetes and Cloud-Native App Security, With StackRox

    More than ever, application security is a top priority. Beyond secure coding practices, a holistic app security strategy addresses the full application and infrastructure stack. This includes containers, microservices, orchestration, infrastructure software and the cloud. Bolting on the next security tool may not be the answer.

    Kamal Shah, StackRox CEO, joins us on this DevOps Chat, diving into the need for a systemic security approach across the life cycle of cloud-native, even “Kubenative,” applications. We explore how Kubernetes and cloud-native apps bring access to rich configuration information, usage visibility, runtime context, inherent security controls and compliance. It’s a fascinating conversation that will open up new paths to secure Kubernetes and cloud-native applications.

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

    Transcript

    Mitch Ashley: Hi, this is Mitch Ashley from staging-devopsy.kinsta.cloud and you’re listening to another DevOps Chat podcast. Today I’m joined by Kamal Shah, who’s CEO of StackRox. Our topic today is security in a cloud-native world. Kamal, welcome to DevOps Chat.

    Kamal Shah: It’s great to be here, Mitch. Thank you for having me.

    Ashley: Well, I really appreciate you taking time out of your schedule. I know you’re very busy. Happy to have you on. Would you start by introducing yourself? Tell us a little bit about you and what you do. Of course as CEO we can imagine, but also a little bit about StackRox.

    Shah: Absolutely. So again, I’m Kamal Shah. I’m the CEO of StackRox, and StackRox is a leading provider of security and compliance solutions for your cloud-native infrastructure. So as you’re embarking on your journey towards microservices, containers and Kubernetes, we help you address your security and compliance requirements across the entire application life cycle from build to deploy to runtime.

    Ashley: It’s about secure software, especially in a cloud-native containerized world. That’s for sure. Well, tell us a little bit about how you approach this problem? You know, how do you think about security in a kind of contemporary app development world where you’re doing cloud-native applications? Kub-native, I know is a way that we like to talk about it. How do you approach this from a StackRox standpoint?

    Shah: Absolutely. And so the big trend that we saw when we started the company was that customers were, you know, shifting their monolithic applications built on traditional infrastructure to microservices and containers and as a result security also had to evolve to meet and secure this cloud-native infrastructure. And we saw an opportunity to build a new set of solutions that are purpose built for this cloud-native infrastructure, because when you really think about it there’s fundamental differences between traditional application and traditional security and cloud-native applications and cloud-native security, right? I mean you’re deploying containers; security then has to make sure that it understands the ephemeral and immutable nature of containers and security has to shift left and provide controls and guardrails for the build and deploy side of the application life cycle, not just at run time.

    And equally important, security now has to seamlessly integrate with DevOps processes, automation and workflow, because if you don’t then the DevOps organ is gonna reject—or sorry, the DevOps body is gonna reject the security organ.

    Ashley: [Laughs] I’m glad you talked about it in both ways because Kubernetes, containers, that obviously changed the architecture of software and how we’re doing that in the cloud. You know, it isn’t just about locking down servers anymore. It’s really app security level, but at the same time we’re creating software differently. Can you say some more about what maybe some of the unique challenges are that you’ve had to address for both cloud-native world and also shift left within DevOps?

    Shah: Yeah, absolutely. I mean the one big trend, people talk a lot about microservices and containers, but the other big thing that I would like to call out is that Kubernetes has emerged as the de facto standard for orchestrators, right? We did a survey late last year and again six months later and what we found is the adoption of Kubernetes as the orchestrator has grown from 57 percent of organizations using it to now, you know, over 86 percent of organizations using Kubernetes, right?

    Ashley: Wow.

    Shah: And for the right reasons, because it is really, really hard to scale, manage, and deploy containers in large environments, and Kubernetes was purpose built to help you do that. It was an opensource system developed by Google, and Google today uses Kubernetes or a version of Kubernetes, the internal version, to manage over 4 billion deployments at 4 billion containers at scale. So the first thing here is that you have to appreciate the importance of Kubernetes and you have to make sure that security is focused on not just the container but also at the orchestrator and specifically Kubernetes, right?

    Ashley: Sure.

    Shah: And that itself brings a whole new set of challenges because Kubernetes is a large system with significant operational complexity, right? And they just went through a security audit and the assessment team found that the configuration and deployment of Kubernetes is nontrivial, and I can get into the details as to what those challenges are, but the starting point is to make sure that you’re not just focusing on security at the container layer but also focusing at the Kubernetes layer.

    Ashley: Well, isn’t that the truth. We find so often even outside of the container world it’s oftentimes configuration issues, not just the software itself. And as you mentioned, Kubernetes, well as great as it is, it is very complex to set up and operate. It’s not a simple task. Maybe it is as a developer to get an environment running but not in a multi-cluster distributed environment in the cloud, et cetera, high bred, all that kind of thing.

    Shah: They highlighted, you know, the three reasons why it is nontrivial. The first reason was that there are certain missing operational controls, right? So you obviously have to make sure that you understand what those are and put guardrails in place for those controls. The second is that there are a lot of components that have ability to put controls in place but the default settings are confusing, and the big takeaway for me is that we need to distinguish between security controls being available by default and that doesn’t mean that they are configured securely by default, right? So the misconfiguration is therefore the number one concern that users have and it was expressed by two-thirds of the audience in the StackRox State of Container Security Report that two-thirds of the respondents were concerned about misconfigurations.

    Ashley: I believe you even have that report or some information about that on your website. I remember downloading some of that. It has some great information in it. Talk to us about then how do you approach that from a StackRox product standpoint? What parts of those issues does StackRox come in and really help you solve?

    Shah: Yeah. So, you know, what we have taken is really a holistic approach to container and Kubernetes security and we have focused on making sure that our approach is both container-native and Kubernetes-native. So what does that mean? It means two distinct things. First is making sure that we capture all the rich configuration data that is in Kubernetes and use that to address and improve the efficiency of all the use cases that we address in the product. So let’s take vulnerability management as a very simple use case, right? You can go scan images and say here are a list of all the images with a vulnerability score of seven or higher.

    Now imagine you have hundreds of images with vulnerabilities and you give them to developers. What are they gonna do? And I say, well, they’re gonna throw their hands up in the air and say, “Well, I can’t get to all of them,” and that’s where we had the Equifax problem. But by deeply integrating with Kubernetes and being Kubernetes-native, what StackRox does is takes the additional step of saying, “Hey, you know, it’s great that we have these images with vulnerabilities, that’s a good, important first step, but let’s take the second and third and fourth step to understand are those images even deployed anywhere in your production environment?”

    Ashley: Exactly.

    Shah: Right? And if they’re employed in production environment, what data is it accessing, what secret is it accessing, what’s the network configuration, is it publicly accessible, what behavior are we seeing at runtime? And by taking all this rich context we can t hen give you a prioritized list of risks in your environment so you can focus on the most important risks first as opposed to getting a laundry list of issues. So that’s an important—you know, that’s how Kubernetes-native solutions can help you prioritize risk and that’s precisely what we do at StackRox.

    Ashley: I was just going to say, I think this is an extremely valuable aspect of your product because so many security teams—and I’ve talked to even, you know, major online tech companies that say, “I don’t need more information; I need problems solved, right? Tell me what are the biggest, most important things to go after,” and I think that’s a huge part of what StackRox does.

    Shah: Exactly. And, you know, alert fatigue, as I’m sure you’ve heard, is a very common problem in the security industry.

    Ashley: That’s the nice way to say it. [Laughs]

    Shah: Yeah. And by leverage the context, the rich context available in Kubernetes, you can actually make that information more actionable for your development teams and your security teams. So that’s one example. The other example of what it means to be Kubernetes-native is really to leverage the built-in controls available in Kubernetes for policy enforcement, right? And so let’s take network segmentation as another use case where you want to segment your networks between—inside—so that not every container can talk to every container, and there are two approaches. You know, Kubernetes has something called Network Policies and you can leverage those, and it’s much more scalable and robust and it seamlessly deploys within your infrastructure, right?

    The other approach would be to go deploy a proprietary firewall, which is fraught with scale challenges and creates issues if it fails, right? And so a customer again says, “Hey look, when I’m talking about being Kubernetes-native I want to leverage Kubernetes for what it’s designed to do, leverage the native capabilities, because it’s much more scalable and robust, and I want to make sure that my controls are all in Kubernetes, have a central place for policy enforcement as opposed to multiple proprietary tools doing policy enforcement,” which is not the approach and not what Kubernetes recommends and that’s precisely why they have those built-in controls. And so that’s again another example of what—you know, the advantages of being Kubernetes-native and it allows for native enforcement of your policies.

    Ashley: Well, I think that’s another place where, you know, the DevOps intersects with other parts of the organization, DevSecOps, et cetera. You know, a security team might be used to locking down a server or at a massive application level, and as you’ve mentioned sort of outside of the Kubernetes environment locking something down at the firewall, that doesn’t deal with really what’s happening amongst all the clusters, all the containers, microservices. So you’ve really highlighted an important aspect of security, that once security teams get engaged and find out what’s possible now they can, you know, do that through StackRox. That’s gotta be a huge advantage.

    Shah: Yeah, and precisely the reason why we took this approach, because when we go talk to customers what we find is that there are security teams that care about the controls that we are talking about here and then there are platform and infrastructure teams that are responsible for the operationalization of these tools, right? They are responsible for SLAs. The SREs are the ones that have to operate these container and Kubernetes-native security solutions and, you know, they just prefer solutions that are more native to the infrastructure versus deploying proprietary third party tools. And so having a Kub-native approach also helps align security and DevOps teams, and what we are seeing now is as a result that this emergence of DevSecOps, which is all about bringing the two together and really being responsible for the security of your application and your cloud-native infrastructure.

    Ashley: I’m curious. Who is it usually that’s reaching out to you or showing interest in StackRox? Is it the developers, DevOps folks, is it security folks kind of figuring out how to talk to the dev teams? What do you see happening in the market?

    Shah: Yeah, and a great question. We typically see security teams or security architects or application architects reach out because they know they have to address it, and so that’s where the initial conversation starts. What we find is that when they involve the DevOps teams, because they have to get involved to do a proof of concept or even to deploy an operationalized solution, the DevOps teams actually much prefer a container and Kubernetes-native approach as opposed to a proprietary third party security tool because they often refer to proprietary tools as a root kit that they do not want to install in their infrastructure, right? And so it is—you have to speak to both audiences.

    You have to make sure that you cover all the use cases that security teams care about and you also have to make sure that from a day-to-day operationalization of the product it aligns with your DevOps teams, their processes, their workflows.

    Ashley: I have to believe that’s gotta be a big plus to the security team. It’s not another security tool that they bolt on to the network. It’s something that’s built into Kubernetes and managed through Kubernetes and StackRox. It’s also native to the application infrastructure versus something they have to integrate in or yet another tool to watch. It just seems to be much simpler, although it’s a complex topic, but simpler thing to implement as well as manage.

    Shah: Absolutely. I mean you said it spot on. This is security that’s built in versus security that’s bolted on, and if you think about where the security industry is headed it’s all about security as code, right? Where you built it into your applications. People talk about infrastructure as code, which is what we’ve been doing for the past five years, and now we are moving to this security as code where it presents us with a unique opportunity to address security from the very beginning and forever change the security equation in our favor.

    Ashley: I’m curious. When we talk about shift left for security, I think bundled inside that, really what’s also shifting left, is auditing and compliance. Are there things about a Kub-native environment that help us with that as well, the auditing and compliance aspects of security?

    Shah: Yeah. Absolutely. When we think about compliance and, you know, shift left you want to make sure that your Center for Internet Security benchmarks cover both your containers as well as your orchestrator in Kubernetes. If you’re doing any kind of PCI or HIPAA or NIST 800-190 compliance controls you want to make sure that you extend them not just to your containers but also to your orchestrator in Kubernetes specifically. The whole shift left movement is that if I can catch an issue early on and prevent it from being deployed in my environment that is 100 times more effective than deploying it in my environment and then catching it when something goes wrong, right? So the sooner—it’s more preventative as opposed to, hey, we’re gonna detect it—let anything run in the environment; we’ll detect everything bad that happens.

    And, you know, and as we know that’s not effective. You have to have preventative solutions, you have to have guardrails in place that harden your environment so you have fewer chances of things going wrong. And that said, you also need capabilities at runtime, so despite your best efforts, when things do go wrong, you can still catch them and prevent any damage from happening.

    Ashley: Well, that’s the whole observability tracing into microservice, et cetera, understanding what’s happening in the environment. You have to know what the environment is in the first place as well as tie it back to that data.

    Shah: Exactly. And I think what we’re going to see is logs and metrics and tracing forming observability as you point out; and similarly, you know, security is just the other side of the coin, right? So observability and security go hand in hand. What we are doing is leveraging all of that rich information that is available at the node level, at the cluster level, and leveraging that to protect your applications across the entire lifecycle.

    Ashley: Excellent. Well, we’re coming up on the end of our time here. One last thought. Is there a certain best practice or something that you’ve observed as you work with customers when they begin engaging with StackRox and see your technology and what it can do for them? What is the thing that they walk away saying, “Wow, this has really helped me and I’ve solved the following problem or knowing the following has saved me a lot from avoiding some problems”?

    Shah: Yeah. So there are a lot of, you know, great resources available on our website at www.StackRox.com, and we talk a lot on misconfigurations and we’ve highlighted some best practices. For example, making sure that you use a read-only root file system, right? Because that’s a very powerful mitigation against attempts to gain foothold in your infrastructure and the adversary’s job becomes that much more difficult. Or minimize the image contents, because a lot of file systems often contain bash or package managers which further enable an attacker to do bad things, and so remove all nonessential binaries or pay attention to your Kubernetes RBAC configuration.

    Why? Because Kubernetes API is a critical attack surface. It controls what happens in your cluster and it controls what security configurations are in your cluster, and so if you minimize who has access to that Kubernetes API it prevents—it again hardens your environment, and also upgraded to the latest version because Kubernetes, the community, is constantly adding more and more security controls, they’re constantly addressing vulnerabilities that are discovered, and so running on the latest version of Kubernetes is also an important step that you can take to secure your Kubernetes environment. So there are lots of other, you know, best practices that I would call low-hanging fruit that we’ve called out on some blogs that we’ve written about, and that’s irrespective of whether or not you’re using StackRox, right? These are just some good best practices as you embark on your journey to containers and Kubernetes.

    Ashley: You do have an excellent blog and I would certainly recommend that to our listeners. Well, it’s been great talking with you. Kamal, thanks for being on the podcast.

    Shah: Mitch, thank you so much for having me.

    Ashley: It’s definitely been my pleasure. So I’d like to thank Kamal Shah, CEO of StackRox, for joining us today. You, of course, have listened to another DevOps Chat podcast and I’d like to, of course, thank our listeners for joining us today as well. This is Mitch Ashley with staging-devopsy.kinsta.cloud. Thank you for joining us. Be careful out there.

    — Mitchell Ashley

  • DevOps Chat: Value Stream Management With HCL UrbanCode

    DevOps Chat: Value Stream Management With HCL UrbanCode

    Value stream management (VSM) is a term we hear with higher frequency. DevOps, Agile, Lean and contemporary application development are very dynamic. These rapid, dynamic approaches can make the software development process opaque to the broader organization. It’s early in this part of the market, but it’s born out the need for quantifying the business value coming from our investments in software development.

    Steve Boone, head of product management at HCL UrbanCode, joins us on this episode of DevOps Chat to talk about the state of this emerging market. Steve shares valuable insights about how organizations are working together, where DevOps and Agile are making a measurable difference and what management can do to provide teams with tools to manage their VSM.

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

    Transcript

    Mitch Ashley: Hi, everyone. This is Mitch Ashley with staging-devopsy.kinsta.cloud, and you’re listening to another DevOps Chat podcast. Today, I’m joined by Steve Boone, head of product management at HCL UrbanCode. Our topic for today is extracting value stream management from your existing DevOps culture. Steve, welcome to DevOps Chat.

    Steve Boone: Hey, Mitch! Thank you so much for having me here today. It’s an honor.

    Ashley: It’s an honor to have you on. We appreciate you joining us. Would you start by just introducing yourself, tell us a little bit about what you do at HCL UrbanCode and a little bit about the company?

    Boone: Yeah, absolutely. I’ve been with the UrbanCode brand now for a little over 13 years. If you’re not familiar too much with UrbanCode, back in 2013, we were acquired by IBM, and then just recently, about two years ago, we entered an IP partnership with HCL. Which is fantastic, because then we have both the likes of IBM and HCL investing into our whole portfolio of UrbanCode products. You know, everything from continuous integration, continuous delivery, release orchestration, and lately, we’ve been turning our eyes towards value stream management and trying to focus on how we can help enterprises take that next step and challenging and kind of solving what we think of are day two DevOps challenges, you know? Kind of overcoming the fact that now that we’ve got all this automation, how do we take it to the next level, how do I identify the new bottlenecks that are emerging in my organization and become more successful? I think, ultimately, that’s what we’re all trying to do.

    Ashley: Absolutely. We should start with a little bit of a definition. How would you define value stream management?

    Boone: Boy, it is a great question. I think it is very much kind of an emerging market. When we think about value stream management from an UrbanCode perspective, we’re really looking to make sure that the work that our development teams are doing is one, aligned to be overall business goals, right? And then two, we want to be able to provide the data and information that’s important for not only development teams but testing teams, designing teams, for them to be responsible for what we would think of as their own value stream.

    And when we think about it, it’s really the idea of how do I take something from idea and move it all the way into, let’s say, production or my customers’ hands? But what are all the different steps along that journey, right? That’s really what we think of as the value stream.

    So, have an idea. Eventually, that idea turns into some item in my developers’ backlog, and then I wanna progress those several sets of ideas that equate to some business value. And, you know, years prior, in the throes of the DevOps revolution, if you will, you know, a lot of the things that people would say—“Well, your bottleneck’s clearly in deployment automation” or, “It’s clearly in test automation.”

    And that’s just not the case any more. I mean, many of these companies have invested millions of dollars in people, process and tools, right? And now, they’re starting to come back and go, “Well, great, we’re doing all of these things. How do we get better? Where are my new bottlenecks?”

    And value stream management really looks to kinda shed light on that space and help people understand where the new bottlenecks are emerging within their organization.

    Ashley: Excellent definition. I totally would agree with how you’ve laid it out. Validate if you think this is a correct or help me advance the idea a little bit—it seems like value stream management has come on the scene because things like agile, lean, DevOps, very dynamic processes that are creating software, doing work in much smaller increments, much more flexibility about how you pivot, adjust, take on the next story in an agile way, whatever it might be. But that also can be very confusing and opaque to the organization, trying to understand if we insert money here and requirements for products here, what do we get out? And the value stream management is maybe a reaction or a way of putting kind of a systemic view on what’s happening in all of that process so we can understand both where we’re getting the value and are we getting the things that we needed to take to market as well as continuous improvement and how we can get better.

    Is that on track? Do you think maybe that idea needs to be advanced in a little different direction? What are your thoughts?

    Boone: No, I think the market’s really early, and I think that what you’re saying reflects that, right? It’s a very big message that I think value stream management is trying to take on.

    I kinda look at it as a couple of things, right? I think you’re right. There are many different development teams within an organization. I think these days, many of them would raise their hand if you said, “Hey, are you an agile team?” You know, having many agile teams doesn’t really necessarily make an agile enterprise, right?

    And so, the question becomes, what are we doing differently across these teams? How do we surface best practices? How do I gain visibility into the work that these teams are doing? And how does that roll up?

    So, if I am a C level executive and we say, “Hey, you know, we wanna go invest in these new features and functionality”—well, what’s the right technology to do that in, what are the right teams that we should handle that onto? What are those teams currently working on?

    All of those become very important questions. And I think, more importantly, when you look at the investment that these organizations have made over the last 10 years in DevOps, there’s a little bit of kind of mounting pressure to be able to show an ROI, you know? Out of the people that we’ve invested in and the processes that we’ve been working on, the tooling that we’ve acquired, is it paying off? And if not, why not? What do we need to adjust?

    Ashley: Yeah, excellent. I think you’re right and I appreciate you saying that up front. It is emerging, it’s still kind of being formed, and we’re early in this process.

    One of the things that enterprise organizations tend to do is, they don’t always like to be first in something. They like things to be proven out. Not always, but you don’t want to be on the bleeding edge of everything. How are enterprise organizations approaching value stream management in these earlier days? Are many of them jumping in, are a few taking the lead, and there’s other followers? How do you see this unfolding?

    Boone: Yeah, you know, it’s kind of been an all at once thing. I don’t think any organization is unfamiliar with the concept of value stream management. What we’ve seen is, they typically go through some kind of value stream process once or twice a year where they’ll look at from kind of a large, 1,000 foot picture, how is the organization working together, right? How does work turn in this giant crank, and how do we improve it?

    But kind of the theory of DevOps, right, we want that fast feedback and once or twice a year looking at your whole organization and how ideas move through it—that’s not really effective, and it’s definitely not feedback for the people who are doing that work.

    And so, what we’re starting to see is management try to give teams the tools they need to control their own value stream and to be responsible for that value stream, right? In a large company, they’ll say, “Hey, we’ve got value streams everywhere.” HR could be its own value stream—how we hire and train new employees into our organization has an impact on the type of work we’re able to deliver.

    From an UrbanCode perspective, we’re focusing on value stream where we know best, which is continuous integration and continuous delivery. So, we focus on looking at the tools that are in our space, whether those are deployment tools, build tools, testing tools, source code tools, and then we start looking at, “Well, who are all the players in a typical development team that advanced these ideas?” Right? You know, our development teams are dependent on design teams. They’re dependent on testing teams.

    And all of those have an impact in things like lead time and cycle time and mean time to recovery. Kind of the main types of things that, if we were to look and ask somebody, let’s say DORA, the types of metrics they care about and, you know, identifying high performing teams and being able to look at other teams and say, “Hey, look, these are kind of metrics we’d like to see you improve upon.”

    So for us, we’re looking at the value stream very much at a kind of AppDev/Operations level, but with big business value in how you can roll that up to the business, and justify the work that’s being done, justify the investments that are being made and to continue to recognize areas of improvement within that DevOps culture.

    Ashley: Well, it seems as organizations evolve and their adoption of DevOps eventually run into what were traditional stage gates, maybe you can view them as barriers, stopping points, because the rest of the organization is not set up to operate in that kind of dynamic flow, and it has traditional kind of waterfall processes. It seems like what you’re doing with UrbanCode is, you’re not only automating and integrating that at full CI/CD process across the tool set, but you’re also giving information that ties back into communicating some of those things that will help teams more easily flow through, pass, or if it is a stop, it’s minimal, because you’ve got all the information there that you need to say, “Are we ready to go into production?” or, “Were these things in the release?”

    Is that how you’re connecting kind of value stream to the dev process?

    Boone: Yeah, that’s right. I mean, one of the key things we look at is just, you know, where are these ideas that developers are working on store? Well, you know, typically, they’re in something like JIRA, right, or RTC—but there is some backlog management that is holding these really brilliant ideas, and they’re in the form of Epics and work items and they’re tied to sprints and releases.

    And so, you’ve got all of these ideas, and they’re all in motion. They’re all at some stage of work. They’re either sitting in a backlog or they’re being designed or they’re in progress or they’re in review, or they’re being merged, they’re being built. And that idea has a journey. It has a history and a life, and if we can start kind of surfacing that journey, then people can start seeing how ideas flow between various different teams, right?

    And everyone’s trying to do the best that they can for their group, their team, their application, their project. It is by no means about pointing fingers and saying, “Oh, well, we were held up on this release or this particular value, because it didn’t come out of testing fast enough” or “We didn’t get the designs fast enough.”

    But it is about surfacing the relationships between these different teams so that we can start having meaningful conversations with the right folks to improve these small bottlenecks that kind of crop up from time to time within our own internal processes. And, you know, very much like we talk about people, process and tools, at the heart of that is culture, right? And I think one of the really cool things about value stream management is, executed correctly, we can really start to enforce that DevOps culture and kinda stoke the flames of that, right? Reignite in the creativity and really get people bought in on the sense that it’s not about one individual team or application, it’s about the enterprise working together to deliver value for our customers in the most efficient way possible.

    Ashley: I love where you’re heading with this. This seems like one of the potential natural reactions of the DevOps team or development organizations is, since the organization hasn’t quite worked in that kind of an environment, value stream management could be seen as a way of gaining control, which is sort of the dark or the negative side of this. Another way to look at it is bringing transparency and giving, you know, really looking at a systemic view, as I mentioned earlier, across this.

    Have you seen that reaction of kinda pushing back against value stream management, because this sort of feels like the big brother kinda coming in and trying to grab control, or do DevOps teams pretty quickly see where the value is and start to embrace it?

    Boone: Yeah, I think it’s a couple—I mean, I definitely, I think back to the earlier days of just continuous integration, right? We have that thing where, if you broke the build, you’d get the big red light flashing in the dev pit and people would look and be like, “Oh, he must have broke the build over there” and—

    Ashley: The wall of shame. [Laughter]

    Boone: You know, you’d have to—yeah, it’s like, you’d have to wear the dunce cap. I think we’re far away from those days, but there is still some hesitancy, right? I mean, the reality is, if you go into a lot of organizations and say, “How is your DevOps journey going?” they’re gonna go, “Oh, pretty good. We’ve added a lot of automation. We’ve invested in a lot of training. We feel pretty confident about where we’re at.”

    So, any time you walk into a dark room and kinda turn that flashlight on and see the real data for the first time, there can be some alarming things there, things that people didn’t necessarily now about. You know, maybe some quote-unquote skeletons in the closet, so to speak.

    But what I’ve learned is that development teams, they really want to be the best that they can be, right? They wanna deliver high quality product and they wanna do it in a bleeding edge, fast way.

    And so, if we’re giving them the feedback of how their work is moving, and if they can see where things are breaking down, they tend to do the right thing. They have the meaningful conversations and they improve and take responsibility for their own value streams. And that overall starts to drive the business that much more efficiently, right?

    So, I think that’s one of the really positive aspects about it is it gives people the tools needed to take that responsibility. And then, sure, as we roll that data up—so, you know, you provide value to the development teams, that data and that value then rolls up to the upper levels of management, so they can effectively run a business, right? I mean, at the end of the day, there’s still a whole lot of money tied up in these organizations. So, if we wanna put together a new plan, a new set of functionality, if we wanna be first to market, we wanna make sure that we’ve got the right teams, we’ve got the right technologies and platforms, and that the efforts that we’re investing in are aligned to the business goals.

    And so, there’s kind of a win-win for both sides of the house. You know, the AppDev team wins, the business wins. And where we really think we can make a lot of impact is, some of the groups that maybe haven’t quite felt as much love in the last couple of years in the DevOps space—I’m talking more about our folks that are sitting in operations, security, testing, maybe some of the folks that are more focused on our agile success.

    You know, we see more and more of these high turnover rates of developers and management within organizations. You know, as you move from company to company, the definition or the implementation of agile best practices is probably a little different and maybe even changed, right?

    Ashley: Mm-hmm.

    Boone: So, how do we make sure that everyone understands how our business works, how things are working here and so that we can constantly be working to improve that process?

    Ashley: You know, one of the things that I get asked frequently, both by individual technical experts, developers, even leaders of technical organizations is how can we better communicate with the C suite. And usually, it boils down to, you have to talk in business terms. You know, how is this investment or this money, whether it’s a process improvement or a technology, helping us increase revenue, bring in new revenue streams, improve customer experience, reduce churn—which is always kind of a famous one, catch all.

    But you have to put it in business terms, and it seems like if you believe in what you’re doing, if you believe in DevOps—and we know it’s not all perfect, we’re all a learning organization—that transparency can help you get very quickly to say, “Why is investing in another test tool, or investing some time in re-engineering, a process worth spending the money on it?” Because we can see the results of it and we can also have a way to communicate what we’re doing and the value of doing that.

    Boone: That’s exactly right. I can give you kinda two classic examples of that. You know, right now, we see a lot of companies trying to rearchitect or modernize their applications to speed up delivery, right? So, we’re taking distributed applications, we’re building them into microservices with the idea that they’re much easier to manage from a configuration and a delivery standpoint.

    Ashley: Mm-hmm.

    Boone: But there’s a cost associated with taking a team of developers and saying, “Hey, you need to rearchitect this thing.”

    Ashley: Absolutely.

    Boone: So, you basically need to build it from the ground up, but you also need to manage the existing business value that’s keeping the lights on.

    And so, if you’re gonna make that investment, you know, six, seven, eight months from now, even while you’re making that investment, you’re gonna wanna be able to know how long does it take for us to actually do this? Is this something we can repeat elsewhere in our organization? Does it make good business sense to do that, or should I just focus on building new microservices and new applications and not focus on rearchitecting?

    Ashley: Mm-hmm.

    Boone: You know, other places where we see this manifest is, you know, one of the things that constantly can be what we call a drag on a team’s velocity is things like unplanned work or incidents that might pop up, customer support. It would be really easy for management to say, “Well, we’re not getting what we need from this development team. We need to hire more developers. Obviously, if we throw more people at it, that’ll fix any issues we have.”

    But what kind of people, you know? It could be that we need more support engineers, we need more designers, we need more testers. And so, understanding where resources, people are, the type of work that they’re doing, where that work gets held up is extremely important to understand what kind of folks we should go hire, what kind of training might we need to improve that culture that we’re trying to establish?

    Ashley: Since you’ve kind of been engaged in the value stream management part of this, are there—have we gotten to a point where you have maybe a couple of best practices, “if you’re implementing this, kinda going down this journey, some lessons learned or make sure that you do this” kind of thing, trying to lead you to the best chance of hitting a home run or at least a first experience with value stream management?

    Boone: Yeah. You know, when we first started talking with customers and they’d say, “Well, how would we get involved in understanding our value streams better?” We like to do small workshops, right? And a lot of it starts at a white board with some open and honest conversations, right? Again, the whole idea is, we’re not really here to point fingers, but we’re here to understand how we get better.

    We sit down and start to think about—okay, well, if we get a brand new idea from the business, what is its journey? And I think if you get five or six different people in the room, they’ll come up with the 80% of the journey and then, through more conversation, you’ll start to understand—yeah, well, sometimes, we’ve gotta pull in these different shareholders. Or sometimes it gets held up in kind of political red tape of approvals and sign offs and we don’t get those for weeks at a time.

    So, you start to air some of that laundry, but at the same time, you really start to get to each individual step of the value stream and the journey that it goes through.

    Once we kinda have that planned and visualized out end to end, then we can start looking for areas of improvement, right? And I think those are kinda the basic things I see companies doing now.

    The ones that are being a little bit more aggressive are starting to visualize these different processes as they change state. So, they’re getting to where we can start mapping and tracing the actual journey of a work item, from commit to pull request to actual code merge to build, deploy—you name it.

    And, as part of that, they’re starting to look at some of the tools that are out there. You know, UrbanCode Velocity is great if you’re looking to get started for a two person, or I should say a two ____ team. You know, pull it down, the community edition is free to get started with and start integrating your tools. And you can start seeing these work items come to life and see how they start to propagate all the way from your back log, hopefully into your customers’ hands.

    And it’s been a pretty eye opening experience, I’d say, for a lot of teams, because they’re learning quite a bit about their own processes, and then having really meaningful conversations with other teams, kind of an, “Oh, did you know? Hey, are you guys seeing the same type of process bottleneck within  your own organization?” And it’s been fascinating to watch.

    Ashley: That’s super helpful and I appreciate your thinking around let’s start with the fundamentals, laying out the process, and getting agreement about where we are and then start to instrument from there, and you all do some great work with UrbanCode and having that community edition is really a kinda low barrier, low resistance approach. You can just bring it down, download it, start working with it and understand how you can start applying it to what you do. It’s a great, great tool.

    Boone: Yeah, thank you. We’re really excited about it, because it is a very new space, but we kinda see the opportunities abound in front of us for being able to improve not only how people work day to day, but improve the culture that they have for the folks around them. Building software is exciting, and at times, it can be quite stressful, right? And I think that, as people show up to work every single day, one of the things they wanna do is be a part of a culture that’s supportive, that’s creative and that can help them be the best people that they are.

    And I think value stream really gets to the culture of DevOps, right? How do we make sure that what we’re doing as an organization is for the best of the business? and make sure we’re giving people the tools they need to succeed.

    Ashley: Mm-hmm, absolutely. Well, Steve, thank you very much for being on DevOps Chat with us—Steve Boone, head of product management for HCL UrbanCode. Steve, thank you.

    Boone: Mitch, thanks so much, again. It was a real treat.

    Ashley: And of course, we want to thank you—you, our listeners, for joining us today. This is Mitch Ashley with staging-devopsy.kinsta.cloud and you’ve listened to another DevOps Chat. Be careful out there.

    — Mitchell Ashley

  • DevOps Chat: Red Hat Developer Experience in the IBM Era

    DevOps Chat: Red Hat Developer Experience in the IBM Era

    Red Hat Linux is a staple of most enterprise IT organizations’ software diets. Developers and IT leaders all over the world took notice when IBM acquired Red Hat. Will IBM Red Hat change? Will Red Hat continue to operate as it does today or will it be subsumed and disappear into some IBM business unit? Will IBM Red Hat still contribute to projects and tools like Kubernetes, JBoss, Fuse, OpenJDK, Eclipse IDE and many others? All are important questions.

    Brad Micklea, lead of the Developer Program and Tools at IBM, joins DevOps Chat to talk about the future of Red Hat as part of IBM. Brad sends a strong message that Red Hat will remain focused on the developer community and tools for Linux, Kubernetes, Java, DevOps and others.

    Join us as we talk with Brad about the future of Red Hat, DevOps and open source developer tools.

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

    Transcript

    Mitch Ashley: Hi, everyone. This is Mitch Ashley with staging-devopsy.kinsta.cloud and you’re listening to another DevOps Chat podcast. Today, I’m joined by Brad Micklea, lead of the Developer Program and Tools Business Unit at Red Hat.

    Uh, Brad, we’re gonna talk about the Red Hat Developer Program experience in kind of this new era, post-era, of acquisition by IBM. Brad, welcome to the DevOps Chat.

    Brad Micklea: Thanks very much for having me. I’ve been a fan of staging-devopsy.kinsta.cloud for quite a while, and so it’s exciting to be able to talk with you today.

    Ashley: Well, thank you. We’re a fan of you and a fan of Red Hat. So let’s start out by having you just introduce yourself, if there are some folks who don’t know who you are. Introduce yourself, a little bit of what you do at Red Hat.

    Micklea: Absolutely. So I run the Developer Tools Program and Evangelism group here at Red Hat. Uh, I’m actually fairly new to Red Hat. I’ve been here about two years. I came into Red Hat via the acquisition of Codenvy, which is a little startup out of California that I was part of, although I’m based in Toronto, Canuck power. Um, so–

    [Crosstalk]

    Ashley: You had to get that in. Good for you [laughs].

    Micklea: I did. I did. I always have to get that in [laughs].

    Ashley: Oh, goodness.

    Micklea: Yeah. So that’s, um you know, so our mandate really is to make–kind of help the whole organization in, you know, reaching out to developers. We have the developer program where developers can come and get great content on topics like Kubernetes and Java and Linux, as well as things like secure programming, DevOps of course, and a number of other things. Uh, we pair it–we kind of marry that with a set of developer-oriented tools that support our projects and our products.

    And evangelism is done as well, of course, in the upstream communities and events and other places, to help developers become aware of what they may not know, which is that Red Hat is not just the Linux company, although, of course, that’s a huge part of what we do. We do so many more things than that in the open source.

    Ashley: Well it seems certainly Red Hat is the model for, you know, a program like that with the developer community, with the user community. And you all have done a fantastic job of expanding that into other areas. Talk a little bit about–it’s more than just the operating system. Tell us about what some of those things are.

    Micklea: Yes. Well, of course, right now, a lot of the buzz is around Kubernetes. And a lot of people don’t realize that Red Hat is actually the second largest contributor and committer to the Kubernetes project.

    Ashley: I did not know that.

    [Crosstalk]

    Micklea: Yeah. Yeah, it’s one of those things where, you know, we’ve been probably the second largest contributor for pretty much the entire history of Kubernetes, but a lot of times it just goes unnoticed. We run SIGs, a number of different things out in the open source for that project and related projects like Tekton, like _____, et cetera. So that’s a huge focus for us right now, and something that is–I’m certainly very passionate about, personally having come, like I said, to Red Hat via a very container-oriented company.

    But beyond that, we have, of course, our middleware portfolio is huge and has been around for, you know, well over a decade with, you know, OpenJDK is, of course, a Red Hat project. We’ve got all of our middleware solutions, whether it be, you know, JBoss or some of our integration platforms like Fuse, our automation platforms.

    So there’s really a ton of different things and it really is something that is exciting about being here for me, because there is a lot of stuff for developers. Although people think of us as a very kind of ops-centric company, we have always had developers at heart and certainly, you know, it’s a company of engineers, really, which is probably why, in some cases we–people don’t know all these things we do because we’re engineers, not marketers [laughs], you know, so.

    Ashley: Write a lot of software you do.

    Micklea: That’s right, exactly.

    Ashley: So I mean, you know, it’s not just Linux. I know you’ve contributed to Java, like IDEs, if I remember right. I think you contributed to Eclipse or something.

    Micklea: Absolutely, absolutely. We were one of the kind of early contributors and continue to contribute to the Eclipse Desktop IDE as well as other Eclipse projects. We’re actually one of the key, I guess, contributors to the Eclipse Cloud Development top-level project and to various projects under that umbrella.

    But also, and this is kind of mind-blowing perhaps for some people who haven’t been tracking where Red Hat has been going over the last several years. We publish a large number of plug-ins for the VS code IDE and–

    Ashley: Microsoft.

    Micklea: Microsoft’s, yeah, Azure DevOps. And, you know, certainly there was a time, maybe what, a decade ago, when the idea of Red Hat and Microsoft hanging out together would have been just inconceivable, but–

    Ashley: There’s been a lot of ret, that’s about it.

    [Laughter]

    Micklea: Yes, that’s right, exactly. But, I mean, those plug-ins have done fantastically well for us. The Java support that you have in VS code is, you know, comes from Red Hat and has, I want to say, a little over 60 million downloads at this point.

    Ashley: Wow.

    Micklea: So it’s incredible stuff, yeah.

    Ashley: Well, it’s amazing how the developer community, you could kind of picture back to the Java days, when you were just Java and that was it and that was the solution to everything. And while Kubernetes has certainly set the world on fire, containers really has, but it’s interesting. What I see is how much the developer communities kind of cross and intersect with each other and work with each other, both at the vendor level, at the company level and just at people developing software. So yeah, you may have a favorite in Microsoft or Google or, you know, in Amazon for a hosting environment or whatever, OpenShift, something like that, but people do a lot more work together it seems like to me. Is that your experience?

    Micklea: Absolutely. And I mean I’m like you, of a certain age, where, like, I remember the people used to just identify themselves as, “I’m a Java developer.”

    [Crosstalk]

    Ashley: “I remember when,” yeah.

    Micklea: Yeah, exactly, right.

    Ashley: “Back in the Java days.”

    [Laughter]

    Micklea: But I mean today, that’s not really the case. Pretty much everybody codes in a couple different languages, at least, sometimes more than that, and has personal projects and the work projects. And so I think it’s just become the norm for developers to kind of pull from many different areas of the community, you know, getting inspiration from different areas and bringing things together in a way that just works for whatever their particular project needed.

    Ashley: You know, it may be a causality, it may be the source of it, but things like DevOps, things like Agile, it’s really changed the way we even think about creating software or the way we form teams, you know, shift left. There’s organizations where they’re trying to sell into a customer base that those people are different now. The security people are part of a dev team and they’re learning development. And in a way, it’s both creating a lot of new business models and operating models on how we create software. It’s also creating question marks maybe and some confusion for some vendors and manufacturers of, “I don’t know if I understand DevOps yet, but I sure got to figure it out because that’s where the world is going.”

    Micklea: Oh, I couldn’t agree more. And I’ll just say, like, thank goodness it is ’cause, um, I certainly–[crosstalk]–don’t miss the way software used to be developed.

    Ashley: Oh, come on, those silos, oh, those were the fun days, yes.

    [Laughter] 

    Micklea: Yeah, but I think it’s interesting, too. Again, as, you know, from our perspective, a lot of what you see in good DevOps practices is similar to what you see in a healthy open source community. You have, you know, people coming to–the whole point or an open source community is that it is open and everybody really is on the same team, and there isn’t so much the straight lines of, “Hey, this group in the community only deals with security, and this group only deals with that.” People do blend. They bring whatever skills they have, whatever experience they’ve got–

    Ashley: ____ to work on, right.

    Micklea: Exactly, that’s right, and I think you see great DevOps teams or–pardon me–great teams that follow DevOps principles, I think you see something very similar, where it isn’t so much like, “Hey, I’m Brad. I’m the ops guys in this DevOps, you know, world. You know, Mitch is the dev guy in the, you know, in this world.” It’s not like that. It’s just, you know, I come and I say, “Hey, I’ve hit this security issue, so let’s not do it this way. Let’s do it this way and we’ll avoid it.” And I think that that’s really what makes it exciting.

    Ashley: Well, you know, you’ve connected those two dots of open source and DevOps in a new way for me, and maybe we really do need to credit open source for creating that and a work team environment that’s evolved now into this DevOps structure. So it makes sense to me. I mean look where open source is coming just in the last ten years, more or less before that. So I’m really curious to–it’s just a rare occasion we get to speak with someone who is really kind of overseeing and leading on such a big community of contributors and users of all the Red Hat technology.

    What does that take? What’s a day in the life of Brad like?

    Micklea: Hmm, uh, it’s interesting. I think one of the things I love about my job, honestly is that I’m a little bit–I get bored easily, um, [laughs], and so this is a job that is never boring. Um, I’ve come from more of an engineering side and product side. So for me, it’s pretty natural to be hopping around, investigating new projects, um, you know, jumping in to get hub repos and looking at pull requests and contributor stats and seeing kind of how is the community and the engagement within different projects changing over time.

    That’s all, you know, just kind of part of kind of who I am and how I work. The part that’s interesting and fun for me is, you know, now hitting more of the program side and the marketing side and, you know, working with folks who are, thankfully, much, much more experienced than I am on my team in this area, and learning from them about, you know, how we can reach out to developers, how we can get our message heard by them, and then helping other folks, both within Red Hat and outside, to understand kind of the best way to speak to developers.

    And I’m, I think, really proud, I guess, of the way that the approach that engineers naturally have to their job, which is one of kind of no nonsense, no hyperbole, just, you know–just the facts please. Let me judge for myself whether this is the greatest thing since sliced bread or whether it’s irrelevant to me.

    And I think that I’m starting to see and I like this, that more and more aspects of marketing, even beyond developer marketing, are waking up to this, this idea of, “We’re the number one,” isn’t the best way to market. It’s really more about saying, “We do this. We do that, and we do the other thing. And if you need those three things, then we might be the best thing for you. And if you don’t need any of those three things, then you probably don’t care.”

    Ashley: I could go on–I could go on a tangent of how many sites, vendor sites I’ve been to and said, “I read your site. I have no idea what you do, but [laughs] nice site.”

    Micklea: That a huge thing, you know, and it’s one of those things that I’ve always been very passionate about when it comes to positioning and content is–and, again, it comes from that engineering background, is I don’t want adverbs. I don’t want adjectives. I just want a description of what it is.

    Ashley: Save the hyperbole.

    Micklea: Yes, save hyperbole. Tell me what it is in plain English, and then I’ll tell you if it’s useful for me.

    Ashley: Mm-hmm. It’s much more of a transparent and kind of honest relationship with the customer, the user, where we’re not trying to flower it up. Yes, we’re trying to–yes, put our light on it, but in a way that they’re gonna consume it, ’cause you’re right. They’re not gonna take the hyperbole and the, you know, we’re the world’s best of everything. We know you’re not, right.

    Micklea: Well, exactly, and I think–

    Ashley: So I’ll be the judge of your technology.

    Micklea: That’s right, and I think if you show people that respect, you know, they reward you. And ultimately as a business even, ’cause, you know, Red Hat is not a, you know, an NGO. We’re a business. We make money.

    Ashley: Mm-hmm.

    Micklea: I’d always rather go to somebody, tell them exactly what they do, and know that either right away they’re gonna say, “Not for me,” and walk away and I lose them. I’m okay with that. I was never gonna win them.

    Ashley: Yeah.

    Micklea: You know, and I’m–so now I can focus on the people who didn’t walk away right away, and now I know that I’ve got a better chance of kind of converting them to my products.

    Ashley: Well, you know, one of the topics I wanted to cover with you is not too long ago the IBM Red Hat merger/acquisition had been completed. And I’m sure you’re not an expert on all things in the merger [laughs] and all things that happened, but what kinds of–if you can share with us, and if not, that’s okay–what kind of things have you heard from the community? What questions are they asking you, now that you’re part of IBM and how have responded? I know you wrote a blog post about some of these things.

    Micklea: Yeah, no, absolutely. And I– let me just start actually by saying that this acquisition personally kind of blew my mind. When I–when I first got the e-mail, it actually was one of those e-mails I had to read two or three times to make sure I was actually reading it properly–

    Ashley: [Laughs] is this, uh, April 1? What happened?

    Micklea: Really, I mean because $34 billion for a company that has nearly no IP. Like, that–when I read that, having been through numerous acquisitions in the past and, you know, having been close enough from an executive level to them that I, you know, was involved in negotiations for how much is this company worth based on how much money does it make, based on how much IP does it have, all those normal questions, I thought, “That’s incredible.” What an incredible kind of proof point of the value and increasing dominance of open source.

    Ashley: And the community. That’s the value.

    Micklea: And the power of the community, exactly. You took the words right out of my mouth. And the power of the community, $34 billion in terms of value of that community.

    Ashley: It’s amazing.

    Micklea: Um, you know, so I think what’s understandably the, you know, initial reaction from many people, you know, both in the community and inside Red Hat and elsewhere, was a bit of skepticism on how this would turn out.

    Ashley: Of course, because you expect–it’s only natural, right.

    Micklea: It’s only natural.

    Ashley: You’ve seen these things happen before. They go well. They did not go well.

    Micklea: Yeah.

    Ashley: You know, what’s gonna happen to us?

    Micklea: That’s right. And, you know, I think it’s easy for people to forget. One of the benefits of having worked in dev tools is I’ve been close to this. IBM has, you know, contributed to open source for a long time now.

    Ashley: Mm-hmm.

    Micklea: That doesn’t make them like Red Hat. I mean Red Hat is quite different and quite unique in the way that we don’t really have any proprietary products. But, you know, at least they are open source aware and have been contributing to open source, and especially, like I said, around dev tools. That’s really been the whole way that they’ve done their dev tools.

    You know, so I am optimistic and kind of in my blog I talked about the fact that the plan is for the developer program of IBM and the developer program of Red Hat to remain separate, and there’s a commitment from both sides to do that.

    And it was funny because going into my very first conversation with my IBM colleagues to try and discuss this, I was honestly quite nervous. I thought you want me to go in there. I don’t know these people, and the first thing I’m gonna say is not very embracing. It’s gonna be, “We’re gonna keep these things separate, guys. I’m sorry. You’re not touching my program.”

    Ashley: Got to go in there swinging, fighting for what’s important, right.

    Micklea: Exactly, and I said–that’s exactly what it was. I said, “You know, this is important to me, so I’ve got to start there.” What amazed me and it was I think a very, very nice thing to see is that from the very beginning it wasn’t even a question. They were like, “Well, oh yeah, of course it’s gonna remain separate.”

    Ashley: Interesting.

    Micklea: Like you need to be separate. You have all that kind of credibility that you’ve developed over 20 years with this community and within open source, and we don’t want to change that. That’s why you’re worth $34 billion.

    Ashley: So now you got my head spinning. Why do you think–how did they come–the folks putting the deal together, how did they come to that conclusion so clearly, where you didn’t have to convince them?

    Micklea: Well, I think that to their credit, there are a lot of smart people in IBM.

    Ashley: Sure.

    Micklea: And, you know, they looked at Kubernetes. They looked at Linux and said–and our Java, and really said, “Hey, you know, these are three core components not just in people’s, you know, datacenters today, but in the way that IT and development will together in the future.” And so, if we go and try and take them, you know, buy it and then grab this stuff and make it proprietary and, you know, do all those things, which, frankly, a lot of people would have expected them to do, there’s nothing stopping everybody from walking away.

    Ashley: Mm-hmm.

    Micklea: There are alternatives and people vote with their feet. So I think that they had the clarity of mind to say, “If we do that, we’re going to be buying a company and then destroying the value of our investment. If, on the other hand, we allow that company to run as it has, and instead give ourselves, IBM, the ability to focus our resources and thinking on parts of this portfolio like OpenShift, like Red Hat Enterprise Linux, so that we can kind of add additional weight and momentum behind them,” and I think that’s really where they see the ongoing value.

    Ashley: It’s awesome that they did that and I think one of the characteristics of something that has a community built around it like this is people make an emotional connection to the brand and to the community, right. They believe in Red Hat. They believe in what this group is developing and the approach that they’re–we’re taking with open source and, you know, being free contributors to it and having that flexibility. And so they don’t want to lose that. So it’s super-smart to keep–I’m not saying there’s anything wrong with the IBM developer program, but it has its characteristics, too, and blending them you–instead of getting the best of both, you might get the worst of them both.

    Micklea: I think that that was exactly the thought, is that if you blend them you’re gonna get actually the worst of both and not the best. And their program has, like you said, a bunch of strengths that ours doesn’t have. Like, we are not able to cover the breadth of topics that they are. We just don’t have the size or expertise to do that.

    Ashley: Mm-hmm.

    Micklea: And so we don’t try, you know. That’s something that’s great for them and they have a killer program, and if you, you know, if you haven’t, Todd Moore wrote a–from IBM–wrote a great blog about the acquisition and kind of his excitement.

    And then from the community perspective, Chris Wright on the Red Hat team also had a wonderful blog on kind of what it means for the community. But you’re 100% correct. The feeling of the community towards Red Hat, and that was one nice thing about the acquisition. Although a lot of people were very vocal about, you know–’cause I was on Hacker News when it happened and trying to respond to some of the–to some of the threads that popped up. You know, people were very vocal about I–you know, this feels like it’s gonna be the end of Red Hat.

    What was–you know, and obviously, I don’t feel that, but I understand where they’re coming from. What was nice though is that it shows the degree to which they cared. You know, there was genuine feelings of sadness in those posts, even though they’re–you know, they’re not–you can’t hear the voice. You could kind of just feel through the post somebody saying, “Oh, this is the end of–if this is the end of Red Hat, that would be a terrible, terrible thing.” And, you know, I don’t think it will be, like I said, but–

    Ashley: Well, you know, it was done well on the front end, this decision about the developer communities. And, you know, of course, just like we were talking about marketing to developers, that transparency, that honesty, the proof’s in the pudding, too, right.

    Micklea: Exactly.

    Ashley: It’s–in the end, that’s what will convince folks of, yep, it is. And maybe it’s a little better, maybe it’s a lot better, maybe it’s the same, but it’s at least got what we love about it. So that’s what you hope happens.

    Micklea: Well exactly, and that was kind of my repeated message. It’s been my repeated message, you know, since then, which is actions speak louder than words. So I can tell you everything is gonna be, you know, the same, as it was and–or sorry, I shouldn’t say that. I believe–I wouldn’t say that because nothing ever remains the same in technology. Even if we hadn’t been acquired by IBM [laughs], things would change.

    But, you know, it’s the core of Red Hat will remain the same. It will still be there. But, you know, people should watch everything we do and, you know, if they see something that they feel isn’t true to that, it should be called out.

    Ashley: Well we’d love to have you on for another episode, maybe a little ways down the road, if there’s some news or just to check in on out in the community and how this unfolded.

    Brad, I want to thank you, Brad Micklea, who is a lead in charge of the, Developer Program at Red Hat. Thank you so much for joining us on the podcast.

    Micklea: Thanks for having me, Mitch. It was a pleasure.

    Ashley: The pleasure’s definitely been mine. I also want to thank you, you, our listeners, for joining us. This is Mitch Ashley with staging-devopsy.kinsta.cloud. You have listened to another DevOps Chat. Be careful out there.

    — Mitchell Ashley

  • DevOps Chat: Data Protection in the Cloud With Druva

    DevOps Chat: Data Protection in the Cloud With Druva

    As any CIO knows, a data management architecture is essential to caring for one of the organization’s most valuable assets: data. Data management sounds simple but it’s not. Backup and recovery, disaster recovery, data retention, governance and e-discovery are all parts of any effective data protection strategy.

    As businesses move and grow their presence in the cloud, the same capabilities apply in this very dynamic and elastic environment.

    Recently, Druva received another investment round of $130 million led by Viking Global. Mike Palmer, CPO at Druva, joins us on this episode of DevOps Chat where we talk about Druva’s planned use of those funds and Druva’s approach to providing a SaaS-based data protection platform.

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

    Transcript

    Mitch Ashley: Hi, everyone. This is Mitch Ashley with staging-devopsy.kinsta.cloud, and you’re listening to another DevOps Chat podcast. Today, I’m joined by Mike Palmer, chief product officer at Druva. Our topic today is how data protection is in your future as you move to the cloud. Mike, welcome to DevOps Chat.

    Mike Palmer: Thank you, Mitch. I have been looking forward to this conversation with you.

    Ashley: Me, too. Glad we’re together online and talking about data protection. Would you first start, though, just let’s introduce yourself, tell us a little bit about what you do as chief product officer and tell us a little bit about Druva.

    Palmer: Well, as you say, running product is my primary job as chief product officer, as you would imagine. I run engineering and pricing and strategy for the company. And Druva is an amazing organization, one that I came to around about a year ago, coming from various positions in the industry, watching the evolution of both storage as well as data protection software and how it’s been evolving in a world of public cloud adoption.

    Druva is the first and only SaaS player in the data protection space, which made it super intriguing for me because, as we look at enterprises and how they adopt SaaS, whether that’s been from CRM to ERP to collaboration platforms, what stood out as the next big wave of SaaS adoption was, in fact, data protection. So, we’re focused on that space and growing rapidly.

    Ashley: You guys are doing real well. As a matter of fact, I know a little bit of old news here, about 30 days, but you had a $130 million investment. I think Viking Global led that for you—congratulations, by the way. That’s awesome.

    Palmer: Thank you very much. I don’t think $130 million ever feels old.

    Ashley: [Laughter]

    Palmer: But it was a great validation of the strategy and Viking is a tremendous investor. Folks in the industry know kinda their origins dating back a couple of decades and we were glad to have them aboard. They were a great partner in talking through the evolution both of our business as well as the industry over the next, what we consider to be, kind of 5 to 10 years and they saw what we saw, you know, which was kind of a relentless pace of adoption in cloud and cloud storage, the desire for enterprises to find ways to simplify their current environments and move technical skills from some of the legacy areas like data protection into some of the more advanced ones or next generation ones like machine learning and analytics, and we stood at the intersection of these trends, and they got on board with us and have been a great partner.

    Ashley: Clearly see a good future for you. Let’s talk about—so, this 130 million and the other investments that you’ve had, they didn’t give that to you to put it in the bank, they want you to put it to work. So, what does the future of Druva look like as you start to invest those kinds of funds?

    Palmer: Yeah, it’s a great discussion, because we are competing, frankly, on a few different _______ looking forward. You know, number one and the basic one is, how do we drive the best possible TCO for enterprises who have increasing amounts of data to manage, increasing amounts of risk and liability related to the regulatory environment surrounding that data. How do we expand the applications and the workload coverage for them as they support current apps, but also the ones that they’re adopting in the native cloud?

    And then, as we look a little bit forward, as I was told by an investor, you know, this is either a good investment or a great investment and it’s gonna hinge around how we can expand the data protection definition into one in which customers get more value from that copied and stored data. If we can find ways to help them use that data and extend it into the ecosystem, get better visibility into it, it will effectively not only change the architecture, but we will have changed the entire value proposition, and that’s what we’re shooting for.

    Ashley: Now, you’re operating in AWS in an elastic environment, you know, storage is right there, you want some more, you just grab it, use it. I would imagine that’s very easy to get out of control proliferation. You need some data management capabilities around what you have as well as the whole process of backing up data, restoring, recovering, making sure you’re not losing information—all of that.

    What are some of the key things that are different about operating in a cloud environment versus maybe a traditional on premise data center?

    Palmer: Great question, and let me start by giving us some background statistics to frame up how big this challenge is and the opportunity is. You know, the thing that we keep most in mind is, if you look at Amazon’s five year Kager of cloud storage pricing, it’s negative 60%.

    Ashley: Hmm. Going down.

    Palmer: In a world like that—it’s going down and if you talk to Amazon, they will say that that is the path that they will continue on over the next five years, enough to challenge customers with, “Tell me, when you buy an appliance today, how much cheaper is it gonna be next year or the year after or the after?” It’s likely it’s gonna be the same, so they’ll lose out on the innovation in the industry, even just around the ability to create better price and performance. ESC did a very nice survey and asked CIOs in their premises data centers what were the top five opportunities for cost efficiency? And number one on that list was storage management.

    Ashley: Mm-hmm.

    Palmer: You know, enterprises are dealing with this long history, and you had talked earlier about your history as a CIO. All CIOs deal with generations of proliferation of storage vendors as well as the hardware itself, the incompatibility, and just even the ability to track it, tough challenges, and the third stat, which is the one that I find most interesting because it indicates the tipping point is, in 2021, so just about a year and a half from now, we’ll see the crossover point where there are more dollars spent in cloud storage than premises storage. So, this will be the point at which companies can effectively be viewed as cloud first from a storage point of view to the point where they’ll have to defend [Audio skip]. And in that world, your first question about what do we have to help them with—we have to help them realize the promise of those savings.

    You made a good point—it can easily get out of control, especially where you have very distributed teams who are building applications and taking advantage of that infrastructure in a more decentralized way. We have to help them manage the tiering, we have to help them manage the data classification, we have to help them manage not just the cost side, but give them advice on performance. Much of this can be automated through machine learning. So, we’re gonna give them a new model for what old terminology like ILM or information life cycle management or HSM or hierarchical storage management, we’re gonna turn that, really, into a background automation process and let them focus on what matters, which is, do I have the right policy, can I leverage this data for other uses, and can I do that without special skills?

    Ashley: Well, you know, you bring up some really good points and that is, it’s one thing for a startup or someone who’s building a Cloud Native application as a young company or maybe a one-off kind of application. Enterprises look for environments that are gonna de-risk or things that are gonna de-risk their move to the cloud. And I would imagine having a structure that it’s at least familiar so you have not only data protection and data management, but you’ve got governance and things like that. You’re able to do some forensics, predictive analysis things like that. The kind of functionality that they’re used to having on prem, but maybe in a cloud environment or possibly even a hybrid model.

    Palmer: I think—yeah, you nailed it. And one of the words that I used frequently is convergence. You know, one of the benefits of cloud is that because you’re provided with all of the substrate, you’re provided with compute, you’re provided with storage and networking and policy and all kinds of things surrounding you that the job of a company like Druva and even the job of enterprise developers is just to focus on the application logic.

    And what that means in our space is, as you mentioned, you have a lot of surround in your data center. Customers that, in my former world, they would buy a product for backup, they would buy a product for disaster recovery, they’d have an e-discovery product, they’d have an archived product, they’d buy a data classification product.

    Ashley: Been there, done that. [Laughter] Been there on all those.

    Palmer: Painful, right? You know, and all you see is your costs going up and complexity going up and different skill sets and your training and conferences to go to and it’s slowing you down, right? And when you look at Druva in a single platform, we simply consider those ancillary value propositions like e-discovery or data classification as on demand, callable apps.

    Ashley: Mm-hmm.

    Palmer: So, when you back up with us, you simply tack on the DR service, you simply tack on the data classification. You have a work flow for legal hold. And by the way, you pay for this on demand, you don’t have to pre-pay capacity licenses, you don’t have to pre-pay storage.

    Ashley: Mm-hmm.

    Palmer: So, you have a world in which not only do we replace your current apps, but we have a world in which, as customers come to us and we release new capabilities every other week, that they can put something on a roadmap and see a functional working application in weeks and months over their existing data set, paid for only when they use it. You know, and this is revolutionary for most CIOs.

    Ashley: Usually you have to buy the amount of storage you think is sort of your top capacity and use it as you go and then potentially upgrade where, of course, in the cloud, it’s elastic, it’s fungible. We can change, add more as we need it.

    Palmer: And of course, you have to do the same with your software licenses, you have to then integrate those products, you have to find space in your collocation facility. You know, when you really analyze how much cost and effort it is to adopt a new piece of software or a piece of hardware, it’s far beyond the obvious.

    And not to mention, by the way—and this is a stat that I quote to a lot of people. It has been in my experience that, when a software vendor releases a new version of a product, it can be 12 to 18 months before even half the install base adopt that version. So, if agility and speed matter to you as a business in adopting capabilities, you have to take risk and wait a long time before you get a capability, whereas in SaaS, you get it on demand with no effort—again, completely changes the model.

    Ashley: I mentioned hybrid earlier, something we haven’t talked about yet. Most enterprises can’t lift and shift everything into the cloud. As a matter of fact, they may not want to. They may want to keep some hybrid either multi-cloud or on premise. Is that an area that you can readily address with them?

    Palmer: Yes, and thanks for asking that, because one of the difficulties in being unique in your space is just explaining your model in the first place. And from a SaaS point of view, while our application architecture is Cloud Native, we service customers in their premises data centers and into the public cloud, including their SaaS providers as well.

    So, what that means is, as you said, you know, if you have a customer that has—and most are within this category—have a data center where they have workloads where their recovery times are perfectly fine to take advantage of all of those benefits I mentioned earlier in the cloud, we help move them to the cloud and manage and restore and so forth for them to their local premises facility. However, if there is an application that has an RPO or a recovery point or a recovery time objective that requires it to be within the data center, we also kind of provide them with a virtual appliance that solves that problems as well.

    And then, as they build native cloud applications and, for example, Amazon, AWS, or they adopt Office 365 or Salesforce, we also help data protection and classification, both natively in Amazon as well as with SaaS providers as well. So, we really are in them with their current architecture. We’re also with them in their future architecture.

    Ashley: Yeah, that’s the key to transition, I think. Again, I mentioned earlier about de-risking and part of that is familiarity as well as giving me a path to get where I want to go, and I may not fully go to the cloud, right? I may always have to have something, as you mentioned, because of RTO or RPO requirements to be on prem.

    Palmer: That’s right.

    Ashley: Tell us a little bit about some of your, some of the capabilities that are just kinda native with the product that, you know, what does it take to get started using Druva? Can I just plunk down the credit card and, like Amazon, I’ve got all of it available to me, or is there a set of planning processes that are helpful to go through to properly architect a data protection architecture like this?

    Palmer: Oh, and we love this question, because again, coming from the industry where the idea of even doing a POC is a very complicated process of governance rules and software installation and finding hardware and disk capacity. With Druva, you literally sign up on the online platform. We give you access to the agent type that you’re looking for, so let’s use VMware as an example. You can download a proxy, provide it your credentials, put a policy in, do all of this within about 10 to 15 minutes and you can initiate your first backup.

    And you can do this and we have tested this over and over without having specialist backup administrator skills, which means you can also start delegating privileges to application teams and such where you as an administrator have the ability to enforce and create overall policy. So, now you have a world where your most mundane, everyday tasks are made so simple that you can delegate them to your customers, your customers from an IT provider point of view—which increases their satisfaction, because they can do these things on demand, and they free up your time to do more important things.

    Ashley: That’s awesome. I was breaking out in a cold sweat as I was asking that question. Having done this at multiple companies, it is not a fun process to stitch it all together with different products and really have to architect it properly because you have to worry about things like how are you gonna monitor compliance. You mentioned e-discovery. Now, we have things like GDPR compliance as well as our own internal processes about data retention and making sure we’re protecting ourselves against ransomware, things like that.

    Palmer: And we deal with some of the largest companies in the world, and one particular use case we saw super well is on the end point side where customers are dealing with either legal situations or they’re concerned about end user behaviors and what they’re doing with data. So, we not only provide them the ability to protect devices, but we also provide them with ideas about what’s going on with the data, and then certainly with workflows as you mentioned to go and pull that data aside or do a hold where they need to—again, this is all just workflow in an interface. It’s not trying to get one product to work with another product or making sure that versions are upgraded or compatible or patched sufficiently. We take care of all of that.

    Ashley: Mm-hmm. As I’m kind of peeling the onion here remembering things that you have to address with a data management approach, you know, you have to deal with things—you mentioned tiered storage earlier. Does de-duping apply in a cloud environment? Does caching apply in a cloud environment? Are those things that you also address?

    Palmer: All of the above. So—and you asked a very good question earlier. If I’m a customer adopting the cloud, where are some of my risk areas or things that aren’t provided to me? And one of those examples is de-duplication. So, if I’m going to adopt S3 or I’m going to move data into Glacier, how am I gonna do that efficiently in a world where I’m potentially coming from a de-duplication position on premises, I’m gonna lose that in the cloud.

    With Druva, we de-duplicate that data for you, so we are minimizing your cloud storage footprint. And once we’ve done that, we’re also taking care of the tiering into whether it’s S3IA or Glacier or Glacier Deep Archive, we’re not only replacing your HSM strategy, we’re doing that, as I said earlier, in an automated way.

    Ashley: Mm-hmm. What’s nice, too, is—again, I’m kinda having the negative flashbacks here. The old process of which are tier one, how much in memory storage are you gonna have at your first tier of storage, how much are you gonna have at this speed, how much are you gonna have at your third tier of speed. With the different services that Amazon provides, that’s what you’re bringing together in one collection in a full data management architecture so you can, of course, dynamically allocate any of those as you need them, but that’s what you’re tying into is those services as well as what you provide.

    Palmer: Capacity planning is a non-issue in a cloud and SaaS world. Of course, we will work with you where, as you mentioned earlier, where you have RPOs and RTOs on site where you know that the use case doesn’t apply to a remote data center. We’ll work with you with a virtual appliance. We also have customers that will always want a land speed restore, but they’re increasingly collocating in places like Equinix, for example, where they can cross connect into the cloud provider.

    So, even where you have requirements that look like data center requirements, it’s almost as if your data center is moving into clouds in certain collocation facilities where you can take advantage of SaaS even without the virtual appliance.

    Ashley: What do you feel like is the biggest pain point that you address for customers? Obviously, they have needs, functionality, capabilities—all of that kinda thing. But when someone comes knocking on your website and says, “I think I need this,” what is most commonly the biggest problem that they’re trying to address?

    Palmer: There are two problems, but the compelling events are different. So, the two problems we’re solving for them are cost. They look into the future and they realize their costs are going up, not down, and cloud can help solve that problem.

    And the second one is complexity. They don’t want to have to hire more storage administrators or backup administrators, track different vendors. They don’t have to do hardware refreshes. They don’t want to have siloed systems. These are problems that are all solved with SaaS provides like Druva and the public cloud. So, those are the core problems.

    The compelling events, on the other hand, can be very different. We have Fortune 100 companies that have data centers all over the world, and their cloud journey can include moving the satellite facilities to the cloud today and increasingly looking at cloud and the core data centers tomorrow. So, they have a more data center migration consolidation use case.

    We have others that have remote offices or field facilities where supporting an appliance is expensive if not impossible because they don’t have the staff. So, it’s refreshes and getting equipment out of facilities is the second one.

    Ashley: Mm-hmm, mm-hmm.

    Palmer: We have customers that come to us because of ransomware, where we offer an air gap solution where the only alternative on premises was tape. So, we give them the same security via encryption and have an air gap solution to their primary network that no one else can. So, they’re adopting the cloud with the safety of tape.

    And then, of course, your basic use cases of backup and disaster recovery, where customers want not just to be able to restore data but move an application, have the full orchestration capability, and instantiate that without the additional costs of owning their own architecture or frankly even managing their own cloud integrations.

    So, we integrate a DR capability in our platform. So, customers come, they get native backup, they get native disaster recovery all in one interface without other products or other training. So, we have compelling events and we’re saving our customers 50% based on their existing legacy architecture and we have proven that a few different times via external experts as well as customers themselves and complexity and really taking all of the legacy mundane tasks and skills and making them obsolete.

    Ashley: Well, Mike, I’d like to thank you for joining us. We’ve run out of time, here. I think we could talk another hour about data management [Laughter]—

    Palmer: [Laughter] For sure.

    Ashley: —share some war stories along the way, too. So, I’d like to thank you, Mike—Mike Palmer, chief product officer at Druva, for joining us.

    Palmer: Mitch, thank you very much. It was a great time talking to you. Maybe we’ll do it again.

    Ashley: That would be great. We’d love to hear an update as things kinda move forward and you spend some of that money. [Laughter] And I’d, of course, like to thank you—you, our listeners—for joining us today. This is Mitch Ashley with staging-devopsy.kinsta.cloud, and you’ve listened to another DevOps Chat podcast. Be careful out there.

    — Mitchell Ashley

  • DevOps Chat: Splunk Moves Into Microservices With Omnition Buy

    DevOps Chat: Splunk Moves Into Microservices With Omnition Buy

    Swiftly after announcing its acquisition of SignalFx, Splunk is vaulting into microservices tracing by announcing its intention to acquire Omnition. Tech companies are rapidly making acquisitions to strengthen their position in the DevOps and contemporary cloud-native software stack.

    Rick Fitz, SVP and GM of Splunk’s IT Markets Group, joins DevOps Chat to share with us the drivers behind Splunk’s move into microservices and service mesh tracing. Information about Omnition is in short supply as Omnition’s been in stealth, racing to develop a product to address the observability needs of DevOps teams. Omnition has received some notice through its contributions to OpenCensus open source, now being merged into OpenTracing.

    In addition to this episode of DevOps Chat, check out Mike Vizard’s article about the Omnition announcement.

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

    Transcript

    Mitch Ashley: Hi, everyone, this is Mitch Ashley with staging-devopsy.kinsta.cloud and you’re listening to another DevOps Chat podcast. Today, I’m joined by Rick Fitz, SVP and GM of the IT Markets Group at Splunk. And tailoring onto some recent news, the topic is about Splunk’s intention to acquire Omnition. They announced that on September 4th. Rick, welcome to DevOps Chat.

    Rick Fitz: Thanks, Mitch. Happy to be here.

    Ashley: Great to have you on. Would you start just by introducing yourself, tell us a little bit about what you do? And I’m sure most people know Splunk, but maybe a sentence or two about Splunk.

    Fitz:  Sure. A little bit about me, I’ve been building commercial software my entire career, and started out as a developer working for companies that were development oriented, and then the last 15 or 20 years, I’ve been working on just developing software for IT operations and application development teams in a commercial fashion.

    And in my new role now, I’m here as a General Manager, so I’m an executive here at Splunk, responsible for our strategy and vision of what we’re doing in the company. For those who don’t know Splunk—shame on you, darn it.

    Ashley: [Laughter]

    Fitz:  [Laughter] But let me tell you a little bit about the company. We are the company that actually built and invented, if you will, the ability to index logs at scale. And it made it really easy for the IT practitioners of the world to search that data and find, through an investigative lens, find the actual answer to those murky problems that are always out there. And so, the company is roughly 5,000 employees now, and growing very rapidly. So, we’re headquartered in California.

    Ashley: Well, just a little bit of trivia. I can’t claim credit for this, but I came across Splunk in probably 2006 or so at, I think it was an RSA conference. Tiny little booth, great ideas. Like, this is a cool idea. And of course, the company’s done really well, and I later became a customer of Splunk. So, congratulations on all the success and glad to see that you’re there, too, of course. Well, let’s talk—

    Fitz: Well, I thank you for being a customer.

    Ashley: Oh, absolutely, absolutely. [Laughter] So, let’s talk about Omnition. A lot of people may not know about them. Maybe they do, if they’re open in the—or involved in the OpenCensus, OpenTracing, OpenTelemetry projects, if I can say that right.

    Fitz: Mm-hmm.

    Ashley: They may know them from that, but they’re in ________ so there hasn’t been too much about Omnition. Tell us about that company.

    Fitz: Yeah. The—first, I’ll back up a little bit and kind of let you know why we even picked up a company called Omnition that no one really knows about. [Laughter]

    Ashley: Sure, that’s a good question, too.

    Fitz: The reality is that, in these large, cloud native worlds that a lot of us are starting to develop in, all kinds of things are changing. The things that we build on, the infrastructure we build on, the compute surface, the storage surface, there’s all these things that are now services that are available to us to leverage as application developers.

    And the other thing that’s changing pretty dramatically is just the way we actually build applications. The way we try to attempt to continuously integrate them, continuously deliver them. And perhaps one of the most profound things that’s occurred is that developers are now being asked to kinda own their code and they’re being asked to be on call or being asked to resolve issues.

    And so, if you will, they’re starting to become, as your website suggests, DevOps professionals.

    Ashley: A la DevOps.

    Fitz: Yeah. [Laughter] These trends start to kind of cause a paradigm shift—well, they have, actually, created a paradigm shift in the way you monitor. So much so that, probably over the last couple of years, DevOps practitioners have been talking about monitoring as—they’ve labeled it as a new world called observability.

    Ashley: Mm-hmm.

    Fitz: You know, I’ve been here around enough to know it’s simply monitoring. But I think what they’re trying to point out is that you need to observe the behavior of the data from the systems in order to make your lives easier. And that data comes in the form of logs, which is what Splunk has been known for a long time. It comes in the form of digital exhaust coming from monitoring tools in the form of metrics, which is really important.

    And then the last thing—and if you’re an application developer, I think we can all kinda relate to this—is the traces, the traces that actually come from the application code itself being executed are really great uses of good information.

    But all three of those things combined, the logs tell you kinda the root cause, the metrics tell you kind of what’s going on—is there a measurement that’s out of whack? Do I need to do something proactively to cause something to remove an error?

    And then the traces are really good for that logical layer—that logical layer telling you where to look. Do I have a backing problem? Do I have a code problem? Is it my problem, or is it a front end problem? And that kind of isolation is really important to trace it.

    So, that leads me to answer your question is that, you know, Omnition. Omnition was actually founded in 2018. The team is very small. They were in stealth mode, meaning they were building an application that was focused on tracing, and very specifically, they had a couple tenets in mind when they wanted to do this. They wanted to leverage open source. So, you mentioned that they’re big open source contributors, specifically to the OpenTelemetry project.

    And the other thing that they wanted to do is, they wanted to build this logical topology model that would allow you as a practitioner to isolate where a problem resides. And that was a pretty—it is a pretty novel way of looking at this particular problem. And it’s important, because having a thousand traces isn’t terribly intuitive or useful for a developer.

    Ashley: [Laughter]

    Fitz: But being able to isolate that it’s a front end problem so I can go talk to the guys that are in charge of that—or maybe it’s my logic that’s causing it, but maybe it’s a network issue, firewall issue or something like that. Or maybe it’s outside my firewall and I’m dealing with some latency issues from the world around us.

    Ashley: Mm-hmm.

    Fitz: But you need to be able to isolate that problem so you can solve it. So, long winded answer is, these guys, this team really figured out how to build this logical topology sitting on top of this trace data, leveraging open source—so, pretty darn powerful.

    Ashley: What I was really excited about with this announcement is, one of the things that I talk with companies about and work with them oftentimes is what DevOps, in this fundamental way that we’re creating more cloud native applications, how this really changed the way organizations work as well as how we create software, which I know you speak a lot about.

    And in some ways, what we’re doing is through this kinda granularization of functionality into containers, microservices, mesh—service mesh—it’s very interesting, because you can do lots of great things with it. But it makes the complexity of operating and monitoring—as you say, observability—even more difficult. So, that’s created this whole new cottage area, if you will, which is what Omnition went about, and actually some of the, they’ve had some developers who came over from Lyft, I think, went over to Omnition to help solve this problem.

    So, it’s fascinating to me to see Splunk bring this, this quickly, into your kinda product portfolio of companies, or at least that’s what we expect to happen with the acquisition, that you’re jumping right into service mesh, microservices, and observability, the monitoring of that. So, it seems like it’s a natural fit—maybe, you know, sooner than I expected it to happen, actually.

    Fitz: Here’s what’s interesting. I mean, we have the luxury of a lot of—you know, being around for a while and talking to a lot of our large enterprise customers that are going through this digital experience. You know, they’ve done their lift and shift, they’ve moved to kinda the lift, shift, and augment, and now they’re building a whole new series of cloud native digital services. So, they’re building in this new cloud native way. And when you start to talk to them, they recognize the problems, and they realize there has to be a way of doing this.

    And what we’ve found was, a number of them were trying to build it on their own, or they cobbled together a prototype that actually would kind of get ‘em there, give them some visibility. And then having a lot of those customers kind of advise us—because they’re very large customers at Splunk because of the fact that logs are a critical component of this strategy. But they were building the rest on the side, and in some cases, you know, using other companies to try to do it.

    And we just quickly realized that this is an opportunity for some of our largest customers, for us to come in and help them with this very critical issue and build alongside them as we move forward.

    So, yeah, we recognize that certainly the tracing part of this world is pretty new, but we think it’s the right approach, it’s the right answer to a long-standing problem, and I think the application architectures are at a stage in this cloud native world where this is perhaps the only way that this is gonna be accomplished. So, that’s why it was so strategic for us to do this.

    Ashley: You know, like, observability kind of being replaced for the term monitoring, tracing is also used—you used the word “also”—as kind of a new term in this service mesh, microservice world. Does it have a fundamentally different meaning to you as to what log analysis and things like that—is it substantially different or is it just an extension of what we’ve been doing in a non-container, non-microservice world?

    Fitz: Well, the only analogy is, it tends to be text, [Laughter] and you have to put it somewhere. And actually, some of our customers were putting it in the log and then extracting it, but that’s useful if you’re looking for one specific trace, but if you can imagine some of these applications are throwing up hundreds of thousands of traces a second, and sifting through that, while you can search through it, it’s great, but you really do need some analytics on top of it to organize it in a way that creates useful information. And that, I think, is again what Omnition has done.

    You know, answering the question, “Is this different from the old approach?” You know, I had the opportunity to work with an early Wily team. They had been acquired by CA Technologies, and I got to work with the team, which is an APM company. And the team actually invented bicode instrumentation, which is a way of doing instrumentation of the application on the fly. And it was very novel, because at the time, the operations teams were responsible for monitoring and the developers weren’t. So, the only way they could get their developer team to get visibility into the application—because they couldn’t tell their developers to actually put stuff into the logs.

    Ashley: Mm-hmm.

    Fitz: Well, they could ask. [Laughter]

    Ashley: [Laughter]

    Fitz: But they just couldn’t demand.

    Ashley: They might have ________.

    Fitz: Exactly. [Laughter] You know, us developers, how we are. And so the funny, interesting thing about that is, we tended to sell to the operations teams, so they could get that visibility into their application. In the open tracing world, because the onus, and it gets back to this DevOps ________, the onus is actually upon either an SRE function or, if you will, a DevOps function to establish the standards and policies. Those policies have been enforced by that team, and therefore, the developers, before they can actually bring product into production or bring code into production, there’s ________. And now, all of a sudden, you’re getting a lot more visibility and a lot more fidelity inside the code by that enforcement.

    And then, of course, open tracing is now on to its own standard, so you’ve got a standard to kinda drive. Before, there was no real standard, so you were just putting stuff into a log. And therefore, it’s hard for a vendor to look at it and develop an application to give you visibility into it.

    So, that’s definitely some of the big shifts that have caused this new paradigm to actually emerge, which is pretty awesome.

    Ashley: I think I saw in a blog post either on your site or Omnition’s that their investment and contributions to OpenTracing is something you’re likely to continue and support and want that to continue, is that correct?

    Fitz: Oh, absolutely. Absolutely. We’ve actually been, at Splunk, probably for the last four or five years, pretty definitely contributing to open source more, leveraging open source. We’ve been kind of on that bandwagon for quite some time. But this one, it makes a ton of sense. Both the OpenCensus and OpenTracing have now converged into OpenTelemetry. It makes a lot of sense. And I think that this is definitely where the world is—where it’s headed. I think it’s long overdue, actually. [Laughter] I’m glad to see these things kinda moving forward.

    Ashley: Given the players involved, I think if I recall right, OpenCensus was started by Google, but quickly followed by Microsoft and Dynatrace and Omnition—

    Fitz: Yeah.

    Ashley: – I think was part of this effort, too. So, it’s got some important names behind it.

    Fitz: Yeah, and most of the monitoring companies out there that are touching on applications are participating. So, I firmly believe it will take on as a standard. I think that’s pretty clear.

    Ashley: As you were considering an acquisition like Omnition, what were you hearing from your customers that led you to say, “We need to go find a company” or, “We found somebody like this. This would be a great fit for some of the problems and needs requirements that’s awesome we’re hearing from customers”? What was it that’s behind that, what you’re hearing from customers?

    Fitz: Well, there’s the big part of kind of the equation was this idea that we can use OpenTelemetry and spit this data into a log. But that’s good. I mean, that’s a great first step. I can search for something and that’s a fantastic, great step.

     But very quickly, the customers that we were dealing with at scale, they were saying, “You know, what’s interesting is that all this data—I have the data, but I can’t find any useful information out of the data, you know? I’m struggling with that.” And so, you know, we were in there building, on top of Splunk, the ability to model it and do different things. And we realized there’s the answer. The answer is to develop some form of analytics on top of this big, rich set of data that provides you really useful insight.

    And then, from my APM experience and FHIR experience, you know, the whole idea was having kind of a logical topology that represents the application, and I mentioned some of those words meaning back ends and front ends on the application itself. So, once you have that meta model in your mind and can decorate it with trace information, it becomes incredibly powerful. And that’s—when I broach the subject with our customer and said, “Is that really what you’re looking for?” they said yes.

    And so, we’re surveying the market and seeing is there anything out there, and then Omnition popped up, and it was like—wow, it’s a good day. [Laughter] It’s a perfect day for us, because we would’ve had to build this, and I think this team, with the expertise they have and the smarts they have is gonna be a welcome addition to the team and help us do it for us.

    Ashley: They do. They do have some great people. Now, Omnition, as I understand it, they describe themselves as a SaaS company. I assume this is a SaaS service that they’ve been building. Is it something new for Splunk in terms of a SaaS offering, or does this fit in well with other things that you’re doing?

    Fitz: No, it fits in very well. You know, SaaS grows from a business perspective as a very high growth business for us. We tend to, because data has gravity, [Laughter] we tend to have our software where the data resides. But more of that data is starting to reside in the cloud, so you know you’re starting to see people, as I mentioned, lift and shift or lift and shift and augment or building kind of in a cloud native way.

    So, we’re definitely—we’re part of that trend as well, and we think it’s the smart thing for all of us to get there. So, yeah, we are definitely gonna be SaaS on this particular offer, for sure.

    Ashley: Well, that makes sense, too, doing cloud native if you’re doing microservices, service mesh—more than likely, that’s gonna be stuff in the cloud. So, having Omnition there as well, that seems like the place to be, the right place to be.

    Fitz: Yeah. You know, it’s interesting, I was telling some sales reps yesterday, we were talking and I said, “You know, I contrast the conversation that I had with somebody who owns the data center with somebody who’s working in a cloud native way, and the vocabulary is completely different.” [Laughter] You know?

    Ashley: [Laughter]

    Fitz: Nobody says on premise or cloud—they just don’t think that way. They just assume that it is all cloud, you know? Whereas if you talk to somebody that’s still in a data center, they wanna know where the data is, where do I stack it, where do I rack it, where do I plug it in?

    And so, there’s definitely a difference in that cloud native world, the way people think.

    Ashley: Well, I’ve often had to believe, maybe learned over time, is that you can tell who drew the picture of a diagram on the whiteboard. Whatever is at the center is the data—if it’s the data center people who drew it, if it’s the cloud, it’s the cloud people.

    Fitz: Yeah.

    Ashley: But it’s interesting the transition we’re making with multiple companies investing in cloud management platforms, even down to storage providers and VMware and others. You know, I think eventually we’ll stop talking about hybrid. Everything’s a cloud, whether it’s just in your cloud or somebody else’s cloud and it’ll be managed much the same way. That’s where we’re headed, anyway.

    Fitz: Yeah, and I kinda share that point of view. I think, organizationally, we have to kind of force some of that standardization of vocabulary just to make our lives work. [Laughter] I think it’s gonna get—

    Ashley: Well, it’s also—yeah. [Laughter] I also think you have to do it from a cost standpoint, right? Complexity, managing a physical data center one way and then all these different clouds a different way. So, anyway, a whole ‘nother topic for another time.

    Fitz: Yeah.

    Ashley: We have just a little bit of time left—is there any message that you wanna make sure that gets out to listeners, to customers, future customers about the path that Omnition sets you down or other things about this pending acquisition that we wanna make sure folks know?

    Fitz: Yeah, let me just kinda share a couple things. One is, as I opened with, I think this world of observability is certainly all about having logs as well as metrics as well as traces. Just a couple weeks ago, we actually also announced our intent to acquire SignalFx, so we’re bringing in some of that metric capability. We’ve been known for years to be the log company, and then of course, Omnition is helping us with our tracing capability.

    And so, I think the combo is gonna be pretty darn powerful. I’d encourage your listeners, if they get a chance, if they wanna join us in Las Vegas this year at our .conf, which is our conference. We’ll be talking a lot about what we’re doing there and getting everybody up to speed. And if you can’t attend, all that stuff is posted online, too. You can check us out there, as well.

    Ashley: Yeah, there are definitely some great videos out there, too. Well, I wish you all the best with the acquisition and future business with Splunk. I just want to say thank you—Splunk is a great product, and when I had the opportunity to introduce it in organizations that I was running, all positives. So, it made a big difference in our world, and I think your move into observability around microservices, et cetera, is fantastic, and we appreciate you taking those steps.

    Fitz: Well, thank you. Thank you, Mitch, and thank you to all the listeners for your kind words. I’m sure you’re gonna share with me online later on.

    Ashley: Well, thank you, Rick—Rick Fitz, SAP and GM of the IT Markets Group at Splunk for joining us on the podcast today. And, of course, I’d like to thank you, our listeners, for joining us as well. This is Mitch Ashley with staging-devopsy.kinsta.cloud, and you’ve listened to another DevOps Chat. Be careful out there.

    — Mitchell Ashley

  • DevOps Chat: DevOps and the Programmable Network with Cisco DevNet

    DevOps Chat: DevOps and the Programmable Network with Cisco DevNet

    Network technology has undergone its own transformation in parallel with cloud infrastructure, how we create software and the adoption of DevOps. SDN, NFV, virtual network appliances and an ever-expanding suite of APIs make network and security technologies much more accessible to developers.

    Network engineers’ worlds are rapidly changing, too. From highly skilled to associate-level, all network engineers are faced with building up a new and necessary skill: software development. Learning software development can be a daunting, intimidating proposition even for someone already skilled in the network engineer domain.

    So, how do we lift up the community of network engineers and help them build their development chops? How can software and DevOps engineers easily get access to all the programmatic interfaces that configure, manage and control the network?

    These questions and more we explored with Susie Wee, founder, senior vice-president and CTO of Cisco DevNet. DevNet is an online resource full of information for app developers, infrastructure developers and network and DevOps engineers. On DevNet, you’ll find training (Python, API and more), sandboxes for experimentation, code exchanges (including GitHub), CI/CD and new Cisco certifications for software.

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

    Transcript

    Mitch Ashley: Hi, everyone. This is Mitch Ashley with staging-devopsy.kinsta.cloud, and you’re listening to another DevOps Chat podcast. Today, I’m joined by Susie Wee, founder, SVP and CTO of Cisco DevNet. Our topic today is a really interesting one—DevOps within a programmable network. Now that we can program the network, what does that mean to the DevOps world? Susie, welcome to DevOps Chat.

    Susie Wee: Hey there, Mitch, it’s great to be here. Thanks for having me here.

    Ashley: Thank you so much for joining us. Hey, would you start out and just introduce yourself to our audience, tell us a little bit about what you do and what you do at Cisco DevNet?

    Wee: So, I’m at Cisco, and as you said, I founded DevNet, which is Cisco’s developer community—and you might be wondering, “Why does Cisco have a developer community?” It’s because the network has become programmable, and we’ve been really driving that whole portfolio of networking to not only be software and hardware, but you know, to have both. And the fact that the network has APIs, the fact that the network is programmable means that there’s a fundamentally different way to leverage the network. And the thing that we recognized more than five years ago is that we are going to be pushing our technology portfolio towards software, towards programmability, towards having APIs, but what that also means is that the people who operate networks and the people who interface with networks need to learn about that.

    Ashley: Mm-hmm.

    Wee: So, in addition to building our products in a software and programmable way, we had to bring our community along as well, so we formed a developer community for Cisco, and that’s what DevNet was all about. It’s our developer program that builds our developer community, and when I say developer, I actually do mean software developers and the way that we think about software developers—people doing DevOps, people writing applications—but I also include networkers and specifically networkers who are running networks who need to learn some software capabilities so that they can use the programmable network.

    Ashley: Interesting. I was sharing with some friends several years ago, maybe nine years ago, a network engineer asked me for some help with career development and the first thing I said was, “I think you need to learn Python,” and of course, he wasn’t familiar with that, and he went to a Cisco live event and heard about the visualization of the network and programmability and came back all excited. And, of course, I didn’t have much to hand him other than, “Here’s a Python book.” I don’t know what APIs are available yet, but things have, of course, evolved greatly.

    How would you describe where we are today and what’s the way to get started and get going with this?

    Wee: Excellent. Well, the thing that I’ll tell you is that you are a visionary to have given him that advice five years ago. [Laughter]

    Ashley: Check is in the mail, I’m writing it out now. [Laughter]

    Wee: [Laughter] Check is in the mail. And basically, now, you actually would have somewhere to send him to, which is to DevNet, the reason being is that, you know, if you go to Developer.Cisco.com, and everything in DevNet is in Developer.Cisco.com, we have all of these free resources, like coding resources, learning resources, learning about APIs. Python is definitely fundamental to what we’re teaching, because we’re recommending that we use that as actually our base language and, obviously, people can use any language that they want, but it’s a great tool set to start out with.

    And, you know, in addition to Python, there’s of course just using all of the software development tools that we want people to use like GitHub, Postman, you know, just your favorite code editor. So, we have a whole bunch of, just, regular software tools that we wanna make sure our networkers are familiar with. We want them to understand the practices used in software, you know, just code sharing, right? So, just using GitHub repos, and using it not only for sharing code, you can actually use it to share network configs and check network configs and use it in CI/CD pipelines.

    So, there’s a whole bunch of ways that we want the networking industry to use software practices and software tools. And so, at Developer.Cisco.com, we have learning labs, and we have StartNow, like, Developer.Cisco.com/StartNow is a place for that networker to get started with software to get started with our APIs. But in addition, we have stuff for advanced software developers as well. Like, if they wanna get in there and just start programming a network, doing some automation, using advanced security services and things like that, we actually also have a DevNet sandbox. You know, if you wanna play around with this world, you might not have a bunch of kit in front of you to start coding.

    Ashley: Sure, yeah.

    Wee: And so, with the DevNet sandbox, you can actually make reservations to real networking gear, real security products, real collaboration products—things that you can actually get active with right away to, you know, even test out your advanced coding and advanced networking needs.

    Ashley: Well, it’s interesting, because it seems like—I mean, you understand software, coming from your background with HP and all the work that you’ve done. You’re really trying to marry these two different disciplines about how software folks think of the world, you know, sort of a GitHub of networking kind of attitude about tools and how to learn and downloading code segments and things that’ll help you experiment with what may be a CCIE or a CCNA engineer has experience with in their certification training where they’ve got a sandbox lab, that they don’t have to create their own physical lab—kinda married those two worlds together.

    Wee: We have, and it’s super interesting, because when we talk about who will run the IT system or the DevOps kind of platform and infrastructure of the future, will it be the CCIE networker, you know, who really knows how to run mission critical networks and keeps these things up 24/7, you know, many nines of reliability? Or will it be a software developer who really understands the software skills, can code up hundreds of lines of code a day? And really, what we’ve come to, you know, in watching people who move to automation and things like that is, it’s a combination of both. You’re gonna want someone who really understands networks, [Laughter] you know, to that really professional level.

    Ashley: Mm-hmm. Oh, sure.

    Wee: And you’re gonna want someone who can code. You might find the unicorn that does both and knows both of them to the level of, you know, of a CCIE networker or the advanced software developer. But chances are, you’re gonna have a set of folks working together. You also want the networking tools to be simplified so you don’t need that really high level, and there’s a lot of automation that occurs. You know, so if you’re kind of a smaller outfit or growing in another way—but oftentimes, you’re gonna want these groups to be working together, and that’s what we’ve tried to hit with DevNet.

    Ashley: Well, you know, what you describe is, I imagine you’re leading towards something that looks like what DevOps is today or DevSecOps including security as part of the DevOps suite of everybody working together. What does the NetOps or the NetDevOps world look like as you’re helping folks move out of the networking centric world and the software centric world to where that’s blended together?

    Wee: Yeah, so, I—and I think that the importance is that we do the blending so that we can take the best from both worlds. I see it as pretty flexible, and once again, whether it’s all embodied in, you know, one person, the unicorn who learns it all, [Laughter] but more likely is that you have the right level of instructions and you have people who can interface together.

    So, one of the new things that we actually just announced last month, or in June at Cisco Live, is a brand new Cisco certification that is a Cisco DevNet certification

    Ashley: Excellent.

    Wee: And what happens is—actually, I have just all the respect in the world for the networkers of this world, and there is 1.7 million Cisco certified professionals, like, people who have earned a Cisco certification in the world. And basically, they know all about networking. And Cisco certifications have been out there and if you’re a CCNA associate level, professional, CCNP or the highly revered expert CCIE—now what we’ve done is, with Cisco, we’ve created the Cisco DevNet certification. So, we have a Cisco DevNet associate level, professional level, in the future we’ll be announcing the expert level as well. And this is bringing that set of software skills to networking.

    And so, if you go and take a look at Developer.Cisco.com/certification, you’ll see that it’s actually all of the software tools that you would need to learn.

    Ashley: Right.

    Wee: So, you know, using rif APIs, using APIs securely, using authentication. So, it starts from fairly beginning software, but in a rigorous way, and gets up to fairly advanced software topics as well. And what that does is, that helps train up the software folks or at least validate the software folks who already have those levels so that they can work together.

    Now, the way that we designed it is that our networking certifications are 80% networking, 20% software. Our DevNet software certifications are 80% software and 20% networking.

    Ashley: Okay. Interesting.

    Wee: We’ve done that so that these folks can work together, you know? And so, there is a little bit of networking that you’d have to learn, but enough that you could be effective in it, that you could really deliver these systems, that you could write automation software for DevOps pipelines that leverage the programmability of the network. So, it’s a pretty important part of what we’ve done here.

    Ashley: Well, you’ve created, really, an exchange by focusing on automation as a core use case. So, coming to software can be really daunting, right? I need to learn this language, I’m not even sure what problem I would solve with software, how I would write something to do something with software. So, it can be really intimidating, so I really like how you’ve laid out automation as a key subject area, use case for people to collaborate on at the site where they can share their code and get [Cross talk], right?

    Wee: That’s right. So, what we did was, also in June, you know, we announced the new DevNet certifications, but we also announced the DevNet Automation Exchange. And basically, what we recognized is that automation is our customers’ biggest problems. So, basically, anybody who just has any type of infrastructure needs to work on automation, because their infrastructure has grown, their businesses have grown, they’ve had to scale out their infrastructure. And what they need to do is automate it. And this goes all the way to even manufacturing companies, right?

    Ashley: Sure, yeah.

    Wee: So, you’re digitizing, you need to automate your IoT, you need to automate your collaboration, your systems, you need to automate just your compute and your network.

    So, automation is the biggest problem and what happens is, Cisco’s products—well, actually, in many products around the world for infrastructure—our software product, they use SDN, virtualization, they work in a software world, containers, microservices, everything there. But, as we get there, next, what you want to do is, you want to be automating your infrastructure overall. And as we want people, it’s one thing to say, “Okay, here’s all of our products. Our products now all have APIs.”

    Ashley: Right.

    Wee: You know, so our routers, they’re all programmable, it’s just, at the device level itself.

    Ashley: REST APIs, even—yeah!

    Wee: We have controllers—REST APIs throughout. We also have controllers, you know? So, controller level that abstracts out and interfaces with the individual network devices and the security products and everything there and let you work at that next level. But, as you’re working on all of this, you know, people have said, “Okay, great, Susie! With DevNet, you guys have taught us how to code. You’ve taught us about your product’s APIs, but next, we want help solving our automation use cases.”

    Ashley: Mm-hmm.

    Wee: And so, what we did was, we created automation exchange to be the place where we’re using community software, so we have code in GitHub and we encourage our community to submit code in GitHub, and it’s a code exchange that we put in there to solve real automation problems.

    Ashley: Mm-hmm.

    Wee: And so, what we’re trying to do is, you know, we’ve seeded it with 50 code repos, and that’s all different automation use cases. We’re inviting our community to submit more, and you know, just use it as an exchange where Cisco’s community, we have the best infrastructure experts around the world who’s, you know, working on DevOps, working on IT, working on compute, and working on networking, of course, and security. And what we want is, we want them to get together and have a place where they can exchange code to really build up that automation repository to make it easy for them to do their thing.

    Ashley: Mm-hmm. Well, let’s look at this from maybe a 180 degree view. We’ve talked about it from a network engineer’s perspective. If you’re a software engineer doing DevOps and maybe doing DevSecOps, but you’re living in containers—you had mentioned Kubernetes, microservices—

    Wee: Yep.

    Ashley: you know, cloud or maybe even the Cloud Native world—how would you look at this? Is this something that they’re gonna be interested in, or how would they approach it, or why would they approach this as something they wanna tackle?

    Wee: Yeah. So, first of all, the answer is yes, they should be looking at it. There is both the set of DevOps folks and the set of app and cloud developers. You know, so, even if you’re in DevOps, you’re kinda scaling out your system, you’re working on that portion of it or if you’re the actual app developer or cloud developer who is developing the applications, the microservices and everything that runs on top of it.

    Ashley: Mm-hmm, right.

    Wee: In both of those worlds, what happens is, there is this opportunity right in front of us, because—and I say opportunity because most of them have not yet realized that the network is now programmable.

    And so, what has happened is, people are used to the fact that your compute is programmable, we use virtualization, kind of everything in that world, but the world is just starting to realize that the network is programmable as well. Yet, you know that every time you scale out an application, as you reach the cloud, security becomes a concern, the connectivity becomes a concern, the way you connect up your databases to your applications and make sure that the right devices and users have access to the right stuff—that’s all core to how you’re building up these applications and your Cloud Native applications and everything there.

    But the thing that we realized, that people can realize now is that—oh, the network is programmable. I can actually get, for example, a network level of security or use the network for a network layer of access control that is even, you know, that adds another level of kind of control and security than working at the application level alone.

    Ashley: I would think there’s, too, some good analogues that they may be used to in a cloud world, like virtual load balances, firewalls, things like that that they may have been part of setting up in their DevOps world.

    Wee: Absolutely. And what happens is, with the new—like, when we talk about a controller on top of a network, so, it’s one thing to say, “Oh, there’s just a controller that lets me abstract what’s underneath it,” but the other shift is that you can actually use policy, and that’s policy you use in compute all the time. But just set up policy to say, “These users or these devices have access to these applications and have access to these applications to this data and these databases and everything there.”

    And you can start to set security policies for access and for your applications in ways that then uses the programmable network underneath it. So, you can, at the detailed level, set up a VLAN that segments out, [Laughter] you know, the right amount of the right part of your network and data and application to give you that next level of security.

    Ashley: So, Susie, you talked about automation as the key use case. That’s a pretty big topic, though, and I’m curious—how would someone get started working on automation in a network that they’re running, they’re managing as a network engineer professional?

    Wee: Yeah, that’s a great point. So, really, you know, automation, while we all strive for automation in this perfect world, the question is, how do you get there? And especially, how do you get there when you have a live system, you know? So, when you’re running DevOps, when you have a large infrastructure, you have things running on it all the time. And so, the question is, how could you get there?

    You know, one thing that we’ve done with DevNet automation exchange is that we put use cases on there—use cases that help people get started. But what we’ve done is, we’ve actually categorized it into this walk, run and fly approach.

    Ashley: Okay.

    Wee: And the way that we say it is, with walk, like, how do you get started with automation is first, you’re gonna walk. Like, first use it in your network or in your infrastructure as a read only kind of a way. Try to get visibility and insights into what’s going on, perform analytics on that, get all of the insights that you can from your running infrastructure or from your running network. And then we have a set of use cases for walk.

    You know, run is when you’re ready to go to this next level where you’re ready to push out a control or push out a policy, you know, actually set something on your live system.

    Ashley: Okay.

    Wee: And so, then you have your kind of run. And then fly would be that ultimate DevOps workflow, you know, where you’re in that full workflow of you’re proactive, you’re monitoring, you’re managing, you’re getting insights, you’re analyzing, you’re pushing changes out, you know, you’re proactively seeing where do you have opportunities to load balance, fix things, deploy things, put in more security to identify threats and everything there.

    So, you know, of course that’s the ultimate case of where you wanna be with the full DevOps workflow, but to get there, you need to take those steps. So, it’s pretty fun to have these use cases that help you walk, run and fly.

    On the networking side, an example of the walk is something that you always have to do in networking if you’re running a large network is, you have to continuously be auditing your network.

    Ashley: Right.

    Wee: You know, if someone reconfigured something in there, they added a device, they changed a setting and what that’s doing is now saying, you know, a threat to your network. So, you know, for auditing, what happens is, if you move things into a software, actually, a DevOps kind of workflow, what you can be doing is taking your network configs across all of your devices, putting them all into GitHub, [Laughter] so that you’re actually taking your networking configs, looking at them with, you know, in a code repository looking at version control.

    You could actually be running Ansible playbooks where you’re continuously kind of running through, making sure you haven’t gone off the golden template, be looking for issues, and then just let people know—hey, something is off here. It’s read only, but you then let your ops team know, hey, there’s something that’s not right. And just moving that into a software workflow is way better than what most teams have to do today.

    Ashley: Well, usually, they’re totally separate worlds, and now you’re talking about being able to integrate those in a CI/CD kinda workflow, you know?

    Wee: Yeah.

    Ashley: You know, a tool chain that manages not just software DevOps but the network ops.

    Wee: Yeah, exactly. And then you push that capability over to the run side, like, if you want to—if you’re talking your wireless network, you wanna set up guest networks or shut down networks or run, I’m imagining you have stores around the world, right? If you wanted to run that, then what you can do is push out your SSIDs, start them, stop them, reset your guest passwords and everything, automate all of that to where you’re pushing out control.

    And then, you know, what’s really fun as a fly use case is just doing DevOps. Like, so, if you have new applications and a new class of applications that you wanna deploy onto your infrastructure, then you wanna do it securely. So, let’s say that you have a new set of applications, you want it to touch your financial database, you only want a select number of employees to access it, you wanna make sure that what your applications are running on, where your data is stored is all working in the right way, you can actually set network level configurations to segment your network, set up the VLANs, get your applications deployed into classes.

    And so, we have something called ACI to help be an application centric infrastructure so that you can actually map your application settings down into your network configuration settings and do all this with a full DevOps CI/CD pipeline. That’s the kind of thing you could do in a fly use case. So, we actually have code for all of this stuff that lets people jump in, get started with it, and then customize it into their own system.

    Ashley: One thing that is really great about this is probably the network world doesn’t quite yet realize how much of this has already kinda been worked through in a DevOps world, and there’s so many resources in thinking about tool chains and workflow pipelines and tools to manage all of this.

    Wee: Exactly.

    Ashley: They may not necessarily be able to lift and shift right onto a network paradigm, but pretty darn close.

    Wee: Absolutely.

    Ashley: So, they’ve got a big leg up that they may not even realize yet.

    Wee: Yeah, absolutely. And it actually, it kinda goes both ways. So, we’re actually not claiming to do rocket science, right, in terms of something very new. In some ways, what we’re doing is, we’re connecting the world so that you can take the best practices from both worlds and put them together.

    Ashley: Fantastic. Say some more about the certification part of that, because I know that’s extremely valued, you know, if you’re at that CCIE level. That’s a prestigious thing.

    Wee: Yeah! What’s really nice is, you know, once again, I’m kind of honored to join—to my predecessors who’ve actually created the Cisco certifications, because that CCIE is such a high level of expertise, and everyone who’s a CCIE, I just bow to them [Laughter] because of how hard it is to earn that.

    Ashley: Oh, it’s a huge amount of work, yes.

    Wee: But what I also wanna talk to is that, when you take that highest level networker, someone—you know, or any level, whether you’re a CCNA, CCNP or CCIE, the highest level, if there’s sometimes amount of software skills that you could pick up. So, you could actually start with a DevNet Associate, and really, the idea is that you learn enough about software so that you know the modern tools so that you could leverage software and DevOps tools and really get familiar with that side, and then you could get a coder next to you that you could direct in a good way.

    Ashley: Mm-hmm.

    Wee: But what’s neat is that we have, we actually have these coding 101 sessions that we give to folks. And really, what happens is, if you’re a networker, and you have this level of expertise but you’re not coding as your day job, you just don’t know the tools that you use today, that are used today.

    Ashley: Right.

    Wee: And what we do is, we will just walk through, like, every tool and say, “Hey, we’re not going to the next page ‘til everyone gets this set up,” Right? [Laughter] And, you know, it’s just getting in there, again, using GitHub, using Postman, making sure that you can download Postman collections, that you’re getting your authorization tokens and that you’re setting things up correctly. And we don’t go to the next page ‘til everyone gets past that first step, right?

    Ashley: That’s why everybody starts with Hello World, right?

    Wee: Yeah!

    Ashley: I guess in the networking it’s, what, a TCP session established is your Hello World or something. [Laughter]

    Wee: [Laughter] Exactly. And so, we have a group of CCIE advisors, and these are people who are top of their game, but we’ve even selected them to advise us.

    Ashley: Well, I really appreciate having you on the podcast. We have a great community of DevOps, DevSecOps, people doing software, and I think we can play a key role in helping you with what you’re doing with Cisco and DevNet and bridging that gap. We’ve started that process here today, you know? It takes that first step, and I feel like we’ve made that.

    Wee: Yeah, absolutely!

    Ashley: Thank you for doing that with me.

    Wee: No, thank you, and if I can actually, just as a message, just to reach out to the audience and say—you know what, please come to DevNet. Because DevNet is not only for networkers, it provides you a way to interact with networkers, but I would love to have you join the DevNet community and give us thoughts on how can we make the programmable network even more useful to DevOps, to DevSecOps and to achieving everything that you want?

    Ashley: Well, Susie, thank you so much. We’ve completed another DevOps Chat podcast. I’d like to thank my guest, Susie Wee, SVP and CTO of Cisco DevNet for joining us today. Thank you, Susie.

    Wee: Great! Thank you so much, Mitch. Thanks, everybody.

    Ashley: Wonderful. And thanks to you—to you, all of our listeners—for joining us today. This is Mitch Ashley with staging-devopsy.kinsta.cloud, and you’ve listened to another DevOps Chat podcast. Be careful out there.

    — Mitchell Ashley

  • DevOps Chat: Hybrid, Multi-Cloud Management for DevOps With CloudBolt

    DevOps Chat: Hybrid, Multi-Cloud Management for DevOps With CloudBolt

    Agile, DevOps, multiple cloud providers, serverless, contemporary cloud native apps, shadow IT using a credit card–it can be daunting for any IT organization to be responsive to the internal customer needs. It’s even tougher to be proactive and get ahead of the curve. Enter Cloud Management Platforms (CMP).

    On this episode of DevOps Chat, we talk with Bernard Sanders–no, not the presidential candidate–CTO of CloudBolt. Our conversation explores how IT can use a CMP to provide the IT and self-service capabilities so DevOps and Agile teams won’t feel the pain and slowdown of IT past.

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

    Transcript

    Mitch Ashley: Hi, everyone. This is Mitch Ashley with staging-devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. Today, I’m joined by CTO Bernard Sanders from CloudBolt. Our topic today is DevOps for hybrid and multi-cloud environments. Bernard, welcome to DevOps Chat.

    Bernard Sanders: Thanks, Mitch. Great to be here.

    Ashley: Super good to have you on the podcast. Would you start out by introducing yourself? Tell us a little bit about you and also a little bit about CloudBolt.

    Sanders: Sure. So, I’m Bernard, CTO and co-founder of CloudBolt, and spent most of my career in the data center automation/DevOps/cloud management space as it’s been known throughout various eras, you know, since 2000 when I started in the industry. And I’ve gotten to see a lot of different enterprise IT shops and how they work—what goes well, what goes wrong. I spent a lot of time in IT shops and the financial services industry and in retail and government, and it’s been interesting seeing the commonalities between these.

    And it was through an observation of those commonalities and talking with a colleague of mine, Augie, that we decided to start CloudBolt software in 2011 and started working on the software, put out first GA release that year. And CloudBolt is a hybrid cloud management platform, sometimes called a CMP. It essentially helps large organizations who have a data center presence and also want to use the public cloud. It helps them consume both from a single interface.

    Ashley: Cool. Well, first of all, I have to compliment you—anybody with a buddy named Augie has to be a good person.

    Sanders: [Laughter]

    Ashley: Augie sounds like a great guy. [Laughter] So, this was like, sort of from your garage, kinda from the basement type of startup that you two started it originally and got this company rolling?

    Sanders: That was basically it. We did have a leg up in that we were working for a consulting company at the time based out of Washington, D.C. named August Schell, and we spun this company out of August Schell. So, starting up, the two of us and the others we brought on were able to focus on the technology and the solution and going and getting some customers, and we didn’t have to worry so much about the back office stuff—the HR, payroll. We piggybacked on our parent company’s infrastructure for a lot of that, so—

    Ashley: Nice. So, kind of a spinout or bootstrap off of the parent.

    Sanders: Exactly, yep.

    Ashley: Very nice. Alright, well, you know, not everybody gets to start out doing cloud applications in a cloud-native format, or even just within one cloud. You know, oftentimes, we’re saddled with complexity, we’re saddled with the existing applications—I don’t mean it in a bad way, it’s just the reality of the business—or we’re part of a digital transformation moving to the cloud, which is sort of where we get these hybrid and multi-cloud environments.

    What are some of the challenges that you saw that set you about, “Let’s go start this company, build this cloud management platform.”

    Sanders: Yeah, yeah. So, there’s a couple areas to discuss there, you know, the first of which you touched on is that not everybody gets the luxury of starting greenfield. You know, if you’re starting a brand new software company with a few people and a few needs for servers, you could start entirely containerized, serverless with the latest technology. But so many companies we talk with, still ask us, “Oh, do you support mainframes? Do you support AIX, do you support HQX?” [Laughter] The answers to those questions are no, in our case, you know? We gotta draw the line somewhere. But there’s a very long tail of technology at these enterprise companies. There is a need for stability and continuity and they can’t just drop everything and move to the latest platform with all their applications.

    Ashley: You know, I like to say generations of technologies never go away.

    Sanders: That’s correct.

    Ashley: There’s probably code I wrote when I got out of college, scary enough, if we think about that. But yeah, it is. You’ve got to adapt to what you have. We can’t rewrite everything.

    Sanders: You know, your other part of your question was what problem did we see that inspired us to start CloudBolt, and what we were seeing, Augie and I, any time we went out to these large institutions is a breakdown in the communication between the IT department at a large company or organization and their end users.

    Ashley: I’ve heard that happens, yeah. I’ve never seen that, but I’ve heard.

    Sanders: [Laughter] Yeah. It just happens so much it’s almost a joke, but you know, end users will have to put in a ticket with IT if they wanna get a VM, either in their private data center or sometimes even in the public cloud. And then that IT group has to go do a lot of manual steps and there’s oftentimes a lot of hand offs between groups to eventually build that environment or that individual VM or network storage out and then get it back to the user. And it’s a black box and everybody gets frustrated with each other.

    Ashley: Mm-hmm.

    Sanders: We thought—there’s gotta be a better way to do this.

    Ashley: So, how organizations can work together more effectively, let’s also tease apart both the multi-cloud and the hybrid aspect of this. So, multi-cloud, do you find that’s because things sort of start up on their own and different groups go out and somebody starts on Azure because they’re Microsoft code, and somebody starts out on Amazon or Google or wherever and then some day, somebody else says, “Why don’t we pull this together?” Or is it more of a conscious, “No, we need these different cloud environments for these good reasons, so let’s put together a cohesive strategy or architecture for how we go about that?” How do those things evolve?

    Sanders: I think it’s both. I’d say it’s probably 60/40. A lot of times, it’ll be a company that says, “Oh, we’re all on Amazon.” Then they go acquire another company that does Azure and then another one that does something else. So, a lot of times, it’s that unintentional growth.

    Ashley: Mm-hmm.

    Sanders: But I think more and more, you’re seeing each of the cloud providers, they are diverging over time and they each have their own strengths and weaknesses. So it’s totally valid to say, “Hey, we’re gonna use Google Cloud for this one thing and we’re gonna use AWS for this other use case, because that’s where these platforms are strong.”

    Ashley: Interesting, interesting. So, talk about the hybrid part of this. You know, whenever there’s a new generation or a new shiny object, it’s like, everything is gonna go there. So, everything is gonna go to the cloud, and of course, many things have and some things have fully and some things have just partially.

    Sanders: Mm-hmm.

    Ashley: And there’s always that need. You talked about mainframes, for example. There’s that need of having a hybrid environment. How do you define a hybrid environment?

    Sanders: Yeah, so I define hybrid as using both a private cloud and a public cloud. So, private cloud meaning your own data center or, you know, maybe one that you colo or somehow rent out. But basically, your own gear, your own hardware and infrastructure, but also using the public cloud at the same time. And that—you know, I think that’s been one of the biggest about faces in the last five or six years is, if you went back five or six years ago, listening to a lot of the industry analysts, you would’ve thought that we’d be off public cloud, you know, a year or two later. Or we’d be off private—

    Ashley: Of private, yeah.

    Sanders: –and that would go totally extinct.

    Ashley: Of course.

    Sanders: And that we’d be completely on public cloud. But I think that was an unrealistic expectation. There was a Goldman Sachs study earlier this year that said 26% of workloads are in the public cloud. So, that leaves a huge portion that’s still a huge majority in the private environments.

    There’s a growing need for hybrid, you know? People don’t want to use both totally disjointedly, they wanna use them together in some way. That’s what I would call hybrid cloud.

    Ashley: That kinda sets the context for talking about this cloud management platform. Define that for us—what is a cloud management platform?

    Sanders: Yeah, cloud management platform is a tool which can provide a single pane of glass or interface as well as API to manage disparate IT environments, and that can be public cloud, private cloud, containers, virtual machines, physical. It can include serverless, it can include public cloud services as well as basically any request you would make of IT. That’s what I would call a cloud management platform or CMP. The other main defining characteristic is, it needs to provide self-service to end users. It has to be a tool where end users can go and get what they want on their own rather than asking IT to do it for them.

    Ashley: So, really, the ability for IT to manage its environment but also to provide portal access, if you will, if you thought about it that way, anywhere for people to do self-service, APIs, STKs, so DevOps groups can tie into the platform.

    Sanders: Exactly. Yep.

    Ashley: Okay. So, let’s go there. Let’s talk about how does DevOps fit into—IT wants to organize things, right? IT wants to get its hands around and be able to at least manage—you know, not necessarily control or constrain, but you know, they’re responsible for what’s happening in the organization with the technology and so, they want some form or semblance of management control over that.

    How do you do that and, at the same time, let the DevOps groups thrive and flourish?

    Sanders: That’s right. Yeah, so, really what it’s about is having the IT team, giving them a tool where they can set their policies, set the standards, but expose an interface, or multiple interfaces, to different departments or groups for those teams and DevOps folks within those teams to go get what they need when they need it and automate what they want on top of that base that IT has given to them.

    So, in the case of most cloud management platforms, the IT group would bring it on, purchase it, get it installed and set up and then expose that UI and API out to these departments who can code against it. So, the DevOps team in a particular department, for example, might have a CI/CD pipeline that calls into the cloud management platform that’s exposed by IT.

    So, both groups are empowered. IT gets to set the quotas and the approval process and the host name standards—like, everything policy related within that cloud management platform, and those end users and DevOps folks get to provision what they want when they want it.

    Ashley: I don’t want to make it sound like a panacea, but it sounds like this would be a path for an IT organization who maybe has lost control or doesn’t feel like they have their arms around everything that’s happening in the organization and they can become sort of the provider of the cloud computing infrastructure resources.

    Sanders: Absolutely.

    Ashley: And this could be a path to them kind of getting in front of what’s happening instead of just being reactionary.

    Sanders: Absolutely, yeah. The other effect that it has that we’ve seen, you know, CMPs have, whether it’s CloudBolt or a different one is that, you know, the private data center has lagged behind public cloud in terms of its interface. Like, going to the Amazon console or Google cloud, ordering a VM—it’s a pretty easy, fairly self-service process. It’s not that way with OpenStack or VMware and Nutanix. I know it was one of private virtualization systems people use.

    Having a cloud management platform levels up your private data center to a level that’s similar to public cloud where people can do self-service in the private data center, not just the public cloud any more.

    Ashley: Okay, so at risk of me sounding like I’m just happy ears and throwing you softballs—

    Sanders: [Laughter]

    Ashley: –what’s the hard part about implementing a CMP?

    Sanders: [Laughter]

    Ashley: It can’t be all roses and, “Here’s a credit card and download and—poof, your NPS scores shoot from 10 to 56.”

    Sanders: Oh, can I only name one thing?

    Ashley: Yeah. [Laughter] What are the challenges of getting from “life’s pretty tough” to, “we’re in a much better position now that we’ve gotten this platform in place”?

    Sanders: Yeah. So, for folks who bring in a cloud management platform, I think the challenges are oftentimes less technical and more organizational, because it affects so many different groups. You have to get people’s buy-in that, “Hey, we’re gonna do this thing. We’re gonna use this as our common interface to IT.” And that can be challenging. I think it’s made easier if the interface is good and you make it attractive and appealing and powerful and give them what they need in that interface, people will come to it. But it can still be hard enacting any kind of a change within these large organizations.

    Ashley: So, is it easier in a smaller organization, mid-sized or large? I can imagine maybe it’s easier in a large enterprise where you can sort of lay out standards and how you have a process for doing that or maybe mid-sized is tougher because it’s harder to herd the cats? I don’t know, what’s your experience?

    Sanders: That’s a good question. I think, just generally, any time you get more humans together, it’s harder to make change and to get them all doing the same thing. And, yes, if you have executive buy-in in a large organization, that can make it easier, but I think it’s still basically always harder to move more people than it is to move fewer people to a new way of doing things.

    Ashley: Okay. So, another, tougher question—why is CloudBolt better than the rest of the CMPs on the market? Why is it a better mouse trap?

    Sanders: [Laughter] Good question. You know, I don’t do a lot of the competitive analysis myself, but what I’ve heard from our customers is that they can get CloudBolt installed and running and get value out of it much more quickly than other platforms. You know, we’ve done demos before where, by the end of the demo, you know, where in a GoToMeeting or a Zoom meeting or we’re showing the product to a customer and by the end, they’re asking us, “Oh, where’s the button for X?” We have to pause and say, “Wait, what’s going on over there?” In the time it’s taken it to demo it to them in half an hour—so, they’ve downloaded it, installed it, connected it to their VMware environment, they’re, like, provisioning VMs. It’s a pretty nice bar, I think, we’ve hit in terms of consumability. They also talk about the extensibility being very powerful.

    We try to build all kinds of hook points and extension points, capabilities to let them extend it to do whatever they need it to. A lot of these IT shops have very specific requirements and systems and standards and ways they need things to operate, so they like that extensibility.

    Ashley: Well, teams doing agile, DevOps teams, you know, they build an environment around them where they can execute quickly because they can get access to resources quickly, you can go to Amazon credit card—poof, I’ve got whatever. And it’s great to build that kind of process and that environment around them. Of course, we run into things that are gonna slow them down, like quote-unquote IT, or some new thing, the shiny new CMP kind of thing.

    How do you get a DevOps team on board that’s been just fine going to Amazon and Google and Azure and whoever else to get what they need and now they need to go through this IT thingy that’s been placed in front of them?

    Sanders: Yeah. I think, really, what you need to do is solve problems that they’ve got, and CMPs do that. You know, when they see one interface, one API that is consumable and up to their standards and allows them to deploy to any different cloud as well as the private data center, usually, it doesn’t take much more convincing than that. They say, “Wow, we were gonna have to build that,” because we were just given the mandate to do two different clouds or to do VMware plus Azure.

    And now, we don’t have to do that ourselves—that’s great. We can build more functionality and just build on top of that great platform there.

    Ashley: Can you come in and work with an existing either homegrown automation, or if they’ve built around some build and automation tools for deploying both code and to the cloud? Can you work with tools that a DevOps team has already set up, or do you have to kinda retool parts of what they’re doing?

    Sanders: There’s usually very little retooling. There’s bidirectional integration that usually happens. You know, if somebody’s gotta build pipeline in Jenkins or Concourse, they’ll oftentimes have that start calling into CloudBolt to do those builds, and they can sometimes remove some of the complexity from their systems if they were calling directly into infrastructure to do that themselves.

    And then, similarly, CloudBolt can call out into existing tools they’ve got. A lot of our customers have homegrown cloud management or change management databases, CMDBs, and they want CloudBolt at some point in the provisioning process to call into those to register a new server or CI in there.

    Ashley: Mm-hmm. What’s the next thing that’s happening for you with your product and where you’re taking this?

    Sanders: There’s a lot of things that are happening in the cloud management space, you know? The space is not too old, so it’s still defining itself, and the industry is still figuring out what they need in this kind of a tool. So, we have been introducing increased cost management and analytics to show you what your public cloud spend is and what you could save and give you recommendations on how to save. So, that’s a common area of improvement, continuing to make it more and more extensible and consumable, of course, doubling down on our containerization support, we started supporting Kubernetes in 2015 and we’re leveling that up in each of our releases.

    And then, as well as supporting all of the different directions the public cloud providers are going, they’re trying to diverge; we’re trying to provide a common platform. So, that’s a constant challenge for us to solve and it’s a fun one and it’s one the engineering teams thrive off of to give people a common interface with increasingly different underlying technologies.

    Ashley: I can imagine, obviously the more tool support that you provide for Kubernetes to Jenkins or whatever the next iteration of fantastic tools that are used in a DevOps environment, all the better. But also, if you’re solving, “Here’s log aggregation, here’s audit trails, here’s access controls that DevOps teams don’t have to set up,” that would be—and you can do it through a programmatic interface—that’s gonna be a win for them.

    Sanders: Absolutely. Yeah, and security is an increasing focus for us as well, providing tools and integrations through which they can make sure every VM that’s deployed is up to standards and compliance and they can get security reports across their entire enterprise.

    Ashley: Yeah, if you can help them sell through a security audit or review, they’re gonna love you, I would think.

    Sanders: Yes.

    Ashley: We could talk about this for another 40 minutes if we wanted to. Unfortunately, we don’t have that much time. I’d like to thank you, Bernard Sanders from CloudBolt, for joining us.

    Sanders: Thanks, Mitch. It’s been really fun.

    Ashley: And I’d like to thank our listeners, of course, for being with us today. This is Mitch Ashley with staging-devopsy.kinsta.cloud. You’ve listened to another DevOps Chat, and be careful out there.

    — Mitchell Ashley

  • DevOps Chat: Enterprise Multi-Cloud Backbone With Aviatrix

    DevOps Chat: Enterprise Multi-Cloud Backbone With Aviatrix

    Our podcast guest believes the world changed “on a Tuesday” six months ago when the enterprise move to the cloud became imperative, not just an aspirational goal. That eureka moment was enough to pull Steve Mullaney off the sidelines and back into the game as CEO of Aviatrix after successful executive gigs at Palo Alto Networks and Nicira.

    “Go build” might be a wonderful approach for cloud-native apps, but enterprises want the framework laid out ahead of their move to the cloud. Think enterprise cloud IT reference architecture, much like Cisco provided for enterprise IP networks, DEC mainstreamed for client-server and IBM established for mainframe computing. You have to bring the cloud to them. That enterprise cloud reference architecture is what Aviatrix targets, in the same buy-with-a-credit-card model that fueled customers’ unfettered move to AWS.

    On our DevOps Chat podcast episode, Steve Mullaney, CEO of Aviatrix, talks about what enterprises want in a true enterprise multi-cloud backbone to support their needs.

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

    Transcript

    Mitch Ashley: Hi, everyone, this is Mitch Ashley with staging-devopsy.kinsta.cloud, and you’re listening to another DevOps Chat podcast. Today, I’m joined by Steve Mullaney, CEO of Aviatrix. Our topic today is enterprise multi-cloud backbone—meaty, good stuff.

    Steve, welcome to DevOps Chat.

    Steve Mullaney: Thanks for having me, Mitch.

    Ashley: Great, good to have you here. I’d like to start by having you introduce yourself. I know a lot of us know you from your background, you’re a fairly well known guy, but tell us about yourself.

    Mullaney: So, yeah, my name is Steve Mullaney, I’ve been in networking and security infrastructure for, really, the past 35 years. I actually started my career in the mid-80s as we were kind of evolving from, transitioning from the mainframe computing model into client server. I was actually an engineer on 10Base-T from the company called SynOptics. So, those of you who’ve been around long enough to remember when Ethernet was starting and—

    Ashley: I do recall.

    Mullaney: 10Base-T started, yeah. So, I spent most of my career in networking and security, I was a very early guy, actually, also at Palo Alto Networks, I was the first VP of Marketing there, employee number 25. And then was CEO of a company called Nicira, which was really kinda the beginning of a lot of this SDN craze and network virtualization. We were acquired by VMWare, and then I stayed at VMWare for a couple years and grew that business, which is now almost a $2 billion business and a ________ business.

    And then, for the last five years, I just, I kind of said no more operational roles and was on boards and I was content to just do that the rest of my life and very happy living the dream. And I saw the world change about six months ago, where enterprises have been talking about the movement to a cloud computing model—honestly, talking about it for the last 15 years, but I noticed really about 6 months ago is when mainstream enterprise really said, “Okay, we are doing this.” And I just looked at that opportunity and said, “My God.”

    And I was on the board of Aviatrix at the time, so I could see this happening up front and just said, “This is just gonna be too much fun not to be involved.”

    Ashley: So, what was it? What was it six months ago or so? When was the nexus point when you saw a change that pulled you out of retirement?

    Mullaney: Yeah. What was interesting was, I love to say, six months ago on a Tuesday. And it felt almost like that much—like, literally on a Tuesday. And that’s how enterprises move, right? They talk about it, they talk about it, they talk about it, they talk about it. It’s like going on a diet. You talk about it and, “I’m gonna go on a diet.” “Well, how about today?” You’ll say, “Well, you know—not a good day.” “Well, how about tomorrow?” “Well, you gotta start on a Monday,” right? And then, “How about next Monday?” “Well, that doesn’t really work, because I’m going on vacation.”

    I mean, there’s all these excuses, and enterprises, about five years ago, really said, “Alright, we are gonna move to the cloud.” And honestly, that’s when every enterprise vendor went, “[Gasps] We’re dead!” Right? “We’re dead. Everything’s gonna go into Amazon and we’re dead.”

    Ashley: Mm-hmm.

    Mullaney: And what happened was nothing, because the enterprises were just talking. They didn’t really mean it, right? So, everyone went along their merry way with quarter after quarter of record highs. Until about six months ago, I’m on the board of Aviatrix, a bunch of other infrastructure companies and I notice the logos are changing. This isn’t Netflix any more, this isn’t small to medium businesses, these aren’t early adopters. These are Midwest manufacturing, conservative companies. What the heck is goin’ on? They shouldn’t be doing this!

    And people think just because AWS is at a $30 billion run rate that we must have crossed the chasm by now. We haven’t. And I’ve noticed, across all of my infrastructure companies that I was on the board of, they’re seeing all the same thing. No one’s done anything different, it’s just, the market just changed. And the way enterprises go, they are a herd mentality. When the majority, you know, the early and late majority of customers all decide to do something, they all decide on the same Tuesday morning, and I saw that happen.

    We saw it with client server. I was at SynOptics at the time. Mainframe computing was the way you did enterprise computing, and client server—PC client server was treated as a toy, just fun and games. So, print sharing, right? PCs—that’s not real computing, right?

    Ashley: Mm-hmm, mm-hmm.

    Mullaney: And then what happened? All of a sudden, in the early ‘90s, on a Tuesday morning, everybody decides the Internet Protocol is the only protocol that matters. All the other protocols went away overnight, and PC client server is the way I’m gonna build up my architecture—and it happened overnight. I saw the same thing happen with cloud.

    Ashley: Mm-hmm. So, it’s really kinda going mainstream, you’re seeing a real—

    Mullaney: It’s gone mainstream. And I’ve been at the company now for three months as the CEO of Aviatrix and every day, I just see more and more evidence of that, that companies are burning the boat—meaning, the corporate data center, the corporate backbone that is dead. It is now an expense. I view it as an expense, and I view anything I do in the public cloud, leveraging the public cloud, as an investment.

    Ashley: Mm-hmm.

    Mullaney: And that means all my people are focused on that as well as all my expenses. And it shifts overnight, and it’s a herd. Every single enterprise around the world is now making that same decision on the same Tuesday morning.

    Ashley: Mm-hmm. I love your Tuesday morning analogy.

    Mullaney: Isn’t it funny? It’s really true, though—it’s really true!

    Ashley: [Laughter] It just seems like it suddenly happened.

    Mullaney: Yeah.

    Ashley: So, you’re on the board of multiple companies. What was it about Aviatrix that you said, “This is the one I’m gonna ride. This is the one I’m jumping on board, I’m gonna be CEO, take this baby where it’s gonna go”?

    Mullaney: Yeah, I think it goes—because it goes in terms of what we say our mission, our mission is to build the enterprise multi-cloud backbone.

    So, when you look at AWS and Azure and GCP and even AWS’ mantra to enterprise is, “go build.” Well, that’s great when you’re an early adopter and they hand you the power tools, and you—

    Ashley: Mm-hmm, the greenfield.

    Mullaney: Yeah and you are that innovative, you wanna go build. That does not go very well when you’re a Midwest manufacturing, conservative company. I’m gonna cut my arm off with power tools. I don’t want power tools. I want a house, I want furniture, I wanna walk in with it done. I don’t wanna build anything.

    Ashley: I want a landing strip, I don’t wanna build the runway.

    Mullaney: Absolutely. I do not wanna build. And so, I think this, honestly, has caught AWS off guard, too, right? Because they’re thinking—all of our customers love that, a “go build” mantra. Not the mainstream, right? Not when it flips. Not when you’ve crossed the chasm and now you’re in the tornado and everybody just, they’ve gone and said, “This is it.”

    And so, I looked at that, and I said, “My God, all of these enterprises are begging—begging—someone to define the architecture for them.” This is just like in the client server where they needed Cisco to come out and define the networking and security architecture for them. Give me the canonical architecture that everyone’s gonna do, and then I will go implement that.

    Ashley: And it’s proven, we’re not inventing.

    Mullaney: And that’s what people want, and they want a validated design. They wanna be able to go, “This is what everyone’s doing, we’ve all agreed, this is what you do. And oh, by the way, I can’t get that from Amazon, because Amazon’s trying to lock me into Amazon. I can’t do it—I can’t get it from Azure or Google. I can’t get it from the old world, I can’t get it from Cisco, because they don’t even understand this,” right?

    Being able to—it’s just like, you wouldn’t go to IBM or Deck for the client server architecture. This is a whole different computing model. You can’t—by definition, the leaders of the old are never the leaders of the new. So, who do I go to?

    Ashley: Yeah, and to the point of multi-cloud, you’re probably not gonna be in just one, yes? It might be appealing to be in Azure for some Microsoft apps, but you also have compelling reasons to be elsewhere.

    Mullaney: I have not met an enterprise that says they’re only gonna be in one cloud. They’re in at least three. Because then you’ve got, if you’re in China, you’re in Alibaba. Then you’ve got, you know, data sovereignty and GDPR and all these kinda other issues that I may have to have multiple providers in Europe, country by country, right? And not even AWS.

    And so—sure, absolutely, it is going to be, and it should be. Because not that you’re gonna move workloads between one to the other. Like, that’s not gonna happen. But what is gonna happen is, maybe the marketing team likes GCP for AI reasons or, you know, I started with Office 365 in Azure and so I’m moving off on that. Or I’m a big enterprise, manufacturing enterprise and Microsoft really understands me. Or I’m a retail and I will not have anything in AWS, right?

    Ashley: Yeah.

    Mullaney: Or I see, even, I’m a customer, I’m a company—a software company. I’m selling to other enterprises. I cannot have my infrastructure if I’m selling to retail. I cannot even have my own internal infrastructure on AWS because they don’t want that to happen.

    So, absolutely, it has to be across all this. And then the other thing is the “go build” mantra—so, even if you could say, “I can figure out how to go build on AWS,” the constructs in Azure and GCP are different.

    Ashley: Right, you’d have to go build everywhere.

    Mullaney: So, now I need to learn those constructs, and now I have to go build there, but with different tools that work differently—like, one’s in metric and one’s in an American system. It’s like—oh, my God, you know? And the tools don’t work. Like—okay, this is ridiculous.

    Ashley: So, you painted a picture of multiple compelling reasons somebody needs to lay the groundwork for me. I’ve gotta be multi-cloud, so I need that reference architecture that’s gonna work across multiple providers. I don’t wanna stick build any more, I wanna be able to walk in and plug my application into a framework, a reference architecture that I can use—that’s what Aviatrix is about?

    Mullaney: Yes. And then layering on top, leveraging the constructs, right? Leveraging the wonderful underlay, right? Of all—think of all the fiber, and the pops, and the data centers, and the regions, and all the wonderful stuff underneath that AWS Azure and Google provide, and growing.

    Ashley: All that infrastructure you don’t have to do.

    Mullaney: That is unbelievable, right? And guess what? I’m an over the top networking and security software player. So, when you think of guys like WhatsApp, you know, AT&T used to always get really mad because WhatsApp gets bought by Facebook for like 30 billion or whatever it was, and AT&T with all their fiber and all their different pops and all their right of ways and everything else like that—what’s their market cap? I don’t know. Probably not even much more than that. And you go, “Why is that? Like, I do all this stuff and I get no credit.”

    Ashley: Spend a lot more money getting there.

    Mullaney: And then WhatsApp with, you know, six engineers gets bought for $30 billion, where’s that? Well, yeah, because the over the top guys, that’s where all the value is. They’re leveraging it.

    So, in a sense, we are an over the top software player, but what we’re over the top of is not the internet on top of AT&T, it’s the new internet. It’s the hyperscalers. It’s AWS, Azure, Google, et cetera, all with massive bandwidth and the best latencies you can get in peering points to each other such that when we overlay these decoupled security services on top, the combination is an amazing architecture and network.

    Ashley: So, talk about those services. Talk about security operations, extensions, transit—all of those things that you need to take care of, orchestration—how does that work with ABHS?

    Mullaney: Yep. Yeah, so in this what we call the enterprise multi-cloud backbone, there are, you know, today probably seven or eight different services that a customer can start with. And the beautiful thing about this, again, you can use Aviatrix. We have over 300 customers right now and growing rapidly all over the world—customers all over the world. We don’t even know that, because this is low friction land and expand. A real true cloud model where they can actually start. It might be $500 a month. It might be $50 a month. It also could be $3,000 a month. They just start using it, and they might stop with one use case. “Let me try it out.” They get their credit card, it integrates in through AWS Marketplace or the other marketplaces, and all of a sudden, they just start charging. And guess what—next month, they add. Next month, they add. Next month, they add. And then they say, “Oh, I now need additional things,” right?

    So, they may start with a service we call user VPN. So, basically, we take OpenVPN and we add a lot of additional functionality to it, integrating it with SAML and other authentication means, add in some more security controls, and say, “Hey, I’ve got users, and I want them to VPN into the cloud, because I have resources in the cloud. I want them to be able to securely connect them to the cloud.”

    That might be the first use case you start with, and maybe you’re paying $1,000 a month, but from there, it’ll start growing where then you say, “Well, now I need transit networking,” right? Or, “I need egress filtering. So, guess what, I start going into the cloud.” Guess what, most of your VPCs and your resources in the cloud have to access things on the internet for build packages or et cetera, right? Because this is a very distributed, hybrid world. So, it’s not just all inside the cloud. Well, guess what? I wanna do filtering on that outbound, and I wanna do what’s called FQDN, fully qualified domain name, which, I don’t wanna do filtering based on an IP address or let them go anywhere they want. I wanna say, “You can go anywhere, yahoo.com or wherever you need to go for that build package.”

    Ashley: Mm-hmm.

    Mullaney: And that’s it. So you wanna be able to whitelist it, and you wanna be able to define it per user and per VPN. So, you wanna be able to have security policies of who can go where. So, that’s another use.

    Other use case is encryption. You know, right now, people say, “Well, you run”—you know, six months ago, when the cloud was kind of fun and games, “Hey, I’m putting workloads up there, it doesn’t really matter, it’s not my enterprise.” You know, maybe you didn’t worry about encryption. But now, you’re a retail or you’re a bank, you know, and all of a sudden, you care. So, you’re gonna wanna—

    Ashley: Yeah, if you’re gonna put in an enterprise application, you’re gonna miss encryption, security, it’s high [Cross talk].

    Mullaney: Yep, yep. You’re gonna wanna encrypt in flight, right? So, not only do we allow encryption, but we also allow high performance encryption, right, to 10 Gig, 20 Gig, 30 Gig and more, where—you know, and that’s important as people are putting PII data and other things. And also, from a security perspective, people know that—look, I’m just gonna encrypt everything. The data as well as in transit.

    And then, you know, as you talked, being able to do this across multiple clouds, right? So, I maybe can connect, I wanna be able to connect up multiple regions within one of the clouds, but then I also wanna be able to go to the other clouds as well and create one kinda common framework upon what we’re doing.

    And then I’d say another service is what we call firewall network service, and that’s another one, I can talk more specifically about that. But everybody that’s coming to the cloud—again, this isn’t fun and games any more, this is serious business. The first thing they say is what? Security and policy, I need to bring my next generation firewall policies into the cloud with me. And I need—so, if I’m a Palo Alto Networks customer, the first thing I wanna do is, I wanna take my VM series into the cloud. And when I try to do that, the construct of how AWS says you can connect your VM series firewall into AWS forces compromises in performance, scalability and visibility that are just untenable. And, with Aviatrix, we eliminate those trade-offs.

    Ashley: It’s certainly a fundamental component of where you’re gonna start to build out your infrastructure. If you can bring as much of your own network security into the cloud, all the better—that’s your strategy, yeah.

    Mullaney: Yeah. Well, you know, I think what’s important is, and I think guys like Amazon are realizing this, is when you have to deal with, when you’re dealing with the enterprise—and I mean, the enterprise. The Midwest, conservative, classic mainstream enterprise, right? You have to bring the cloud to them. You can’t make them go to the cloud, right? They’re looking at this and they’re saying, “Okay, I’m all in. I’ve burned the boat, I’m gonna get rid of my data centers, I’m all in.” But then they look and they go, “The grass ain’t as green as I thought it really was.”

    Ashley: Mm-hmm.

    Mullaney: There’s a lot of burned out spots, here. This “go build” mantra? Whoa, whoa, whoa, whoa—wait a minute. I thought I was gonna hit a couple clicks and be done. And oh, by the way, CEOs and CIOs of companies, they’re all bought in and said, “Hey, you know, we used to have hundreds of people managing this infrastructure when it was on prem, but I understand cloud. I only need tens now,” right?

    Ashley: Mm-hmm.

    Mullaney: So, the problem is, [Laughter] they go to the cloud, and again, I’m seeing this everywhere, every enterprise said, “We don’t really have enough people.” Like, we got kinda sold a bill of goods, here. Everyone kinda told us this was like click, click, click—you’re done. It ain’t that easy, right? And then you throw across, “Now, I’m gonna do it across multiple clouds—I don’t know how we’re gonna do this.”

    Ashley: Well, let me ask you, then, we’re coming up on the end of our time here, together—if you had one parting recommendation thought for those enterprises that are in that first six months window and really looking at moving to the cloud or are in that process, they wanna check out Aviatrix, they wanna maybe do a prototype or look at the reference, how they build a reference architecture on the platform—how do they get started? What’s the best way to do that?

    Mullaney: I mean, the first thing I always tell people, the best way to get started is actually just get started. The good thing about this modern world is, we don’t have to do a POC. We don’t have to—you can actually get started over the weekend, and that’s how many of our customers start. They just start playing around with our software, like on AWS Marketplace, it’s a great place to start. They just spin up a controller, they spin up a couple gateways, they—and we have quick start guides to show you how to do it in a very easy way. And people start playing with it and they go, “Oh, that’s pretty interesting.”

    And so, they start with kinda one use case, right, and a very small little bit and they effectively do their own little POC. And they say, “Okay, that’s pretty interesting.” Now, we can also do it for them, but that’s a pretty good way to start.

    And then I’d say the other thing is, what you really are gonna look for—I mean, there’s only one reason why people aren’t using Aviatrix right now is because they’ve never heard of us. As soon as they—as soon as we talk to people, they’re sold. Because they look and they go, “This is exactly”—people say, “That’s exactly what I’m looking for. I need someone to help me build out my multi-cloud, my enterprise—my, my, not someone else’s, my enterprise’s multi-cloud backbone, and all these networking and security services that go along with it. That’s what I need, and you guys are doing it for me? That’s exactly what I need.”

    Ashley: Well, great. I thank you so much for being with us. We’ve reached the end of another DevOps Chat podcast. It seems like there’s never enough time. I’d like to thank you, Steve—Steve Mullaney, CEO of Aviatrix for joining us.

    Mullaney: Great.

    Ashley: And thank you, you, to our listeners for joining us also, of course. This is Mitch Ashley with staging-devopsy.kinsta.cloud. You’ve listened to another DevOps Chat. Thanks for joining us.

    — Mitchell Ashley