Tag: open source

  • Survey Surfaces Uneven Approaches to DevSecOps

    Survey Surfaces Uneven Approaches to DevSecOps

    A ZeroNorth survey shows implementing DevSecOps is rife with questions for many organizations, with no clear answers

    There’s general agreement that digital business transformation initiatives are driving an overall acceleration in the rate at which applications are developed. At the same time, however, given the critical nature of those applications, cybersecurity has never been more of an imperative for DevOps teams. The challenge they are encountering is not so much a lack of tools to address that requirement, but rather a lack of clarity in terms of what tool to use when.

    A survey of 57 cybersecurity professionals conducted by ZeroNorth, a provider of a platform for orchestrating vulnerability scanning tools, highlights the extent of the DevSecOps challenge. The survey finds 63% of respondents said their organization currently employs six or more scanning tools. The most widely employed are network scanning (53%) and vulnerability scanning (51%). However, a quarter (25%) don’t know if their organization is using interactive application security testing (IAST), while 19% don’t know if they are using software composition analysis (SCA) tools.

    As far as DevSecOps is concerned, there’s little to no clarity in terms of where to primarily focus scanning efforts. Build/CI environments (68%) receive the most focus, but 46% are focused on scanning within integrated development environments (IDEs). Container/artifact management (67%), source code repositories (58%) and deployment (56%) all fall somewhere in between, the survey finds.

    There’s also no clear consensus on the merits of open source versus commercial testing tools Open source software (OSS) tools were identified as a priority for less than half of respondents (47%). However, 27% of respondents said they expect to begin using open source tools in 2020. Of the respondents currently employing OSS tools, 14% said believe these tools are more effective than commercial test and scan tools. Well over a third (39%) said they believe they are more effective when combined or customized. Just under a third (32%) said OSS tools are equally as effective as commercial options, while only 9% said they are less effective.

    The survey also shows disparity when it comes to the various areas that make up a digital business transformation, with the most mature being cloud migration (80%), followed by DevOps (67%), continuous integration/continuous delivery (CI/CD) (62%) and microservices (62%). Overall, 79% of respondents said they have a digital business initiative underway.

    ZeroNorth CTO John Steven said it’s clear that in many cases, the need for faster iterations of application development is outpacing the operational capabilities of IT organizations, especially when it comes to DevSecOps. Given the chronic shortage of cybersecurity professionals, there may be an average of only one cybersecurity professional for every 100 developers. Having cybersecurity professionals participate in every scrum session isn’t feasible, so there needs to be a way for cybersecurity professionals to provide guidance to developers specifically when it comes to what scanning tool should be applied and when, said Steven.

    The survey finds network (53%) and vulnerability (51%) scanning are the most broadly employed. However, that also suggests that many IT teams involved in digital business transformation initiatives are not making use of scanning at all.

    The good news is that survey respondents said identifying bugs, flaws and vulnerabilities throughout the software development life cycle (SDLC) is either “extremely” (58%) or “very” (42%) important to all participants involved. A total of 47% said it was either “extremely important” or “very important (35%) to improve visibility around operations by integrating security earlier into the software development life cycle (SDLC). However, while the DevSecOps spirit may be willing, the ability to implement best DevSecOps practices is still clearly weak.

    — Mike Vizard

  • Report: More Salesforce Customers Adopting DevOps

    Report: More Salesforce Customers Adopting DevOps

    A survey of 201 executives who work in organizations that have adopted the Salesforce Lightning platform finds a surprising number are employing DevOps practices to customize Salesforce software-as-a-service (SaaS) applications.

    Conducted by Beagle Research Group on behalf of Copado, a provider of a commercial continuous integration/continuous delivery (CI/CD) platform for Salesforce SaaS environments, the survey finds 48% are using open source platforms to drive those DevOps processes, while 26% are relying primarily on in-house developed CI/CD toolchains. Another 36% are using commercial platforms developed for the Salesforce platform.

    Andrew Leigh, senior vice president of marketing for Copado, said DevOps has gained traction in Salesforce application environments because most digital business initiatives revolve around customer records and marketing applications. As organizations attempt to drive new digital customer experiences, they find they need to frequently update what have become highly customized SaaS applications.

    Many of those organizations are surprisingly agile. A quarter (25%) said they release code to their Salesforce production environment multiple times per day, while another 29% said they can implement changes in less than one day. More than half (53%), however, said deployment can take between a day and a week.

    Ambitions in terms of DevOps capabilities are running high. A total of 19% want to be able to deploy multiple times per day; while another 16% would like to release between once per hour and once per day. One-third (33%) want to able to at least be able to release customizations once per day to once per week.

    More than half, (54%) said their lead time for making changes to their Salesforce environment is between one day and a week. However, 21% said lead time is less than a day and 8% said they need less than an hour. Collectively, 83% said they can make changes in a week or less.

    Overall, 77% described their Salesforce DevOps strategy as being as mature as the DevOps strategies for other technologies in their companies. However, only 42% are consistently employing automation to drive DevOps processes.

    Like most organizations that have adopted DevOps, it doesn’t appear customers who rely on Salesforce are immune from their share of DevOps issues. Almost half (43%) said they have performance problems after a deployment up to 15% of the time. Only 2% said they had issues between 76% and 100% of the time. One-fifth (21%) said the time to restore service levels is less than an hour, while 43% said it could take up to a day to rectify an issue.

    As far as future plans are concerned, the top three priorities identified by survey participants are increased speed to market and increased developer productivity (tied for first place), making applications more customer-relevant and continued innovation (tied for second place) and increased employee satisfaction and release quality (tied for third place).

    Salesforce may not be getting its full due for being a provider of a SaaS platform for building customized applications. However, it is clear that most Salesforce customers have come to recognize that SaaS applications are just another type of platform for building and deploying customized applications using best DevOps processes.

    — Mike Vizard

  • DevOps Chat: From 0 to 1,000 Deploys Per Month with Redbox

    DevOps Chat: From 0 to 1,000 Deploys Per Month with Redbox

    Many organizations want to implement the latest DevOps/SRE practices, but many struggle with transforming the existing processes over to new streamlined processes. How does an organization transform from zero automated deploys to 100s/1000s a month? Most importantly, how do you show the value of Spinnaker to your business as a whole?

    November’s Spinnaker Summit 2019 in San Diego allows us an opportunity to hear and learn from DevOps engineers, developers and practitioners using Spinnaker open source software. Joel Vasallo, manager of Cloud DevOps at Redbox, shares a preview of his talk where he shares his experience about using Spinnaker open source to increase the number of deploys into production. Joel found Spinnaker so useful because it is very extensible, covers AWS well, strong support for Kubernetes, different deployment types and has the automation to create the software delivery platform that fits the need.

    Joel’s talk, Transforming Software Delivery using Spinnaker, is on November 17, 12:30 pm PT at Spinnaker Summit 2019 in San Diego.

    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 devopsy.kinsta.cloud, and you’re listening to another DevOps Chat podcast. Today, I’m joined by Joel Vasallo who is manager of Cloud DevOps at Redbox. We know Redbox is the movies, the kiosk, the online service—great.

    Our topic today is going from zero to thousands of deploys a month. Boy, if you’re not doing a thousand a month already, that sounds like a great place to be. This is actually a preview of a talk Joel is doing at the Spinnaker Summit on “Transforming Software Delivery Using Spinnaker.” It’s 12:30 p.m. Sunday, November 17th in San Diego. Joe, welcome to DevOps Chat.

    Joel Vasallo: Hey, thanks so much for having me, Mitch. I’m glad to be here.

    Ashley: Glad to have you here. Well, tell us a little bit about yourself, what you do at Redbox and also, hopefully people know Redbox, but just a bit about Redbox.

    Vasallo: Yeah, no, my name is Joel Vasallo, I’m the Manager of Cloud DevOps at Redbox involved with software delivery to the cloud. In my spare time, I’m a GDG organizer, so a Google Developers Group here in Chicago. But about Redbox, I mean, you said a lot of people know what Redbox is. We’re the kiosk that’s usually found in your grocery store. So, we do DVDs and Blu-rays, but we also, a little known fact is, we do have an on demand platform, so video on demand, and that’s kind of our new thing that we’re doing right now. And there’s actually a lot of motivation around building fast deployments, and that’s kind of gonna be my drive for the talk.

    Ashley: Awesome. Now, just a question for you for cloud DevOps—does cloud actually include software that’s being delivered or information being delivered out to those kiosks, too, or is this really for the on demand platform in the cloud that you—

    Vasallo: Yeah, there’s some aspects of it as well. I mean, there’s a lot of APIs in use across the company, so there are some that do kind of traverse the cloud in that regard—yeah.

    Ashley: The only thing better than APIs are common APIs, right?

    Vasallo: [Laughter] Exactly.

    Ashley: Reuse.

    Vasallo: Yeah, especially if you have a solid delivery platform—of course.

    Ashley: Absolutely delivery platforms. Okay, so, let’s jump into it. We’re giving a preview of your talk, so there’ll be a lot more content, of course, in your actual talk. Tell us a little bit about, if you’re already achieved this thousands of deploys, you’ve been at this for a while. Tell us a little bit about how you got started on this journey.

    Vasallo: Yeah. You know, to preface a bit, I mean, I’ve been in the Spinnaker community since, like, late 2015, when it was still kind of an early release out of the open—in the open source community. And at a previous role at Gogo, I used to work at Gogo and we implemented Spinnaker basically from day one. And prior to that, we were using some other open source—Netflix open source tooling as well.

    But in that journey, we were going from a traditional monolithic, you know, to a microservices architecture, and the goal was to essentially build a way to deploy to the cloud as fast as possible, right? And just taking and building on those practices, you know, applying all the things, the same—the 12 factor concepts, immutable infrastructure, routing, all that stuff.

    It kind of transformed into some open source tooling that we’ve written in my history, and there’s also some practices when using Spinnaker to make such a big change in an organization, right? I mean, the whole topic of DevOps in an organization, there’s so many great talks out there, right?

    Ashley: Mm-hmm.

    Vasallo: And that’s definitely one of the—I guess, arguably, the hardest bit is, “Well, what does the DevOps mean for you?” Right? That’s the typical phrase you hear when people say, “Well, we’re DevOps.” “Well, what does that mean?” Right?

    Ashley: Well, now, you’re talking, obviously, at the Spinnaker Summit, and it sounds like you’re pretty committed to the product. This isn’t a podcast about that specifically, but you sound pretty dedicated to it. Why Spinnaker?

    Vasallo: You know, it’s—the core fact is, it kind of extends a little bit past just deployments. It has—it’s really, the biggest thing is, it’s so extensible. Right out of the box, you’re just coming out swinging. The fact that Netflix, Google, Microsoft, a lot of big names—Amazon as well, how could I forget?—are contributing and helping build this product up, you have some pretty big names out there, right? And why not lean on the shoulders of giants. They’ve seen, I would argue, probably one of the bigger challenges in terms of software delivery, especially at an in demand space such as, you know, for example, Netflix, right?

    Ashley: Mm-hmm.

    Vasallo: And building on that success, you know, you basically get those batteries included, right? You get some battle tested software, and I think that’s one of the biggest things.

    But in addition to that, I mean, it’s extensible. It covers Amazon very well, it covers Kubernetes, it has support for various deployment types and various customizations as well, some of which are customizations you need to build, and some customizations are actually built into the platform. And the best part, it’s open source, so that’s my favorite thing.

    Ashley: One of the key words I didn’t mention that I know your talk’s gonna be about is automated deploys, right? You’re not doing hundreds of thousands with a lot of manual process. Talk a little bit about the key of automation and you kind of assume a development team is gonna be all about—yeah, let’s automate this and make our lives easier, but maybe it’s not that easy to get from point A to B where you do have that automated. Talk about that part of the journey.

    Vasallo: Yeah, no, I agree with you. And I mean, it’s an unfortunate thing in the landscape right now where a lot of companies are rushing into the DevOps landscape, right, and they just say Jenkins, right—Travis CI, GitLab, whatever. And, you know, you’re essentially flooding tools on the market, right? And it’s very tough.

    But having a lot of tools doesn’t mean you’re DevOps, right? There’s some fundamental business changes that have to occur in order to achieve that delivery that we’re talking about, right?

    Ashley: Mm-hmm, yeah.

    Vasallo: So, with that, it’s kind of taking—how do I call it?—the little infinity loop of DevOps, right? Where that’s great and, you know, the plan, code, build, release—you know, that little cycle, it’s great, but you can’t use that as a guiding principle. There’s not enough detail, right? And then you can have the extreme on the other side, where it’s like the Candyland, I like to call it, where it’s like the Candyland of ITIL process where you’re just essentially passing Go and then passing down a ladder, if conditions. That’s too complex, and that’s hard to explain. So, there has to be something kind of in between.

    And that’s kind of what I’m gonna be focusing on in my talk and really asking the questions of how do you lay out an effective delivery process? What are some steps—what are the steps at your organization to get changes out the door? Because it’s a different answer for every company, right? There’s no one truth out there, unfortunate as it sounds.

    Ashley: Mm-hmm. Well, and everybody’s environment is unique. Maybe some of the problems are the same, but there’s also, you know, what is unique about your organization, whether it’s the business technology or just people, the team you’re working with has strengths in certain areas.

    Vasallo: Yeah, of course. And that’s something that I kind of build on in the talk is about building minimum viable products, right? And the argument is, many minimum viable pipelines, right? Really laying out, end to end, what needs to be done to get software delivery to occur. And the best way to start is really to look at what’s kinda currently happening, right? Lay out, you know, change has to come in, goes through phase two, phase three, phase four, and then ultimately phase five—profit, right?

    Ashley: Mm-hmm.

    Vasallo: Well, what are those phases and how much investment should be done in each spot, right? You can spend your time automating, I don’t know, some aspects of your pipeline, but what’s the return on investment, right? Would it have been better served in, for example, automating quality versus automating security scans, right? What’s gonna be the most immediate value in shaving time and getting you back from, you know, these long, drawn out pipelines to potentially fast and efficient ones, right?

    Ashley: It’s interesting. What was sort of the starting problem that took you down this path? Was the business asking you, “Hey, we need stuff faster, faster, faster”?

    Vasallo: Yeah.

    Ashley: Or was it just your own, “We don’t have resources, so let’s figure out how to automate it”? I mean, what kinda got you going on this?

    Vasallo: Yeah. So, a little bit about myself, I joined Redbox back in 2018 with the mission of building a software delivery pipeline to get software—me and my team to get software into the cloud. And with that, there’s also the transformation aspect of, “Well, what is the cloud? How do we integrate with the cloud?” And a lot of questions kinda came up.

    Fortunately, we took a big investment in doing a cloud native approach, you know, from day one. Which means no lift and shift, which is awesome. It’s arguably the hardest path, [Laughter] as we probably all know, but this means essentially from the ground up, building a software delivery platform, right, that’s integrated from the, all the way down to the development layer and all the way up to the automation layer. So, we’ve been very fortunate to work on something like that.

    That’s kind of where we started, and that was the motivation of building a truly cloud native pipeline, so, yeah, working on that stuff.

    Ashley: Now, you mentioned you’ve developed some tools, too, and with Spinnaker being open source, have you contributed a lot back to the community yourself, or are you more of a consumer of it? You know, everybody plays a different role, and not everybody’s, you know, having an open source project.

    Vasallo: I’ll selfishly say that I’m more of a consumer of it.

    Ashley: That’s okay.

    Vasallo: I would love to contribute more to it. I’ve done a few contributions in my past, but in recent times, I haven’t.

    With that being said, though, my team is empowered to make change and drive changes, so we do have one or two changes in flight, and one of them actually got merged this past week. So, we’re looking to help grow and not just be consumers. We’re hoping to also build and solve the same problems we’re seeing, maybe, for other people as well.

    Ashley: Well, good. That’s great if you get a chance to do that. Keep in mind, you know, exercising it, especially at the volume you’re talking about, that is super valuable, too. That’s what helps improve software, whether it’s open source or paid for. So, that’s another—

    Vasallo: Well, yeah, and I mean, it’s kinda like what you’re saying. If you’re not paying for the software, maybe you can pay for it within support in the sense that Spinnaker’s community is an open community. There’s a Slack channel out there and you can join—anyone’s more than welcome to join, ask questions, and get answers from potentially some high up people. And Netflix, even people in the community in general, right?

    We’re all on the same journey, and I mean, that’s arguably what kinda kept me involved in the Spinnaker community is just seeing such an open and collaborative group of individuals just willing to help each other—special interest groups every week or so meeting and just saying, “Hey, what’s the direction of the project? What else can we do? What are some challenges we’re seeing?” It’s actually been pretty fun.

    Ashley: What are some of the objections you typically see or maybe that you even ran into about automating and doing deploys at that volume?

    Vasallo: Yeah. So, it’s not like we’re doing 1,000 more changes a month, right? It’s arguably, running fast can initially be seen as a reckless approach, right? You know, if you said, “Hey, we’re averaging 10 deployments a month”—maybe that’s a standard organization—“to 1,000,” you’re gonna definitely open up some eyeballs, right? People will be like, “Wait, wait, wait. What do we need that for?”

    Ashley: “What about stability? What about up time? What about”—

    Vasallo: Exactly, exactly. But the argument is, it could be said that smaller changes typically result in less down time, right? If you can break down a purchase path change in some company, right, and maybe saying, “Hey, we’re gonna make a UI change and then we’re gonna do a back end change that’s backwards compatible and we’re gonna do, then, an API tier change to support that change such that everything hooks together,” you then broke up one large change of three major components into three separate small, individual pieces that can be rolled out safely, right? And tested and embedded as well. That’s the most important part. Because you’re only as good as your automation and testing as well.

    Ashley: Now, did you do much shift left in terms of doing more security testing or vulnerability testing earlier in the Dev cycle, too, as part of this?

    Vasallo: Well, so, that’s the beauty of it. I mean, essentially, the pipeline doesn’t, at least for us, doesn’t start at Jenkins or the build time. It starts all the way at the commit. So, we have a lot of tooling, at least at Redbox, that’s built to empower developers. The thing to also note about those 1,000 deployments—those deployments aren’t, you know, some Ops team clicking an OK button. They are developers promoting their own code, and they are empowered to write and deploy code to production when they feel it’s appropriate to release, right?

    But in doing that, we don’t just give them the keys to the city, right? We build a nice, safe, and reliable pipeline—essentially, a paved road, if you will. That’s the kind of term I’ve been hearing it described where, you know, you can ride the paved road and have fun. You can get off road and it’ll be bumpy, but the majority of the time, the paved road will get you to production as fast as possible.

    Ashley: Right. Yeah, that paved road concept comes from the Netflix paved road talk that they gave. I think that was OSCON or something.

    Vasallo: Yeah, there are definitely a lot of great things from the engineers there, a lot of inspirational things kinda came out of it. I mean, again, it’s building on the shoulders of these giants, right? They’ve seen, arguable, large percents of Internet traffic, right? And at that level of success, you know that some of those concepts definitely can be applied elsewhere, right?

    Ashley: Mm-hmm. Well, you know, one of the things that’s maybe a little bit misleading in saying automated deploys is, it isn’t just the deployment process that’s automated, is it? Talk about what all the parts that are automated to be able to deploy at that volume.

    Vasallo: Yeah, no—definitely. I mean, it’s essentially part of the—part of the talk is also gonna, the little secret of it is, it’s not like you can roll in Spinnaker and have an automated deploy and you’ll be good, right? There’s a lot of aspects of a pipeline, and as I was alluding to from a commit layer, right, whether you do your static analysis for security early on, whether you do your unit tests at build time, whether you have an automated way of storing in archiving artifacts, right? You need to know what is making it out to your environment stage prod.

    In addition to that, you need to build that infrastructure automatically, right? So, we have things—you know, you can use things like Terraform and CloudFormation as well, right?

    Ashley: Mm-hmm.

    Vasallo: But your load balancers, your security groups—again, we’re talking within the context of AWS—how do you reliably and repeatedly build your infrastructure in such a way that it can support that rapid deployment, right? You can’t just have an automated pipeline where it’s like, “Okay, hold the lights, let’s go call up somebody and say, ‘Hey, we need a load balancer. Can we get that done?’ ‘Sure, give me five minutes.’” Even five minutes is too slow, right? We need to have an automated way of creating and also getting fast feedback to our developers when these changes work and when they don’t work, right, so they can help triage and figure out what’s going on.

    Ashley: It’s almost like I’ve said before—DevOps is an overnight success 35 years in the making. [Laughter]

    Vasallo: [Laughter] That’s a good one, that’s really good.

    Ashley: Where you kinda get there one step at a time, but it is, and I think that’ll be something interesting to anticipate about your talk is really thinking about it holistically and what that entire process—not that you’re gonna go into every bit of detail in that amount of time, but it is about all of that and connecting the toolchain, the work flow, and the process, people process part of it into something that can be automated and happen at high scale.

    Vasallo: Yeah, that’s definitely something to be said there. I mean, a lot of—it’s generally a soft topic, but it’s arguably one of the more important ones is, there has to be a cultural transformation and understanding if you truly wanna be as successful as some of these giants, right?

    Building the concepts of open culture, right, working together, cross functional teams—there’s no magical fix out there in the world to fix a broken process in a broken culture, right? And that’s the toughest thing. And then that’s something, definitely, we touch on as well. And I alluded to it earlier with the concepts of, for us, that’s empowering our developers. So, building compelling tools for our developers to use every day they come to work.

    Ashley: Well, you mentioned keys to the kingdom for the developers. I can’t imagine you did all this without some form of senior leadership backing. How did you get that and where did you get it from to go down this path?

    Vasallo: Yeah. So, it definitely started very grassroots, right? Say the challenge to get to the cloud, right? That’s an easy challenge and I think a lot of—sorry, that’s an easy statement to say, but what does that mean? And for every organization, it’s different, right? For some, lift and shift is the most appropriate solution if you’re not willing to invest in the cultural changes, right?

    But for me, at least in my experience, it’s always been finding the hero in the regards of not necessarily a hero mentality, but finding that one champion who can help drive that, you know? That team who is under a tight deadline and you’re like, “Hey, you know, you’re a relatively new project. You’ve never really seen—you’ve never really gotten deployed. How about we just take an experiment and see if we can automate your app end to end, right?”

    Ashley: Mm-hmm, mm-hmm.

    Vasallo: The good news is, it’s a pretty low risk, it’s a new feature. The timeline, obviously, is always a concern, right, in terms of meeting business deliverables. But in doing that, working with those individuals, you not only can get fast feedback as to the proposal of the pipeline, you can also build a relationship that essentially is like DevOps and Devs working together to kind of create this delivery solution, if you will.

    Ashley: Hmm. Well, I feel like we just scratched the surface, which is probably a good thing, because it’s the preview of your talk. I appreciate you coming on the podcast today, Joel.

    Vasallo: No—no worries. Hey, thanks so much for having me. Again, I hope to see everyone at the Spinnaker Summit. It’s gonna be a great time, so I hope to see everyone there.

    Ashley: It is. Well, definitely, I’d like to thank Joel Vasallo, Manager of Cloud DevOps at Redbox for joining us today. Again, Joel’s talk at Spinnaker Summit, which is at 12:30 p.m. Sunday, November 17th in San Francisco, it’s titled “Transforming Software Delivery using Spinnaker,” so be sure and check that out if you’re making it. Now you have a reason to go to San Diego in the fall coming on the winter.

    Vasallo: Other than the great tacos, yeah. And everyone, join us on the Spinnaker Slack, we’re happy to help out and answer any questions as well. We’re more than a welcoming community, so hope to see more folks there.

    Ashley: That’s a great point. It’s a very vibrant community. So, we wish you all the best in your talk, and everyone, you’ve listened to another DevOps Chat podcast. I’d like to thank you, our listeners, for joining us today. This is Mitch Ashley with devopsy.kinsta.cloud and you’ve listened to another DevOps Chat. Be careful out there.

    — Mitchell Ashley

  • DevOps Deeper Dive: DevOps Accelerates Open Source Innovation Pace

    DevOps Deeper Dive: DevOps Accelerates Open Source Innovation Pace

    In the span of a few short years, open source software has evolved from being a means to create the free equivalent of an existing commercial platform to now becoming the primary means of driving innovation across the IT industry.

    That rate of innovation has increased dramatically in the last few years. However, much of that innovation would not have been possible if large swaths of the open source community hadn’t been able to employ best DevOps practices to collaborate, said CloudBees CEO Sacha Labourey.

    Early on, the adoption of open source software was driven by a desire to commoditize operating systems and databases by making available a free equivalent.

    “It was all about replacement software,” said Labourey.

    Open source adoption got a major boost in the enterprise during the last economic downturn. Many organizations implemented an “open source first” strategy to lower their IT acquisition costs. As part of that mandate, developers began making greater use of cloud infrastructure to build applications based on an open source stack of software using best DevOps practices.

    In some cases, that preference for open source software turned into religious fervor. In other cases, it simply became a means to bypass IT purchasing processes that developers considered obstacles to writing code. Of course, it was only a matter of time before the open source software used to build applications made its way into production environments managed by IT operations teams.

    Just as significantly, open source software was leveraged to build public clouds that today are transforming the way IT is consumed.

    None of this shift has been lost on IT vendors. As the demand for proprietary code slackened, many found it profitable to offer support services for open source software. The more there is to consume, the more the support services contracts grew. Now every vendor from IBM to small IT services providers such as Fairwinds has launched open source projects that help drive demand for IT services expertise.

    “There’s pain around integrating a lot of disparate open source projects,” said Robert Brennan, director of open source software for Fairwinds. “Organizations may be getting software for free, but there’s usually not a lot of help around.”

    Now almost every IT vendor in the world is making software engineers available to work on open source projects. All that talent focused on open source projects has led to the development of new platforms such as Jenkins, GitHub, Kubernetes and, more recently, a raft of smaller projects. With the rise of containers and cloud-native applications, open source software projects are entering another era that will see many of those same software engineers leveraging DevOps practices more broadly to drive even more innovative projects at increasingly faster rates.

    “All the innovation is now being driven by open source,” said Joe Fernandes, vice president, products for cloud platforms at Red Hat. “You no longer have to wait for a single vendor to move something forward.”

    The challenge many organizations now face is keeping pace with the rate of innovation. Most major open source projects, thanks to DevOps practices, are updated once a week. To shield themselves from having to work with raw bits of code, many IT organizations rely on curated distributions of open source code from vendors such as Canonical, SUSE and Red Hat.

    Today, the economics of software development have changed. Providers of proprietary software are at a distinct disadvantage when competing against open source projects that can marshal more developer resources. A vendor selling proprietary software needs to keep a smaller team of developers highly focused on adding compelling, innovative features faster than an open source project can replicate them. As many vendors continue to show, that goal isn’t impossible to achieve; however, it is a pace of innovation that is exceedingly difficult to maintain.

    It remains to be seen just how much of the software deployed in IT environments will be based on open source code going forward. But with each passing day, the balance on the scale continues to lean further away from proprietary code.

    — Mike Vizard

  • 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 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 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 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 devopsy.kinsta.cloud. Thank you for joining us. Be careful out there.

    — Mitchell Ashley

  • Kong Employs Machine Learning to Extend Services Control

    Kong Employs Machine Learning to Extend Services Control

    At the Kong Summit 2019 conference, Kong today announced it has acquired Insomnia, an open source testing tool for application programming interfaces (APIs). In addition, it has added support for REST, Kafka Streams, gRPC, GraphQL and plugins written in Go to its service control platform.

    Kong also added more capabilities based on machine learning algorithms in the form of a visual service map a Kong Immunity module that detects anomalies across services spanning multiple platforms.

    Additionally, the company is delivering Kong Studio, a suite of tools to design, build and maintain APIs for REST and GraphQL endpoints based on the API testing and debugging tool Insomnia, which then can be published to Kong Gateway, proxy software for deploying and managing distributed APIs. The 2.0 release of Kong Gateway separates the data and control plane for the platform and provides the ability to write plugins in Go via Kong’s Plugin Development Kit.

    Kong CTO Marco Palladino said collectively, this approach makes it easier to address a raft of potential API issues at design time rather than after an API has been pushed into a production environment.

    Finally, Kong also updated Kuma, an open source control plane for a service mesh based on Envoy proxy software developed under the auspices of the Cloud Native Computing Foundation (CNCF).

    Kong has been making the case for a service control plane dubbed Kong Brain, which spans both cloud-native and legacy monolithic environments and makes extensive use of machine learning algorithms. Palladino said as more services proliferate across existing monolithic and cloud-native application environments, there is no way IT organizations will be able to keep pace without relying more on machine learning algorithms to manage events and processes occurring within milliseconds of one another across the much more complex IT environment.

    In fact, Palladino noted that rather than expecting one environment to supplant the other, IT organizations should expect to see services proliferate across both monolithic and cloud-native application environments. Managing all those different classes of services will require a service control platform capable of spanning multiple environments, he said.

    Over time, machine learning algorithms will enable service control platforms to become smarter as IT environments transition to managing services end to end versus continuing to focus on individual applications. Naturally, there’s a high correlation between organizations that have made that transition and those that have embraced DevOps to build, deploy and manage those services, said Palladino, noting the most successful organizations employ DevOps to deploy and update APIs as if they were a standalone application rather than a set of add-on capabilities that tend to be forgotten over time.

    It remains to be seen how the confluence of APIs and DevOps ultimately will change how IT is managed. The only thing that is for certain is the days when applications were managed in isolation are finally coming to a much-needed close.

    — Mike Vizard

  • 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 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 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 devopsy.kinsta.cloud. You have listened to another DevOps Chat. Be careful out there.

    — Mitchell Ashley

  • Continuous Delivery Foundation Momentum Picks Up

    Continuous Delivery Foundation Momentum Picks Up

    The Continuous Delivery Foundation (CDF) this week revealed that it now includes 33 member organizations, including now JPM Chase, eBay, Dell Boomi, Cycloid, White Source, the Association of DevOps Professionals and the DevOps Institute.

    Founded by CapitalOne, CircleCI, Cloudbees, Google, Huawei, IBM, jFrog, Netflix and Salesforce in March the CDF is committed to promoting the adoption of open source continuous integration/continuous deployment (CI/CD) tools and platforms. Dan Lopez, CDF program manager, said the CDF plans to launch technical committees soon that address areas of CI/CD interest, including cybersecurity, software supply chains, software delivery management and machine learning algorithms in IT operations (MLOps).

    The CDF is not focused on promoting one open source CI/CD platform over another as much as it is fostering cross-engineering whenever feasible. As such, Lopez said the CDF is trying to advance adoption of the open source Jenkins and Jenkins X CI/CD platforms as well as the Spinnaker platform from Netflix. As other open source technologies are presented to the CDF, a technical oversight committee will evaluate them for inclusion, he said.

    At present, the membership of the CDF falls into three broad categories: companies that build tools and platforms, companies that leverage those technologies to deliver products and services and end user organizations such as JP Morgan Chase, eBay and CapitalOne.

    Lopez said the next goal is to expand the reach of the CDF beyond the U.S. and Europe to create a global CI/CD community. It’s not clear how many CI/CD platform providers will join the CDF. However, as membership in the CDF increases, pressure to join continues to mount.

    In the meantime, DevOps teams should expect collaboration between vendors to accelerate the pace of innovation across the entire DevOps life cycle. Vendors will be able to more easily identify areas to collaborate on that don’t provide much in the way of differentiation and yet are critical to advancing DevOps adoption.

    While a lot of progress has been made in terms of CI use, CD has proven to be an especially thorny challenge for most organizations. That’s become a significant challenge as organizations build applications at a faster rate and in many cases are still being deployed manually in production environments. Via the CDF, vendors are hoping to promote adoption of best practices across the entire DevOps toolchain as they gear up to introduce additional products and services that assume a strong CI/CD foundation is in place.

    It’s not clear to what degree the CDF will be able to accomplish that mission, given that most of the CI/CD issue organizations encounter are more cultural than technical. At the very least, however, organizations struggling with these issues should find solace among other like-minded souls wrestling with the same issues.

    — Mike Vizard

  • Red Hat Unveils Ansible Platform

    Red Hat Unveils Ansible Platform

    At the AnsibleFest 2019 conference, Red Hat this week announced the general availability of the Red Hat Ansible Automation Platform that combines several IT automation technologies into a single subscription.

    Built on top of Red Hat Ansible Engine, the platform also includes Red Hat Ansible Tower, a management console, and Red Hat Network Automation, an instance of Ansible designed to automate the management of network resources.

    Red Hat is also providing access to a software-as-a-service (SaaS) analytics application that enables IT teams to monitor how deeply Ansible has been adopted within any IT environment. That application also provides access to Ansible Content Collections, a packaging format that streamlines the management, distribution and consumption of Ansible content, and Automation Hub, a repository for certified content packaged using Ansible Content Collections.

    Richard Henshall, product manager for Red Hat Ansible Automation, said with this offering Red Hat is trying to make it easier for enterprise IT organizations to implement Ansible at scale. Most of the time the Ansible framework is adopted from the bottom up within an IT organization. Red Hat Ansible Automation is intended to make it easier for enterprise IT organizations to centrally deploy and manage all their instances of Ansible, he said.

    Although it’s not possible to know how many instances of the open source IT automation framework have been installed, Henshall noted there are already more than 4 million Ansible nodes that are tied to a paid support subscription from Red Hat. Most of those instances involve organizations that have adopted a declarative IT automation framework as part of their overall DevOps strategy, he said. While IT organizations don’t necessarily have embrace DevOps to employ Ansible, Henshall said there is a strong correlation.

    Much of that success can be tied to the fact that as a declarative framework Ansible doesn’t require IT operations teams to learn how to program to manage IT operations at scale. That approach has allowed IT teams to adopt the open source framework to meet the demands for more agile approaches to managing IT infrastructure stemming from developers who have embraced best DevOps practices.

    In addition, IT infrastructure vendors such as Cisco Systems, NetApp and F5 Networks have begun to embed Ansible within their server, storage and networking platforms. As those vendors sell the latest edition of their offerings, the number of IT organizations exposed to Ansible should begin to substantially increase.

    Henshall said the biggest issue now is expanding the scope of Ansible deployments. Most organizations initially wind up using Ansible to automate disaster recovery before moving on automate additional existing processes. Red Hat is now trying to encourage those teams to create new processes that previously would not have been possible without an IT automation framework, he said.

    Ansible may not be a de facto standard in the enterprise just yet, but it’s well on its way. Of course, there are still many IT professionals for one reason or another still tend to resist relying on IT automation frameworks. There are also several rival IT automation frameworks that have been embraced by DevOps teams. But when it comes IT automation, it’s clear Ansible is starting to emerge as the path of least resistance.

    — Mike Vizard