devopsy.kinsta.cloud

Tag: survey

  • Upskilling: The Enterprise DevOps Skills Survey and Report

    Upskilling: The Enterprise DevOps Skills Survey and Report

    There has been a lot of recent reference to “T-shaped” IT professionals—individuals whose core competence (the stem) is supplemented by a broad range of other knowledge including soft skills (top of the T). T-shaped talent is in such high demand with a limited supply that recruitment efforts have become very competitive for those with upskilled and cross-skilled transformational know-how.

    Unfortunately, the migration from a deeply skilled specialist to a T-shaped practitioner is leaving many confused about what skills they should be acquiring and hiring and when. That’s why DevOps Institute (DOI) recently launched the 2019 “Upskilling: Enterprise DevOps Skills Report” community survey to help individuals and enterprises better understand the current and future state of DevOps skilling across the global IT community. Using data science coupled with hiring manager interviews, DOI’s goal in fielding the report is to provide tangible insight into why and where IT practitioners, managers, leaders and business stakeholders should focus their efforts in growing personal and organizational skills portfolios.

    Eveline Oehrlich, a former vice president and research analyst at Forrester, is bringing her data science expertise as the lead analyst for the report. Founding Platinum sponsor Electric Cloud and founding Gold sponsor Cloudbees are also sponsoring this important project. The “Upskilling: Enterprise DevOps Skills Report” will be a year over year project, and the results will be published in Q1 2019.

    The global survey will remain open until Dec. 7 and can be accessed through the following link: https://www.research.net/r/K9WD2XC

    We encourage everyone in the DevOps community to complete the survey so that the data samples truly reflect the global state of DevOps skills.  Any organization that has at least 20 people complete the survey will get a personal snapshot of the data results. All respondents who complete the survey will be entered into a drawing for four $100 Amazon gift cards.

    — Jayne Groll

  • DevOps Chat: Mainframe Attitudes with LzLabs’ Dale Vecchio

    DevOps Chat: Mainframe Attitudes with LzLabs’ Dale Vecchio

    Dale Vecchio has spent many years in the mainframe business, including 18 or so years with Gartner covering the mainframe beat. Today, he works as chief marketing officer at LzLabs, which recently conducted a survey with Microsoft on mainframe use: info.lzlabs.com/lzlabs-microsoft-…ation-survey-2018

    The results may or may not surprise you depending on your views on mainframes. It seems that a very high majority of mainframe users would like to ditch their mainframes if they could. There are some other interesting results here as well.

    Transcript

    Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. Happy to be joined by our guest who’s actually in London today, and he’s Dale Vecchio. Dale is with LzLabs. Dale, welcome to DevOps Chat.

    Dale Vecchio: Thanks, Alan. Great to talk to ya.

    Shimel: Great to have you here. So, Dale, let’s first do a little sort of level-set. Give us a little bit of your personal background, maybe your journey, and then tie that into how you come to LzLabs and what they’re about.

    Vecchio: Sure, Alan. I’m currently the chief marketing officer at LzLabs, which was a startup company out of Switzerland designed to help customers move mainframe workload to modern x86 open-cloud environments. But, before that, I was 18 years a Gartner analyst, covering the mainframe. I probably took 10,000 inquiries over those years, to mainframe customers all over the world. And I used to joke I was the only Gartner analyst with a theme song, and it was called “Should I Say or Should I Go” by The Clash.

    Shimel: [Laughs]

    Vecchio: ‘Cause mainframe customers weren’t quite sure if they wanted to stay or they wanted to go, and I said, “Well, here’s the challenges and opportunities if you stay; here’s the challenges and opportunities if you go. You make the decision. I don’t have a dog in this fight.” But I was 18 years a mainframe software vendor. I grew up as a mainframe application developer and assembler, Citrix programmer, the whole nine yards, so I’ve been dealing with this platform, on one way or the other, for four decades.

    Shimel: Yeah. You know, Dale, it’s funny; you get to a certain age, not that I’m saying you’re old, but I am, and you get to a certain age and you’re surprised how many people that you’ve dealt with, that you run into, who, actually, their root’s in IT, where “I was a mainframe developer. I was writing code on mainframes back in ’70s, ’80s, even ’90s,” and that’s very different, of course, than generations past, people who’ve come into the workplace since 2000, let’s say, or whatever.

    So, Dale, you have that historical perspective. Look, there’re people who – and, like you said, you have a dog in the race. I’m in the same boat. Right? We get cutting-edge DevOps, Agile people who say, “If it’s not on the cloud and SaaS, it just can’t keep up to today’s pace,” and then I run into a lot of people whose businesses still run on mainframe. You guys actually did a survey – I think it was in conjunction or in partnership with Microsoft?

    Vecchio: Correct.

    Shimel: On kinda people’s attitudes towards their mainframe, if you will.

    Vecchio: That’s right. Because I’ve always found the challenge for the mainframe, moving forward, is not a technical one. It’s a great box; I’ve always been a fan of the box and the hardware. The problem is that people have lost faith in it being the only platform in town. I mean, you can’t say, “I can’t run mission-critical workload on the cloud or in x86.” I mean, I don’t know how – how does Amazon do it? Or eBay? Or Google? Or Facebook? Or any global startup in the last 20 years hasn’t been built on a mainframe, so there are technical options. But the disciples of the mainframe – as you said, baby-boomers, born between 1946 and 1964 – even if an organization says, “I wanna have young developers,” your decision-makers, you database administrators, your system programmers, those guys are not young.

    Shimel: Right. They cut their teeth on ’em.

    Vecchio: And I always used to say that the biggest decider of whether customer wanted to stay on a mainframe or not was the age of the CIO ’cause, if you want an older CIO, as you said, you grew up in the world; you understand the value proposition of the box. If you’re a younger person, not so much. So that skill survey that we did, we wanted to get some objective measures from 500 senior IT leaders around the globe – “What is it you think about this platform?”

    There’s two things that came out of that that was pretty shocking. First off, almost everybody has open-source, cloud, and Agile development as key components of their IT strategy, moving forward. Now does that say the mainframe can’t participate in those? No. Is it where you’re mostly likely to find those things? Probably not. So that’s the first part. The second part was 94 percent of the respondents said they would consider getting off the mainframe, number one, which is a shocking number to me.

    Shimel: Yeah.

    Vecchio: I didn’t say they will. Said they were –

    Shimel: No, no.

    Vecchio: Which, 10 years ago, you wouldn’t have got that kind of number. But I think the one that was more surprising to us was that half of the mainframe companies that we surveyed have lost faith because IBM is more focused on the cloud and Watson. And they not even sure that the keeper of the flame is as focused on that platform as, say, Compuware, who is 100-percent focused on that. I mean, they have a great DevOps story.

    Shimel: Yep. Well, look, all of the mainframe people have developed a DevOps story, right, Dale? Whether it’s IBM – as you said, the keeper of the flame – or the Compuwares, the CAs, and there’s a few others we’ve dealt with that are mainframe vendors and stuff. Here’s how I kinda – couple of things. First of all, that 50-percent number on people’s perception about IBM’s focus on the mainframe? I get it. You know, I go to IBM Think every year. It’s this huge – it’s in Moscone this year and it’s a huge floor. And you look at how much is dedicated to mainframe versus the shiny, new objects.

    Last year – well, it’s been Watson for a few years, but, this past year, it was the – not “cognitive.” What’s the new computers? It was like a copper machine – eh, whatever. I forgot the name of – it’ll come to me, I’m sure, while we’re talking. But, anyway. But, yet, when you look at the bottom line, when you look at the revenue – and I’m not a stock pundit and I’m not here giving anyone investment advice, right?

    Vecchio: Nor I. Nor I.

    Shimel: Their revenue still comes, way, way, way more than they would like to really tell, comes from mainframe.

    Vecchio: Well, their profit does. Their profit does.

    Shimel: Their profit. Yeah.

    Vecchio: Yeah. That’s for sure. I mean, this is a challenge for anyone with a mainframe. It’s not a bad box. You’re faced with the challenges of skills decline. Most of the, if not all of the, vendors in the space are very focused on maintenance revenue. And why would anybody buy Rocket or CA, why would an investor look at that, unless they were managing the maintenance revenue streams? So that doesn’t bode well. This is not about whether that box is any good; it’s the dynamics of the market are working against it.

    Shimel: I get it. Yeah, by the way, it was “quantum computing.”

    Vecchio: Ah.

    Shimel: That was brought up _____ _____ _____.

    Vecchio: Oh, yeah, quantum computing. Yeah.

    Shimel: Yeah. That was definitely the shiny bullet at last year’s Think. And you’re right. Look, you got Chris O’Malley at Compuware and he’s all mainframe and he’s not shy about it either. CA – a lot of people are saying the whole reason Broadcom bought CA was for mainframe – I don’t know if I buy that either.

    Vecchio: Well, for mainframe revenue.

    Shimel: Yeah.

    Vecchio: For mainframe –

    Shimel: Well, more for using the mainframe customer base to go sell routers and switches, which I’m not – we’ll talk about that offline. But let’s stick to the survey. So, yeah, I can understand the 50 percent. It doesn’t jive, of course, with IBM’s profits, but here’s my kind of basic nitty-gritty on this issue, Dale, is, yeah, we’d all – look, I’d like to get a different car. I’d like to do something different. The problem is that trillions – and it is literally trillions of dollars that have been sunk into mainframe. I don’t know how many organizations can just afford to walk away from that.

    Vecchio: Well, this is sorta the challenge, when you talk about this, is it becomes a very black-or-white conversation. People talk, “Oh, you’re saying the mainframe is dead?” No, we’re not saying the mainframe is dead. All we’re talking about is mainframe’s getting marginalized to the high end of workload. If you went back 20, 30 years ago, there were 30,000 or 40,000 mainframes. Now there’s maybe 3,000 or 4,000 mainframes. Well, sure, they’re much bigger than they were, so there’s been some consolidation, but, even in the number of customers, there are fewer.

    One of the things that I always found, the time I was at Gartner and even out of what these survey numbers tell me, is they want to get off. They want to. They don’t because they’re not sure they want the risk, number one, and, number two, they don’t have to ’cause they still have the people. But, as those – every single one of them in that survey, 85 percent of ’em, said, “Yeah, we have got a problem.”

    So you’re either gonna fix the problem or you’re not, and that gets us to the whole conversation about DevOps – just “Can I bring my hammer to the mountain or the mountain to my hammer?” Can I bring all of that DevOps, Agile mindset to a platform where the culture is a 180 degrees from that? You know, all of the things on a mainframe were designed for security, reliability, availability; they weren’t there for speed. There’s not all the automated testing. People don’t understand these applications and what they do. You know, we used to joke, “These aren’t legacy systems; they’re leprosy systems,” ’cause nobody wanted to touch ’em ’cause they might lose a body part.

    So how are you gonna do Agile and DevOps in that environment? So is it technically possible? Absolutely. Does Compuware have a compelling story? Absolutely. Have they convinced enough that you believe that the future of the mainframe is bright or it’s gonna continue to decline? I –

    Shimel: I don’t know. I mean, I guess time will tell us that. I’ve often thought, “Why can’t you duplicate the resiliency, the power, if you will, of the mainframe?”

    Vecchio: Ah, that’s a great question, Alan. Because part of – the mainframe was very much a scale-up world. You know, if you wanted more processing power, you added more MIPS. One single operating system, unified database, transaction monitors, et cetera. It is absolutely 100-percent unique _____ _____. Everything else is scale-out.

    Shimel: Mm-hmm.

    Vecchio: Like, “How could I take a scale-up environment and move it to scale-out?” And that’s what we’ve tried to do with our software-defined mainframe, is to give someone the ability to move an application without recompiling it, without changing the data, down to an environment that now will do scale-out. So just take full advantage of Linux, of OpenStack, of cloud-deployment models, take that exact same application and now I can run it in a scale-out world. That’s only the first step because you’re gonna wanna maintain it and then you’re gonna wanna transition to modern languages. But it’s a lot easier to take advantage of the innovation and community of open-source off the mainframe than it is on, you know?

    Shimel: Yeah.

    Vecchio: Sure, IBM has Linux on the mainframe. Sure. But you tell me where the community and innovation is going. Right? It’s going to cloud; it’s going to x86; it’s going everywhere else.

    Shimel: You know what? It’s going – well, look, you could run containers and stuff on mainframe, but, look, when I’m talking to startups and even enterprises now, Dale, who are “high-performing IT organizations,” let’s call them, right? They’re not Google and they’re not Facebook, but they’re not necessarily iron miners or something, right?

    Vecchio: Yeah, okay.

    Shimel: They’re talking about things like Kubernetes and serverless and microservices, and I’m not saying that you couldn’t run these on a mainframe. I’m just saying I don’t think – I don’t know if it’s the right tool for the job. You know, one thing I learned as I grew up: I was never a handy guy, Dale, right, but tools make the man. Right? And –

    Vecchio: Yeah.

    Shimel: You know what I’m saying? And so I –

    Vecchio: Tools are your – Alan, you’re 100-percent right. And this idea of bringing DevOps to the mainframe, which is Compuware’s story, depends on two things. First, you have to have the tooling, as you said, to make that happen, but much, much harder. And I even read some of the posts up on devopsy.kinsta.cloud about this – the culture is the challenge.

    Shimel: Yeah.

    Vecchio: So you can’t just try and take the culture and bring the tools into that world and expect it to take. It’s not gonna do it. Now – so we’re sorta the other way around. We’re saying, “Bring that workload to the world where DevOps readily – ”

    Shimel: That culture exists. Right.

    Vecchio: Right? Now are you gonna keep running those applications? No, but, to your point, they’re not so easy to change, in a big way. But, if I can get out of the complexities of the operational environment – ’cause DevOps is a combination of operations and Agile development, as you all understand – sure, I can do the Agile development; how do I deal with the operational side of that? How do I do all of the automation that’s required? How can I take a fix – can you imagine trying to roll out one-tenth of the fixes that Amazon does in a day, on a mainframe.

    Shimel: Nah.

    Vecchio: Very, very difficult to do.

    Shimel: Yeah.

    Vecchio: And I would ask you, any large customer that you speak to, if you said to them, “If you had to do it all over again right now, would you build it on the mainframe?” And I’ll bet ya seven out of ten would say, “No.” So the challenge for mainframers is it’s hard to get off, but the challenges of staying are not free either. So, to me, bringing DevOps and Agile to the mainframe is 100-percent reasonable, intelligent story. I haven’t seen it be successful. And I think the dynamics of the workforce are in play.

    Shimel: Yep. So, Dale, we don’t have a lot of time, but I wanna ask you, so I’m not as familiar with your company; this is our first conversation. I’d love to see some case studies of companies who have sorta migrated to software-as-a-mainframe kind of thing and see what their experience has been, and so forth. How _____ _____ _____ –

    Vecchio: Yeah. Well, that’s –

    Shimel: How long are you guys offering this?

    Vecchio: That’s just a perfectly reasonable thing to do and I’ll see, when we’re offline, if we can’t make that happen. There’s two parts to this whole conversation of moving mainframe workload. One is the infrastructure side, the operational side, and the second one is the applications, running the application technology itself. And our solution is designed to allow you to move the applications and get rid of the infrastructure side and take full advantage of a Linux, VM, OpenStack, OpenShift container world in order to do that. That’s the first part of the conversation. There is not many people that we speak to who aren’t intrigued by the notion of cloud.

    Shimel: Sure.

    Vecchio: Whether it’s public or private.

    Shimel: Mm-hmm.

    Vecchio: Once you say that, what you’re saying is “I want to be in an Agile, scale-out world.”

    Shimel: Yeah.

    Vecchio: Now the problem is so few of the vendors left in the mainframe world are actually innovating. And I assert Compuware’s one of ’em, but, for the most part, they seem to be more interested in managing a maintenance revenue stream. That’s not really conducive for what we’re trying to accomplish.

    Shimel: Understood. You know what, Dale? We’re gonna need to continue this conversation ’cause we’re about out of time, but let’s do that. Fascinating stuff. And you know what? People make fun of mainframes and say, “Boring,” but this really is fascinating stuff, right? And it’s real-world ’cause there’s still a lot of stuff running on those mainframes.

    Vecchio: Nobody wants to get off because it’s a bad box. ‘Cause it’s not. I mean, it’s an incredible piece of engineering. No question –

    Shimel: Yeah, it really is. It’s still a _____ _____.

    Vecchio: Also, it’s hard to get out.

    Shimel: All right. Dale Vecchio – was it CMO or VP marketing?

    Vecchio: CMO.

    Shimel: CMO at LzLabs. Thanks for being our guest on DevOps Chat today. Good luck and we’ll be speaking to you soon.

    Vecchio: My pleasure, Alan.

    Shimel: All righty.

    — Alan Shimel

  • CA Technologies Report Highlights App Modernization Paradox

    CA Technologies Report Highlights App Modernization Paradox

    The rush to modernize IT environments using microservices, application programming interfaces (APIs) and containers may very well turn out to represent something of a double-edged sword.

    A survey of 1,087 IT and business professionals conducted by Frost & Sullivan on behalf of CA Technologies, a unit of Brocade, finds that organizations that have modernized their application environment are eight times more likely to achieve key performance indicators (KPIs) for the business. Four out of five respondents also said agile practices are helping them build what customers really need to improve overall customer satisfaction.

    On the downside, however, the study also finds more than half of respondents (56 percent) claimed that software issues can negatively affect the achievement of KPIs. A full 69 percent of all respondents say the pressure to release new applications or updates negatively affects quality and security, and 67 percent admit that their organization sometimes trades off security for application development and deployment speed.

    Nine out of 10 respondents who claimed to widely utilize modern application architectures also concede it’s challenging to manage and monitor APIs, microservices and containers, and that APIs and microservices add new risks for their organizations. A total of 80 percent of respondents also say they view continuous application security testing and DevSecOps as critical components of their strategy to help resolve those issues.

    Ashok Reddy, general manager for DevOps at CA Technologies, said that while organizations are clearly seeing a business benefit after embracing DevOps to modernize their application environments, the process hasn’t always been easy. The challenge they now face is that the rate at which digital business transformation projects are being launched has substantially increased. Most organizations are not going to achieve those goals in a timely fashion unless they modernize their application development and deployment processes, said Reddy, noting that only then can IT become flexible enough to meet the needs of the business versus continuing to try and force the business to bend to the way their applications work.

    The paradox many organizations find themselves wresting with is that making the business more agile requires a more complex approach to IT. In theory, each microservice deployed is easier to manage than a monolithic application. But as thousands of microservices get deployed, the number of dependencies between services becomes more than the average IT organization can track. In fact, all those dependencies is one reason more organizations are starting to investigate applying machine and deep learning algorithms within the context of an artificial intelligence (AI) model to automate IT management at scale. Clearly, most IT organizations are now on a journey that starts with a simple set of microservices and ends up fundamentally transforming enterprise IT, regardless of whether anyone likes it.

    It may take a while longer before the future of IT becomes a completely settled question. But for now, it’s apparent microservices in some regards are too much of good thing. The challenge is that from a digital business perspective, those microservices have become something most organizations can’t do without.

    — Mike Vizard

  • Survey: Rapid Automation of IT Ops Looms Ahead

    Survey: Rapid Automation of IT Ops Looms Ahead

    The rate at which IT operations will become automated is about to accelerate significantly over the next two years. A global survey of 1,500 senior IT leaders conducted by Cisco Systems finds that 64 percent of respondents today would describe their approach to IT operations as either reactive (26 percent) or proactive (38 percent), but within two years more than two-thirds expect their approach to be either become predictive (33 percent) or preemptive (33 percent). Only 14 percent of respondents describe their IT environments as being preemptive today.

    In general, the survey finds 88 percent of IT leaders said their investment in IT operations over the past 12 months had improved external customer satisfaction, while 89 percent said there have been improvements in innovation. But only 26 percent collect data on an ongoing basis and even fewer (17 percent) employ any kind of real-time automated analysis, the survey finds.

    Nevertheless, 42 percent of respondents said they expect artificial intelligence (AI) to have the biggest impact on their ability to automate. More than half (51 percent) said they already rely on AI to some extent today to automate IT operations.

    A full 82 percent also already collect operational and performance data about their security infrastructure.

    Joseph Bradley, global vice president for IoT, Blockchain, AI and Incubation Business at Cisco, said much of the investment in automating IT operations is being driven by the realization that IT has become a profit center rather than cost center. As organizations increasingly realize they are a software company that happens to make something, they are looking to maximize the return on their investments in IT wherever possible, said Bradley, adding as a result, line of business (LOB) executives are exercising more influence over what applications get built and deployed within the context of an overall digital business transformation strategy.

    Naturally, all that increased appreciation for the value of IT is putting more pressure on IT organizations to modernize their processes. As the number of applications that need to be built, deployed and maintained continue to increase, the need to embrace DevOps processes becomes a greater imperative. To facilitate that shift across enterprise IT environments that now routinely span multiple clouds, Cisco has been making a two-fold case for centralizing the management of highly distributed IT environments and upgrading to next-generation software-defined infrastructure that makes use of machine learning algorithms to automate IT management.

    Cisco is not the only IT vendor pursuing a similar strategy. The success of those strategies, however, depends as much on the ability of the IT organization to implement the processes required to modernize their IT environments as much as it does the technology platforms. That creates something of a chicken-and-egg relationship between processes and platforms. It is difficult, but not impossible, to implement some level of DevOps without having a lot of automation. But applying DevOps at any meaningful scale within an enterprise undoubtedly will require a lot more automation than currently exists within most IT environments.

    — Mike Vizard

  • IBM Survey: Rise of Multi-Cloud Computing to Force DevOps Issue

    IBM Survey: Rise of Multi-Cloud Computing to Force DevOps Issue

    A survey of 1,106 business and technology executives published this week by the IBM Institute for Business Value finds 85 percent of companies are already operating in multi-cloud environments, with 98 percent forecasting they will be using multiple hybrid clouds within three years. But the survey finds that only 39 percent of the respondents have implemented some level of DevOps processes to help streamline the management of multiple cloud computing platforms.

    Blaine Dolph, vice president of Global Business Services for IBM, said it’s clear that DevOps will play a critical role in enabling IT organizations to centralize the management of multiple clouds. But the IBM survey suggests that the management of multiple clouds within organizations is not nearly as efficient as it should be.

    Only 41 percent of survey respondents said they currently have a multi-cloud management strategy in place, and just 38 percent have the procedures and tools in place to operate a multi-cloud environment. Only 30 percent of enterprises have a multi-cloud orchestrator or other multi-cloud management platform to choreograph workloads, while fewer than 40 percent of organizations have cloud configuration management tools that provide information about resource configuration and relationships between resources, the survey found.

    All told, the IBM survey is only able to identify 20 percent of respondents as “multi-cloud maestros” capable of employing multiple clouds to smoothly and routinely deliver one or more business functions. The survey found almost two-thirds of multi- cloud maestros report they employ cloud management platforms.

    The survey also found that multi-cloud maestros are advanced in terms of adoption of microservices and containers. A full 61 percent of multi-cloud maestros predicted that within three years at least 80 percent of new applications will be developed using containers. Currently, 50 percent of multi-cloud maestros are using Docker containers and 63 percent are using containers as a service (CaaS). By 2021, 65 percent expect to use container orchestration. More than half (56 percent) of the multi-cloud maestros are already microservices and 59 percent plan to use serverless cloud services in their cloud environments, according to the survey results.

    Dolph said IT organizations in general would be well-advised to focus on more than just “lifting and shifting” applications into the cloud. They may need to leverage Docker containers to move an application into the cloud. But once there, an effort should be made to modernize that application by turning large swaths of it into a set of microservices that ultimately are easier to maintain and consume by developers building complementary applications, he said.

    The IBM survey makes it apparent that multiple clouds are the new IT normal. Almost half of respondents said they are establishing a multi-cloud architecture to develop new and enhanced products and services. A total of 62 percent of respondents require multiple clouds to create innovative business models, while 52 percent said they need them to produce new revenue streams. Sixty-six percent need them to enhance margin and 46 percent said they need a multi-cloud environment to support agile business processes.

    From a DevOps perspective, more than half (51 percent) of respondents use multiple clouds to cultivate a flexible, modular infrastructure that quickly absorbs and leverages technological advances.

    Obviously, one of the great paradoxes of multi-cloud computing is that in the pursuit of becoming more agile, many organizations are making their IT environments more complex by employing multiple platforms. The challenge they will face next is maturing their DevOps processes to the point where some order is finally brought to that multi-cloud computing chaos.

    — Mike Vizard

  • Modern Software Development Helps KPI Achievement

    Modern Software Development Helps KPI Achievement

    A new survey by Frost & Sullivan in collaboration with CA Technologies clearly shows that business executives believe modern software development helps them achieve KPIs. This is the latest in a string of surveys showing that modern software development practices such as DevOps result in higher-performing organizations, more profits and greater KPI achievement.

    Key findings of the survey show that organizations with more mature programs are:

    • Eight times more likely to declare that applications are very good at supporting the achievement of
      business KPIs;
    • Seven times more likely to say their apps are completely integrated to enable functionality, data
      sharing, authentication and security; and
    • Able to achieve two times’ higher profit growth.
    Ashok Reddy, GM DevOps CA Techologies

    I spoke with Ashok Reddy, Group GM, DevOps at CA Technologies about the findings. In addition to the key findings above, Reddy emphasized another key point: The survey showed that in organizations with modern software development programs, business executives outside of IT are key software decision-makers.

    Traditionally, IT was viewed as servicing the rest of the organization as their customer. A key constituency of this customer base would seem to be non-IT business executives. They recognize that software and applications are so important to achieving KPIs. They are moving beyond just being a customer of IT to actually being involved in the software development process itself, according to Reddy.

    key metric

    Some Troubling Findings

    Not all of the findings from the survey are rosy, though. Pressure to release software endangers quality and security, according to 69 percent of the business executives surveyed. More than two-thirds of respondents said that security is sometimes overlooked to expedite development. Software issues negatively impacting KPIs was cited by more than half of the respondents.

    With modern software development practices becoming so important, the findings above seem logical—logical, perhaps, but not acceptable. We must continue to strive to make security a more organic part of the software development process. Security concerns cannot continue to be overlooked because they are a drag on software development. One of the key points that I believe about DevOps and modern software development is that you can have more velocity, speed and security by following these practices.

    All in all, this survey is yet another brick in the wall showing that organizations around the world adopting modern software development practices such as DevOps, Agile, etc., are outperforming their competitors who don’t. It is quickly becoming a case of DevOps or die.

    — Alan Shimel

  • Mainframes and DevOps: The Odd Couple of Digital Transformation

    Mainframes and DevOps: The Odd Couple of Digital Transformation

    I am still surprised when I go to industry conferences and I hear people talking about the imminent demise of the mainframe. More common and equally wrong is how mainframes don’t work in today’s agile/DevOps/cloud/container world. The fact is, with trillions of dollars invested in our mainframes and more every day, the mainframe is not going extinct anytime soon. Equally factual is mainframes and DevOps can work well together.

    They may seem incompatible at first blush, but mainframes and DevOps work. We have written more than several articles on mainframes and DevOps. Our own Don MacVittie has written two excellent ebooks on mainframes and DevOps: “DevOps-ing the Mainframe” and “Automation: Modernizing the Mainframe for DevOps.” There is also a series of DevOps Chats on this subject. This one, with Rosalind Radcliffe of IBM’s Enterprise Systems, is a good one.

    Now, we would like to hear from you. What do you think regarding mainframes and DevOps? Working with our friends at CA Technologies’ mainframe business unit, we are conducting a mini-survey (just 10 questions) on mainframe use. It is embedded below this paragraph. You taking a few minutes to answer will help us better understand what is happening with mainframes and DevOps.

    The Mini-Survey

    Create your own user feedback survey

    If the survey embed didn’t work for you, you can also answer the 10 questions right here.

    If you’ve reached here because you took the survey, thanks very much. If you didn’t, please take a moment and do so. The survey doesn’t ask for any contact info and we promise you won’t receive any spam email or calls.

    Still would rather not answer the survey? OK, at least have a look at the ebooks listed above or listen to the chats. But, if you really think mainframes are going away or you have an opinion on mainframes and DevOps in general, you can write me at editor@devops.com. I would be happy to hear about it. Perhaps you want to write an article about your views? That is fine, too—write me.

    In the meantime, next time you are at a tech conference and the issue of mainframes and DevOps comes up, don’t spread fake news. The mainframe is alive and well. More of our financial, health and other transactions as well as systems of record go through them than ever before.

    — Alan Shimel

  • Manual Processes and Silos Complicating DevOps Deployments

    Manual Processes and Silos Complicating DevOps Deployments

    The DevOps concept largely originated in 2009, as software and IT organizations were beginning to adopt Agile methodologies. It came on the heels of a movement to integrate lean manufacturing concepts and infrastructure as a service into IT organizations. Rapid development was the goal, but application and infrastructure teams were still working independently, creating barriers to progress. Flickr employees John Allspaw and Paul Hammond delivered a presentation at the O’Reilly Velocity Conference that outlined ideas for streamlining deployment through better collaboration between development and operations. They hoped to temper conflicts between team members and minimize waste. DevOps took off soon after, when Patrick Debois founded the DevOpsDays conference in Belgium.

    When DevOps is a mature practice in IT and software organizations, there are some powerful benefits:

    • Every change to the application stack triggers a new deployment.
    • Deployments become easy and not a fire drill.
    • Fixing errors in production become a simple redeployment without the need to perform a huge root cause analysis up front.

    The Long Road to DevOps

    While many organizations are adopting DevOps practices and tools today, we’re still a long way from reaching DevOps maturity. Our company recently conducted a survey on DevOps adoption, and the findings indicate that there are still too many manual processes and silos standing in the way. I will break them down here:

    Manual Infrastructure Management is Still Common 

    Nearly 40 percent of IT professionals surveyed say that they manage infrastructure manually. Yet nearly 60 percent report the use of infrastructure-as-code tools such as Terraform, configuration management and Kubernetes. This speaks to a disconnect between having the technology available to operate in an automated way and being able to execute change with those tools. Heavy manual processes lead to higher costs, since so much effort goes toward tinkering with configurations and fixing problems. Manual work also detracts from the ability to members to focus on the application and business needs.

    Managing Environments in Silos

    Another tenet of DevOps infrastructure management is environmental parity. This means that through infrastructure-as-a-code tools and processes, IT manages all development environments similarly through a common code base. According to the survey, only 25 percent of companies are managing development, test and production environments identically. This results in application stability issues. Without environmental parity, every change will eventually lead to an outage.

    Managing Teams in Silos

    From the start, DevOps has emphasized breaking down the walls between development, QA and IT operations. The goal is to enable continuous feedback, fewer errors and faster development cycles. Of survey respondents, 78 percent report that separate teams are still managing infrastructure/operations and application development. As well, just because you create a DevOps team consisting of various job roles doesn’t mean that people are working together and are committed to the team’s success.

    There must be incentives to encourage a developer to understand testing needs and for infrastructure engineers to get clear on a project’s requirements and objectives. There should be minimal tolerance for functional experts isolating themselves without making an effort to understand the bigger picture.

    When organizations are able to minimize manual processes and break down these technology and silos, they benefit from a totally different, more productive way of working:

    • Adoption of continuous integration/continuous deployment, whereby every code check-in triggers a testing cycle and a build.
    • Transparency between infrastructure people and developers, avoiding surprises resulting in issues or rework later.
    • Incorporation of success metrics, such as deployment frequency, mean time to detection (MTTD), mean time to recovery (MTTR) and change lead time.
    • Cost reduction, from fewer errors and labor-intensive manual processes.
    • Increased productivity, as developers get the infrastructure they need quickly to run new projects and QA and IT Ops people can focus on high quality, stability and user experience rather than repetitive tasks and troubleshooting.

    So, What’s Going On? 

    Despite the many benefits of DevOps, there seems to be a lack of urgency in some organizations to take the necessary steps for change. Progressive IT departments that applaud agility and business value should be ahead of the curve, but that’s not always the case.

    DevOps maturity comes down to setting the right culture for change, which must emanate from the top. The shift to DevOps takes time and investment, no doubt. There’s also need for patience. The transition temporarily slows down production as people adjust to new workflows and learn new skills. Replacing toolsets is just part of the strategy. Organizations must make a conscious effort to embrace DevOps with a well-thought out plan.

    — Lars Cromley

  • Survey Finds DevOps Playing Key Role in Cloud Migration

    Survey Finds DevOps Playing Key Role in Cloud Migration

    A survey of 450 C-level and VP/director-level technology leaders in the United States, UK and Canada conducted by 451 Research on behalf of Skytap, a cloud service provider, found that lifting and shifting existing applications into the cloud is giving way to either refactoring and rewriting those applications to take advantage of cloud-native technologies.

    According to the survey results, 67 percent of respondents plan to migrate or modernize at least half of their on-premises applications in the next 12 to 24 months. The survey found 28 percent of respondents plan to refactor applications using a mix of cloud-native and traditional technologies, while another 20 percent plan to adopt some form of a platform-as-a-service (PaaS) environment. That compares to 20 percent who plan to lift and shift existing applications into the cloud with no changes to the underlying code. Another 20 percent said they will replace existing applications with software-as-a-service (SaaS) applications.

    Jay Lyman, an industry analyst for 451 Research, said the survey makes it clear that, when it comes to lifting and shifting applications into the public cloud, too many organizations are still engaged in “wishful thinking.” Most applications migrating to the cloud will need to reworked to one degree or another, Lyman said.

    The survey found that only 20 percent of respondents plan to move 75 percent or more of their applications to a cloud platform in the next 12 to 24 months. Just less than half (47 percent) said they would migrate somewhere between 50 percent to 75 percent of their applications.

    In terms of methodologies that will be employed to achieve that goal, 54 percent of respondents said they were already relying on DevOps processes, while 46 percent said they are relying on agile methodologies. In terms of talent, 55 percent said they are looking to acquire or retain IT professionals with cloud migration expertise, followed by 52 percent who cited application modernization using cloud services. DevOps skills and multi-cloud operations expertise tied for third at 50 percent.

    Just over a third (37 percent) also noted that decisions concerning where best to place a workload were being driven primarily by where an application would run best, while 26 percent said decisions were driven by identifying the best-of-breed cloud-native service. Only 19 percent said their organizations would be employing multiple public cloud service providers. In fact, Lyman noted that while hybrid cloud computing remains the dream state most IT organizations want to achieve, the reality is that most of them will be managing multiple clouds in isolation for many years to come.

    More than 80 percent of survey respondents reported managing more than 100 applications, with 74 percent stating at least half of these applications are on-premises. A full 71 percent of respondents said more than half of their on-premises applications are mission-critical. A little over half of the respondents said core business applications including customer relationship management (CRM), enterprise resource planning (ERP), and data analytics were least-suited for hyperscale clouds. According to the survey, the biggest challenge associated with deploying applications in the cloud today remains security (56 percent).

    The Skytap survey makes it clear IT organizations are still severely challenged when it comes to migrating applications to the cloud for want of skills. Most applications are not easily migrated, which makes reworking them for deployment in a cloud environment a high priority. In the absence of those skills, however, it’s also apparent that any migration of applications to the cloud is going to occur over an extended amount of time.

    — Mike Vizard

  • Can EV Certificates Improve Brand Value and Increase Trust?

    Can EV Certificates Improve Brand Value and Increase Trust?

    Most people know the difference between a website that is completely insecure and unencrypted and one that offers an encrypted session for security. You simply look for whether the URL starts with HTTP and the address bar displays an open padlock, or the URL starts with HTTPS and shows a locked padlock. Within the realm of secure websites, though, not all certificates are created equally. An extended validation certificate — EV certificate, for short — provides a more in-depth validation process than other certificates and may foster more trust from customers as well.

    The difference between an EV certificate and other certificates lies in the verification required to obtain one. Traditional certificates can be acquired by providing organizational information or verifying admin rights of the target domain. On many occasions, though, attackers have found ways to circumvent or subvert the verification process and obtain fraudulent certificates using those methods. The verification process for an EV certificate requires proof that the requesting entity is, in fact, the legal identity that owns and manages the target domain.

    According to Wikipedia, the vetting process for an EV certificate involves a number of additional validation steps: “These include manual checks of all the domain names requested by the applicant, checks against official government sources, checks against independent information sources, and phone calls to the company to confirm the position of the applicant. If the certificate is accepted, the government-registered serial number of the business as well as the physical address are stored in the EV certificate.”

    As attackers have grown more savvy and adapted to the expectation that a website run over HTTPS and have the padlock indicating that it’s secure, they’ve found ways to game the system and create fraudulent or phishing websites that appear to be secure.

    Websites with EV certificates show up differently in browsers with EV support, which includes Microsoft Edge, Microsoft Internet Explorer, Mozilla Firefox, Google Chrome and Apple Safari. In most implementations, websites with EV certificates include more advanced details about the website and the entity behind it, such as the name of the company that owns the certificate and a bar or text that is distinct—usually green—for easy visual verification of a valid EV certificate.

    We’d like to know more about how important secure websites are to you, and whether you know—or would notice—the difference between a website using a traditional certificate and a website using the more secure EV certificate. Please invest five minutes of your time to take a quick survey and help us learn more about the value of EV certificates when it comes to your level of trust online.

    Click here to begin the survey.

    — Tony Bradley