devopsy.kinsta.cloud

Category: Blogs

  • 4 Ways to Scale DevOps in 2021

    4 Ways to Scale DevOps in 2021

    January is a month often dedicated to planning, setting intentions and preparing ourselves professionally and personally for a fresh year. In my own capacity as a DevOps and SRE leader, many of the clients I work with will reinvigorate internal efforts to streamline how they work in Q1.

    I often advise clients to make very concrete goals and milestones for their technology organizations to become more agile, streamlined and modernized. Setting these goals is helpful to articulate to the wider business where you want to go and how you plan to get there. Here are a few DevOps-related initiatives your team may want to tackle in the first half of this year.

    #1: Tighten Security through DevOps

    Securing your organization’s infrastructure is an evergreen priority for technology leaders. When done properly, security should be baked into all DevOps processes (sometimes called DevSecOps) from the design phase all the way to application maintenance. To be effective and not slow down development, security processes need to move at the speed of today’s fast-moving environments, which is near impossible, or, at least very challenging, unless security is well automated.

    Automated security measures can be applied to the full life cycle of product development and should make development time faster and smoother in the long run if you can catch vulnerabilities early. Identify automation tools that work for your team and experiment with what works best.

    Similarly, in fast-moving environments, it’s tempting to play fast and loose with privileged access to unblock individuals and teams. Lax policies for user rights exposes the organization to too much risk from potential hackers. Implement a solution or protocol to keep access controlled. Policy and governance are critical for well-rounded DevSecOps. Communicate policies regularly with the entire organization. Ensure that all engineers know how to comply and enforce them.

    #2: Make DevOps an Organizational Culture

    Much like security, DevOps needs to evolve from an individual role to a cross-functional, holistic, cultural approach to developing software. Organizations should foster a DevOps culture rather than identifying specific individuals in DevOps roles.

    So how do you know when this culture shift has happened? A good pulse check is to see how quickly your company can adapt to change. How mired is your team in legacy code or infrastructure? Can individual teams operate autonomously? Teams and individuals that are independent and accountable are able to continuously experiment and learn at a much faster rate.

    DevOps cultural transformation won’t happen overnight – but it can be expedited if embraced by the entire company. I typically advise companies to focus on making incremental, consistent progress that builds autonomy, trust and transparency. These are the building blocks of a thriving DevOps culture.

    #3: Simplify Your Infrastructure

    Complexity, over time, creates duplication, unnecessary systems and technical debt. All of these have a cost, and create security vulnerabilities. Create organizational goals to clean up and reduce complexity. I often suggest teams create a roadmap to move toward self-service and building platforms. As you focus on building a DevOps organizational culture, you will likely notice that teams will identify opportunities to simplify and standardize, which will also remove complexity.

    #4 Review system SLAs and SLOs

    Establishing and monitoring key metrics are a fundamental part of any SRE role. Service level agreements (SLAs) and service level objectives (SLOs) need to be defined and monitored to ensure your team is fulfilling them. System availability (uptime, latency, etc) is core to any cloud SRE team. Define what reliability means for your organization. January is a good time of year to start fresh and articulate these metrics, how they relate to your core business and what investments or changes need to be made to achieve them.

  • A Security Vulnerability Management Guide

    A Security Vulnerability Management Guide

    Living in a container-native world is not easy. Containers have a reputation for being a point of entry for security vulnerabilities for many organizations. In 2015, according to a research paper, over 40% of Docker images distributed through Docker Hub had high-risk vulnerabilities; at that time there were more than 95,000 container images hosted on Docker Hub. Today, there are over 3.5 million container images on Docker, and container security is of even greater concern. In a more recent 2020 study by a team of researchers at the Norwegian University of Science and Technology found container image vulnerabilities in certified and popular packages.

    This is just one example of one kind of security vulnerability. This article will share an introduction to security vulnerabilities and the role of vulnerability management for containers and other artifacts in a continuous integration and continuous delivery (CI/CD) pipeline.

    What is a Security Vulnerability?

    A vulnerability is a weakness or flaw present in software. Security vulnerabilities can be present in application dependencies or operating system (OS) packages. Common vulnerabilities include missing data encryption, buffer overflows, missing authentication for critical functions and insecure interactions between software components.

    There are different risks associated with different types of vulnerabilities. With critical or high-risk vulnerabilities, an attacker who exploits your software has the potential to seriously impact your organization. Risks associated with data breaches impact not only an organization, but also its end users and customers.

    Vulnerability Management Techniques

    Vulnerability assessment practices and tools exist to make detecting vulnerabilities simple, accurate and fast. Some of these practices include:

    • Penetration testing – Penetration testing, or pen testing, allows you to identify security vulnerabilities by attempting to break into your own systems to identify weaknesses.
    • Configuration management – Configuration management involves managing infrastructure configurations and identifying missing patches that leave your software service vulnerable to errors and risks. There are tools that provide infrastructure scanning as-a-service to help detect outdated or misconfigured instances.
    • Container and application Scanning – Allows you to detect vulnerabilities in deployable artifacts and running applications. Some available tools for container scanning include Twistlock, Clair and Trivy.

    These practices help build solid, repeatable vulnerability management techniques across your security and delivery teams. One way to scale these security practices is through security automation. Security automation is the use of technology that performs tasks with reduced manual assistance. It ultimately enables users to apply security decisions automatically and secure processes to deliver more robust applications and infrastructure.

    Security Practices in your CI/CD process

    Security automation is a core tenant of DevSecOps. DevSecOps is short for development security and operations, and it describes how organizations deliver and make security decisions and actions within the development life cycle of their valued deliverables.

    DevSecOps is a way of continuously integrating security in the software development life cycle. It’s a way of working and thinking so that security is at the forefront of how security teams deliver business value.

    One way to enable DevSecOps is through your CI/CD pipeline. Today’s enterprises can use CI/CD to accelerate better software delivery, but with that speed it becomes even more important to enable robust security. Vulnerability scanning improves software security while giving individuals across engineering and product teams accountability for each of the processes these teams own.

    Don’t let Security Vulnerabilities Ruin your DevSecOps

    This is a simple, basic introduction to security vulnerabilities and the risks they pose for your organization. There are practices and tools for detecting and reducing security vulnerabilities, and finding ways to incorporate those processes into a CI/CD pipeline is a great way to accelerate your DevSecOps.

  • The Use of Open Source in Mainframe Environments

    The Use of Open Source in Mainframe Environments

    Open source is a critical element of IT computing. As companies modernize the mainframe and start to add components to mainframe applications that are off the mainframe, they should to be able to build, test and deploy the components of that application that go across the mainframe and different computing platforms in the same manner. Organizations need open source tools to run on the mainframe to be able to drive those processes in a unified manner across all the different components of that application.

    Tim Willging, chief architect and strategist, and Peter Fandel, mainframe open source evangelist of Rocket Software, join Mitch Ashley to discuss advancements in the use of open source software with mainframe apps and tools. Tim and Peter challenge some long-held beliefs around mainframes, open source software and the increasing role open source is playing today.

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

    Transcript

    Mitch Ashley: Hi everyone, I’m very pleased to be joined by a couple of great gentlemen here to talk about some interesting open source, security, mainframe, DevOps, all kinds of good things. So I’m pleased to be joined by Tim Willging who is chief architect and strategist for the mainframe business unit with Rocket Software and Peter Fandel, senior director of product manager mainframe open source. Welcome, guys.

    Tim Willging: Hello, thank you.

    Peter Fandel: Hello.

    Ashley: I think I might have said your name correctly, Tim. Is it Willging? I don’t know if I said that right. 

    Willging: That’s correct. That’s fine. 

    Ashley: Okay, good. Would you start? I’ll have you both introduce yourselves. Maybe you can also introduce the company, Tim, and then we’ll have Peter do the same?

    Willging: Sure. Yeah, I’m Tim Willging. As Mitch mentioned, I’m the chief architect and strategist for the mainframe business unit at Rocket. I’ve been with Rocket about 15 years and spent the majority of my career developing commercial solutions for the mainframe and mostly around database tools, DB2 tools. Rocket Software has been in existence for 25-plus years and is a privately held company and specifically we do software that’s not just on the mainframe but let me talk mostly about the mainframe software.

    Rocket has a development partnership with IBM and many of the solutions we develop are IBM branded; but we also have many things we’re doing Rocket direct; and open source, particularly the subject of this call, is one of those things that we also sell direct or partnership with companies direct to provide that open source. So Rocket has a long history with the mainframe and we believe in its future and in its sort of importance in the computing divisions across many of the largest companies of the world. 

    Ashley: Excellent. Great. Peter, if you would introduce yourself.

    Fandel: Sure. Peter Fandel, again. I’ve been at Rocket for 19 years. The great majority of those years in engineering management, and I took over management of the open source porting team about, oh, four or five years ago and transitioned to product management about a year ago. And I manage both the open source porting portfolio as well as the Zowe portfolio, and both of those portfolios are critical components to the modernization story for the mainframe in large part because of the huge amounts of open source that are out there that you can _____ can get them running well on the OS as well as attracting talent, the next generation of developers. So that’s really our focus area for open source.

    Ashley: Excellent. You know, maybe you ought to start – and I started my career in the mainframe, too, and so I understand/kind of get where you’re all coming from in the market. There’s a lot of built up beliefs about mainframes and applications and whether you should think about porting or not or, you know, replatform them, leave them alone. Probably like you, I’ve learned it’s very costly and also fraught with danger to just go rebuilding applications, you know, because you think you want them on a different platform. You have to have a really good reason. But open source is actually a really important part of the mainframe ecosystem. I think maybe folks don’t really realize how important it is. How would you guys kind of set that up to give people an idea for the role that open source is playing in the mainframe environment today?

    Willging: Well, I’d start off by saying open source is incredibly important part of IT computing. I mean it’s something early career professionals are learning. It’s a huge way companies are running their business today and rather than writing things from scratch, many are starting with open source and then augmenting or augmenting existing systems with open source to modernize that open source because of its collaborative nature, how different companies and individuals contribute to that open source based on the needs of the industry. You really can’t separate the needs of our organizations that are running mainframes from that open source. Open source is a critical component of running your compute division. So without it, I think the mainframe would be, you know, would have a big missing part in what companies need to run their business today. 

    Fandel: I think also there’s a huge cost savings associated with that because you take any recent graduate and even not-so-recent graduate of any comp sci program and you ask them to start developing applications, they’re going to expect to build those applications on open source building blocks. And if they’re not there, your cost goes way, way up. As well, another area where open source is a must have is DevOps where if you want to – do you want to have a different DevOps tool chain for the mainframe than the rest of your organization or do you want to unify that? And if you’re going to unify it, it’s got to be open source based.

    Ashley: It’s a massive source of innovation and I don’t know if we’re here yet, but if we aren’t, we’re quickly reaching a point where you can’t operate a company, a software team without open source software. And if you aren’t using it, I can promise you your competitors are. So take advantage of it, right? Well, let’s talk a little bit about I know Zowe is of course a big important part of your strategy. Break it down for us. Go into a little bit more detail about where the places, roles that open source does play a role in the software development process and operational systems of mainframes, kind of paint that picture for our folks, our listeners. 

    Willging: I think there are a lot of different ways it plugs in, but the one that I hear most of the companies I talk to is precisely what Peter just said. You know, the mainframe through many years of existence has been very waterfall-ish I’ve heard some companies because of the reliability. It’s the security, the maintainability of the mainframe that there’s a process which changes are rolled out in large batches. As companies modernize the mainframe and they start to add components to those mainframe applications that are off the mainframe, like in the hybrid cloud or have a web frontend or a mobile app frontend to a backend service or application that’s running on the mainframe, they want to be able to build, test, deploy the components of that application that go across the mainframe and those different computing platforms in the same manner.

    And to have tools, pipeline building tools, pipeline organization tools that have tools that build these environments, run the tests, destroy these environments, they need those open source tools to run on the mainframe to be able to drive those processes in a unified manner across all the different components of that application. So many companies today are just starting – you know, mainframe companies are starting on this journey. Many of them are hand rolling over the years have hand rolled sort of tools to try to have them plugged in, but that can get expensive as we’re talking about. So to get that open source running on the mainframe it’s important for them to be able to deploy those DevOps principles and practices in that application management lifecycle process. 

    Fandel: I would –

    Ashley: Very much so. Of course there’s also more with that too. Go ahead. I’m sorry, go ahead, Peter.

    Fandel: I was going to build on what Tim said by introducing a really important distinction and that is that there is three very different ways you can get open source onto the mainframe. Most of the open source we’re talking about is units based. And you can do it by a Linux on Z, you can do it by a zCX Docker container or you can do it by UNIX System Services. And it used to be that the low cost way of doing that was Linux on Z and now more recently zCX because the porting is not much work to do because it’s all automated just port to the hardware which is done by compiles on those systems.

    But doing it on UNIX System Services is a lot more time consuming if you do it manually. But the advantage if you do port well on UNIX System Services is you’re close to the data. I mean if you’re running open source on Linux on Z or on zCX, it’s akin to running it on another machine on the network. You don’t have direct access to the data. Everything has to pass through TCP/IP. But UNIX System Services is part of z/OS and so you have direct access to all of the important data in your organization that MVS data. And that’s a key distinction. Where Rocket plays is open source on UNIX System Services on z/OS. So we are close to where the data is and we have solved the problem of high cost of porting through this GCC glibc technology where we essentially automate the port of open source by simply compiling and linking in GCC and it injects the z/OS specific changes directly into the binary output of the build. 

    Ashley: Talk about that process. Is that something that you’ve been doing a while? Of course going and changing binaries, most folks probably don’t do that as a natural first thought. But it does sound like a pretty straightforward way of minimizing the steps that you have to go through to get to begin using this. You can actually do it _____.

    Fandel: Yeah, it’s just we’ve been working on this GCC glibc port in this manner for over two years, and it’s just coming to fruition now where in first quarter we will be releasing new versions of several of our ports that are not ported by hand. They are ported simply by building them with GCC, and we hope to have transitioned our entire portfolio by the end of 2021 to be built in this manner. And that means we no longer have to modify the source code because upstreaming is no longer a question, an issue. It means that we can turn around security vulnerability fixes much, much faster than we could otherwise.

    Ashley: I don’t mean this in a hyperbolic way or kind of playing up to you in any way, but that kind of an approach can be a pretty big game changer because you’re really asking people, it’s a low lift instead of a heavy lift to port if you will.

    Willging: I’ve talked to many through the z/OS community who believe that due to the effort of going through these ports in the past, they felt that a better strategy was to run your open source close the mainframe – I say close with parentheses – or on a partition on the mainframe that’s running zLinux because the porting effort to get open source running on zLinux is minimal. And so they felt that the version currency, the security fix as Peter said, and the breadth of the packages available, open source source packages available on z/OS proper would always be behind. So they felt that was a better strategy to run it on zLinux.

    We don’t believe that at Rocket. We believe, as Peter said, that there are technical advantages to running that open source both from a DevOps standpoint but even more so from somebody who is looking to augment a legacy application say via some Python library that they’re looking to deploy where they’ve found some open source with a particular function. Running that Python on z/OS and accessing the data directly in concert with the legacy application that’s running or via some subfunction in that modernization effort is vastly different than running that Python in zLinux or on a machine off-platform and reaching into the data. The latency of what you can do, trying to embed that open source sort of in transaction, in the code in transaction becomes much more difficult to do. So we feel that Z customers as they’re looking to modernize will benefit greatly from open source running on Z proper. 

    Ashley: And as I understand, I think as you were describing it Peter, really you are talking about that compile process, right? That’s where you’re introducing GCC glibc libraries. So that’s where this process is happening, changing things in a binary to adapt it to be able to use open source. Is that pretty much it or what else do you have to do to verify or test it or what are folks going to want to go through as they start to introduce this into the process?

    Fandel: Once we build it, we obviously have to run it through the test suites and we have two forms of testing. We have the built-in test suites that most open source products come with. I mean if you go to Git or Python and you download the source code from the community, it will be the product plus a huge volume of test code, self-test code. And so we execute that test code to make sure that it performs with the same results as on a test UNIX System. I think we used Ubuntu as the comparison and we compare the results. And if there’s any divergence on z/OS, then we inspect those divergences.

    And then in addition to that, we have a series of tests that test the z/OS specific capabilities that you want in open source. That’s mostly relating to the ASCII/EBCDIC conversion because z/OS and including UNIX System Service assumes EBCDIC is the default. Most of the data that you’re dealing with is in EBCDIC. And so our philosophy in porting on UNIX System Services, ASCII is the default internally. We compile with ASCII. Communication between open source packages and programs is in ASCII. But when you reach to the operating system, that’s where the conversion has to take place. So we have extra test suites for all of our ports that make sure the ASCII/EBCDIC conversion is taking place correctly both in file IO and pipes. So that adds to our testing process. So it’s not just build it and ship it. We do thoroughly test as well. 

    Ashley: That’s great. I’m glad you explained that too because there certainly are some fundamental differences in the operating system and environments down to the characters that –

    Fandel: Sure.

    Ashley: – that we’re using. How about are there any kinds of applications that are more easier to port this way? That’s not the right way to say it. It’s not porting it but, you know, understand starting to use open source this way or others that maybe are a little more challenging, you might want to wait to take on that kind of an app? How would you recommend people get started?

    Fandel: Well, I mean we found that the porting a language is the most challenging because it just dips into every aspect of the operating system. So our conversion of the Python and Perl ports will be the last ones we release at the end of 2021. Our Python and Perl today are still, the ones we’re releasing are based on manual porting efforts.

    Ashley: Okay, good. Any thoughts on that, too, Tim?

    Willging: I thought your question originally was like talking about a customer application they were looking to augment and add open source to what might be easier.

    Ashley: I would like to go there, too. That actually was my – but I’m glad you answered it the way you did, Peter. I’m curious from a customer perspective data intensive, things that are ultra-high security, high volume, lots of parameters can go into deciding what kind of an application you might use first to go down this path. Any thoughts on what you’d recommend to look at, to pick what app you might try this with?

    Willging: I mean there are a lot of mainframe applications that leverage CICS for online transaction processing and CICS is a great environment to deploy open source. It’s been very forward thinking in its development to take and say a CICS application that’s written in COBOL and say you wanted to augment that via some modules that are written in open source language. That’s very possible and to make that communication really between the first thing you think about is there a runtime environment that’s involved, how do I want to lower that runtime environment so it doesn’t load every time that transaction is moving or it’s moving from the legacy code to the modern language?

    If there’s not, if it’s just a binary without a runtime environment, then you don’t have those types of concerns. So thinking about that and thinking through how you’re laying that out from an architectural standpoint and making sure you think through that. The speed of transition between legacy and open source language environments, that’s probably the biggest concern depending on what you’d like to do. But many companies have successfully done this and gone off and said, okay, we don’t want to necessarily go and rewrite my 30 million lines of COBOL. 

    Ashley: In a billing system probably not where I would start.

    Willging: But there’s a new function we would like to add that potentially goes and augments via reaching to another system where customer data is available that you certainly can do that and many companies have done that successfully. Again, leveraging more modern languages and having that available for that augmentation is much cheaper, much less risk than is involved in a total rewrite and a re-platform which is again even then much of your language that you’ve written or much of what you’ve written won’t even necessarily run on a new system in the cloud. So replatforming is also very expensive or very risky depending on, again, the number of lines of code.

    Anyway, I probably went too far there but that’s sort of how I think about it from an online transaction standpoint. But a batch, different again, that you might just have some data that you want to reprocess and write a new output from that batch and augmenting there with open source is much easier because, again depending on the language can it run in batch, does it require to be hosted within a web server? But even then you can still have a batch process that alerts a web server to now go read this files so you can embed your open source within a say WebSphere Liberty or some web server that can go and even augment batch processes that way. It’s really getting the right architecture down first to say how you want to do that. 

    Fandel: Another area is data science and machine learning. You have for the past 20 years or so you’ve had academics and scientists and corporate engineers developing machine learning extensions, data science extensions, and they haven’t been writing those extensions in COBOL. They’ve been writing it in Python. And so that’s the go-to language for data science.

    Ashley: It does give you access to a lot of new innovation just because of the language as well as the platform –

    Fandel: Exactly.

    Ashley: – and software stack differences. Two other areas I’d like to explore in our kind of time remaining, you mentioned DevOps and the role that open source plays in this. How does it help facilitate moving a mainframe application or developing a mainframe application now into more of a DevOps fashion? Are there some things inherent about because it is, you know, libraries that have a compile time process and there’s other tools? There’s Zowe and things like that can help you with interfaces and tool chains, workflows, things like that. What are your thoughts on that topic?

    Willging: Go ahead, Peter, you start.

    Fandel: Well, I was just going to say that Git, since we release Git I think it’s three years now for z/OS, I think it was our number one download within 30 days of release. Everybody in the world is using Git now –

    Ashley: It starts with Git, doesn’t it?

    Fandel: – or Source Code Control. And so it, like I said before, just enables you to have a unified DevOps pipeline and that’s just huge.

    Willging: Yeah. I mean to add to that, to have all of your source code in Git and then kick off a build process but then thinking of the mainframe and some of its legacy components like the parts of an application that help that make up the database. You know DB2 is very big on the mainframe. DB2 for Z. So to say that you can take those parts of the application touch the tables or smooth the tables in DB2 and extract those and then store those in a source code management repository because in DevOps you really want to store everything as code and represent everything in code so changes can be tracked over time. So taking open sourced, taking some even commercial tooling, taking some open source scripting languages, open source to allow you to interact with a DevOps pipeline that’s running off the mainframe that’s driving the build and reaching in. You know, DevOps is really, again, not a product. It’s a culture and it’s a –

    Ashley: It’s a process. It’s a way of creating software, right?

    Willging: And so to build that DevOps pipeline using those tools but then have the tools – the DevOps tooling and scripting and running on the mainframe to be able to interact with the mainframe sometimes is a combination of open source, purchased tooling, and then hand rolling the pieces in between to fit your company’s needs. That’s really not possible. Again having a Git client for the mainframe and a lot of the other tools there are really important for that process.

    Ashley: I’m curious about the security side of this. You know, a lot of application of air gap requirements things like that or the frequency or timeliness of security fixes. I don’t know if there’s a lot of difference between mainframe environments versus open source. That tends to happen of course more transparently. Maybe what are some of the advantages, pros and cons from a security standpoint of taking this approach?

    Fandel: Yeah, I’m glad you mentioned that because that’s one of the major changes that we have put in place this year with the introduction of the Rocket Open AppDev for Z Solution Bundle. We have switched from sort of old style, one at a time download of tarball and FTP it and then run through ten steps to set environment bevels and get it installed for each source tool or language. And as an example, GIT, which has four dependencies meant four or five downloads. Then you FTPed them over, and then you do the ten steps four or five times. It’s like _____ way. We’ve switched to conda as the system for downloading, installing, and deploying open source on z/OS. That has made a huge difference in terms of the user experience and the ownership experience.

    So it’s now once you have conda installed on your mainframe, that takes about 30 minutes including the download and the setup, then it’s a single command to install Git and all of its dependency from the command line; and further, conda has this concept of a channel which is their word for a software repository or repository of software you download from. Conda supports something called a file channel as well as internet channels.

    So in addition to this, we have set up two internet channels at Rocket, one public one at anaconda.org that anybody in the world can use to download from and a secure channel server on our network that is authenticated for our customers on support. And then additionally you can set up a file channel which is on your premise which is ideal for air gap systems. So if you have an air gap mainframe, you don’t want it to have a connection to the internet, you can set up a file channel, populate it with the full contents of our bundle and then all of the developers within your organization can download at will from your on premise channels. That’s a big advantage in the area of security. 

    Ashley: Those some really big ones, big changes. 

    Willging: It is a big change. I mean there are a lot of companies that have said that the only delivery mechanism for software to my mainframe is through IBM Shopz. So you know, I have some feelings on that. I think that’s old school thinking as far as I’m concerned, but there’s still a culture amongst many mainframe customers that that’s it. I think that is changing and to make it simple, to guarantee that it’s secure and to provide options is what Peter just went through I think is important to help increase adoption of open source on the mainframe. And so Rocket is really leading in that area to help make that possible. 

    Ashley: It is culture. It is sort of tried and true. You know, if it’s not broken don’t fix it. But on the other hand, when you start to demonstrate new capabilities, new benefits, speed improvements, more security, whatever it might be, access to innovation, suddenly that becomes maybe a compelling reason to start to break down some of those traditions or barriers or kind of think about adding this as a capability. You’re not talking about changing everything, right? We’re talking about adding capability to how you create software in a mainframe and expanded environment, correct?

    Willging: Yep, exactly. 

    Fandel: Sure. 

    Ashley: Good, good. Well, where can folks learn more about this? I don’t know if you have any trials or free downloads or you’ve been in beta on some things that are GA or coming out in GA. What’s the best way for folks that want to engage with you and find out more and kind of give this some –

    Fandel: I think you can Google z/OS Miniconda. You can Google Rocket Open AppDev for Z which is the product release from September and that will lead you to our product pages, our download page, documentation on how to install z/OS Miniconda which is the bootstrap to get you started. There is a couple of published videos. If you look at the Open Mainframe Projects Summit from September and look for, under the video there, “Demonstrating a Secure System for Downloading and Installing Software on z/OS,” you’ll find a video there that shows how it’s used. 

    Willging: The only thing I’d add to that is go check out zowe.org.

    Fandel: Thank you, Tim, yes, absolutely, zowe.org.

    Ashley: Don’t want to look past that, of course. 

    Willging: It completes everything else Peter said. 

    Ashley: Very important. 

    Willging: Important stuff. We haven’t really talked much about Zowe, but yeah. 

    Ashley: We’ll have a chance to do that. Would love to have you back and we can delve into that. I really would like to explore some more about this delivery of software into production and how do we start to evolve and expand helping more organizations consider how they might do that so there will be some great areas to explore further. So look forward to doing that with you. It’s been a lot of fun talking. Any parting thoughts before we wrap things up here?

    Willging: Just real quick, I’d encourage those mainframe z/OS shops, if you don’t have a policy for downloading, consuming open source, I encourage you to get your thought leaders together, you know think about the advantages that open source will provide in your modernization efforts. Check out zowe.org but create a policy to not only to consume but contribute. Get involved in the projects. It’s a way to expand your employees’ interest in the mainframe to make that open source there available. So if you haven’t done it, you really should do that. 

    Ashley: Access to more talent I think as Peter was mentioning earlier. It really is opening up new pathways as opposed to replatforming and a lot of not very attractive options sometimes that you now have because of open source. So folks definitely should consider this, look at it, get into it, get involved. Great. Well, gentlemen, it’s been great talking with you, both Tim Willging and Peter Fandel from Rocket Software. Take care, gentlemen, we will see you next time. 

    Willging: Thank you.

    Fandel: All right, thank you. Take care. Bye-bye. 

    Willging: Bye.

  • Managing Data Risk in 2021

    Managing Data Risk in 2021

    You can’t protect your data if you don’t know where it is stored. The first thing to consider when creating a risk-based approach to data protection is the ability to identify and prioritize data, and control who has access to it. But, how do we do this? How do we prioritize data?

    In this TechStrong TV episode, Ron Bennatan, senior vice president and general manager of data security at Imperva, joins Mitch Ashley to discuss privacy, compliance and managing data risk in data lake environments in 2021.

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

    Transcript

    Mitch Ashley: I’m very happy to be joined by Ron Bennatan, who is GM of Imperva Data Security. We’ve talked before—Ron, it’s good to be speaking with you again.

    Ron Bennatan: Hey, Mitch. Nice to see you again.

    Ashley: As always, yes. Data and security—two of my favorite topics. [Laughter] Welcome to 2021.

    Bennatan: Yeah, 2020 finally is over. [Laughter]

    Ashley: Ooh! You know, it takes a pretty big rearview mirror to look at that, but I’m not sure I wanna look back too much. [Laughter] Well, we’re gonna be kinda talking about looking forward into this new year. First, would you introduce yourself, tell us a little bit about you, and also a little bit about Imperva?

    Bennatan: Yeah. So, Imperva is kind of the market lead for data and application security. We secure all paths to data. So, it kind of straddles between both covering how data is accessed and where data is accessed, kind of covering everything regardless of on prem and cloud, hybrid cloud.

    Ashley: Mm-hmm.

    Bennatan: And I am the GM for the data security side, and really glad to be here.

    Ashley: No small problem you’re solving. [Laughter] Data is everywhere, you know?

    Bennatan: One problem, yeah.

    Ashley: [Cross talk] data. At least not very many of ‘em. So, let’s talk about it. I mean, you know, we have the whole government breach in 2020 Russia—you know, Russia, Russia, Russia, that whole thing.

    Bennatan: Yeah.

    Ashley: It certainly brought a lot of attention to supply chain attacks. Of course, you know, that being an intelligence brief, it’s collecting a lot of data, right? You know, that could, of course, happen on a—it is, did happen on corporate networks, it could also be for financial gain; it doesn’t mean it has to be a national state attack. So, I imagine that’s gonna be a—supply chain is a word we’re gonna hear a lot about this year.

    Bennatan: Yeah, I think so. I think, you know, as a, just an individual, my fear, by the way, is—you know, there’s a really big project coming for the entire world, which is the delivery of the vaccines, and that itself is a supply chain. I just hope nothing messes up there, you know? Like, you know, knowing that whatever vaccine you’re getting is actually the valid one and not—you know, there’s a lot of…everything is in data and everything at the end sits in some kind of a, like, what’s the lineage of something? What’s the providence of something?

    Ashley: Mm-hmm.

    Bennatan: You know, it doesn’t necessarily—you know, we in the data governance area talk a lot about providence and proving the correctness of data, but you know, it goes all the way to the vaccine as well. So, I think this issue that we’re seeing, whether it’s breach—breaches get headlines, okay? And, you know, so this SolarWinds thing gets a big headline, the thing that these attacks on MySQL with ransomware, that gets headlines. But really, the bigger issue is getting control of our data and creating kind of a complete risk oriented approach, not just plugging a hole here and plugging a hole here and plugging a hole here. It’s—that’ll never work, right? It’s much easier to create a new hole than to plug all the holes.

    Ashley: The whack a mole strategy. “Here’s another mole to whack.” [Laughter]

    Bennatan: The whack a mole—yeah, the whack a mole doesn’t work. Whack a mole doesn’t work. And especially today when the complexity of the data environment is so much greater.

    Ashley: Mm-hmm.

    Bennatan: You know, 20 years ago—okay, 40 years ago, we just had some dashboard on the mainframe. Twenty years ago, we just had Oracle sitting on some Unix server. Today, it’s such a complex environment, data moves from place to place, you know, you look at what a data lake implies. It’s no longer a single stack, it’s a combination of stacks. Whack a mole doesn’t work.

    Ashley: Mm-hmm.

    Bennatan: So—and most companies understand that. Most companies are in this process of investing in a non-whack a mole approach, in a risk based approach that says, “Okay, I need to know where my data is. I need to prioritize which. You know, not all data is created equal. I need to scan, I need to understand, I need to know who has the ability to access something. I then need to know who is accessing something. I need to control what they’re accessing.”

    So, you know, I think there’s a better understanding that whack a mole doesn’t work.

    Ashley: Mm-hmm.

    Bennatan: I think 2021 is still gonna be a transition year. I don’t think we’re gonna necessarily get there, but we’re gonna transition.

    Ashley: We won’t have universal enlightenment [Laughter] on day—

    Bennatan: It just takes time. I mean, it takes time.

    Ashley: It does.

    Bennatan: There’s a lot of data.

    Ashley: I wanna ask you about—you did a nice job of kind of outlining, you know, identifying what data you have, prioritizing it, access to it. One of the things that I’ve always struggled with is that second step. How do you prioritize? What are the things to consider? You know, there’s obviously sorta crown jewels of my business—this is the customer data or secret sauce or that kind of things, but is there a good sort of stratification of how to prioritize data?

    Bennatan: Okay, there’s a technical answer and there’s a human answer.

    Ashley: Okay.

    Bennatan: Okay, technically, there are very good ways to do this. It takes some effort, okay? You can—you really do this based on a scoring of a bunch of dimensions, okay? So, one dimension could be the sensitivity level of the data, okay? Another dimension could be, what is the impact if something happens, okay? Which—but the reality is that we’re all people, and people are driven by incentive, and incentive is not necessarily, doesn’t always necessarily create the right prioritization. It creates whatever prioritization the incentive is structured around.

    So, I’ll give you an example. A lot of projects going on around privacy—a lot of projects. Because it’s a very, it’s a relatively new thing, less understood, and people don’t always equate the fact that we have been doing the work, almost the identical work, we just didn’t call it privacy, right? We called it classification.

    Ashley: Mm-hmm.

    Bennatan: But when you look at what privacy implies, it’s the same, but very new terminology—different semantics, different terminology. So many people don’t start from an investment they’ve already done in the last five years, they start from scratch, and the incentives are created because there’s a new role in the company. There may be a new—you know, a data privacy officer, okay, and that person has certain mandates and they drive things top down.

    And so, I think that the reality is, prioritization is driven by the projects and the funding that these projects have, and they’re also driven by breaches, okay? Because breaches are very dramatic.

    Ashley: [Cross talk] response, right? [Laughter]

    Bennatan: Dramatic, immediately created. So, I think that the reality is gonna end up somewhere kind of in the middle where things are gonna be driven bottom up and top down and they’re gonna meet somewhere.

    Ashley: Mm-hmm.

    Bennatan: But it’s not terribly complex to create a good prioritization strategy, but it’s not trivial, either.

    Ashley: Yeah, you definitely have to put some thought into it, and it’s not a textbook exercise, right? It’s all contextual.

    Bennatan: Yeah.

    Ashley: What’s important to the business.

    Bennatan: And I think you’ll find in—I mean, my prediction in 2021 is that there’s gonna be a lot of, you know, privacy is not gonna just drive a lot of these from a compliance perspective. Okay, until now, privacy is really—you know, when a company embarks on these privacy and classification projects, or at least what I see from our customers, is that it’s driven a lot by compliance, okay? They need to comply with a CCPA, they need to comply with GDPI.

    Ashley: Mm-hmm.

    Bennatan: I think we might end up having also, like, an attack flavor, okay, around privacy, which is not intuitive, not necessarily intuitive. And it has to do with the fact that, you know, part of the mandate is, you know—so, say that I am, you know, year one of my consumers and you store, I store some of your data. That means I—you have the right to demand some things from me. Like, you have the right to demand that I delete you from my system.

    Ashley: Mm-hmm.

    Bennatan: You have the right or portability, you have the right to ask me what data do I own or do I store about you? And you can come to me with these requests, okay? Different terms, different subject rights request or data access requests. You know, you can easily think about what is the effort that I, as a big company, have when you ask me to do this? It’s not a small effort. So, okay, if you—now, the nice thing is, most people don’t do that, okay? I’ve never called somebody up and told them, “Hey, delete me, okay?”

    Ashley: [Laughter] No, I think that’s probably very much an exception—maybe a rare exception.

    Bennatan: Yeah, but what happens is some people realize that this is the way to cripple a company.

    Ashley: Mm-hmm.

    Bennatan: What happens if they organize and they say, “Hey”—

    Ashley: Or protest, right?

    Bennatan: – protest, you know?

    Ashley: Moving of Facebook onto whatever.

    Bennatan: “We don’t like you, let’s organize 10,000 of our friends and we’ll all hit them at the same time.” What do you think that’s gonna do from a work perspective? It’s pretty serious.

    Ashley: Yeah, I’m guessing it’s not just press a button—that’s gonna consume some resource at the company, people resource, things like that.

    Bennatan: Yeah.

    Ashley: You know, one thing I was wondering, too, is, with this year, there’s discussion now about do we need a national cybersecurity strategy, things like that, just to mention politics, the Biden administration is talking about working with other countries to establish sort of norms of what we do when it comes to cyber whatever with each other and what is considered an attack.

    It seems like that is—maybe not this year, but that’s certainly potential for regulation of those kind of discussions, whether it comes out of any national strategy or not or could be another country that says, “Okay, now we’re gonna take this to the next level.” Like, what is our position around data? Not just privacy, but if it’s compromised, then what happens to you as a firm? I mean, it could get kind of interesting.

    Bennatan: Yeah, it could. You know, I mean—again, we’re delving into, like, opinions and politics.

    Ashley: [Laughter] Yeah, I know.

    Bennatan: I’m not a fan of—I’m not sure that something like this could go that route. But I do think that it goes other routes. So, for example, like, I’m reading a book on kind of the history of the Mossad, okay, the Israeli intelligence service.

    Ashley: Mm-hmm, mm-hmm.

    Bennatan: And you can see—and whenever you read any of these books, you see that all of the intelligence community, they have back channels, right? They agree on things.

    Ashley: Right.

    Bennatan: So, to me, if we wanna have something like that, it should be, like, the cyber czar of the U.S. and some other—you know, the big players, they have to agree. It doesn’t need to be regulated, it doesn’t need to be at the politician level, it has to kind of stay at the—

    Ashley: Kinda behind the scenes with the cyber czar.

    Bennatan: Behind the scenes with the experts at the—but, you know, there’s definitely an issue with state nations, okay? This does need to be addressed. Now, you know, it’s not necessarily that every—you know, we always think that, you know, we’re the good guys, they’re the bad guys, you know?

    Ashley: We would never do anything like what they did to us, right? [Laughter]

    Bennatan: Well, you know, there’s examples in history, okay, of things. So, I do think this is coming. I don’t believe it would happen at a politician level, it will happen at the actual subject matter experts. And by the way, there are good examples of things that have happened like that, especially in the financial services community. I mean, for years, maybe even decades, you know, FS-ISAC, they work together to create some level of standards across investment banks or banks. These things work, I just don’t think it’s political.

    Ashley: Interesting. Well, I wanted to kinda tap your thoughts on that. I know I threw the line pretty far out there in the water, [Laughter] just to kinda get your thoughts on that.

    Well, let’s reel that back in a little bit and talk—you know, there’s GDPR and CCAPE for California. A lot of people are still in this, I think in this kinda implementation stage, even though we’re supposed to have those things all covered, right? Maybe a little farther along with the GDPR, of course, but is that something, this year, you think it’s—we’re in this, okay, let’s now institutionalize some of those things in the organizations and really take care of our knitting there or do you think there’s more things on the horizon that are gonna come at data people?

    Bennatan: I think it’s gone into an implementation phase, for sure—which is good.

    Ashley: Mm-hmm.

    Bennatan: You know, there’s a lot of things, many things are not terribly clear, by the way, even though it’s in implementation. I’ll give you an example, right, this notion of being—my ability to request that you delete me, okay? But let’s take something else, which is a different type of compliance requirement, which is for you to keep logs for a certain period of time, activity logs. There are a whole bunch of other compliance requirements that require you to do that.

    Ashley: Data retention requirements, yeah.

    Bennatan: Yeah. Okay, so—now, what happens if part of the activity logs has my identity in it and I request you to delete it?

    Ashley: Mm-hmm.

    Bennatan: Should you delete it, or should you not delete it? One, in order to comply with one thing, you should delete it. In order to comply with another thing, you can’t delete it, maybe for three years. So, there’s even things like this, which are conflicting messages. And at the end of the day, it’s going to depend on some level of interpretation.

    Ashley: Mm-hmm.

    Bennatan: Which, at the implementation level, I can tell you, I can see two approaches. One is—okay, this interpretation needs to be given by legal or it’s okay for the business to give the interpretation to that. So—and you know how it is. If it goes to Legal, it takes a longer time; if the business can make the decision, then it goes much faster. And I’m seeing more and more of this moving to the business, taking ownership, and making the decisions, in which case, it goes much, much faster.

    Ashley: Well, and oftentimes, it seems that that always happens with laws and regulations, right? There’s what it is and there’s the interpretation of it, and there’s sorta those middle tier organizations, the consultants, the larger firms to sort of establish the frameworks that, “This is our interpretation of it,” so if you do that, you’re sort of in the norm with what the industry is doing. Who knows if that’s the right interpretation or not? It’s always subject to change, but that’s usually where that help comes from, at least on the big thing.

    Bennatan: Well, yeah. I mean, it starts from there and then usually what happens or what it evolves to, which makes it really go much faster, which is what’s happening now is that if—and by the way, it goes back to your question about this nations coming together or an industry coming together. The minute you have some critical mass within a certain peer group and you say, I don’t know, maybe I’m an insurance company, if my peers have taken upon themselves a certain interpretation, I usually don’t even care where they got it from.

    Ashley: Mm-hmm.

    Bennatan: Maybe they got it from these consultants, maybe they didn’t. But if three big players in my industry are doing the same thing, I’m gonna do the same thing.

    Ashley: Yeah.

    Bennatan: And that’s what’s happening now is that, you know, I know the insurance industry well and I know the banking industry well, and I can see that they’re now, “Oh, we’re gonna do like them” and then it’s much easier to follow, like, a track that seems to be proven than to try to invent it. And that’s happening and that’s why I think there’s an acceleration for a lot of these things.

    Ashley: Yeah, I agree with you. That makes a lot of sense. What are your other thoughts about 2021? What are we gonna be thinking about that we didn’t realize is gonna be on our radar for this year?

    Bennatan: I think we are going to kind of understand this notion of, you know, look at the data from every way that you can get at the data, not try to—like, historically, there have been a focus on pillars or silos, which were more and more, or in the past were driven really by tool specialization, okay? Like—okay, I’ve got the DLP and I’ve got this and I’ve got FAM and I’ve got databases, and I’ve got big data.

    And today, the lines are so blurred, especially on the cloud services, they’re even more blurred that there’s starting to be a realization that we really need to look at all paths to the data and all ways to secure the data and look at it instead of individual silos, looking at it as, “This is my data fabric.” Okay, so you’re starting to hear things like, you know, data lakes, data fabric, data services, and the data service could be structured by different implementation stacks. But you’re no longer trying to secure each stack by itself, you’re trying to secure the entire fabric.

    Ashley: Mm-hmm.

    Bennatan: And it’s really the right thing to do. It’s the right way to think about it. It is something that requires a transition, because even organizationally, many companies had one group doing this and one group doing this and one group doing this. And this notion of, you know, looking at a single overlay control layer, okay, which can drive policy down or can bring things up is, you know, it’s time for that. And I think 2021 is gonna be, part of this year is going to be starting to deliver things at that level of abstraction, and it’s also enabled by the fact that there is technology that can kind of bubble everything up into one level, right? You don’t need to look at it as 20 different tools, you need to look at it as kind of like a federated layer, and at least it’s doable, right? Ten years ago, it wasn’t doable to do any of it.

    Ashley: You know, it’s interesting. What it makes me think of is maybe some norms that we’ve had for a while of thinking about data owners, and that sort of puts the blinders on of, now I create that vertical view of, “This is that data for that purpose for that business unit for that application or process, whatever it might be.” And what you’re saying is looking at it more systemically, right? The entire collection of data, and securing it, but also uses of that data and sort additional intelligence and things you can mine from it.

    It’s interesting—so much, as we continue to move more and more into the digital economy, digital world for how we operate, all of those digital activities generate their own data, too. So, now, we’re adding that to the fabric of the data of, you know, we have a lot more usage information, we have a lot more telemetry that we never had. You know, it seems to be expanding exponentially. So, our ability to even just fathom what’s there and how it’s—what uses it might have and how it might be correlated in new ways sort of boggles my mind. [Laughter]

    Bennatan: Yeah, yeah. And, you know, I mean, it used to be this—one of the things people used to talk about when they started building big data platforms was that, you know, until recently, we just, we couldn’t use our data. We just threw 97% of our data away, and now we don’t wanna throw it away, but you’re right, it’s a beast that feeds itself.

    Ashley: Mm-hmm.

    Bennatan: But yeah, I think it’s, I think looking at the risk profile of the entire thing and not cutting into separate projects, which then have no tie to each other, right? I mean, if you want to reduce the risk, you asked about prioritization. Okay, prioritization needs to drive everything, right? Needs to drive reducing service area, needs to drive access control policies, needs to drive audit. If you start separating each one of them, not only is it not very effective, but it means you’re working 10 times harder, because you need to do this many, many, many times.

    So, this notion of a single kind of data security platform which kind of can have this internal feedback loop and use whatever effort you’re doing, it doesn’t matter if your effort is driven by compliance or security or privacy, whatever investment you make needs to build into this platform, not do itself over the next time you do anything. Otherwise, we’re just wasting our time. We’ll never get done. Because you said the data’s growing exponentially—if we’re chasing, if we’re not leveraging what we’re doing for one purpose when we wanna do the next purpose, we’re gonna lose. It’s gotta be a single platform.

    Ashley: Well, and to your point, it seems that once you sort of make that shift, right, to that platform view of data, now you can apply that to how you look at the data across all sources, all uses, all former kind of vertical siloed—you know, you may still want to look at it that way, but it’s not like, “Okay, now we’ve figured it out for compliance, but we’ve gotta go start over to do it for something else for operational process or whatever.”

    Bennatan: Exactly.

    Ashley: No, it’s there, you kinda take that—

    Bennatan: Exactly.

    Ashley: – those same tools and look at the data, analyze it. Now you’ve got that capability to do that for lots of things.

    Bennatan: Yeah, it’s exactly—it’s exactly right. I mean, you know, it’s like, in the business world, there was always this notion of a customer 360 where, you know, what’s the point that I have one system for quotes and one system for support and one system for my policy and I never know what’s going on, and I can’t upsell, and I can’t cross sell. It’s the same thing in security, okay?

    There’s this notion of data 360, data security 360 where, if it’s there, you know, then prioritization becomes easier, right? If you can check your configs and your vulnerabilities, okay, and you get this huge list—what are you gonna do? But if you know that, of this huge list, your consumer data is here and that, you know, the crown jewels are here—great, you don’t have to boil the ocean.

    Ashley: Mm-hmm.

    Bennatan: And if, at the same time, you can bring in and you can check your entitlements and you can say, “Well, you know, I have this vulnerability, and it is important data, but I did a really good job at narrowing it down and access to it is only by these individuals and access is Kerberized and—I don’t know, and maybe I also regulate the policy very tightly—these are all related, okay? So, if you have that single platform, you’re in much better shape than…you know, it’s like, I’m trying to think of a metaphor of, you know, when you have a single viewpoint, that viewpoint may be wrong. When you have—it’s kind of like, you know, these days, this discussion about whether news means anything any more, because it’s so tailored to what you wanna hear.

    Ashley: Mm-hmm.

    Bennatan: But it’s kind of like somebody forcing you to go and watch Fox and CNN and NPR and—you must watch all of these before you make a decision. It’s the same way. We can’t reduce risk by just looking at one thing at a time.

    Ashley: Yeah, we certainly have our own selection bias and data as we do our news programming as well, right? [Laughter]

    Bennatan: Yes, exactly.

    Ashley: Well, this has been a lot of fun talking with you. I just have a sense 2021 is already off to a good start with vaccines and the COVID situation. Hopefully—

    Bennatan: Hopefully.

    Ashley: – you know, we’ll round that hump and folks can really figure out new ways of collaborating with each other without worrying about COVID. Maybe that day’s down the path not too far, but we hope, anyway.

    Bennatan: Yes.

    Ashley: So, it’s been fascinating talking with you. So, we didn’t talk about, you know, go into product stuff, it wasn’t that conversation, but tell us a little bit about where folks can find out more about Imperva.

    Bennatan: So, Imperva.com, we are—you know, if we’re talking about data security, then there’s a whole section there, and you’ll see that we’re investing a lot in, you know, things that we believe 2021 and our customers are implementing. So, a lot of kind of complete security, complete security, whether it’s for compliance, security, privacy—a lot of effort in privacy, a lot of effort around data lakes, everything around cloud. Any cloud that you can think of or any data service, any data-centric workload on the cloud is something that we’ve worked very hard with the cloud vendors to provide support for. And yeah, I think 2021 is gonna be an exciting year because of this modernization that everybody’s embarking on.

    And my hope and what we’re trying to do with Imperva is that the path of modernization for the applications and for functionality also brings with it modernization of security, updated security. That’s really what we’re working on.

    Ashley: I would definitely suggest folks check you out. In thinking about our conversation before of the response to regulation and policies and things like that of looking at what other leaders do, Imperva works with some very impressive companies who are solving the data challenge from a platform standpoint. So, there’s a lot of good reasons to check out Imperva, because there’s a lot of problems you’re solving on the advance that could help a lot of organizations, so I hope people will do that.

    Bennatan: Yeah. Well, thanks, Mitch. Always great to talk.

    Ashley: You bet. Good to talk with you, Ron, and thanks, everybody, for listening in. It’s been a great conversation, and I wish all of you a great 2021 as well.

  • How MLOps Can Help Get AI Projects to Deployment

    How MLOps Can Help Get AI Projects to Deployment

    Did you know that most AI projects never get fully deployed? In fact, a recent survey by NewVantage Partners revealed that only 15% of leading enterprises have gotten any AI into production at all. Unfortunately, many models get built and trained, but never make it to business scenarios where they can provide insights and value. This gap – deemed the production gap – leaves models unable to be used, wastes resources and stops AI ROI in its tracks. But it’s not the technology that is holding things back. In most cases, the barriers to businesses and organizations becoming data-driven can be reduced to three things: people, process and culture. So, the question is, how can we overcome these challenges and start getting real value from AI? To overcome this production gap and finally get ROI from their AI, enterprises must consider formalizing an MLOps strategy.

    MLOps, or machine learning operations, refers to the culmination of people, processes, practices and underpinning technologies that automate the deployment, monitoring and management of machine learning models into production in a scalable, fully governed way. Laying an MLOps foundation allows data, development and production teams to work collaboratively and leverage automation to deploy, monitor, manage and govern machine learning services and initiatives within an organization. In short, MLOps can help enterprises see AI projects through to deployment at scale by addressing the three previously mentioned barriers: people, process and culture.

    People

    There’s a skill, motivation and incentive gap between teams developing machine learning models (data scientists), operators of those models (DevOps, software developers, IT, etc.), and the business leaders who look for the results of that work. By providing actionable visibility into the different steps of the machine learning model life cycle for these different roles, MLOps can increase collaboration across departments so that enterprises can streamline the process of getting models operational and finally meet strategic goals.

    Process

    Operations teams are geared towards ensuring overall quality of service, optimizing runtime environments on their cloud, resource management and role-based access, among many other tasks. Data science teams are often unaware of the considerations these dependencies require, and, hence, models they create do not take these tasks into consideration. Additionally, lack of a proper native governance structure as it pertains to machine learning models – with system, performance, life cycle, and user logs – stifles troubleshooting, as well as hinders legal and regulatory reporting. Organizations that don’t properly monitor their models end up introducing potential risk to their organizations. When production models don’t reflect the ever-changing patterns in data and user behavior, these factors may affect the accuracy and overall performance of the model. Machine learning-based applications are far more sensitive to production environments than typical software applications. Therefore, machine learning models need to be validated and updated over time to ensure that they’re performing properly and leveraging the most accurate and recent data. As part of implementing an MLOps strategy, by having the right monitoring processes in place to detect drift – and many other machine learning-specific metrics – enterprises can ensure their models are delivering the most accurate results, and that their projects are more likely to move forward.

    Culture

    Fear of failure (or worse) can delay organizations from collaborating to operationalize machine learning models, or prevent this entirely. Leadership needs to be clear about their commitment to the process and fully support teams in enduring the hardships involved. This is only compounded by the fact that machine learning applications typically tend to involve processes that might introduce material risk to the company. To stay on top of such transformations while still producing trustworthy value, enterprises must keep careful tabs on all model deployment processes and the updates they entail. Many operations professionals are not aware of the unique characteristics and sensitivities of machine learning. As their role is focused on managing mission-critical production environments, they are often solely concerned with the implications on their work that deploying machine learning into production might have. While these are justifiable concerns, in the final analysis, they serve as trivial reasons for significant delays in progress and deployment. The way to mitigate all these risks and get all teams aligned around these common goals is to implement a solid MLOps strategy that matches the goals and unique position of the organization and its various teams’ responsibilities.

    MLOps: All Systems Go

    MLOps allows organizations to alleviate the people, process and culture issues posed by machine learning. MLOps provides a strategy and a set of processes and best practices, a technological backbone, for managing and scaling machine learning-based services through automation. It also provides for seamless collaboration between the data science teams responsible for generating models with the teams that are accountable for running the services in production environments. This combination of process automation with role-based collaboration and governance capabilities helps pave the way toward strategic AI goals. Specifically, MLOps can help organizations move from anticipating the management and scaling of machine learning services into production and turn that into reality.

  • What Does the Future Hold for DevOps and CI/CD?

    What Does the Future Hold for DevOps and CI/CD?

    After such a challenging year, we have finally made it to 2021. Although a new year has started, we are still trying to figure out what the “new normal” will look like once the COVID-19 pandemic is finally over.

    While the pandemic has affected many businesses and our daily lives in general, it also had a major impact on software development. This past year we have seen rapid innovation and acceleration of digital transformation as a result of the pandemic. So, what does 2021 have in store for DevOps? How can DevOps teams improve productivity and become high performers in 2021?

    In this interview, CircleCI CEO Jim Rose joins Rebecca Auguste to talk about what 2021 has in store for DevOps and CI/CD, how the pandemic impacted software teams and what they can do to succeed in this new year.

    Jim is one of the distinguished speakers that will be sharing his knowledge and predictions for 2021 at this year’s Predict Virtual Summit. During his session, Jim will discuss what’s in store for engineering teams in a post-pandemic world, backed by anonymized team data from millions of DevOps workflows. Attendees will leave with insights and benchmarks to help teams build better software faster.

    Jim has led category-defining companies through economic crises, with COVID-19 being no exception. He is on a mission to provide everyone the ability to build and deliver software at the speed of imagination.

    To find out what the future of software looks like, attend Jim’s session at Predict Virtual Summit on Jan. 21. To check out the full agenda or to register for free, visit the Predict 2021 website.

  • DevOps for the Development and Delivery of High-Performance Applications

    DevOps for the Development and Delivery of High-Performance Applications

    Engineering teams that successfully implement DevOps practices often deliver software with higher business value. These organizations can easily identify areas where problematic code exists, quickly eliminate issues and deliver high-performance applications more quickly than their competitors that use traditional delivery methodologies. DevOps practitioners understand that creating an efficient model for performance testing goes hand-in-hand with four key objectives of digital transformation: extending performance testing to new roles; integration into continuous integration/continuous delivery (CI/CD) processes; end-to-end performance monitoring; and continuous optimization.

    Reduce Cycle Time and Time to Market

    In order to meet the requirements of rapid, high-quality application delivery, modern software teams need an approach that goes beyond conventional performance testing. This is where DevOps-centric approaches can provide faster, more efficient development and help ensure the delivery of high-quality software. Building the components of an application using agile approaches and validating features as they are created ensures that applications can be tested and verified more quickly, with no increase in associated costs or resources.

    By adopting DevOps practices, individual steps within the application delivery process can be automated as part of a DevOps tool-chain. For example, automating quality assurance test runs can eliminate – or significantly reduce – time-consuming human or analog searches for defects in code. Test automation can lead to an increased volume and expanded scope of testing, which, in turn, leads to a reduction in the defect escape rate. That saves resources, time and money.

    Shift Left to Increase Agility

    To mitigate performance errors and to address issues as early as possible in the application delivery cycle, tests should be executed during the build stage of the development process. By shifting left – running the tests as early as possible, ideally as part of a code commit – enterprises reduce the risk of discovering defects or issues with the product after significant amounts of development work have been completed. It is widely accepted that addressing defects later in development cycles takes significantly more time and money versus identifying and remediating defects early in the development cycle.

    As developers perform rapid, high quality, incremental changes, business analysts or product owners can more easily share changes, concepts or suggestions with their development teams. This continuous flow of communication can significantly reduce feedback time, increasing an organization’s ability to react to changing market requirements and allowing a level of flexibility within the development process that drives competitive advantage.

    DevOps in a Hybrid Landscape

    By supporting a wide range of tools and technologies, organizations that adopt DevOps practices can support applications that run in a local network environment, in cloud-based environments or, more commonly, in hybrid IT environments. As companies continue cloud migrations and transformations, well-designed DevOps tools can help simplify this transition while continuing to provide support for the legacy applications that provide core capabilities and processing for many enterprises. These hybrid tools are fully integrated into existing application development processes, allowing all application delivery teams to successfully transition to DevOps-centric practices without leaving any teams behind.

    One particularly important DevOps practice is performance optimization through continuous analysis. By using a centralized store and a common approach for quality-centric data collation, this practice helps analyze, enforce and improve the connections between software developer, CI Build and end-to-end performance testing to ensure a “quality first” mentality and higher-value delivery outcomes. The application of data visualization techniques allows teams to access code – build – test results in real-time and make decisions based on up-to-date insights.

    If DevOps practices are successfully established within a team or organization, they not only support more efficient software development and delivery but also are cost-effective. However, in order to successfully implement DevOps practices, enterprises need to understand and implement both technological and cultural changes. Through a combination of process, tooling and cultural simplification, and aligning teams toward common business objectives, organizations can deliver their end goal of creating high-quality, high-value software that satisfies the needs of the end user. By focusing on the common goal, and understanding the journey necessary to get there, enterprises can do so more quickly and at less cost – a win-win!

  • Set DevOps Free With Modern Application Security

    Set DevOps Free With Modern Application Security

    Development teams increasingly use technologies like cloud computing and microservices, in conjunction with DevOps principles, to innovate faster and remain competitive.

    But such progress comes at a cost. The fast pace of DevOps has left security teams scrambling to keep pace and install appropriate security guardrails. Traditional security practices used to occur in the final stages before release. The rapid release cycles of agile software development often make this difficult, if not impossible.

    The speed of development is outpacing the rate at which security teams can check configurations and scan for vulnerabilities, especially as developers now outnumber security professionals 500 to 1 and modern application environments represent a vast attack surface.

    The pressure to keep up, and do so securely, has led to a gradual reframing of DevOps as DevSecOps, where security is “shifted left” and introduced earlier in the software development life cycle.

    Unfortunately, while most businesses understand the intent of DevSecOps, they are still unsure how to translate that intent into action. In fact, just 14% fully integrate security throughout the software development life cycle.

    Recent research also shows that, while 65% of security teams report shifting left, less than one fifth are doing the scans necessary to verify that shift is actually happening. The same report suggests that most security teams don’t have the processes in place to monitor and protect cutting-edge application technologies, such as microservices, APIs and cloud native/serverless.

    This lack of visibility leaves security organizations blind when problems surface in production. The longer vulnerabilities go undiscovered in the development cycle, the more costly they are to fix. A study by IBM System Science Institute suggests that fixing a defect found during implementation can cost six times as much as one identified during early design phases. A defect uncovered in production can cost 100 times as much. Even more disturbing, nearly half of enterprises admit to deploying vulnerable applications, just to meet tight deadlines.

    It’s clear that compliance and security oversight are often overlooked, and even deliberately avoided, in favor of faster, more frequent deployments.

    The Great DevOps-DevSecOps Divide

    One of the most significant issues lies with developers’ ingrained perceptions. In the past, teams worked independently, with rigidly scheduled handoffs between distinct phases of development. Security operations (SecOps) teams often introduced security functions during the final stages of the development and release process, which resulted in delays.

    Successfully putting the “Sec” into DevSecOps depends on changing older cultural biases, reinforcing the need to embrace security and empowering teams with the right tools and automation to make smarter decisions without slowing down the entire organization. In essence, DevOps and security teams are all aiming for the same goal – a high-quality, timely product. The difference lies in how they measure and define “high quality” and “timely”.

    The truth is, development won’t be slowing down any time soon. Thirty eight percent of developers now release monthly or faster, and 54% of containers live for five minutes or less. Viewing security as a separate entity bolted onto the code, instead of a key feature that must be embedded end to end, slows down development processes and reduces efficiency.

    Delivering Speed and Security

    The core questions organizations must answer to improve application security are: What makes it easier for DevOps teams and application security teams to collaborate? And what does built-in security really look like?

    For organizations that want to improve their DevOps security, here are some tips:

    • Automate security as much as possible. Invest in security solutions that can be automated and embedded directly into the CI/CD pipeline. This makes it easier to secure applications without sacrificing development speed for the sake of security. Adopting technologies like static code analysis, dynamic analysis and penetration testing reduces risks and alerts developers to potential problems. There will never be enough security professionals to handle all security issues on their own, so use automation whenever possible.
    • Build security as a guardrail, not a gate. Provide appropriate guidance and tooling, so that security becomes a guardrail rather than a gate. For example, ensuring that DevOps teams have access to templated policies enables them to align applications with security requirements from the outset, without adding unnecessary time to development. Applications and security policies can also be tested as part of the CI/CD pipeline, so they are checked like any other functional specification. In short, it’s important to provide developers with everything they need to create and test applications with the appropriate security controls applied, or they won’t do it. Empowering development teams with a better understanding of security and self-service compliance reduces vulnerabilities and risks to the organization. Developers always want to move faster, so make it possible for them to “speed” safely.
    • Enable more proactive responsibility. The average developer cannot be expected to have the level of expertise necessary to stay current with all the latest security trends—they have enough trouble keeping their programming skills up to date. Reduce complexity and make it easier to gain developer buy-in by selecting solutions that provide simplified, easy-to-understand insights within the CI/CD feedback loop.
    • Make security adaptable, scalable and reliable. Secure applications with solutions that offer consistent, centralized and self-service security for any environment. For example, AI-driven security policy engines are one way to enable the adaptability necessary to support rapid change in applications resulting from CI/CD methodologies. Being able to adapt security policies in response to the latest attacks and identify dependencies makes it easier to assess risk and take action faster.

    The dawn of frictionless and adaptable security

    Security can no longer be an afterthought, bolted on to a process. Today, integrated security must become a normal part of any DevOps implementation. Making security frictionless and adaptable enables development teams to power ahead without fear. Modern application security can be a robust support system that empowers organizations to reach their business goals securely.

  • I am, I am!

    I am, I am!

  • AIOps in Service Management: Removing the Noise

    AIOps in Service Management: Removing the Noise

    AIOps (artificial intelligence for IT ops) refers to the automation of IT operations through AI and machine learning. With every organization working rapidly toward the ultimate goal of digital transformation, there is a natural place for AIOps within service management as a means to automate processes and automatically spot and react to issues in real-time. But what exactly is AIOps, and how does it remove the noise from service management?

    AIOps: Taming the Growing Complexity of IT

    Digital transformation has resulted in IT infrastructure complexity growing at an astronomical rate. The resultant increases in infrastructure data and alarms at the service desk far exceed the capacity of any human to meaningfully read, analyze and respond to them. The infrastructure itself is also constantly morphing and changing, yet service desks are still expected to resolve requests, incidents, and performance issues in seconds – an impossible task, given the volume of data.

    AIOps provides the necessary firepower to address this exponential rise in data, using artificial intelligence to continually monitor and analyze changes in the IT infrastructure in real-time. By combining these insights with service desk automation, organizations can benefit from a closed loop of discovery, analysis, detection, prediction and automation which, combined, bring us closer to the enviable goal of self-healing IT.

    Two Phases of AIOps Implementation

    The implementation of AIOps falls into two phases: discovery and analysis.

    Discovery

    The discovery phase involves uncovering all of the compute, network and storage entities across your ever-changing IT environment and ensuring your configuration management database (CMDB) is always kept up to date. But just knowing what is on your network is only the first step – you then need to determine how each asset relates to, or depends on, each other. This dependency mapping stage requires tracking of dynamic, multilayered relationships between applications and hybrid infrastructure, and creating rich, visual topology maps so that you can immediately see where dependencies lie within the network, and, therefore, where potential bottlenecks or risks reside.

    Analysis

    With your CMDB now kept up to date with automated discovery and dependency mapping, you now need to make sense of this data. After all, data is useless if you can’t use it to make informed decisions. By applying machine learning algorithms to analyze this data, AIOps can identify patterns, spot anomalies and predict future outages.

    Why AIOps in Service Management?

    AIOps has many benefits within the larger service management context. AIOps can:

    1. Support, not hinder, rapid digital transformation – with automatic discovery and dependency mapping, AIOps allow the business to continue to invest in new IT services without upsetting those in operations that need to keep the lights on.
    2. Reduce downtime – with automatic reporting of anomalies, operations can address potential issues before they result in a service outage.
    3. Automatically update the CMDB – An accurate CMDB is the foundation of successful IT operations. If your CMDB is out of date, then you are left trying to solve problems blindfolded. Just make sure your AIOps supports hybrid environments, so it can discover all IT assets from physical to virtual infrastructure, on-premises to public cloud, etc.
    4. Remove noise from the service desk – AIOps helps the service desk to overcome alarm noise and determine which events need their attention by eliminating false positives, performing advanced event correlation, reviewing time-series event playbacks and determining probable root cause.
    5. Actualize self-healing IT – no longer a myth or an IT operator’s dream, self-healing IT can be realized through AIOps. By automatically triggering actions based on the findings of the machine learning engine, AIOps can quickly fix issues or prevent them from happening, whether it’s a network link that’s gone down, an over-utilized disk or a service that simply requires a restart.

    Operations is not known for being a calm and relaxing environment in which to work. When your role is primarily a reactive one, there is rarely time to be proactive. You are bombarded with alarm bells and error reports all day long. How can you tell the difference between a false alarm, an isolated incident or the early indicators of a bigger problem? AIOps, leveraging machine learning, has finally provided IT operations with the tools needed to make sense of this growing barrage of data.