devopsy.kinsta.cloud

Category: Features

  • AI for IT Operations: All It’s Cracked Up To Be?

    AI for IT Operations: All It’s Cracked Up To Be?

    Artificial intelligence for IT operations (AIOps) is becoming a critical tool for organizations attempting to bring automation quickly to network management and IT problem resolution. However, many organizations are still unsure how to deploy AIOps for the most value and to net the full, promised results. Perhaps the challenges come from not looking beyond data silos, or perhaps the problems can be attributed to a lack of understanding AIOps’s full potential in the enterprise.

    Enzo Signore, chief marketing officer at FixStream, lends credence to the problem of siloed information. “Despite continued investments in system resources, IT cannot holistically see what’s in their physical and virtual infrastructure,” he said. “And without a clear view of the entire IT environment and the ability to make sense of the mountain of data being served up by various system tools, Ops teams can’t figure out what’s wrong or how to fix it.”

    In essence, for AIOps to be successful, IT must be able to access that siloed data and then be able to process that data to derive actionable insights, exactly what AIOps is meant to do. Yet, complexity still seems to be one of the major challenges of bringing a holistic approach to managing networks and resolving problems. 

    “IT teams are bogged down by the sheer complexity of today’s hybrid, dynamic IT environments,” Signore noted. “Along with steep learning curves and lightning-fast changes to new technology, IT departments must cope with soaring consumer expectations, supporting legacy systems, lack of skilled talent, disparate tool sets and opaque physical and virtual IT infrastructures. These factors complicate IT staff’s ability to oversee operations and optimize system performance.”

    Naturally, companies such as FixStream have a major stake in the AIOps game; the company offers numerous AI solutions that promise to modernize IT operations and bring AI into the realm of IT operations. However, understanding what AIOps is all about is one of the first hurdles to overcome when contemplating the technology. Gartner defines AIOps as platforms that enhance IT operations through greater insights by combining big data, machine learning and visualization. “IT leaders should initiate AIOps deployment to refine performance analysis today, and as an augment to IT service management and automation within the next two to five years,” advised Pankaj Prasad, senior principal analyst at Gartner.

    Gartner defined some best practices that businesses should adopt, which include: 

    • Deploy AIOps by adopting an incremental approach that starts with historical data and progress to the use of streaming data, aligned with a continuously improving IT operations maturity.
    • Select platforms that enable comprehensive insight into past and present states of IT systems by identifying AIOps platforms that are capable of ingesting and providing access to text and metric data.
    • Deepen the IT operations team’s analytical skills by selecting tools that support the ability to incrementally deploy the four phases of IT operations-oriented machine learning—descriptive, diagnostic, proactive capabilities and root cause analysis, to help avoid high-severity outages.

    Best practices aside, FixStream’s Signore opined that there are some other challenges that must be addressed. “Without the foundational capabilities of accurate discovery, contextualization and full-stack correlation, AIOps can become severely limited,” he said. “The lack of those features have become the big elephant in the room that everyone is not addressing, and it’s holding back the advancement of AIOps and machine learning for many companies.”

    Simply put, when AIOps is not fully deployed, important insights may go unnoticed and leads to data remaining in silos. “Companies are getting all this data, but it’s not being properly processed and correlated, and it’s going to waste,” he said.

    It is those types of deployment issues that are lending credence to AIOps not being as effective as promised. “AIOps is a multi-layered platform whose capabilities should include efficient data collection at big data scale, correlation across the collected data, machine learning, analytics and visualization,” said Bishnu Nayak, FixStream CTO.

    Businesses discouraged by the initial ROI of AIOps should take a long, hard look at their implementation strategy and take into consideration what their data sources are and how they are applying analytics, Nayak said. “Done right, an AIOps implementation can lead to a decreased mean time to remediation and better proactive problem-solving. By increasing system availability and responsiveness, AIOps can enhance your digital business operations and improve profitability.”

    — Frank Ohlhorst

  • 5 Ways DevSecOps Can Manage Software Supply Chains

    5 Ways DevSecOps Can Manage Software Supply Chains

    The unbridled use of open source components within the software supply chain is on a major uptick, according to new research. Even as this surge in open source dependencies fuels faster innovation, the study shows that it comes with high cybersecurity costs, as the number of breaches related to these components is similarly on the rise.

    However, the numbers also indicate there are some clear practices used by the best DevSecOps teams to minimize the risk while maximizing the speed and agility that third-party components offer.

    Sonatype and research partners from IT Revolution and Galois made a thorough analysis of download patterns, software component makeup and DevSecOps behaviors around open source components and third-party libraries for the “2019 State of the Software Supply Chain Report.” Their analysis found that the rate of open source component releases has picked up by 75% in the last two years and that download requests from teams using these components have risen 68% year over year.

    Most tellingly, the study showed that among modern applications today, 85% of the average code base is comprised of open source componentry. Not only are the majority of applications using open source components and libraries, but also they depend on them heavily.

    “The practice of assembling open source component releases into the form of an application screams of efficiency. Developers no longer need to code every line from scratch,” according to the report. “Developers can download component releases in seconds that deliver new capabilities, built by experts outside of their organizations who make their code freely available to others.”

    Perhaps not coincidentally, the study noted a parallel rise in breaches associated with open source component use. Last year 1 in 4 organizations suspected or verified they experienced a breach related to open source components in the last 12 months. That’s a slight improvement over last year’s stats, which had it pinned at 1 in 3 organizations. But since 2014, that rate of breaches has risen by 71%.

    The trouble is, many of the components developers download and integrate into their code are full of dangerous vulnerabilities. For example, just over half of all JavaScript package downloads contain known vulnerabilities, with 1 in 3 rated as high vulnerabilities. One in 10 of those flaws were rated as critical.

    The point the report hammered home is that not all components are created equally. There exists a certain class of well-run open source projects that release updates more frequently, update problematic vulnerabilities faster and remediate flaws more quickly. It is up to DevSecOps teams to systematically manage components, so they leverage more of these high-quality open source projects and try to avoid the riskier open source dependencies.

    “Management of software supply chains is not simply ensuring quality at velocity. Our supply chains are being attacked by adversaries in new and creative ways,” according to the report. It found that organizations that actively manage their supply chains are able to reduce the proportion of vulnerable components by 55% compared to those who do not.

    The report found several software supply chain practices contributed to this reduction of risk, with the following five standing out as the most impactful:

    Develop a governance program: Foundational to this is having some sort of open source governance or standards policies in place, according to the report, which noted that among the best DevSecOps organizations at managing risky components, nearly 3 in 4 have such policies in place.

    Have a process for evaluating and adding new components: As a part of that open source policy, the best teams have standardized processes for how developers add new open source components. This includes how these components are evaluated, approved, standardized and so on. The exemplary organizations are 11 times more likely to use this kind of process for new dependencies.

    Proactively remove problematic components: New vulnerabilities are discovered every day, so simply evaluating a dependency upon its first inclusion in an application can only take an organization so far. The best organizations also take the initiative to look for potential sources of open source vulnerabilities in existing code. That includes proactively seeking out and removing known vulnerable dependencies, as well as reducing the attack surface of the code by eliminating open source dependencies that aren’t being used. The best organizations are 9.3 times more likely to do so.

    Aim to always use the latest versions of components: It should go without saying that the latest version of any given component has the least vulnerabilities. The report showed that component releases that are 3 years or older have a 65% higher defect rate compared to newer components. Exemplary organizations strive to use the newest updates of all of their open source components and are 6.2 times more likely to do so than other organizations. That doesn’t happen accidentally—these teams are 10 times more likely to schedule update dependencies as part of the daily work of DevSecOps teams.

    Use Enforcement Automation: Just having a policy in place is not enough—organizations need to enforce the open source standards to reduce risk meaningfully. The study showed that DevOps practices combined with automated enforcement of policies increase developer adherence to standards by 150%. The exemplary teams with the lowest open source defect rates are 12 times more likely to have automated tools to track, manage and/or ensure policy compliance of open source dependencies.

    All of these best practices add up to less risk from components, as well as less pain for DevSecOps teams, who are three times less likely to consider the process of updating components as painful.

    — Ericka Chickowski

  • DevOps Chat: Global Intelligence for AWS GuardDuty, With Sumo Logic

    DevOps Chat: Global Intelligence for AWS GuardDuty, With Sumo Logic

    Wouldn’t it be helpful to know if other cloud users are seeing the same or similar attacks that you are? Security intelligence about cloud applications beyond just those you own and operate as an enterprise opens up a new dimension in attack visibility against even large sets of cloud apps.

    During AWS re:Inforce 2019, Sumo Logic announced it is extending its machine analytics and intelligence platform to include AWS GuardDuty. Dubbed Global Intelligence Service for Amazon GuardDuty, the new service is more than just a data aggregation and reporting play. The new service provides additional context around GuardDuty data by reporting attack information across multiple Sumo Logic customers using AWS GuardDuty. Essentially, it’s a “crowdsourcing” approach to reporting threat intelligence across the cloud.

    In this episode of DevOps Chat, David Andrejewski, senior engineering manager at Sumo Logic, joins us to talk about this new, more expansive threat intelligence service. More information about Global Intelligence Service for Amazon GuardDuty is available in the press release and website.

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

    Transcript

    Mitch Ashley: Hi, everybody, this is Mitch Ashley with DevOps.com, and you’re listening to another DevOps Chat podcast. Today, I’m joined by David Andrzejewski, Senior Engineering Manager at Sumo Logic, and our topic is a real meaty one—Global Intelligence Service for Amazon Guard Duty. David, welcome to DevOps Chat.

    David Andrzejewski: Thanks so much. Thanks for having me on.

    Ashley: Well, we really appreciate you being on the podcast today. Would you start by introducing yourself, just tell us a little bit about what yourself and what you do at Sumo Logic, and maybe just a brief overview of Sumo Logic the company?

    Andrzejewski: Yeah, fantastic. So, Sumo Logic, what we offer is a cloud-based machine data analytics platform, which is a bit of a mouthful, but what that specifically means is a cloud-based, multi-tenant service where you can send your logs and metrics and data to our service for helping you monitor, troubleshoot, and secure your applications, platform, environment, infrastructure for your own application or your IT infrastructure.

    So, we offer this as a kinda cloud-based web app service. The idea here is, you’re sending us all of that data and we can kind of manage the scale, reliability, and analysis for you and kinda help you focus on running your business and kind of running your app and everything like that.

    Specifically at Sumo Logic, I manage the Advanced Analytics Team, and we’re focused in particular on ways that we can do especially kind of useful or interesting things to help customers get more out of their data. So, some of the features in the past we’ve worked on are log reduce, which kind of applies clustering techniques to your logs to kind of give you a more comprehensible snapshot as well as outlier detection and things like this. But our current focus right now is this kind of Global Intelligence Service that we’re really excited to be announcing at AWS Reinforce.

    Ashley: Great. Well, we are a DevOps and also a security podcast—talk a little bit about how Sumo Logic fits into the DevOpsSec world.

    Andrzejewski: Yep, absolutely. So, ultimately, in any of these situations, you really need some kind of—you need the ground truth actual data to really kind of know what’s happening in your environment, both from what kinds of experience are your customers getting, how is the, kind of the health of your machines or what resources are available, what is the performance of various services, you know, events are being kind of logged and audited and then you’re kind of pulling data together from all up and down the stack into one place.

    And that’s kind of where we come in as sort of one kind of one-stop shop for sending all of these very kind of heterogeneous logs into one service such that the teams that are responsible for up time from kind of a DevOps SRE perspective and security from all sorts of aspects of that, which increasingly is, like you said, kind of this DevSecOps. The developers themselves are often increasingly deeply involved in all of that, where they can kind of pull together the data from their own kind of custom application logs, the infrastructure, the actual machines, the operating system, the firewall, the databases, the third party services and kind of have it all in one place so that when you can sort of help detect when things do go wrong and then kind of identify, dig in, troubleshoot what’s going wrong and then once you fix it, you know, verify that it actually is corrected.

    Ashley: Mm-hmm.

    Andrzejewski: So, you would interact with the service by sort of operating queries against your data, creating dashboards and visualizations and using these dashboards or potentially setting up alerts to notify members of your team that some condition has been triggered that requires immediate attention or action to generate sort of scheduled kind of reports on these kinda things and in general, kinda analyze and interact with the data, the raw data being kind of sent out by your software, your machines and everything like that to really understand what’s going on in your app.

    Ashley: And are you oftentimes the system in the SOC, or do you connect into a different monitoring system, alerting system in the SOC?

    Andrzejewski: So, this is kind of a—as far as the SOC aspect, some customers are kind of using it for tracking these different kind of logging events, others are sort of, we have a lot of kind of integrations with other services to kind of consume data kind of emitted by those services. So, for example, AWS Guard Duty, you know, alerts like that.

    So, it all kinda depends on, there’s sort of a wide variety of ways that customers have kinda made use of Sumo Logic. So, yeah, in some cases, I think that that’s a reasonable use case that the [Cross talk]—

    Ashley: It’s probably, I imagine, where they’re starting from if they have systems all ready for you to integrate in, or maybe you become the main single pane of glass, if you will.

    Andrzejewski: Yeah, so, in the security use case, I think—again, it depends on kind of which sort of person within the organization might be most interested in that. Developers often, you know, given that this is a place, a single sort of solution that you can collect the logs for both these kind of monitoring SRE troubleshooting as well as some of the security use cases.

    Ashley: Mm-hmm.

    Andrzejewski: That ends up being kind of an appealing property that you can kind of have one service to collect the data, analyze the data for various use cases, right?

    Ashley: Okay, great. Well, this is the week of AWS Reinforce, and I feel like we’ve kind of laid out enough teasers about your announcement that you’re making this week. [Laughter] Tell us about Global Intelligence Service for Amazon Guard Duty.

    Andrzejewski: Yeah, yeah, we’re really excited about this. So, the basic idea here is that we’re going to add some additional context around the Guard Duty alerts where we can essentially take your alerts and kind of recontextualize them in terms of how frequently we’re kind of seeing them or they’re being sent or observed across others.

    So, if something is a very kind of rare threat that very few other organizations are kind of getting, seeing in their environment, then that might be something that you would want to prioritize more highly, right, if you are—you know, there’s going to be some, in any kind of alerting system like Guard Duty or others, there’s often going to be a very kind of high just baseline of sort of very generic, general threats that everybody kind of sees at some base rate all the time, and this is kind of one way that you can sort of kind of do some noise reduction on those and really kind of prioritize and focus on the ones that are a little bit more idiosyncratic or unique to your environment and more, perhaps more interesting and more relevant for kind of immediate investigation and triage.

    And this is kind of being exposed to the customers via an app, which is kind of, in the Sumo Logic scenario, it’s kind of some pre-defined analyses and dashboards against your Guard Duty data. So, your customer would sort of consume this service by installing the new Guard Duty with Global Intelligence Services app, and they would immediately get access to these new visualizations, analyses, and dashboards that kind of place their own Guard Duty alerts in this modified context, this more—you know, bringing in a little bit broader information about how often these are being seen in other environments, what are the general most common threats, threat purposes, various threat types seen across sort of the general customer population at Sumo Logic.

    And this will sort of kind of serve these multiple purposes for the user—on one hand, helping you kind of prioritize rare events, on the other hand, kind of giving you sort of this bird’s eye view survey of what’s generally out there, right? And that can help potentially in prioritizing or allocating efforts at improving your own security posture or efforts in, for example, you see that a particular kind of threat is especially prevalent, you know, elsewhere, that might be something that you say, “Okay, well, what do we have to be doing to make sure that we’re, our bases are covered with respect to that ourselves,” right?

    So, ultimately, we want to kind of show you your AWS Guard Duty threat data, but in this kind of enhanced context that’s hopefully going to be more meaningful and more relevant to you and help you make better decisions and kind of run your business more securely.

    Ashley: Okay, so, the benchmarking aspect of this, is that something that happens in real time? You know, we’re looking at the console, we’re getting alerted to say, “This attack is happening, and by the way, it’s happening on 20 percent of the other AWS customers” or however your present it, or is it more a retrospective looking at past data of what’s occurred over the last month, last quarter, last year? Or is it both?

    Andrzejewski: Yeah, so, this is something that we’re kind of, in some sense, as we are having conversations with customers, seeing what’s going to be most valuable for their use cases. Right now, the real time—is it real time, like, up to the second? You know, is that really something that’s going to be valuable, or is that going to be kind of too noisy of a signal?

    Ashley: Mm-hmm.

    Andrzejewski: So, right now, it’s derived from sort of recent history in some sense, and yet, potentially, that’s an interesting question of whether more very long term stuff, like, month over month is going to be useful for people, but you know, is it—right now, we’re not kind of focused on the use case of, you know, up to kind of real time real time.

    Ashley: Mm-hmm.

    Andrzejewski: Really, your data will still be real time, real time, but the question of whether that’s—you know, does the context need to evolve that quickly, or is that just going to kind of introduce more noise?

    Ashley: Right.

    Andrzejewski: Part of the advantage of kind of using a little bit of a recent historical window is looking at—you know, it gives you a little bit broader pool of data to kind of contextualize your real time activity against, right? So, again, it’s all about sort of your data and kind of seeing how—you know, how it kind of looks in context of this broader view and evolving the broader view in real time. It’s an interesting thought.

    Ashley: Well, that makes sense, too, because you may be having a false positive or something. Not everything that is being highlighted by Guard Duty might be as relevant as other things, so if you have a chance to filter some of that information out to say, “This is what’s relevant” versus, if everything’s real time, you could introduce some noise, maybe some things that aren’t as helpful, too.

    Andrzejewski: Yep. Yeah, exactly. So, it’s—that’s definitely a potential tradeoff, there.

    Ashley: So, what would you learn—because now, there must be some kind of an opt-in where you’re looking at events that are happening across different customers, AWS users—what would you learn by knowing that a whole other population of people are seeing this same kind of attack versus if you were only looking at your data, if you had known that you would do something differently?

    What would be a scenario like that where this would be super helpful?

    Andrzejewski: Right, so, the—you know, one kind of particular case sort of going the other way of a rare event might be that, you know, again, so, some of these threats are going to be very kind of common, and it ends up that that’s not something quite as potentially actionable or something that you need to jump on right away, but there’s still kind of part of your Guard Duty feed and they’re going to kind of potentially be a little overwhelming when you’re looking at everything. Whereas this more kind of like rare threat type, this—by kind of knowing, “Okay, this is a little bit out of the ordinary in that lots of customers are not seeing this,” that kinda helps it pop to the top of your queue and maybe you are going to allocate your very limited time and attention to focus on that.

    It might be a little more challenging to prioritize or see that kind of rare event pop, because you don’t necessarily know that it’s rare, you just sort of see it amongst all of the other kind of more common alerts and more common threats.

    Ashley: Right. This is a rare event, something that’s unusual, you should take a look at this versus something that’s happening normally across multiple AWS accounts.

    Andrzejewski: Exactly. That’s exactly right. And so, that potentially becomes a valuable tool to kind of—like I said, ultimately, teams everywhere are ultimately struggling with the scarce resource of your time and attention.

    Ashley: Mm-hmm.

    Andrzejewski: And anything that can kind of bring in some additional context information to help you allocate that time and attention more efficiently, more effectively is potentially, hopefully going to give some good value for our customers.

    Ashley: Well, many resources are precious resources, and certainly security folks are definitely in that precious category. So, being able to assign them to something you know is something we need to look at versus kinda chasing things that we really don’t need to be paying attention to would be super valuable.

    Andrzejewski: Absolutely.

    Ashley: So, obviously, Sumo Logic does a lot of other things in your products. You have operational analytics, business analytics, those kinds of things. Does this Global Intelligence Service tie into those in some way, to give you some additional broader insights, or this focused really—just really heavily on the security aspect of what’s happening in Guard Duty?

    Andrzejewski: No, absolutely—that’s a really good point. So, right now, kind of, very sort of aligned with Global Intelligence is some of the stuff that we’ve been doing a few years now around the modern app report and similar where kind of giving these sort of horizontal views of technology choice trends and various kind of software choices, infrastructure, cloud provider choices, kind of adoption of various tools and technologies across the industry, and that definitely kind of extends into the, kind of the DevOps SRE space. And again, hopefully the idea there is that these tools kinda give you this sort of broader context about actual hard data where various—you know, where the market in general is on their journey to cloud adoption or their migration to Docker or Kubernetes or other kind of related technologies.

    Ashley: Mm-hmm.

    Andrzejewski: So, that’s one place where there’s already something in place at Sumo Logic that’s kind of bringing that broader sort of horizontal context to bear to kind of help teams kinda make more effective, more informed decisions and, again, prioritize and allocate their attention and efforts in kind of using that extra information to kind of know, actually, from the hard data where others are actually at.

    Ashley: Mm-hmm.

    Andrzejewski: So, right now, this particular announcement at AWS Reinforce is focused on Global Intelligence Services for AWS Guard Duty in particular which, as you said, is absolutely a very kind of security focused use case.

    Ashley: Mm-hmm.

    Andrzejewski: But in general, the general sort of Global Intelligence Services, you know, kind of platform and approach is something that we’re also actively thinking about how can we help in the operational analytics use cases? Where are there places where that broader context is going to help our customers make better decisions or solve their problems more quickly?

    So, right now, we have this Guard Duty announcement, definitely focused on security, but in general, we see Global Intelligence Services as a very powerful kind of horizontal enabler across the SRE DevOps kind of side of the house as well.

    Ashley: Mm-hmm. Yeah, it seems like an area that would be ripe for machine learning—yeah, the statistical analysis that you could do across multiple areas of the analytics that you’re doing. You know, that’s what data’s all about, right? What insights and learnings can you get from that that brings additional value benefit to the business?

    Andrzejewski: Definitely, yep.

    Ashley: Well, good. Is this product available now? Is it coming out some time down the road? How soon can we get our hands on this?

    Andrzejewski: So, as of the kind of announcement, it should be available to Sumo Logic customers at the enterprise level, and again, it would be a matter of installing the app and kind of start—obviously, in this case, you would need Guard Duty as well. I can provide some links to go out with this, if that’s helpful—

    Ashley: Sure.

    Andrzejewski: – that would have kind of links to the specific resources that would be involved in getting started and getting set up with this, but yeah.

    Ashley: Okay, great. It sounds like a pretty easy thing to do to get started. If you’re already running Sumo Logic, installing the app is not a heavy lift, it’s pretty straightforward.

    Andrzejewski: Absolutely. And the other aspect, of course, having Guard Duty in place as well. Which, again, is—in the links I’ll send, should be, is a pretty painless process.

    Ashley: Excellent! I also want to mention, too, that Sumo Logic is located in Booth 714 at the Reinforce conference. So, definitely recommend folks stop by and maybe see a demo of this, get to talk with folks about the new announcement.

    Well, our podcasts have no problem flying by quickly, because we talked about great things and I appreciate you doing that with us. David, I’d like to thank you, David Andrzejewski, Senior Engineering Manager at Sumo Logic, for joining us.

    Andrzejewski: Well, thank you so much for having me. It’s been a really great conversation—super, super interesting to talk about.

    Ashley: Great. It’s good stuff, and I wish you and Sumo Logic the best at the show this week.

    I’d like to also thank you—you, our listeners—for joining us. This is Mitch Ashley with DevOps.com, and you’ve listened to another DevOps Chat. Be careful out there.

    — Mitchell Ashley

  • DORA Adds to DevOps Brain Trust

    DORA Adds to DevOps Brain Trust

    I am super excited to announce that Jessie Frazelle is joining the DORA team this year as an author on the “Accelerate State of DevOps Report.” I am a big fan of hers and we are all thrilled to be working with her. For those of you not familiar with her work in containers and security, she wrote a blog post to introduce herself. ~Nicole

     

    Hello! 👋

    I am thrilled to join as a co-author of this year’s “Accelerate State of DevOps Report.” For those who might not know me: I have worked as an engineer on container technologies and ran containers in production since Docker was at version 0.4. Before that I worked at a bunch of different startups as an engineer. I have been a long-time reader of the State of DevOps Report and jumped at the chance to get to work on it this year. It’s an amazing team of people!

    Each year I have admired the report for its insight and intuition backed by data. This year, I am excited to add my experience in open source and perspectives from working at various companies both large and small. Open source is very near and dear to my heart and I think a lot of the insight gained from the report can also be applied to open source projects to make contributors more productive. Through various jobs over the years, I have seen a lot of different DevOps practices at many different scales and I am looking forward to applying my perspective from those experiences as well.

    As someone who has been an engineer for more than a decade, I find the study of high performers in organizations fascinating. Personally, when I put my full-effort into something I am building, it comes from a place of caring. The link from culture and a strong mission to outcomes, as seen in past reports, falls in line with a lot of my experience. I can see myself using this year’s report a lot in future conversations to show something I know is true and is also backed by data—I can’t wait to share what we’re finding!

    Lastly, I love how the State of DevOps Report focuses on outcomes, not whatever is the latest hype or argument between thought leaders on the internet. Getting companies to a place where they can make changes and ship features faster, safer and more securely is a noble mission! I can’t wait for you to get your hands on this year’s report!

    Best,

    Jessie

    — Jessie Frazelle

  • Linus Torvalds Sees Lots of Hardware Headaches Ahead

    Linus Torvalds Sees Lots of Hardware Headaches Ahead

    Linux founder Linus Torvalds, today at the KubeCon + CloudNative + Open Source Summit China conference, warned attendees that managing software is about to become a lot more challenging, largely because of two hardware issues that are beyond the control of DevOps teams.

    The first, he said, is the steady stream of patches being generated as new cybersecurity issues related to the speculative execution model that Intel and other processor vendors rely on to accelerate performance. That model is the root cause of malware such as Spectre and Meltdown that have roiled the IT industry. Additional bugs in speculative execution with colorful names such as Fallout and ZombieLoad are showing up more frequently. Each of those bugs requires another patch to the Linux kernel that, depending on when they arrive, can require painful updates to the kernel, Torvalds told conference attendees.

    Short of disabling hyperthreading altogether to eliminate reliance on speculative execution, each patch requires organizations to update both the Linux kernel and the BIOS to ensure security. Turning off hyperthreading eliminates the patch management issue, but also reduces application performance by about 15 percent.

    The second major issue hardware issue looms a little further over the horizon, Torvalds said. Moore’s Law has guaranteed a doubling of hardware performance every 18 months for decades. But as processor vendors approach the limits of Moore’s Law, many developers will need to reoptimize their code to continue achieving increased performance. In many cases, that requirement will be a shock to many development teams that have counted on those performance improvements to make up for inefficient coding processes, he said.

    In the meantime, Torvalds noted updates to the Linux kernel are still coming at a rate of every three months, and the Linux team is basically working on a six-month planning cycle—there is no master five-year plan the Linux team is working from. Roughly 1,500 developers work on contributions to the Linux kernel, with 100 maintainers overseeing the implementation of those contributions.

    Naturally, cybersecurity patches at the kernel level have significant implications for all of DevOps. Changes to the kernel need to be absorbed by all the various distributions of Linux, which in turn impacts all the stacks of software that depend on Linux. Jim Zemlin, executive director for The Linux Foundation, said that in the wake of the rise of these hardware issues and previous cybersecurity issues involving open source software such as the Heartbleed vulnerability, cybersecurity is the top priority for The Linux Foundation. As part of that effort, The Linux Foundation is researching various DevSecOps approaches to better securing the global open source supply chain, he said.

    In the meantime, organizations large and small alike will need to up their DevSecOps game significantly if they want to continue to push application performance limits.

    — Mike Vizard

  • 27-Factor Assessments Lead to Success With DevOps

    27-Factor Assessments Lead to Success With DevOps

    October 2019 will mark the 10th anniversary of the first DevOpsDays, where the term “DevOps” began to catch on. In the world of information technology, 10 years is a long time and it is quite evident based on the amount of change that has transpired since then. To name a few, we have seen the maturing of CI/CD automation and many innovations such as application release automation, containers, cloud infrastructure orchestration, DevSecOps, DevOps database, DevOps governance and micro-services.

    These innovations have become part of “mainstream DevOps.” This evolution is continuing with AIOps, machine learning, value stream management and others. Each of these innovations has made DevOps not only more powerful but also more complex.

    As a consultant working on DevOps projects through their life cycle, I have learned that complexity can plague the success of DevOps within an organization. Complexity cannot be avoided, as DevOps is complex and will likely continue to be. However, the key to avoiding failure through your DevOps journey is to engage the complexity by using DevOps tenets to implement DevOps. Do not try to boil the ocean. Instead, at each leg in the journey, take inventory of where you are in terms of current goals, state and best practices. Fine-tune your direction and build your solution using proven continuous delivery methods.

    The 27-Factor Assessment Model

    A comprehensive yet efficient assessment of your current state is key for ensuring complexity has not gotten out of hand and the organization is focused on success criteria that meet the needs of the business.

    I use a 27-factor assessment model. The factors are the cross-product of current best practices for three dimensions (people, process and technology) with nine pillars.

    A Scope of the 9 Pillars

    Leadership: Gain insight and understanding of your leadership practices and how leadership can improve DevOps adoption and performance.

    Culture: Identify opportunities to improve cross-functional collaboration and communication across your organization.

    Application Development (or Design for DevOps): A practical analysis of application development practices identifies improvements for your DevOps performance.

    Continuous Integration: Analysis of branching and software integration workflows and tools identifies bottlenecks and improvements for builds and packaging processes.

    Continuous Testing: Analysis of end-to-end software testing, verification workflows and tools identifies bottlenecks and improvements for accelerating testing while improving the coverage and quality of tests.

    Infrastructure on Demand (or Elastic Infrastructure): Analysis of systems and services for orchestrating and hosting applications and DevOps workloads provides insights to improve performance and utilization of resources.

    Continuous Monitoring: Analysis of end-to-end monitoring workflows and tools for applications, releases metrics and infrastructure provides improved visibility for all business and technical stakeholders.

    Continuous Security: Analysis of security practices and tools identifies opportunities to integrate security practices into the continuous delivery pipeline.

    Continuous Delivery/Deployment: Analysis of delivery and deployment practices identifies improvements for safer, faster and more efficient releases.

    Each combination of pillar and dimension has associated best practices used to score relevance and current state relative a DevOps goal agreed by the organization. Here is an example of the continuous security pillar.

    The 27-factor assessment for an application is an important input to a future state value-stream map workshop. The value-stream map is then transformed into a road map and implementation plan.

    This assessment approach is thorough and yields results that are usually accepted by stakeholders because they are involved in the process at each step. The result is aligned to their priorities and goals and the solution road map is directly traceable to stakeholder inputs. The approach is flexible enough to evolve over time and can be customized to suit the priorities of an organization. For those that argue that 27 factors are too many and too complex, I must say the complexity of DevOps itself requires a comprehensive assessment approach.

    Conclusion

    In this article, I described a comprehensive, efficient and evolvable assessment approach that uses 27 critical success factors for assessing DevOps applications. While DevOps offers immense value for software development, delivery and deployment, a rigorous and thorough assessment with up-to-date best practices are essential to accomplish DevOps goals. Each organization is different and has different DevOps goals and requirements. The changes to the three dimensions vary according to the results of each DevOps assessment.

    — Marc Hornbeek

  • Agile Stacks Extends Reach of DevOps Automation Platform

    Agile Stacks Extends Reach of DevOps Automation Platform

    Agile Stacks this week announced it is extending the reach of its namesake DevOps automation platform to Kubernetes and additional cloud services.

    Company CEO John Mathon said that by extending the reach of the company’s platform to include Google Cloud Platform (GCP), Microsoft Azure and Red Hat’s OpenShift distribution of Kubernetes alongside existing support for Amazon Web Services (AWS), Agile Stacks will make it easier for organizations to implement best DevOps practices across hybrid cloud computing environments.

    Agile Stacks made the announcement at the HPE Discover 2019 conference. The company counts Hewlett-Packard Enterprise (HPE) among its investors, and at the conference this week, HPE this week outlined how Kubernetes is core to the company’s evolving hybrid cloud computing strategy.

    Mathon said the Agile Stacks platform provides a framework for automating the creation of DevOps pipelines across multiple tools and continuous integration/continuous deployment (CI/CD) platforms. In all, there are more than 80 DevOps tools and platforms available in the Agile Stacks Service Catalog, including Kubeflow, Jenkins, GitLab, Spinnaker, Harbor, Minio, Ceph and Portworx.

    At the core of the Agile Stacks platform is a SuperHub automation hub, which accelerates software delivery based using a set of custom composable stacks that can be configured by the DevOps team. Each component of a stack is auto-configured to deploy, upgrade, rollback, promote, clone, backup, generate test scripts, perform merges, conduct performance testing, scan for vulnerabilities and execute functional testing.

    In effect, Mathon said Agile Stacks is essentially automating the DevOps automation. Organizations that have embraced best DevOps practices tend to rely on multiple tools from different vendors, which inevitably leads to silos of automation that often work at cross purposes. Agile Stacks provides an extensible GitOps framework for integrating all those tools that enable organization to evolve more easily as their DevOps processes mature, added Mathon.

    In addition, he said Agile Stacks expects to play a role in making DevOps more generally accessible by reducing the complexity organizations initially encounter when trying to embrace DevOps practices.

    As hybrid cloud computing starts to become more commonplace, thanks in part to the rise of Kubernetes, Mathon said DevOps complexity is only likely to increase. Organizations have made it clear they want to leverage multiple clouds alongside their existing on-premises IT environment. Right now, however, the DevOps processes associated with each of those platforms is, at best, fragmented. In addition to making it easier to unify DevOps processes across multiple platforms, Mathon noted Agile Stacks can also enable organizations to keep better track of cloud spending by applying automated cloud tagging via Superhub.

    Of course, most organizations are challenged automating the development and delivery of software on a single platform. However, regardless of how far down the path any organization is toward DevOps, the business is moving forward. In many cases, the rise of hybrid cloud computing will finally force many organizations to implement a set of best DevOps process enterprisewide. As part of that process, organizations will look to standardize on a specific set of DevOps tools whenever possible, or at least until developers discover the latest DevOps tool to supplant all others.

    — Mike Vizard

  • 4 Traits of High-Performance Digital Leaders

    4 Traits of High-Performance Digital Leaders

    Businesses that have retooled their culture, their hierarchy and their business mindset toward the use of technology are consistently outperforming their more traditional peers. According to the newly released Harvey Nash/KPMG CIO Survey 2019, digital leaders are the top 30% of businesses that are extremely effective at leveraging digital capabilities to advance their business strategy. The survey showed that digital leaders are beating the competition more handily than their cohorts on some of the most important business metrics followed by CEOs, including time to market, customer experience, response to change and profitability.

    As the report explained, organizations don’t spontaneously become digital leaders and they don’t create their success by “pedaling harder in their traditional IT function; in fact, for many organizations the concept of a traditional IT department is an anathema to them.”

    The study showed that organizations that have established themselves as digital leaders tend to have incredible support and commitment from the top of the food chain. Whereas only about 58% of CEOs at most other firms want their technology projects to make money versus save money, 78% of CEOs at digital leaders see technology capabilities as their proverbial goose laying golden eggs. In the same vein, digital leaders are also much more likely to have a top technology leader—be it CIO or chief digital officer—reporting directly to the CEO and sitting on the executive team.

    “There is a chicken and egg question–is the technology leader influential in these enterprises because the board supports them, or does the board support them because they are influential in their own right?,” ruminated report authors on the board access and influence that CIOs have at digital leader organizations. “The truth is, it’s probably a mixture of both.”

    Regardless of how that relationship evolved, the tone from the top is helping digital leaders to hone themselves through some common winning practices and modes of operating. The report found that these organizations tend to exhibit four common traits, many of which have significant cross-over with the practices and principles of technology organizations that have embraced DevOps transform their IT delivery models:

    An Emphasis on Modern IT Delivery Speeds

    In fact, one of the most stark differences between digital leaders and everyone else is that they are far more likely to have leveraged DevOps to accelerate innovation. The study showed that these organizations are more than three times as likely to use agile or DevOps methodologies enterprisewide to speed up feature delivery. What’s more, digital leaders are also fully buying into the old DevOps ethos of innovating fast and failing faster. Digital leaders are similarly almost three times as likely to pivot quickly from small experiments, scaling up quickly on success or stopping quickly on failure of these small pilots.

    Strong Business-to-IT Collaboration

    “Digital leaders are swapping control for influence and investing time in business relationships,” according to the report.

    The report showed that whereas only about 18% of most traditional technology functions work collaboratively with business leaders to deliver technology change, that spirit of cooperation is alive and flourishing at 54% of digital leaders. In fact, technology executives at digital leaders are less likely to look down on business-driven spend as rogue or shadow IT, but instead as business-managed IT that’s sanctioned and even encouraged. At the same time, technology decision-makers are more likely to influence and govern these business-managed IT decisions than at other organizations.

    Focus on Value Rather than Technology

    The report showed that digital leaders have an “expansive mindset,” meaning that they’re much more likely to think of technology in a big-picture way. So they look at technology delivered as long-term products rather than short-term projects. And success is not viewed through traditional technical SLAs, but instead “… through the lens of business performance, often tied to measures like customer or employee experience, lifetime value, loyalty, uptake and time to market.”

    Additionally, this expansive mindset combined with high levels of collaboration with the business has most digital leaders putting together cross-functional digital teams that combine IT and business staff. These organizations are three times as likely to invest in training non-IT people in IT skills.

    Fanatical About Data

    Finally, all of that experimentation and work is driven by data. The report showed that “data is at the heart” of digital leader organizations. Digital leaders are more than three times as likely to maximize the value of all of the data they hold, and almost four times as likely to maintain an enterprisewide data management strategy than other organizations.

    This use of data is helping them provide business leaders with actionable customer insights, to improve operational efficiency and to get a better line on risks and opportunities the business will face in the future.

    “Digital solutions are the oxygen that allow a business to breathe and run at market speed,” said Steve Bates, global lead of the CIO Advisory Center of Excellence at KPMG. “This year’s survey provides compelling evidence of the transformational progress digital leaders are making. It is up to the rest to catch up and join them.”

    — Ericka Chickowski

  • DevOps Chat: ‘War, Peace & IT’ With Marc Schwartz

    DevOps Chat: ‘War, Peace & IT’ With Marc Schwartz

    Marc Schwartz is one of those rare individuals who is not only a great IT exec, but he also can analyze what works and doesn’t work and write it up in a way that helps others. His “A Seat at the Table” is still one of my favorite DevOps books.

    Marc’s new book is called, “War, Peace & IT.” You can download an excerpt of it here: dl.orangedox.com/WarPeaceITExcerpt

    In this DevOps Chat, we speak with Marc about the book and some of the lessons behind it. Have a listen and check out the book ASAP.

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

    Transcript

    Alan Shimel: Hey, everyone, it’s Alan Shimel for DevOps.com, and you’re listening to another DevOps Chat. I’m really delighted to have as my guest on DevOps Chat today none other than Marc Schwartz. Marc, if you don’t know, is an AWS executive, multiple author on some of the greatest books on DevOps you’re gonna read—”A Seat at the Table” is still one of my all-time favorites—and I think as he’s described in the latest blurb on IT Revolution, an iconoclastic CIO.

    Marc, welcome to DevOps Chat.

    Marc Schwartz: [Laughter] Thanks. I’m glad to be here.

    Shimel: So, Marc, what is an iconoclastic CIO?

    Schwartz: [Laughter] I like to question assumptions. You know, I find that, very often, people are frustrated. There are obstacles to what they’re trying to accomplish, and the problem is that they’re constrained in all sorts of ways, and if you don’t question the assumptions and knock away some of those constraints, they’re gonna continue to be frustrated—so, that’s what I’m all about.

    Shimel: Yep. I agree. So, I don’t want to spend a lot of time, but Marc, we mentioned you’re from AWS, but I didn’t really mention a role. Just so our audience, who may not be familiar—what currently is your role with AWS?

    Schwartz: They call me an enterprise strategist, and what means is, I’m part of a small team of ex-IT leaders, many of us ex-CIOs or CTOs of large enterprises who did digital transformation, moved to the cloud, and what we do now is, we work with executives from large enterprises to help them overcome some of the challenges that they face as they’re trying to do a transformation.

    So, often, it’s things like cultural change, or organizational change, or organizational structure, financing models, people skills, things like that. And we speak at conferences, we write books and blogs and we work with individual customers.

    Shimel: Very cool. No, let’s jump in, Marc. You’ve got a new book, just recently came out. It’s available on Amazon, by the way, in case anyone is interested, as well as Barnes and Noble, 800-CEO-READ, Indiebound, BAM and any other place where you can find decent books. It’s called “War and Peace and IT: Business Leadership, Technology, and Success in the Digital Age.”

    Marc, share with our audience—what’s the book about?

    Schwartz: Well, the book is essentially an answer to a challenge that people gave me after they read “A Seat at the Table.” Because, in “A Seat at the Table,” it was written primarily for IT leaders, and throughout that book, I made the argument that we needed to get rid of this business versus IT distinction, you know? The way we talk about the business and IT as if it’s two separate things, the way that we see IT as taking requirements from a business and executing on those requirements, but that way of thinking is no longer effective. We need to find a way to bring IT into the business itself.

    And people responded very well to that message in “A Seat at the Table,” but they said, “This doesn’t work unless somebody tells the business folks the same thing, you know? [Laughter] We can’t just change the relationship ourselves. So, somebody should write a book for the business executives to explain to them what you’re talking about.” And I realized that that same book, if I could write it, would also help a lot of the executives that I was talking to as part of my job who were facing impediments to their transformations.

    So, I wrote a book that essentially said, “One of the big impediments to your transformation is that the relationship between the business and IT is not the right relationship, and here’s how you can change it, and here’s why it will make a big difference for you.”

    Shimel: Excellent. So, you know, I think you laid it out pretty well there, Marc, for people. You know, I’m just back—we were talking offline and I told you I was at a KubeCon + CloudNativeCon in Barcelona last week and it was another great event, 7,500 people.

    And what really kinda hit me square between the eyes was the fact that though this is a fairly technical event, right? We’re talking about cloud native and a lot of open source software programs and ops procedures, the business angle of it, the amount of business people who are there trying to get smart about what’s the latest trends, what’s the wave, if you will, in IT, and how could they leverage things like serverless or Kubernetes and some of these newer things to make their business better, not necessarily because it’s cool or, you know, shiny trinket syndrome or anything like that.

    But really, how does—when does rubber meet the road with this technology? And, you know, I can’t help—I mean, I’m heartened by it, Mark, but I still don’t know if business executives are all bought into that.

    Schwartz: Yeah.

    Shimel: Your thoughts?

    Schwartz: Well, I don’t think it’s about the cloud, per se, or DevOps or whatever it is. What really is important is how the cloud and DevOps and new ways of doing IT empower businesses to do new things that they couldn’t do before. And I think that’s what the non-IT business executives need to learn about what’s possible now that was not possible before.

    And the reason why they have to, why it’s an urgent matter is because their competitors are, you know? Whatever tools you have available to you, your competitors also have, and if you’re not using them, and your competitor is, then you’re at a business disadvantage. And I think mostly, it comes down to a question of speed, one way or another. So, using the cloud well, using DevOps well, lets you move at a much faster pace to get IT capabilities to change your business.

    And that pace is important not just for the obvious reasons that you need time to market, you need to get first mover advantages, you need to respond quickly when you competitors disrupt you, but also for more subtle reasons, because we now use speed as a way to test out ideas quickly and see if they’re gonna work, and manage our risk by testing out ideas before we fully commit to them, and we use speed to get feedback from customers and users and alter our product offerings based on what we’re able to learn, and we use speed to mitigate risk to improve our security posture, to improve our availability of systems.

    So, speed becomes a really important factor, and the cloud, DevOps, you know, their technical implementations, but they happen to help companies achieve speed, and that’s the important message, I think, that executives need to take away.

    [su_pullquote align=”right” class=”do_blockquote”]I don’t think it’s about the cloud, per se, or DevOps or whatever it is. What really is important is how the cloud and DevOps and new ways of doing IT empower businesses to do new things that they couldn’t do before.[/su_pullquote]
    Shimel: I agree. But, you know, there’s an old saying—speed can kill. Great speed kills, too, right?

    Schwartz: [Laughter] Well, if you’re using the right model for speed, it doesn’t kill, and the reason for that is that the models that use speed usually also use automated controls or guardrails. So, what you want, and the idea is, you want to be able to move really quickly, but within the boundaries of guardrails that enforce compliance, enforce security, enforce quality and it’s possible to do both. We always thought, in the past, that there was this trade-off between speed and stability or speed and quality, and it turns out that, in this DevOps world, in this cloud world, speed—increased speed actually increases quality, resilience, availability, security and all of those things. It’s a question of learning how to use speed for those purposes.

    Shimel: Yeah. And that’s really—I mean, tongue in cheek, speed kills. What I was really trying to get at is, speed for speed’s sake alone is, you know, speed has to be wielded—with great power comes great responsibility, right?

    Schwartz: [Laughter] Yes. You have to achieve the speed for competitive reasons and for business model reasons, as I was saying before. So, it’s not really an option, but you do, at the same time, have to learn how to use that speed as a way to reduce risks and improve the quality of what you’re offering.

    Shimel: Exactly, exactly. So, what’s the reception been, Marc? What kind of feedback have you been getting from people?

    Schwartz: Well, the book was just published a couple of weeks ago, really. Where are we? Yeah, May 14th was the publication date, so a couple of weeks. And people seem to be enjoying it. I was a little bit playful in writing the book, and I think there are some aspects of it that are entertaining people, and that makes me feel very good.

    But from the feedback that I’ve been getting, people are seeing it as the successor to that previous book, just as I had hoped. You know, this is the way of looking at a similar message, but very much from the point of view of non-IT business executives. You know, how should the CFO be thinking about the new world, the new digital world, how should a CEO be thinking about it, how should the board of directors be thinking about it? And I’m very happy that people see it as valuable on that front, and a lot of people are saying, “Well, I’m gonna have my entire executive team read this, and it’s gonna stimulate some great discussions,” so I’m very happy about that.

    Shimel: That’s fantastic, great stuff. Let me bring in another aspect of it and get your thoughts on it, Marc. You know, we’ve heard a lot over the last, I’ve heard it maybe over the last year or 18 months—DevXOps, right? We have DevSecOps, DevBusOps, DevHROps—DevWhateverOps, right? DevXOps. And I think there’s a little bit of a reverse equation, here. Business leaders have to be more involved in IT and have to learn how to harness IT to further their businesses’ goals and delight customers, as you say, right?

    At the same time, we can take lessons from IT and things we’ve learned in IT with things like DevOps but not only DevOps. But IT has had, in a relatively short period of time, had a rather torturous road of self-improvement and of learning new things and evolving to things like DevOps that we see. What can businesses do—not harnessing IT, per se, but maybe saving some idiot taxes?

    Schwartz: [Laughter]

    Shimel: You know, from mistakes and lessons learned from IT and apply them to general business?

    Schwartz: Yeah. I think—I also joke about DevOps, DevSecOps, DevSecBizOps, DevSecFinBizOps—you know? You can keep adding to that.

    The real point is cross functional teams, right? DevOps meant we’re gonna have a cross functional team that has dev skills and ops skills, and at some point we realize that that set of skills is not quite enough, they also need to have security skills and you can keep adding to that infinitely, because the bottom line is that functional silos don’t work very well in a fast moving environment like we have in the digital world today. Functional silos slow down your response, they slow down your ability to innovate and grasp new opportunities and respond to change and things like that.

    So, that’s really what was behind the DevOps, DevXOps concept. And I think businesses find this, in general, that when you have functional silos and they operate as silos, you introduce waiting time when you pass things from one silo to another. You reduce innovation because each silo thinks of itself as having its own responsibility instead of joint responsibility for results.

    So, the lesson that I think everybody can take away from what’s happened in IT is that, to respond quickly in an environment where you need to respond quickly, you have to do away with silos and instead focus on cross-functional teams that [Background noise] objective. At least, that’s my biggest takeaway.

    Shimel: Sure, sure. [Background noise] I’m sorry, my machine’s—uh oh, here we go. You know, I’m on my, I’m not gonna give you the brand of the surface I’m on. There’s only one company that makes surfaces.

    Schwartz: [Laughter]

    Shimel: It’s on a roll of reminders.

    Schwartz: Excellent sound effects.

    Shimel: It doesn’t shut up, here. Look at this, this is—

    Schwartz: That’s okay, we could use some background music.

    Shimel: Yeah, I guess so. It’s happening—I don’t know if I like the rhythm, but anyway. [Laughter] So, Marc, a good question is—look, you’re globetrotting around the world evangelizing your AWS role and everything. And yet, you know, over the last, let’s say, three years, four years, you know, this is the third book, actually, isn’t it?

    Schwartz: Yeah. It’s the third one, and I’ve started to work on a fourth.

    Shimel: Can you give us a sneak preview of the fourth, or it’s too premature yet?

    Schwartz: Well, it is too premature. It can go in lots of different directions, but I can tell you what I’m thinking a lot about right now, which is bureaucracy and how to overcome it on the one hand, but even more than that, I think you can harness it in many ways, if you are trying to become a digital organization.

    And, you know, I think that fulfills my role as an iconoclast. I think bureaucracy is one of those words that people have a very strong negative reaction to. But, of course, in my role before AWS as a government CIO, I, of course, witnessed, experienced a lot of bureaucracy and developed strategies for coping with it that I think would be useful to a wide audience. So, I think I’ll probably write something that has to do with that.

    Shimel: Okay, pretty cool. And you know what? We mentioned “A Seat at the Table” and, you know, there’s nothing like your first book, but I feel amiss if we shouldn’t also mention the title of the second book, right, and that is “The Art of Business Value,” right?

    Schwartz: Yeah. “The Art of Business Value” was sort of my initial train of thought. You know, I said to myself, we’re talking a lot about business value and how important it is to guide what you do in the IT world by delivering business value and how you should make prioritization decisions by business value, and it occurred to me that nobody was really talking about what that meant, you know? What is business value, exactly?

    And when I looked into it, I realized that people were not really interpreting it, in many cases, in the best way, and that if you thought a little bit more deeply about that, it would change the way that you practiced IT.

    So, that was what drove that first book, and in that book, I introduced the question of what does a CIO have to do with figuring out what business value is? How does a CIO make sure that he or she is delivering business value? And I realized that that was a good topic for a second book, actually. [Laughter] Something that I really needed to dive more deeply into. So, that’s what generated “A Seat at the Table.”

    And then, as I said before, once I had written “A Seat at the Table,” it was sort of clear to me what the next thing had to be. It had to be the book that I hope will speak to non-IT business leaders. So, that explains the sequence of the three books in my head.

    Shimel: Very cool. So, Marc, is there a tour going on with the book? Are you out speaking—I mean, are you gonna be, for instance, at DOES: London, coming up?

    Schwartz: I will be there. I speak at a lot of conferences in my role with AWS, and so, I’m on a permanent tour, essentially. [Laughter] I speak all over the world, and of course, I write blog posts and I’ll be writing some more books. And it all ties together with my role at AWS, where I’m part of a team that’s trying to lead enterprise executives into the future. You know, here’s the way that we see things developing, here’s how you can take advantage of what’s going on with the cloud and with DevOps.

    And so, I don’t have a speaking tour specifically about my book, but a lot of the topics that the book touches are also the topics I talk about for AWS.

    Shimel: Great. Great, great, great. Marc, we’re about out of time. We mentioned you can get the book on Amazon. Up on DevOps.com, I think we have a link to a, I don’t know if it’s the first chapter or an excerpt of the book. We’ll put that in the show notes.

    Look, man—first of all, congratulations on what sounds like another great book. I’m actually, I’m gonna be on the road a whole bunch in June, so, I’m gonna have a chance to catch up on my reading on planes and stuff, so I’ll get a chance to read this one. And then maybe we can circle back, maybe at the end of June in London, and we can talk a little bit more in depth about it.

    Schwartz: Uh huh. Sounds great.

    Shimel: Great. Hey, Marc Schwartz—iconoclast, CIO, or iconoclastic CIO as well as multiple award winning author, a real DevOps expert. His newest book, “War, Peace & IT,” you can find out more, get an excerpt from it on DevOps.com, you can get it on Amazon or any number of good quality book sites.

    Hey, Marc, congratulations, and thanks for being our guest on DevOps Chat.

    Schwartz: Thank you very much.

    Shimel: Alright. Enjoy your day and we’ll be in touch.

    Schwartz: Thanks.

    Shimel: Alrighty. Bye bye. This is Alan Shimel for DevOps Chat and DevOps.com. Have a great day.

    — Alan Shimel

  • VMware to Acquire Avi Networks for NetOps Capability

    VMware to Acquire Avi Networks for NetOps Capability

    VMware announced it intends to acquire Avi Networks for an undisclosed price as part of an ongoing effort to close the gap between network operations (NetOps) and DevOps.

    Once this deal closes, sometime between now and August, VMware plans to add a software-based load balancer, along with a web application firewall (WAF) and a service mesh to its network virtualization software portfolio.

    Tom Gillis, senior vice president and general manager for the networking and security business unit at VMware, said the goal is ultimately to make it as simple to deploy applications in an on-premises IT environment as it is on a public cloud by enabling IT organizations to automate the provisioning of network resources exposed via the VMware NSX network virtualization overlay. Avi Networks will extend those capabilities by adding a high-performance programmable load balancer, which eliminates reliance on legacy load balancers based on proprietary hardware platforms that are both expensive and rigid.

    Gillis said VMware will then infuse the WAF technology developed by Avi Networks into its network overlay platform to further secure east-west traffic in the data center.

    Finally, VMware intends to marry the service mesh technology from Avi Networks that supports a high-performance ingress controller with its ongoing efforts to integrate the open source Istio service mesh with NSX.

    Once all that work is completed, Gillis said it should be possible to deploy a workload on any platform with a single click. The challenge organizations face today is that provisioning and securing the network resources required to deploy an application outside of a public cloud computing environment still takes multiple days to sometimes weeks. VMware has already signaled its intention to make NSX network overlays available across multiple clouds and on-premises IT environments.

    Avi Networks CEO Amit Pandey noted that both companies are on a similar trajectory to leverage x86 processors to eliminate reliance on proprietary networking hardware. That shift to software-based networks and security services is driving the biggest transformation in the data center in the last 25 years.

    In terms of leveraging application programming interfaces to automate the provisioning of networks, it’s clear networking technologies have been lagging behind advances made in both compute and storage infrastructure. The challenge and the opportunity vendors such as VMware now see is the ability to more holistically manage IT environments spanning from the network to the application. As part of that strategy, VMware has been making a string of acquisitions to extend its core virtual machine franchise.

    It’s still too early to say whether all those investments will pay off for VMware. Reliance on VMware technologies in public clouds is relatively slight compared to the dominance VMware has today in on-premises IT environments. VMware is banking that its ability to extend the reach of its portfolio to foster the development of hybrid cloud computing, which is strongly anchored around on-premise IT environments that still run the majority of the workloads in the enterprise, will prevail.

    — Mike Vizard