devopsy.kinsta.cloud

Tag: red hat

  • DevOps Chats: DevSecOps and OpenShift, with Red Hat

    DevOps Chats: DevSecOps and OpenShift, with Red Hat

    In this DevOps Chats, we had a talk with Kirsten Newcomer, senior principal product manager at Red Hat. It is a great discussion on the state of DevSecOps and how the Red Hat OpenShift team is trying to make it easier for developers, DevOps and cyber folks to work together to create more secure applications.

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

    Transcript

    Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, Container Journal, Security Boulevard—you’re listening to another DevOps Chat. Welcome, and I’d like to welcome to our DevOps Chat Kirsten Newcomer of Red Hat. Kirsten, welcome.

    Kirsten Newcomer: Thank you, Alan. Great to be here. So, I’m Kirsten Newcomer as you said, Red Hat. My focus at Red Hat is DevSecOps for cloud-native applications, been working at Red Hat for about four years now. It’s really kind of fun. I’ve managed to leverage kind of my—all sorts of different elements of my background over the years. I spent time at Rational Software, nine years, working on developer tools.

    Shimel: Sure.

    Newcomer: Yeah. Spent some time with BMC BladeLogic on the operations side of the world, seven years at Black Duck Software focusing on solutions that help companies manage vulnerabilities in open source software, and that led to the move to Red Hat where I get to focus on OpenShift security and DevSecOps and sort of everything comes together. So, DevOps—

    Shimel: It really does.

    Newcomer: Yeah.

    Shimel: I mean, following your career, I think I know just about all of those companies intimately and know a lot of people—I’m sure we even have a lot of people in common that we’ve worked with.

    Newcomer: I bet we do.

    Shimel: It’s funny. So, you were at Rational, left Rational only to return to IBM Rational.

    Newcomer: I know! [Laughter] That is true.

    Shimel: You know, it’s the circle of life right there, man. [Laughter]

    Newcomer: It is the circle of life, yep.

    Shimel: Welcome. So, Kirsten, look, DevSecOps is of course something near and dear to us. We put on every year at the RSA conference our DevSecOps Days or DevOps Connect/DevSecOps Days.

    Newcomer: Uh-huh.

    Shimel: We actually have the virtual event of that live on Thursday, I think it’s the 26th, March 26th.

    Newcomer: Nice.

    Shimel: So, you know, it’s something, quite frankly, this whole security thing is the reason I got into DevOps is, I thought—what a great opportunity for security to cure a lot of original sin.

    Newcomer: Absolutely. [Laughter]

    Shimel: But anyway, you know, when we look at the DevSecOps and the DevOps world, Kirsten, you can’t help—you must take notice of the impact that Kubernetes and the whole cloud-native kind of movement has had on this.

    Newcomer: Okay.

    Shimel: And a great—

    Newcomer: Absolutely, no—big changes, yeah.

    Shimel: And, you know—and it’s really at the core of so much of what is being done right now from an infrastructure point of view. And oftentimes, I don’t know if people—like everything else, right? I remember when the cloud came out and we moved from client-server and all this. Security, there’s always that lag, right, where, “Oh, yeah, we gotta do security with this.”

    Newcomer: Yep.

    Shimel: And we had a little bit of that with Kubernetes, I think, where—

    Newcomer: No, I think that’s fair.

    Shimel: Yeah? You know, people were rushing to do Kubernetes and experiment with it, deploy it, and then someone started saying, “Wait a second, what about security, here? What about compliance? What about this or that?”

    Newcomer: Yeah.

    Shimel: And now, I will tell you, and I’m interested in your opinion—I thought the lag time was much shorter this time than what we’ve seen in the past.

    Newcomer: Oh, I absolutely think so. And I think it’s really interesting. A couple of things that I’ve observed. One is that I really think containers and Kubernetes have created a terrific opportunity to shift security left, and I’ll kinda be more explicit about that in a couple ways. But I, in fact, have worked with a chief of cyber defense in the public sector who believes and evangelizes that containers improve security, and I’ve stolen his line, because I just actually think that that’s really valid.

    Because of the changes in the model, with the OS dependencies and the run time, everything’s kinda packaged together and you have that immutable container image that you’re always deploying from, you really can manage things in a new way and not every team is ready for this, and not every team, not every security vendor is ready for this, either.

    So, I think the opportunity has been twofold. One is to kind of adjust the thinking about security so that it no longer becomes something that happens at the end, but that’s still a process, that’s still a lot of work. And the other thing is, the security tooling space itself has historically been pretty siloed, right? There’s been, you know, the OS layer security, the network layer, there’s been kinda—you know, my SIEM and my SOC that I’m working with, and my cert management and my vaults.

    And none of them really were designed to work with the level of automation that Kubernetes and containers enable, which led to this really interesting opening for smaller companies, a lot of startups that now have been around for a little while, actually, to start breaking down those silos and delivering security capabilities in a new way that kind of really do fit the DevSecOps model, because you get kinda one vendor bringing a set of capabilities that ranges from CI/CD integration to run time security to network security, really fascinating space to see how it’s been evolving.

    Shimel: It really has. The other thing that I will tell you, Kirsten, that I was again encouraged by was when I first started seeing people talk about security through containers and Kubernetes, it really was like—let me scan your container for vulnerabilities, right?

    Newcomer:  Yeah. [Laughter]

    Shimel: And I’m thinking to myself—I don’t care whether my code’s in a container or in a hypervisor or on bare metal. A vulnerability scan is a vulnerability scan. There’s gotta be more to this than just a more vulnerability scan kind of a thing.

    Newcomer: Absolutely. And that’s, I think, where, as you mentioned earlier, that, you know, Kubernetes really has come a long way in that space. So, there are things like, if we think about—so, absolutely. Vulnerability scans are fundamental and kinda, people always understood those. They tended—historically, they’ve happened a little too late in the life cycle, making challenges for the AppDev team and such.

    We’re seeing that shift left a lot, but then there’s all these other range of things that you should be doing and can be doing to build security into the platform. And so, when we saw pod security policies in Kubernetes, for example, that’s a way that the Kube admin can take advantage of the Linux features that enable container isolation at the Kubernetes layer and enforce things like ensure that a container doesn’t run with unnecessary privileges.

    Shimel: Sure.

    Newcomer:  And so, we are seeing more capabilities—now, that’s still beta, so the community still has some work to do there. But as you say, we’re seeing more emphasis and, you know, the open source Kubernetes security audit sponsored by the CNCF is a great example of that.

    Shimel: Oh, absolutely. And look, CNCF has done yeoman’s work here. They’ve really, really done a nice job with the whole Kubernetes project, specifically security.

    You know, but one of the reasons, like—we did a webinar yesterday for instance and it was on, you know, the different cloud providers versions of Kubernetes and—

    Newcomer: Uh-huh.

    Shimel: [Cross talk] environments. And, you know—fantastic, we had 700 and something people sign up for this webinar.

    Newcomer: Great.

    Shimel: A lot of great questions, even on the YouTube afterwards, a lot of great questions. One of the things that became clear to me in listening to people talk is that—you know what? Just going to, whether it’s AWS or Azure or GCP or whatever and setting up my Kube environment may not be the best thing for me because I’d rather get one of the package distributions, if you will, or a more complete solution, of which Kubernetes is a piece, like an OpenShift, but some others were mentioned—Rancher and so forth.

    Newcomer: Sure.

    Shimel: But OpenShift was the most popular one mentioned. And I think one of the reasons is, people want to know that security has been kinda built into it.

    Newcomer: Yeah.

    Shimel: Beyond just the Kube release, whether it’s 1.4, 1.5, what have you, 1.6—you know, what else has been wrapped around that just K8—

    Newcomer: Yeah.

    Shimel: —to make it easier?

    Newcomer: Absolutely, and that’s been a big focus for us at Red Hat, really, from the beginning. You know, an enterprise solution—and this is a place where, so, we’ve talked about changes in the security tooling that needed to be made to adjust to the technology, but by and large, the principles still apply. You know, you still need audit logs, right? You still need, you know, to log data from the cluster itself. You need log data from the applications. You need monitoring tools. And so—and you need to think about host arrest security as well.

    And so, we’ve kind of really looked at the stack as kind of spanning all of those things, and we want to make it as easy as possible to manage that solution as a solution, right? And so, that if you—and plenty of folks do this, you know, and get value from it. But if you’re in a situation where you can afford to kind of do a DIY Kubernetes and add in a logging stack and add in kind of all the different pieces that you really need for the enterprise solution, then you have to maintain them each separately and you’re maintaining the host OS separately as well.

    And so, we’ve really focused recently, especially with OpenShift 4, on automating everything, which includes the host operating system. So, Rel CoreOS, Fedora CoreOS available as an open source project. It’s a container optimized operating system that we manage as part of the full platform. It makes it much easier to apply OS updates across your cluster. You can do that in a way that has zero downtime for your well-behaving apps. You can take a node out of service in the way you would, you know, that Kubernetes manages it. Update that with a patch to OpenShift or its components or the operating system itself, put it back in service.

    And so, kind of a combination of looking at the whole stack holistically, what is an enterprise need in order to ensure that they have a secure environment, a stable environment, a highly available environment and making sure that we kind of leverage the terrific declarative and automation capabilities of Kubernetes kind of throughout the whole stack.

    Shimel: Absolutely. You know, I didn’t realize just really all of—you know, until you just said it, I never kinda put together all the pieces of what you guys are doing with that. It’s pretty amazing, isn’t it?

    Newcomer: It’s really cool. And one of the other fun things that we get to do is, we actually—so, back to, if we think about the host OS layer for a bit, right? If you need to scale your clusters, that means adding a new host and you’ve got the work involved to be sure that you deploy that infrastructure and that you secure that infrastructure according to your standards and then you put Kubernetes on top of it and add it to the cluster and you’re ready to put workloads on it.

    And we’re using the concept of Kubernetes operators to automate the components of OpenShift, including the host OS. So, we have a machine config operator, so if you’re deploying OpenShift in a cloud where you can automate the addition of infrastructure easily, you can use the machine config operator and the declarative nature of Kubernetes, right? It’s a container optimized OS, it’s delivered primarily as container images, the user space is read-only, you’ve got that declaration of what a host should look like and you can just use the machine config operator to spin up new hosts and add them to your cluster.

    Shimel: Excellent. You know, we would be derelict in our duties, I guess, if we didn’t mention the whole COVID-19 and how that’s affecting things.

    Newcomer: Fair enough, yes.

    Shimel: In my mind—so, first of all, I don’t think a lot of what we’re seeing right now and its effects are necessarily three-week or six-week or, you know, a lot of this stuff is gonna stick.

    Newcomer:  Yeah.

    Shimel: I think one of the things that are gonna stick are, people are gonna want more automation, right?

    Newcomer: Absolutely.

    Shimel: In their deployments, in their operations, in their infrastructure.

    Newcomer: Yep.

    Shimel: And automation, from a security point of view, is kind of a double-edged sword, right? At least we, from—when things are automated from a security point of view, we think we know exactly what’s gonna happen, and so we can plan around that. On the other hand, security people tend to get a little fritzy, you know, when things come out of our cold, dead hands, here.

    Newcomer: Yeah.

    Shimel: What do you think? How—what do you think?

    Newcomer: I know; I agree with you. And I think one of the things that, one of the ways that Kubernetes is kinda pushing the boundaries with security teams. And I talk to a lot of different security teams over time. So, it’s kinda like—you know, they’re a little bit more comfortable with the idea of DevOps for the application layer at this point, right? For those containerized apps that are gonna be deployed, it’s like—okay, they kinda have an idea of, “Yep, security static analysis tools, integrated vulnerability scanners integrated.” There’s some cool new stuff coming out that I’m seeing on the market, they’re tools that are starting to evaluate the configs and the Dockerfiles, too, that’s really great.

    But—and then as we continue to move into the ops space, right, with Kubernetes and the SDN, which is required for any Kubernetes cluster, and now we have service mesh added into the mix, or Istio for microservice based communications. The network security teams are uncomfortable with who’s gonna manage network policies at the Kubernetes layer and now, I’ve got service mesh or Istio policies as well, and who’s responsible for those?

    And in the end, it’s really about visibility. So, if we circle back to automation, we’re really looking at infrastructure as code, you know, GitHub’s model that applies again to the Kubernetes layer, to the configuration of the Kube cluster as well, and we need to put in place, you need the automation to get the best results, but you need to do it in a way that gives the security team visibility into the kinds of things they’re used to seeing.

    And so, I think this is another way where we’re starting to shift left in new ways, and I’m also seeing solutions that help automatically generate network policies based on evaluating an environment or an automatic generating service mesh policies based on evaluating the config for the apps.

    But all of that, you know, the network security guys aren’t necessarily gonna log into the cluster to look at that. So, how do they get the view they need to get, and how do they help the AppDev teams understand that whole risk management and their security perspective? And so, this is where it’s not just about tools, it’s about people and processes, right? And I think there’s so much richness here, but you’re absolutely right—we can’t do it without automation. And so, we’re gonna have to help these people become comfortable with this shift while ensuring that they get the visibility they need to know that things are being done in a way that meets their risk guidelines, their regulatory requirements, and the security posture they want.

    Shimel: So, to me, one of the fundamental things with DevSecOps, one of the fundamental shifts in DevSecOps is, first of all, security people recognizing that they’re not the only ones who care about security.

    Newcomer: Mm-hmm.

    Shimel: Believe it or not, the developers and the DevOps folks, they do care about security. They may not be security trained people, but they care about security.

    I think the second thing with that is, the developer people have to realize, and the DevOps teams have to realize that the security people aren’t there just to be the roadblock.

    Newcomer: Right.

    Shimel: And they aren’t always gonna be the people who say no.

    Newcomer: Right.

    Shimel: And what we’re—so, this has nothing to do with technology, per se. This is a people to people issue.

    Newcomer: Absolutely.

    Shimel: And I think we’re making real progress in that, and as a result, what we’re seeing is security people paying for and approving security tools that developers in DevOps teams are using—

    Newcomer: Yeah.

    Shimel: —on the Kubernetes platform—

    Newcomer: Yep.

    Shimel: —you know, because that’s kinda the platform of choice now, and that, to me, that’s what keeps me optimistic about this.

    Newcomer: Yeah. No, I’d agree, and also, when we think about the broader landscape, I mean, there’s, the security threats are just ever-evolving, ever-changing. And there aren’t enough security trained professionals to go round, right? There aren’t enough cybersecurity folks, et cetera.

    And so, we have to figure out, how do we help teams scale, and collaboration is the way to do that. And you’re right, I see the same thing you do, right, that the security team is approving those tools that are container native, Kube native tools that help to ensure. And in some ways, I don’t mean this in a negative way, but in some ways they kind of are pushed into that because they’re traditional tools that used to be used kinda at the back end of things aren’t effective in the container and Kubernetes world.

    And so, they really do have to go with this shift that we’re seeing in the vendor landscape, and it just opens up this terrific opportunity, though, for that collaboration and that shared knowledge which, you know, is an adjustment for people sometimes.

    Shimel: Yeah, agreed, agreed. Kirsten, when we first started, I said, you know, the time goes really quick, I’m only gonna keep you here 15 minutes—well, that was 21 minutes ago.

    Newcomer: [Laughter] Okay.

    Shimel: We—yeah, we did it. Alright. We’re gonna have to call a wrap on this one. Maybe we’ll have you come back another time and we—

    Newcomer: It’s a plan!

    Shimel: —can continue the conversation there, good?

    Newcomer: Great. It was great fun—thank you so much, Alan.

    Shimel: Thank you.

    Newcomer: Alright.

    Shimel: Kirsten Newcomer, Red Hat, our guest here. This is Alan Shimel for devopsy.kinsta.cloud, Container Journal and Security Boulevard. You’ve just listened to another DevOps Chat. Stay well, everyone.

    — Alan Shimel

  • Survey Sees Open Source Adoption, Quality Gains

    Survey Sees Open Source Adoption, Quality Gains

    A survey of 959 IT leaders published this week by Red Hat finds increased reliance on and adoption of open source software is now being driven by perceived higher quality as much as it is cost concerns.

    The survey finds higher quality of software (33%) was the top reason they chose open source, followed by lower total costs of ownership (30%) and better security (29%).

    Gordon Haff, a technology evangelist for Red Hat, said the survey makes it clear that open source adoption is now being driven from the top-down as well as the bottom-up in most organizations. What’s changed is that open source software is now being used more broadly as more organizations appreciate how open source approaches to building software not only lower costs but also improve overall quality.

    The survey identifies the top three use cases for employing open source software to be IT infrastructure modernization (60%), application development (53%) and DevOps (52%).

    As part of that shift, 56% of respondents said they plan to increase usage of containers over the next 12 months. In fact, on average respondents said cloud-native applications already make up 25% of their portfolio, compared to an average of 36% for cloud-enabled applications and 39% for legacy applications. The combination of cloud-native and cloud-enabled applications (61%) already outnumber legacy applications (39%).

    Over the next two years, 47% of respondents plan to either modernize (17%), rearchitect as cloud-enabled (16%) or rearchitect as cloud-native (14%) their legacy applications. Another 16% said they would sunset or decommission those applications.

    Overall, the survey finds there has been a marked shift away from proprietary software. Only 42% said that more than half of the software they use today is proprietary, down from 55% a year ago. Two years from now only 32% said they expect proprietary software to account for more than half their portfolio. On average, respondents said 36% of their organization’s software is open source, which in two years is expected to increase to 44% in two years. A total of 77% said they would increase usage of open source software over the next 12 months.

    However, barriers to adoption of open source software remain. Security of the code (38%), level of support (37%), compatibility (34%) and lack of internal skills (33%) were all cited as ongoing issues.

    The top three areas in terms of infrastructure where enterprise open source solutions are being used today are security (52%), cloud management tools (51%), database (49%) and big data analytics (47%). A total of 83% said open source has been instrumental in their organization’s ability to take advantage of cloud architectures. Almost two-thirds (63%) said they have a hybrid cloud infrastructure environment today. Among the 37% that don’t, more than half (54%) plan to have a hybrid cloud infrastructure environment within the next 24 months.

    It’s apparent that open source software is now everywhere. The real challenge now is finding a way to manage it all.

    — Mike Vizard

  • IBM Doubles Down on Cloud, But Is Krishna an Interim CEO?

    IBM Doubles Down on Cloud, But Is Krishna an Interim CEO?

    Big news from Big Blue yesterday: IBM CEO Ginni Rometty is stepping down after eight years at the helm. In her stead, IBM is doubling down on the cloud by appointing Arvind Krishna as CEO and member of the board. The real move to watch, though, is the appointment of Jim Whitehurst, Red Hat CEO, as president of IBM and a board member. It’s the first time that someone has held the title of president singularly, and it may portend where the real power will be at Big Blue (and Red).

    Krishna was previously head of the cloud and cognitive software division at IBM. He is an IBM veteran, having been with the company since 1990. His appointment sends a strong signal about how important the cloud is to IBM’s future. In some ways, it is similar to Satya Nadella’s appointment at Microsoft. But perhaps it’s not as strong a signal about the importance of the cloud than the $33 billion IBM spent acquiring Red Hat.

    It is that $33 billion investment and the importance of Red Hat to the new IBM that leads me to believe Krishna may, in fact, be a transitional CEO. The eventual appointment of Whitehurst as CEO and the rise of Red Hat leadership within IBM may in some ways be a reverse-merger type of thing, with Red Hat eventually running the show.

    IBM is a huge beast. A company of Red Hat’s size will find it difficult to change the culture and overcome the inertia at IBM. But frankly, IBM has been transitioning for almost all of Ginni’s time there. While the Enterprise Systems group (Z systems mainframe) is still the cash cow, bringing in a large percentage of revenue, IBM has increasingly tried to be a major cloud player.

    The SoftLayer acquisition didn’t quite give the company what it needed, as it was not a public cloud play. It left IBM unable to compete with Google, Microsoft Azure and AWS in true cloud services. After a few fits and starts, IBM decided that Red Hat, with its open source pedigree and cloud strength in both public and private cloud settings, could be the engine that could as it pertains to cloud.

    The street has not been kind to IBM over the last few years as a result of the botched cloud play, either. At a time when its tech competitors and the market in general have soared, IBM has actually fallen, as has its revenue.

    Mitchell Ashley, founder and managing analyst at Accelerated Strategies Group, agrees with this assessment. “We are seeing a sea change in big tech CEO strategy. Like Microsoft’s elevation of cloud exec Satya Nadella to CEO, IBM is rebuilding its executive ranks from the open source cloud software world with the appointment of Red Hat’s Jim Whitehurst as president and board member,” he said. “How soon the Krishna regime including old-line IBM executives gives way to Whitehurst and other Red Hat executives remains to be seen.”

    IBM CEO Change Elevates Open Source from Digital Anarchist on Vimeo.

    Ashley was not the only analyst to weigh in.

    “IBM bet the farm on cloud with the $34 billion Red Hat acquisition,” said Steve Duplessie, founder and senior analyst at Enterprise Strategy Group (ESG). “It was only a matter of time for the succession. Now the two top dogs running IBM are cloud purists. The old IBM died a while ago and they had to change—I like the move! Their stock lost 26% while the S&P rose over 150%. This lets them remake themselves before it’s too late.”

    Changes at the top don’t always portend success. There is a lot of hard work ahead at IBM as the company continues this journey. Competing with AWS, Google, Microsoft and other players in the cloud space is going to be challenging, given the head starts these players have already. But you really can’t count out IBM, ever.

    One other thing I wanted to mention: With IBM’s appointment of Krishna at IBM, there now are CEOs of Indian descent at Alphabet (Google), Microsoft and IBM. This is very positive for all persons of not only Indian heritage but for all people of color and nationalities. Kudos to these companies and these men for their success. Now, how about some women of color in these roles?

    — Alan Shimel

  • Red Hat Bolsters RHEL 8 Monitoring

    Red Hat Bolsters RHEL 8 Monitoring

    Red Hat is looking to expand the number of organizations embracing best DevOps practices by expanding the monitoring capabilities included in Red Hat Enterprise Linux (RHEL).

    The beta release this week of RHEL 8.2 includes an update to Performance Co-Pilot (PCP), a system performance toolkit that now includes collection agents for Microsoft SQL Server 2019 databases.

    Scott McBrien, a principal product manager for Red Hat, said by extending the scope of the performance toolkit, Red Hat is looking to make it easier for IT generalists and developers to collaborate across silos to better maintain application performance levels. Support for Microsoft SQL Server 2019 is an outgrowth of the alliance Red Hat formed with Microsoft way back in 2015. However, McBrien said IT organizations should expect Red Hat to continue to expand the reach of PCP.

    RHEL 8.2 Beta also simplifies the process of invoking the Red Hat Insights analytics service during the installation process and provides tighter integration with the extended Berkeley Packet Filter (eBPF) to better analyze network traffic.

    Finally, the latest version of RHEL extends an Applications Stream capability to segregate runtimes and languages to additional programming environments and provides a tool to test in-place upgrades to RHEL 8 from RHEL 6/7.

    McBrien said Red Hat is trying to keep to a six-month upgrade cycle of RHEL to provide IT organizations with a more predictable timetable. Of course, most of Red Hat customers are still running RHEL 6/7 releases. However, as the rate at which applications are built, deployed and updated continues to accelerate in the age of DevOps, the more pressure there will be on IT teams to maintain application performance levels across an increasingly extended enterprise. Inevitably, IT generalists will need access to a broader range of observability tools at all layers of the stack to keep pace.

    Adoption of DevOps practices across the enterprise remains uneven at best. However, as more IT generalists are exposed to richer monitoring tools at the operating system level, the easier it becomes to augment or supplant legacy ITIL-based approaches to managing IT. In fact, as tools at the disposal of IT generalists become more sophisticated, the need to rely on various classes of IT specialists declines. Most IT organizations are especially keen to achieve that goal because labor stubbornly remains the single biggest cost of IT.

    It remains to be seen to what degree the management of IT will be transformed in the months and years ahead. The one thing that is certain is IT will become more complex as new architectures based on microservices and serverless computing frameworks get adopted. Each additional layer of abstraction may make it easier for developers to build applications, but from the perspective of the IT operations teams, they tend to increase dependencies between systems that are already fairly fragile. The challenge now is to identify where bottlenecks exist between all those systems before a degradation in application performance becomes a full-blown catastrophic event.

    — Mike Vizard

  • Red Hat Extends Runtimes Middleware Portfolio

    Red Hat Extends Runtimes Middleware Portfolio

    Red Hat has made available the latest instance of Red Hat Runtimes, a suite of lightweight open source components and frameworks that makes it easier to discover the middleware most appropriate for building a specific type of application.

    James Falkner, product marketing director for Runtimes at Red Hat, said as organizations embrace cloud-native application architectures based on microservices it’s become increasingly challenging to determine what middleware to deploy optimally and where. Red Hat Runtimes not only makes it easier to navigate all those options, Falkner said, but all the components and frameworks are certified to be pre-integrated.

    The latest version of Red Hat Runtimes adds support for Open Liberty, a lightweight runtime for building Java applications developed by IBM. Red Hat was acquired last year by IBM.

    The latest installment of Red Hat Runtimes also provides access to what has become a standard distribution of Node.js based on Red Hat Software Collections that will be implemented across all Red Hat offerings.

    Finally, Red Hat has also added support for Red Hat Single Sign-On, an access control framework based on the Keycloak project.

    Falkner said Red Hat Runtimes also serves to reduce the total cost by providing a single subscription through which organizations can access everything from container runtimes to the 3Scale application programming interface (API) management middleware, which Red Hat acquired in 2016.

    Very few IT organizations these days are standardized on a single class of middleware, especially as they embrace microservices-based applications built using containers. Most IT teams for the foreseeable future will need a flexible way to access multiple runtimes in support of everything from monolithic applications based on Java to applications built using Node.js code deployed using Docker containers.

    Rather than a piecemeal approach to the middleware infrastructure required to build, deploy and integrate all those applications, Falkner said Red Hat Runtimes provides a more holistic approach.

    It’s not clear how much or even whether IT organizations are centrally managing middleware in the age of DevOps and the cloud. Historically, many IT organizations preferred to standardize on a single application server platform to deploy various classes of middleware. However, many developers today are deciding what middleware to include within their application stacks without much input from a central IT function.

    Via Red Hat Runtimes, Red Hat is trying to make a case for providing developers with the flexibility they cherish in the form of a subscription service that provides IT teams with a modicum of control over what middleware gets employed.

    Tensions between DevOps teams and central IT organizations have arguably never been higher. In fact, many DevOps teams are operating within lines of business that are outside the direct control of centralized IT. As such, the level of standardization that can be imposed by central IT organizations has become more constrained. Many centralized IT organizations are now trying to influence middleware platform decisions rather than outright make decrees that might get ignored anyway.

    Regardless of the middleware platform choice that ultimately gets made, however, the one thing that most centralized IT teams will have to come to terms with is finding a way to support it.

    — Mike Vizard

  • Raytheon Leans on Red Hat to Advance DevSecOps

    Raytheon Leans on Red Hat to Advance DevSecOps

    Raytheon Company is partnering with Red Hat to drive the adoption of DevSecOps workflows and processes it developed around the OpenShift application development and deployment platform.

    Jon Check, senior director for cyber protection solutions for Raytheon Intelligence, Information and Services, said Raytheon has developed a set of DevSecOps practices for organizations building applications deployed in highly secure environments, involving government contracts.

    Raytheon and these customers have been challenged by a chronic shortage of IT professionals with the appropriate level of clearance to work on these classified projects. To overcome that issue, Check said Raytheon developed what it describes as a “code low, deploy high” approach to DevSecOps. Developers who lack security clearances can still build applications; however, those applications can only be deployed by IT professionals having the appropriate security clearance.

    In addition, Check said Raytheon has developed integrations between its DevSecOps framework and various IT tools based on the ITIL framework, which so many IT operations teams depend on to foster collaboration across the application development and deployment process. For example, he said, whenever code gets checked into a repository, an alert can be sent to an IT service management application from ServiceNow.

    That approach enables organizations to build applications quickly without compromising the integrity of the deployment platform, Check noted. Now Raytheon is working with Red Hat to drive adoption of its approach to DevOps to organizations beyond the core vertical industry and government sectors it serves.

    Check said Raytheon chose to work with Red Hat because organizations are now building applications employing microservices based on containers that they want to be able to deploy on any cloud computing environment. Those environments include edge computing platforms to process data in near real-time closer to the point where data is collected.

    In addition, Check noted Red Hat OpenShift is built on Red Hat Enterprise Linux (RHEL), the first operating system to achieve Common Criteria certification with Linux Container Framework Support. Red Hat also assumes responsibility for curating the underlying open source operating system and application deployment platform.

    In general, Check noted that while there’s a lot of interest in deploying code faster these days, the deployment of insecure applications is counterproductive. Organizations too often find themselves rolling back application deployments to deal with one cybersecurity issue or another. By separating application development and deployment, Raytheon is making the case for a DevSecOps approach that enables more secure application code to be deployed faster, he said.

    Each organization will have to determine what rate of application deployment is fast enough for them. The more sensitive the application is, the more an organization is likely to want to be more deliberate when it comes time to deploy and update an application. However, the need to be deliberate doesn’t necessarily mean organizations should continue to rely on legacy approaches to application development and deployment based on waterfall methodologies.

    — Mike Vizard

  • DevOps Deeper Dive: SUSE Sets DevOps Course

    DevOps Deeper Dive: SUSE Sets DevOps Course

    There was a time when SUSE was considered to be the second-biggest force driving the adoption of Linux in the enterprise, after Red Hat. Then came an odyssey to rival any epic written by Homer. A few short years after moving its corporate headquarters from Germany to Oakland, California, the company was sold to Novell, which was then later acquired by Attachmate. Three years later, Attachmate was acquired by Micro Focus. Three years after that, SUSE (as an arm of Micro Focus) acquired distributions of OpenStack and the Cloud Foundry platform-as-a-service (PaaS) from Hewlett-Packard Enterprise (HPE).

    That brings us to 2018, when SUSE was spun out of Micro Focus to become an independent company once again, headquartered in Germany once again. A year later Melissa Di Donato, formerly chief operating officer (COO) of SAP, was named CEO of SUSE. A few months after that, SUSE announced it would withdraw its distribution of OpenStack from the market to focus its efforts on emerging cloud-native opportunities stemming from the rise of Kubernetes.

    For SUSE, those opportunities arise from a distribution of Kubernetes deployed on its Linux operating system, which also serves as the foundation for its container-as-a-service (CaaS) environment, along with a version of Cloud Foundry deployed on top of Kubernetes.

    Brent Schroeder, global CTO for SUSE, said his company’s strategy is being driven by an acute need for increased flexibility. IT environments are inherently becoming hybrid as more workloads move to the public cloud, and many organizations will want to leverage a common substrate based on Kubernetes for building and deploying applications. In some instances, Kubernetes will be deployed on top of virtual machines, while in other use cases Kubernetes will be deployed on bare-metal servers. IT organizations will then decide to deploy a CaaS or PaaS depending on their requirements, said Schroeder, noting that regardless of the path chosen, IT modernization initiatives will create a significant opportunity for SUSE.

    “Virtual machines, bare-metal and the cloud will be a huge catalyst,” said Schroeder.

    DevOps, of course, is playing a major role in driving those transitions, which Schroeder said has become a major focus for SUSE as organizations think through how to not just build and deploy applications faster, but also secure and govern those processes. That latest version of SUSE CaaS Platform 4, for example, added support for Cilium open source project for securing network connectivity between containerized application services.

    Of course, SUSE is not the only IT vendor making this journey. Red Hat was the first to deploy a PaaS environment on top of Kubernetes and since then has been on a mission to obliterate the distinction between a CaaS and a PaaS environment. As an arm of IBM, Red Hat has also significantly expanded its market research as IBM builds out a hybrid cloud computing strategy based on the Red Hat OpenShift platform.

    Of course, Red Hat’s acquisition by IBM might create new opportunities for SUSE. After all, more than a few of the IT organizations that opted to embrace Red Hat OpenShift had plenty of opportunities to consider alternatives from IBM. Now that the acquisition has been finalized, some of them may be reconsidering their options.

    It’s too early to say when SUSE might arrive at its ultimate destination. When venture capitalists buy a company such as SUSE the goal is to either take the company public or recoup the investment by selling it to another entity. Whatever the outcome, it’s clear SUSE intends to leave its mark in the brave new world of containerized applications.

    — Mike Vizard

  • Red Hat Launches Holistic DevOps Training Initiative

    Red Hat Launches Holistic DevOps Training Initiative

    Red Hat this week announced it has created a Global Transformation Office focused on bringing about digital transformation via broad adoption of best DevOps practices.

    The Global Transformation Office initiative is comprised of Andrew Clay Shafer, vice president of transformation at Red Hat; Jabe Bloom, chief sociotechnical officer for PraxisFlow; Kevin Behr, general manager and chief science officer at PraxisFlow; and John Willis, CEO of Botchagalupe Technologies.

    Shafer said Red Hat is trying to encourage organizations to take a more holistic approach to transformation by simultaneously addressing the need to understand how new technologies impact the organization in terms of skills required and the business model around which the organization is built.

    Instead of focusing solely on IT skills, Shafer said the Global Transformation Office at Red Hat is also seeking to educate line of business executives how to engage with DevOps teams to advance digital transformation initiatives, many of which never come to fruition because the IT teams working on those projects don’t know what the end business goal really is. If line-of-business executives can communicate that goal in a way DevOps teams can appreciate, they soon discover how much faster those DevOps teams will be able to drive the organization toward that desired outcome, he said.

    Rather than simply telling IT teams they will have a new role, Shafer said business leaders need to back up those claims by investing in training. Otherwise, IT professionals who today often associate their identity within an organization to the process they manage will resist that transition out of fear of losing their position. Right now, too many organizations are also asking IT teams to embrace DevOps without ever really informing DevOps teams why any given project matters to the business strategy, added Shafer.

    Red Hat is investing in this initiative because the amount of demand for enabling technologies such as the Red Hat OpenShift application development platform will be constrained unless business and IT models evolve in tandem. It makes no sense for organizations to embrace containers only to try managing them using the same processes they previously employed to manage virtual machines and bare-metal servers, said Shafer. Organizations need to realize they will not get the maximum value out of such platforms unless they have the skills and expertise needed to apply them within the context of achieving a business goal, he added. In many cases, organizations may need to reorganize themselves because too many business leaders still value themselves in terms of the size of the organization they lead instead of the contribution the business unit makes to the company.

    It’s not clear to what degree the DevOps tail may be able to wag the business dog. In many ways, it’s only a matter of time before the business needs to be reorganized in a way that makes it as agile as DevOps teams are becoming. The real question is how long that transition will occur. Of course, many organizations that don’t make that cultural DevOps transition won’t be around to find out how it all turns out.

    — Mike Vizard

  • Red Hat Streamlines Operating System Update Cycle

    Red Hat Streamlines Operating System Update Cycle

    Red Hat is looking to make it easier for DevOps teams to absorb leading-edge innovations as they are slipstreamed into a new distribution of CentOS.

    CentOS is a distribution of Linux based on a fork of Red Hat Enterprise Linux (RHEL). The team that oversees CentOS operates independently of Red Hat. That team in collaboration with Red Hat is making available an additional distribution dubbed CentOS Stream, through which a continuous stream of content will be updated several times daily.

    Mike McGrath, senior director for Linux engineering at Red Hat, said those innovations eventually will find their way into RHEL, but until then developers who want to build applications using those features as they become available can use CentOS Stream.

    This latest distribution of Linux from Red Hat is intended to act as a bridge between Fedora, a distribution of Linux through which Red Hat makes available experimental technologies, and RHEL, he said.

    McGrath said developers have been asking for a more stable distribution of Linux that provides access to innovations that are likely to be incorporated in RHEL, which so many IT organizations today deploy in production environments. CentOS Stream will make it easier for developers to take advantage of those new capabilities a lot sooner than they can today, he noted.

    CentOS Stream will be maintained in parallel to CentOS, which means organizations that have decided to standardize on CentOS are not going to be impacted by updates to CentOS Stream.

    As more organizations subscribe to software, version numbers associated with any software platform are becoming less relevant. Many DevOps teams especially want to be able to take advantage of new capabilities within the context of a continuous integration process when and if they see fit, rather than waiting for a formal update of a piece of software to be released.

    It will be interesting to see how many IT organizations embrace CentOS Stream at a time when many of them are under increased pressure to build innovative applications faster. In many instances, those innovations are dependent on features and capabilities embedded in the operating system, so waiting for those capabilities to show up in a major RHEL upgrade isn’t especially helpful. Many developers want to be able to exploit those capabilities the minute they are certified to run on RHEL. In many cases, developers are gaining access to those features only a few short months ahead of time whenever a preview edition of the next version of RHEL is made available.

    Eventually, every software platform provider will need to come up with some similar approach to CentOS Stream to provide developers with early access to new capabilities. In many cases, developers already have access to next-generation features if they have a close relationship with the platform provider. However, the process for making new capabilities available to developers remains haphazard at best.

    — 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