devopsy.kinsta.cloud

Tag: openshift

  • Red Hat Brings Ansible Automation to Microsoft Azure Cloud

    Red Hat Brings Ansible Automation to Microsoft Azure Cloud

    Red Hat this week announced that a private preview of the Red Hat Ansible Automation Platform is now available on the Microsoft Azure Cloud.

    Tom Anderson, vice president of Red Hat Ansible automation, said making the Red Hat instance of the open source automation framework available on Azure is the first step toward making it possible for IT teams to use the IT automation framework across multiple clouds.

    The goal is to make it simpler for IT teams to bridge multiple IT environments using a common framework to automatically configure everything from operating systems to security platforms across a hybrid cloud computing environment.

    Ansible is emerging as a de facto standard for automating IT environments largely because it provides an IT team with a declarative approach to automating IT processes. An IT team can write a playbook that describes their desired state for a platform without having to know anything about its current state.

    Interest in IT automation has soared as the number of workloads being deployed in the cloud and on-premises IT environments have steadily increased. The simple truth is that many organizations can’t keep pace with the rate at which applications are built and deployed because they are unable to hire and retain enough IT staff. The challenge is that writing a playbook to automate any IT process requires a fair amount of expertise that many organizations lack. There are, however, now large numbers of existing templates that organizations can reuse.

    Anderson also noted that security concerns will also force the IT automation issue. Many of the application workloads running in cloud computing environments are misconfigured because they were provisioned by developers that have little to no security expertise. A playbook greatly reduces the chances an application workload will be misconfigured in the cloud without having to turn every developer into a security expert, Anderson explained.

    Ultimately, IT automation frameworks reduce the level of friction that often exists between developers and the rest of the IT operations team in a way that actually serves to increase developer productivity, added Anderson.

    Regardless of how IT organizations automate IT processes, it’s now a question of the rate at which that goal will be achieved rather than if. DevOps teams, of course, have always been at the forefront of automation, but now it’s clear that as IT environments become more complex, IT organizations are embracing automation more aggressively. Most of those initial efforts are focused on repetitive, tedious and manual IT tasks, but the potential to automate IT processes at levels of unprecedented scale has never been greater.

    In fact, many organizations may soon discover it’s difficult to retain IT professionals without investing in automation. After all, the most talented IT professionals will not want to work for an organization that requires them to always manually configure IT resources. Many IT teams might also discover that automation frameworks like Ansible are the gateway to embracing additional DevOps best practices. The challenge, of course, is finding the time to get started automating processes when there are so many immediate issues that IT teams can’t ignore.

  • Red Hat Extends Reach and Scope of Insights Analytics Service

    Red Hat Extends Reach and Scope of Insights Analytics Service

    During its online Red Hat Summit event, Red Hat today announced it has extended the Red Hat Insights predictive analytics cloud platform for managing IT to now include support for editions of Red Hat OpenShift based on Kubernetes and the Red Hat Ansible Automation Platform.

    In addition, Red Hat has extended Red Hat Insights for Red Hat Enterprise Linux (RHEL) to include the ability to prioritize security alerts, streamline notifications and track Red Hat subscription consumption.

    In total, since launching Red Hat Insights in 2019, Red Hat claims there are now more than 600,000 RHEL hosts analyzed per day.

    Joe Fitzgerald, vice president and general manager for the management business unit at Red Hat, said Red Hat Insights provides IT teams with the equivalent of a co-pilot for managing IT environments. In general, advances in automation and artificial intelligence (AI) are making it easier to manage complex IT environments at scale, noted Fitzgerald. However, it’s not likely IT environments will be automated to the point where lights-out management without human intervention is likely to be achieved any time soon, added Fitzgerald.

    However, it’s also becoming apparent that it’s not possible for IT teams to manage complex IT environments without help in the form of advanced analytics tools. In fact, while many IT professionals are leery of automation tools because of the perceived threat to their jobs, it’s also becoming apparent that IT teams will not be able to manage modern IT environments without these tools. Organizations can’t afford to hire small armies of IT personnel. In addition, finding and retaining IT professionals that have, for example, Red Hat OpenShift skills remains a significant challenge.

    Red Hat Insights provides IT teams with additional levels of context required to manage these environments that goes beyond simple monitoring, noted Fitzgerald. That’s critical, as the IT environment becomes more extended in the age of hybrid cloud and the rate at which platforms are updated steadily increases, added Fitzgerald. Platforms such as Red Hat OpenShift, for example, are now typically updated every three to four months.

    DevOps, of course, has always been about ruthlessly applying automation whenever possible. As analytics applications become more robust, IT teams gain the visibility required to automate a wider range of complex tasks, noted Fitzgerald. In fact, in the absence of that visibility, automation can be a dangerous thing when mistakes caused by a lack of visibility and insight are made, added Fitzgerald.

    In the longer term, Red Hat expects to see continued convergence of job functions and roles as IT teams become more cross-functional, said Fitzgerald. Platforms such as Red Hat Insights will provide a single console around which these teams can collaborate, added Fitzgerald.

    Going forward, there won’t be a handful of administrators with augmented capabilities. Rather, IT specialists that have a particular set of skills will be able to collaborate more easily in a way that both creates a better outcome and ultimately keeps a lid on the total cost of IT.

  • 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

  • Integrating IBM Z and LinuxONE into the Red Hat OpenShift developer ecosystem

    By Willie Tejada, GM & Chief Developer Advocate, IBM Cognitive Applications

    https://developer.ibm.com/blogs/willie-tejada-redhat-openshift-ibmz/

    My role at IBM is to make sure that we’re equipping developers with the tools and resources you need, along with the selection and guard rails you prefer, to help you focus your efforts entirely on innovation. Security is key to unlocking the true value of the cloud, and we want that to be one less thing you have to worry about when you’re building high-performance solutions. To that end, this week we announced a major milestone furthering Kubernetes support for Linux on IBM Z and IBM LinuxONE: The Red Hat OpenShift Container Platform for Linux on IBM Z and LinuxONE is now generally available.
    Kubernetes has been available on Linux on IBM Z and LinuxONE for some time and is detailed in this LinuxONE whitepaper. This has already enabled customers to start integrating Kubernetes-based microservices running on Linux on IBM Z and LinuxONE into their infrastructures, as well as the vast ecosystem of projects surrounding Kubernetes itself.
    With this launch, developers can now access a platform with Kubernetes-based tooling, plus fast, built-in security and hardware-driven cryptography, high uptime and resiliency, fast access to your data, and everything else you’ve come to expect from Linux on IBM Z and LinuxONE. This opens the door to easier integration with existing solutions that are already using OpenShift in hybrid and multi-cloud models — whether your infrastructure resides on public or private clouds, or a combination. It’s our latest enhancement to help you truly build once, deploy anywhere.
    Additionally, the IBM z/OS Cloud Broker allows OpenShift applications to easily interact with existing data and applications on z/OS. You will be able to use the IBM Cloud Infrastructure Center, an Infrastructure-as-a-Service (IaaS) that provides simplified infrastructure management of z/VM-based Linux virtual machines on Linux on IBM Z and LinuxONE. OpenShift is a platform-as-a-service (PaaS) and container-as-a-service (CaaS) layer that requires an underlying IaaS layer, which the IBM Cloud Infrastructure Center provides for IBM Z and LinuxONE.
    OpenShift availability on the Z architecture allows for easier development of applications that work across your infrastructure. Microservices-based workloads that you develop can be managed as you see fit. Plus, with the IBM Cloud Pak for Applications, you’ll have access to a collection of tooling to help drive modernization efforts by leveraging DevOps-related tooling like IBM UrbanCode and enterprise-level support for Java, Node.js, Spring, and other runtime environments. With this release, for the first time, Red Hat Enterprise Linux CoreOS (RHCOS) is available for the Linux on IBM Z and LinuxONE platforms.
    We’re helping you build smart, and build secure.
    This release is primarily for evaluation, dev, and test, so we’re eager for you all to check it out. Get involved now to start testing your workloads in anticipation of production readiness, planned for later this year. Initially, you will need z/VM to implement OpenShift on the platform as virtual machines managed by IBM z/VM, with other options coming later. We’re also working on support for HiperSockets, SMC-D, Installer Provided Infrastructure (IPI), and persistent storage other than NFS, and you can expect support for all of these things down the line.
    I invite you to join our webinar on March 5 to learn how the agility of OpenShift, the security and scalability of IBM Z, and the containerized software of IBM Cloud Paks are enabling innovation.

  • Into the hybrid cloud future: Red Hat OpenShift is now available for IBM Z and LinuxONE

    By Ross Mauri, General Manager, IBM Z

    https://www.ibm.com/blogs/systems/red-hat-openshift-now-available-ibm-z-linuxone/

    Today we are pleased to announce that Red Hat OpenShift Container Platform is generally available for IBM Z® and IBM LinuxONE™. Red Hat is a leader in hybrid cloud and enterprise Kubernetes, with more than 1,000 customers already using Red Hat OpenShift Container Platform. With the availability of OpenShift for IBM Z and LinuxONE, the agile cloud-native world of containers and Kubernetes is now reinforced by the security features, scalability and reliability of IBM’s enterprise servers.

    “Containers are the next generation of software-defined compute that enterprises will leverage to accelerate their digital transformation initiatives,” says Gary Chen, Research Director at IDC. “IDC estimates that 71% of organizations are in the process of implementing containers and orchestration or are already using them regularly, and IDC forecasts that the worldwide container infrastructure software opportunity is growing at a 63.9% 5- year CAGR and is predicted to reach over $1.5B by 2022.”

    The availability of OpenShift for Z and LinuxONE is a major milestone for both hybrid multicloud and for enterprise computing. OpenShift supports cloud-native applications being built once and deployed anywhere – and now extends this to on-premises enterprise servers such as IBM Z and LinuxONE. This offering is the result of the collaboration between the IBM and Red Hat development teams and discussions with early adopter clients.

    Build once

    Organizations today are looking to bring business innovation to market faster and more efficiently. Containers enable applications to be packaged together with their software dependencies, and Kubernetes adds powerful tools to manage large numbers of containers and orchestrate the full application lifecycle.

    OpenShift then brings together the core open source technologies of Linux, containers and Kubernetes, adds additional open source capabilities such developer tools and a registry, and hardens, tests and optimizes the software for enterprise production use.

    Working with IBM Hybrid Cloud, we have also developed a robust roadmap for bringing the ecosystem of enterprise software to the OpenShift platform. IBM Cloud Paks containerize key IBM and open source software components to help enable faster enterprise application development and delivery.

    Today we are also announcing that IBM Cloud Pak for Applicationsis available for IBM Z and LinuxONE – supporting modernization of existing apps and building new cloud-native apps. In addition, as announced last August, it is our intention to deliver additional Cloud Paks for IBM Z and LinuxONE.

    Learn more about developing applications for OpenShift in this blog post by Chief Developer Advocate Willie Tejada.

    Deploy anywhere

    By combining the agility and portability of Red Hat OpenShift and IBM Cloud Paks with the security features, scalability and reliability of IBM Z and LinuxONE, businesses will have the tools to build new cloud-native applications while also modernizing current applications. Deploying Red Hat OpenShift and IBM Cloud Paks on IBM Z and LinuxONE reinforces key strengths and offers additional benefits:

    ·        Vertical scalability enables existing large monolithic applications to be containerized, and horizontal scalability enables support for large numbers of containers in a single IBM Z or LinuxONE system
    ·        Designed to protect data from external attacks and insider threats, with pervasive encryption and tamper-responsive protection of encryption keys1
    ·        Designed for 99.999% and more availability to meet service levels and customer expectations
    ·        Integration and co-location of cloud-native applications on the same system as the data enables faster response times than depending on network access speeds

    IBM z/OS Cloud Brokerhelps enable OpenShift applications to interact with data and applications on IBM Z. IBM z/OS Cloud Broker is the first software product to provide access to z/OS services by the broader development community.

    Customers using OpenShift on IBM Z and LinuxONE can also license IBM Cloud Infrastructure Centerto manage the underpinning cluster infrastructure. The Cloud Infrastructure Center is an infrastructure-as-a-service offering which provides simplified infrastructure management in support of z/VM based Linux virtual machines on IBM Z and LinuxONE.

    Stay tuned for more info

    To support this important release, IBM has organized a range of resources:

    ·        Two announcement webcasts, including speakers from IDC, Red Hat and IBM, on March 5 for IBM Z customers, and on March 17 for the wider Linux community
    ·        An IBM-sponsored IDC white paper: Transforming a Corporate Datacenter into a Modern Environment: Kubernetes as a Foundation for Hybrid Cloud
    ·        An IBM Systems Magazine article: Red Hat OpenShift, IBM Cloud Paks and more facilitate digital transformation

    Stay tuned for many more discussions about the enterprise hybrid multicloud with Red Hat OpenShiftand IBM Cloud Paksfor IBM Z and IBM LinuxONEat a series of events during the first half of 2020, including SHARE, Red Hat Summit, and IBM Think.

    We think this is an exciting time for both enterprise computing and hybrid multicloud as they come together with Red Hat OpenShift on IBM Z and LinuxONE.

  • 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 Takes Virtualization Aim at VMware

    Red Hat Takes Virtualization Aim at VMware

    Red Hat, as part of on going drive to wean enterprise IT organizations off proprietary virtualization technologies, today launched a set of Red Hat infrastructure migration tools and services.

    Joe Fernandes, vice president of cloud platforms products at Red Hat, said that as organizations move to modernize their application environments by lifting and shifting them to the cloud, they are simultaneously looking to take greater advantage of open source virtual machines and containers specifically as an alternative to VMware.

    The Red Hat initiative includes a consulting engagement as well as a pilot project that enables legacy application workloads to be deployed on kernel-based virtual machines (KVMs), an instance of OpenStack or the Red Hat OpenShift platform based on the open source Kubernetes container orchestration software. The core tool used to migrate those workloads is the Red Hat Ansible Automation, Fernandes said.

    As management software stack the company now provides on top of those foundations has matured, Red Hat is finding more customers willing to consider transitioning away from commercial virtualization software, he noted. At the same time, he added, wider adoption of KVM by cloud service providers (CSPs) is making open source technologies a much more attractive option to foster deployment of application workloads across a hybrid cloud computing environment without having to refactor them.

    Those two trends in combination, Fernandes said, are making it easier for Red Hat to make a case for organizations to move way from VMware.

    Red Hat may have lost the virtual machine wars to VMware early on, but it’s clear the company is gearing up for a new phase. Many organizations have adopted an open source-first philosophy that Red Hat clearly is trying to exploit at VMware’s expense. At the same time, rising interest in alternative approaches to virtualization in the form of Docker containers and Kubernetes is creating another wedge that Red Hat is looking to exploit. For example, the company is testing Kube-Virt, an open source project that makes it possible to run KMVs within a container. Red Hat has already signaled its intention to apply that technology to other hypervisors as well.

    It’s unclear to what degree containers and Kubernetes will be deployed on virtual machines and used in place of virtual machines altogether. Red Hat is prepared for either eventually, but Fernandes said virtual machines will continue to remain relevant in enterprise IT environments for many years to come. Reliance on container and virtual machines will come down to both the nature of the application workload and the relative cloud-native maturity of the organization deploying them, he said.

    It also remains to be seen the degree to which VMware can stave off a new virtualization challenge from Red Hat. VMware has allied with Amazon Web Services and IBM in the public cloud, while partnering with sister company Pivotal to embrace Kubernetes running on top of VMware. The issue, of course, will be how much enterprise IT organizations are willing to pay for commercial virtual machine licenses in support of the initiatives.

    — Mike Vizard

  • Red Hat Positions PaaS as Cure to Heal DevOps Divide

    Red Hat Positions PaaS as Cure to Heal DevOps Divide

    Red Hat is making a strategic bet that IT organizations increasingly will rely on platform-as-a-service (PaaS) environments to make a broad range of distributed services available to developers, which would eliminate friction without enabling IT operations teams to maintain control.

    Paul Cormier, president of products and technologies for Red Hat, said IT organizations are realizing PaaS environments such as OpenShift have evolved into a platform through which a broad range of curated distributed services can be exposed to developers by IT operations teams. That capability is critical because, otherwise, developers simply go around the IT operations team to download libraries. IT operations teams before too long are asked to support applications of uncertain provenance that in many cases wind up duplicating functions.

    As appreciation of the role PaaS environments play in enterprise IT, Cormier said Red Hat is increasingly having conversations with CIOs and other senior IT leaders who are trying to bridge the historic divide between developers and IT operations teams by exposing a broad range of curated distributed services via well-defined application programming interfaces (APIs).

    Red Hat is expanding the types of applications that can run on OpenShift alongside traditional 12-factor applications. In fact, by embracing Kubernetes container orchestration software, Red Hat is effectively obliterating the line between a PaaS and container-as-a-service (CaaS) environment, Cormier said, adding OpenShift makes it possible to build and deploy those applications on-premises or in the cloud as IT organizations deem best, based on cost, data gravity and regulatory requirements. Serverless computing frameworks will make it possible to bridge those environments by invoking an event-driven framework to take advantage of, for example, cloud bursting in a heterogeneous hybrid cloud, he said.

    In fact, Cormier noted more IT organizations will mix and match internal and external services, as each platform tends to run different classes of application workloads better. For example, IT organizations may want to be able to invoke one type of artificial intelligence (AI) service on one cloud over another based on their performance attributes.

    Traditional enterprise IT organizations are not looking to eliminate the need for IT operations teams, he said. Rather than have developers take over IT operations, most organizations would prefer to maximize the amount of time developers spend building and testing applications. The need to build more applications faster than ever will force IT leaders to separate those concerns to eliminate much of the internal friction that results when developers throw application code over the proverbial IT operations wall, Cormier said.

    Most IT organizations have yet to embrace a PaaS environment broadly. There tend to be pockets of adoption. But most applications today are still built and deployed without employing a PaaS environment, mostly because PaaS environments are viewed by many as being too prescriptive in terms of dictating application development workflow. Red Hat is betting that with the rise of microservices-based applications based on containers, many IT organizations will finally decide to trade a little less control in exchange or for much less IT infrastructure complexity.

    — Mike Vizard