Category: Blogs

  • DevOps Chats: Canary Deploys Using Istio, with Autodesk

    DevOps Chats: Canary Deploys Using Istio, with Autodesk

    Spinnaker Summit 2019 Preview: Canary deploys give us a window into how new code deploys perform in production on a limited basis. The technology holds great promise in helping us learn the positive or negative effects of deploys without putting the more extensive set of microservices, application functions and beyond at risk.

    How do you route traffic? How do you apply a virtual service manifest? Is there a quick way to perform a smoke test to find server errors? When comparing metrics from new code to old, how do you know which results are good or bad? There is a lot to know and learn about how to deploy and use Canaries.

    Our DevOps Chat guest Omar Al-Hayderi, engineering manager and principal engineer at Autodesk, is giving a talk on “Canary Deploys with Istio: Lessons Learned” at the Spinnaker Summit 2019. His talk is on Sunday, Nov. 17, at 1:30 PM PT.

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

    Transcript

    Mitch Ashley: Hi, everyone. This is Mitch Ashley with DevOps.com and you’re listening to another DevOps Chat podcast. Today, I’m joined by Omar Al-Hayderi. He is engineering manager, formerly principal engineer at Autodesk. And Omar is gonna be speaking at the Spinnaker Summit 2019 in San Diego. His talk is on Canary deploys with Istio. It’s happening on Sunday, the 17th of November, 1:30 p.m.

    Omar, welcome to DevOps Chat podcast.

    Omar Al-Hayderi: Thanks for having me, Mitch.

    Ashley: Awesome to have you here. I’m excited to hear about your talk. But first, tell us a little bit about yourself, introduce yourself, and what you do at Autodesk. I think we know about Autodesk, maybe what part of Autodesk that you work in.

    Al-Hayderi: Right, yeah. So, I’ve actually gone through a lot of change recently. I was working at a startup called PlanGrid, and we were a small construction software company four years ago, grown a lot since then. I started off at that company as sort of a backend generalist. You know, there was like 25 engineers, really, at the company, and have grown a lot since then, since the acquisition. We got purchased at about 400 employees.

    In that time, I’ve sort of evolved naturally into more of a DevOps infrastructury engineer role, and—yeah, it was kinda the best four years of my life. Really learned a lot there. Post-acquisition, I moved into a principal engineer role on the infrastructure team. We then went through sort of a re-org and I became the engineering manager of the back end platform team. And now, that team, we sort of specialize in building a lot of tooling around our sort of DevOps and infrastructure cloud.

    Ashley: Mm-hmm, great. Well, great experience to bring with you to Autodesk. It sounds like you’re working on some fantastic things. How did you come to decide that you’re gonna talk about Canary using Istio at the Spinnaker Summit? Was that something you chose to kinda bring in and start up at Autodesk, you joined a team already using it? What’s kinda the background on how you kinda came to this place to wanna talk about it?

    Al-Hayderi: Yeah. So, I was sort of, you know, dipping my toes into Spinnaker at the early stages of it, and I was really fascinated by the tool. I loved using all sorts of features and playing around with it. And at PlanGrid, actually, before we were even acquired, we did yearly hack weeks, and we got to sort of move off of our regularly scheduled program and work on whatever we felt like, just had fun.

    And one of the things that recently came out for Spinnaker was this idea of Canary deployments. So, I experimented with it, never got it off the ground, fast forward one year later to the next hack week, Kayenta, the Spinnaker Canary component, was a lot more built out and user friendly. So, I managed to get it off the ground then.

    We sort of have a monolith API at PlanGrid. And so, a huge problem we had was, we would do weekly releases, and after the release, stuff would break and people would get paged and we’d have to roll back, so.

    Ashley: [Laughter] Vicious cycle.

    Al-Hayderi: Common story I’m sure everyone’s familiar with.

    Ashley: Mm-hmm.

    Al-Hayderi: So, I really wanted to find a way to solve that, and Canary just seemed like a great way to do that. So, after the hack week, I sort of kept working on it full time, and I started doing, you know, presentations to the rest of the company. Because Canary is sort of this new idea that a lot of people aren’t familiar with. I started, you know, being active in the Spinnaker Slack channels, and it actually turns out that an ex-PlanGrid employee moved to Netflix to be a lead on the Spinnaker open source software from there.

    Ashley: Ah, interesting.

    Al-Hayderi: Yeah.

    Ashley: Small world.

    Al-Hayderi: Yeah. [Laughter] And he noticed I was talking a lot about it and he brought up the point that they’re running the Spinnaker Summit in November and he asked if I wanted to talk. And I’ve actually never given a talk at a conference.

    Ashley: Oh, excellent.

    Al-Hayderi: Yeah, and I do a lot of talks internally. So, this is something I was super excited about and, yeah, I jumped on it.

    Ashley: Great thing to do for your career, too, and it sounds like those internal talks have set you up well to do this.

    Al-Hayderi: Yeah.

    Ashley: So, how did you go about deciding, is this gonna be kind of an overview of how to do it? Is it going to be, “Here’s the metrics to watch” and the value that comes out of it is a combination of that? Tell us a little bit about what part of this you’re—kinda what take you’re taking in your talk.

    Al-Hayderi: Yeah. So, public speaking was honestly never my strong suit when I was younger. And some great advice I got was that, when you’re giving a speech to a bunch of people, you wanna tell it like a story.

    Ashley: Mm-hmm.

    Al-Hayderi: So, since then, I’ve really focused on storytelling for even these tech talks I give internally.

    So, the story I’m trying to tell here is how we leveraged Istio to finally solve some of the deep technical problems of running Canaries.

    Ashley: Mm-hmm.

    Al-Hayderi: And once we got it out there, sort of the growing pains and, you know, first obstacles we hit and problems we’ve got. I’m hoping people come out of this with a better idea of how to actually get this running in your infrastructure and some common pitfalls to avoid.

    Ashley: Mm-hmm. Great. Well, tell us a little bit of that story. Kinda get us started down that path.

    Al-Hayderi: Totally. So, the first thing I did was, I went in and learned exactly what Canaries are. And the basic point of it is that you want to expose a small amount of traffic to something new. You want to analyze the deltas and some sort of metrics or something between the new and the old. And then you want to make a decision if this new is ready for the majority of traffic.

    Ashley: Mm-hmm.

    Al-Hayderi: So, there’s a lot that goes into that. Anyone that’s worked with Spinnaker on production scale knows that managing all these pipeline definitions is very cumbersome, and trying to, if you end up changing something, especially changing production pipelines, it can be really dangerous.

    So, a lot of the things we learned about our, you know, how we tested this, even just testing the Canary process in our sort of R&D Dev staging environments and the problem there, even though we got confident with how the pipelines worked, it was very difficult to get a signal on how to actually tune your Canaries. And when I say tune, I mean, when you’re comparing metrics from the new and the old, how do you know if it’s bad or how do you know if it’s a good decision to move forward? What are the thresholds, what metrics are you looking at? A lot of our iterations were focused on that.

    Ashley: Interesting. Now, I’m curious if—are you approaching this problem of using Canary to understand the service mesh or the services itself, or are you trying to also understand kinda Istio and it acting as a sidecar proxy and how that’s performing coordinating traffic load balancing across that? Is it one or the other or both, or what part of the problem were you looking to solve?

    Al-Hayderi: Right. So, actually, we were kind of blocked on the fact that we couldn’t route traffic, you know, with small granularity coming in from the Internet. And we actually only use Istio for its API gateway feature at the moment.

    Ashley: Oh, okay, okay.

    Al-Hayderi: Yeah, there are some blockers right now, at least in our version of Istio, that we’re running around connecting over SSL to Redis. So, that’s blocked having sidecars or application pods. So, when we do canaries, we’re just canarying end user or ingress traffic into our monolith.

    Ashley: Okay.

    Al-Hayderi: Yeah.

    Ashley: Interesting. So, tell us the story. How did you, you went about implementing it—what did you learn from it?

    Al-Hayderi: So, I mean, first off, we had our sort of snowflake-y pipeline that would deploy our own little service and change traffic and compare metrics. So, I guess the first part about it was how do we route traffic and what we actually do is, in a single pipeline, we’ll deploy containers to a new supergroup and we’ll, that’s using the V1 provider of Kubernetes.

    Ashley: Mm-hmm.

    Al-Hayderi: And then we actually used the V2 provider of Kubernetes to apply a virtual service manifest. Virtual services are just a kind of way of routing ingress traffic based on some set of rules. So, if the host header matches this and the path has this Regex, route it to this service.

    What you can also do is, when you match a rule based on some ____ path prefix is route to several services based on weights. So, we first experimented with how are we gonna get a small amount of traffic, yet a meaningful enough amount of traffic to get a good enough sample size of data.

    So, a lot of our, at the start, what we were doing was just sort of like load testing and seeing, “Okay, is 5 percent of the traffic to the Canary deployment enough? How about 10?” et cetera, et cetera. We also looked at some common best practices around Canaries and how they recommend running baseline deployments. So, what we would actually do is deploy two new deployments. So, one with the new code on a small sized server and one with the old code on a brand new, deployed small server. That way, you sort of take away a lot of variables from the experiment, like long running processes, et cetera.

    So, we got there, got traffic routing correctly. Now, the next part we had to do was metrics, right? How do we analyze the delta between the two deployments? At this point, Kayenta only supported Datadog, at least out of the metrics providers that we used.

    Ashley: Okay.

    Al-Hayderi: So, what we really wanted to do, you know, going back to the whole point of getting Canaries out was stop deployments that are just plain broken, right? So, kind of getting, like, a cheap, easy way to get smoke tests. And so, we were just looking for server errors.

    So, as we were trying that, the problem is, is that the server error metric that Istio gives you will only send metrics of a server error happens. So, between two deployments, if you only get two server errors on one, that will trip the Canary as a failure. It doesn’t give you the option to aggregate metrics, so we couldn’t do things like check error rates. So, that just really never worked.

    And actually, in my talk, I go into sort of the—this was kind of a big, big problem the first time we actually released this into production is that Canaries would just fail a lot for no reason, right? And Canaries running for an hour long, you know, our release engineer is sitting there waiting for an hour and then has to trigger it again just because, you know, one server error happened on the Canary deployment.

    Ashley: Well, it sounds like maybe one of the lessons you learned or concept you came up with is, don’t cast a big net. Start out with sort of higher, larger grain, most fundamental issues, kind of a ____ kinda concept. Start there, get those—get that quality fixed, improved, so you’ve got those things working better, probably tighten the net a little bit more and filter out some more specific things that are causing issues. Does that sound like the approach that you learned how to take?

    Al-Hayderi: That’s exactly it, and actually, what I would recommend is, the first time you give out Canaries, don’t have it actually fail or roll back the deployment if the Canary was unsuccessful.

    Ashley: Mm-hmm, okay.

    Al-Hayderi: What we actually ended up doing was actually running this for a month and just gathering data, seeing which metrics worked, which metrics didn’t, and mapping up Canary reports with what we actually saw as problems in production. That way, that gave us more information on which metrics to use. We ended up going with average latency and 95 P latency and once that was out, we started actually aborting and rolling back deployments and then we started to get a lot of great value of this tool.

    Ashley: Mm-hmm. Yeah, that’s actually very similar to kind of a quality process, right? You don’t solve all problems at once. You start, you prioritize, you filter, you work done—you know, improve it one step at a time, rather than just throwing a canary out there and seeing what happens, which sounds like you’ll get results, but you don’t know what or why, right?

    Al-Hayderi: Yep, exactly.

    Ashley: You’ve gotta dig into it and be a little more thoughtful about it, it sounds like.

    Al-Hayderi: Yep.

    Ashley: Good. Anything else? Any kinda other big things you’re expecting to talk about as part of this?

    Al-Hayderi: So, another big thing we learned was, even after this, when we had, you know we were confident that our Canaries were failing when they should and passing when they should. The problem we got was, when a Canary failed, people didn’t really know what to do.

    Ashley: Mm-hmm.

    Al-Hayderi: Because, you know, when a deployment fails, we have a lot of data and we have a lot of observability into that. The Canary is getting a lot less traffic, and it’s hard to know exactly what failed just by looking at the Spinnaker UI Canary report.

    Ashley: Mm-hmm.

    Al-Hayderi: So, we then, you know, sort of invested more into our—we used New Relic for our APM and we piped our Canary into that so that we could actually see transaction data and the delta between it and the baseline metrics to see, you know, which end point, for instance, was misbehaving or was some new database core utilizing this—that helped us a lot, too.

    Ashley: Mm-hmm. Interesting. Well, it sounds like you’re using—think about this in a systemic way, not just Canaries and Spinnaker, but also you mentioned Datadog, New Relic, a number of tools that you’re using as part of your environment, which all have to come together to figure it out, right? It’s not just one thing.

    Al-Hayderi: Yep.

    Ashley: Well, good. I wish you the best in your talk. The folks that would go to this talk, are they gonna be, tend to be software developers, engineers, architects, operations focused on the DevOps team? Who tends to be more interested in this than others?

    Al-Hayderi: I would say more the DevOps operational people. People who work with the Spinnaker pipeline definitions at their company would get the most value out of this. But, you know, back when I was just a developer, I heard a talk about Canaries, and that sort of triggered me to bring this in. So, I mean, anyone who’s interested in resiliency and, you know, release confidence would get value out of this talk.

    Ashley: Okay, excellent. Very good. Well, thank you for being on the podcast, Omar.

    Al-Hayderi: Thank you very much, Mitch.

    Ashley: It’s been great to have you, Omar Al-Hayderi, who is engineering manager, formerly a principal engineer, at Autodesk. He’s gonna be speaking at the Spinnaker Summit 2019 in San Diego. The dates for that is November 17th through the 19th, and Omar’s talk is on Sunday, the 17th, at 1:30 p.m.

    So, thank you, all of you, for joining us and listening to this episode of DevOps Chat podcast. This is Mitch Ashley with DevOps.com. You’ve listened to another DevOps Chat. Be careful out there.

    — Mitchell Ashley

  • CNCF Advances Jaeger Distributed Tracing Project

    CNCF Advances Jaeger Distributed Tracing Project

    The open source Jaeger distributed tracing platform has officially graduated into the top tier of projects being stewarded by the Cloud Native Computing Foundation (CNCF).

    Designed to be employed within any DevOps environment, Jaeger is a tool for monitoring transactions across complex distributed computing environments. It consists of a backend for trace collection and analysis and multiple client libraries implementing the OpenTracing application programming interface (API) in various languages.

    Developed by Uber, Jaeger now integrates with tools such as OpenTracing, OpenTelemetry, Envoy and Prometheus to make it easier to discover the root cause of issues impacting transactions in complex IT environments. For example, DevOps teams can apply data mining techniques and machine learning algorithms to analyze data from a specific cluster.

    JaegerYuri Shkuro, a software engineer for Uber who works on the Jaeger project, said organizations may rely on tools such as Prometheus to monitor environments, but once an issue is identified, it typically takes a tool such as Jaeger to identify the root causes of an issue. The primary reason for that approach is the amount of data that distributed tracing tools would store if they were to run continuously, he said.

    Organizations that are already using Jaeger in production environments include GrafanaLabs, Northwestern Mutual, SeatGeek, Symantec, Ticketmaster, Uber, Weaveworks and Zenly.

    Jaeger is also starting to be bundled with other platforms, such as the Red Hat OpenShift Service Mesh. As that trend continues, more organizations are likely to become exposed to Jaeger as a tool for debugging a wide variety of issues.

    Although originally developed to address the inherent complexity associated with microservices, Jaeger also can be applied to monolithic applications, Shkuro said. While many of those monolithic applications eventually are likely to be deconstructed into a set of microservices, many of those applications are not going away anytime soon, he noted.

    Jaeger now has 15 active maintainers from four companies, with more than 1,200 contributors and 375 authors of commits and pull requests. It also has more than 9,000 GitHub stars and has been pulled from Docker Hub more than 10 million times.

    While distributed tracing as a concept has been around for a while, the rise of microservices is forcing IT teams to look for tools that make it possible to engage in deeper forensics. The dependencies between microservices coupled with the ephemeral nature of containers often make it challenging for IT organizations to discover the root cause of intermittent issues. Within IT environments that have adopted Kubernetes to run those containers, it’s also become easier to deploy Jaeger using tools as Kubernetes templates, Operator software and a Helm Chart.

    As developers are held more accountable for applications, interest in programmable forensics tools is rising. Performance issues that developers once viewed as a problem to be solved by faceless IT operations staffs are now being solved much faster by developers. As a result, application experiences have improved now that developers are seeking out tools such as Jaeger to identify issues that are preventing them from focusing their efforts on writing additional code. Given the long, difficult history of IT, there are more than a few IT leaders wondering what took them so long to figure that out.

    — Mike Vizard

  • How Open Source Software Is Defining the Future of Mobile Connectivity

    How Open Source Software Is Defining the Future of Mobile Connectivity

    Mobile operators face intense pressure to deliver more data, faster connectivity, better coverage and more functionality to end users who are (unfortunately) more demanding than ever. Increasingly, these end users will not be people as we know them but rather Internet of Things (IoT) devices. IDC has projected that by 2025, 60% of the world’s data will be generated by enterprises, double its level in 2017, largely due to the growth in connected devices, sensors, automation and related equipment.

    To address industrial automation, connected cars, smart cities, sensor networks, asset management, connected health and more, operators need to rethink how the connecting network is architected. They must support faster connections, greater density and dramatically reduced latency. And they must add this functionality and flexibility while driving down the costs of deploying, sustaining and managing the network infrastructure.

    For decades, the telecom industry has been dominated by proprietary business and operating models, but with market pressures to find innovative ways forward, operators must find a new approach. That means embracing the open-source principles and innovations that took the computer industry at large from supercomputing to smartwatches and wearables and applying them to wireless network infrastructure.

    Open source software is proving to be key in 5G and IoT development, powering the automation of the mission-critical functions required to support the high speeds and low latency of 5G and the huge number of endpoints in IoT. Stakeholders have recognized that commoditization and democratization of wireless network infrastructure is necessary to stay relevant.

    Several initiatives already are underway to break this proprietary stranglehold and deliver software-defined networking (SDN) into the wireless network. They include the major operators and wireless infrastructure vendors, while disruptive challengers and startups are making an impact, too.

    The operator community along with major enterprises are now actively engaged in collaborative alliances to help drive uptake of open source.

    The O-RAN Alliance includes members such as AT&T, Deutsche Telekom, Intel, Verizon and SK Telecom, and embraces open interfaces and intelligent technologies for the radio access networks (RAN) needed for next-generation mobile applications like augmented reality, IoT, connected cars, smart homes and more.

    The Open vRAN initiative is backed by Cisco and is primarily focused on specifications to enable “unbundling the components of the network into smaller, simpler components and virtualizing capability to reduce cost and increase agility.”

    The Telecom Infrastructure Project’s OpenRAN Group, created in 2016 by Facebook, Intel, Nokia, Deutsche Telekom and SK Telecom, is focusing on more simplified and efficient radio access network technologies based on vendor-neutral hardware and software-defined approaches.

    A key component and enabler of a programmable base station is providing for a software-defined radio, which can revolutionize the traditional RAN landscape and make it easier for operators to roll out tailored services to different customer segments, at a reduced cost, by using software rather than hardware to process radio signals.

    To that end, the MyriadRF open source initiative was founded by Lime Micro in 2012 with the goal of democratizing wireless innovation. It has grown to include contributors ranging from hobbyists and wireless enthusiasts to professional engineers and equipment manufacturers. As of late 2018, more than 8,000 high performance LimeSDR software-defined radio boards had been shipped to developers, with more than 4,000 commits made across 70 GitHub repositories.

    LimeNet’s CrowdCell network-in-a-box platform, which significantly lowers the barrier to entry for software-defined radio development, is opening up a portfolio of new use cases for operators and enables them to go much further than being just a connectivity provider. Furthermore, it has the added benefit of access to a developer community which is constantly creating new applications and modifying and testing existing ones for increased use case fit.

    For example, Vodafone in the UK wanted to extend coverage and add additional services to the network it offers to customers and use this as a means to generate new revenue. By using CrowdCell, Vodafone is able to localize communication to a greater extent and reduce reliance on major cloud service providers–meaning Vodafone gets greater reliability and security at a lower cost.

    They also have the opportunity to develop cloud-hosting revenues and additional services, from which new revenue can enable 5G development and deployment. All this is underpinned by safe access to the app development community that ensures continuous innovation.

    The future of mobile connectivity is software-defined. The software-defined approach and third-party app development will ensure that operators are no longer differentiated solely by coverage or subscription costs but by the value-added services they are able to offer.

    — Tom Canning

  • DevOps Chats: The Future of Farming with Aerobotics

    DevOps Chats: The Future of Farming with Aerobotics

    Spinnaker Summit 2019 Preview: Never underestimate an entrepreneur looking to solve a real-world problem. Aerobotics is bringing drones, imagery, mapping, containers, Kubernetes, Spinnaker, data pipeline processing and machine learning to agriculture. Sounds interesting, right?

    Aerobotics uses aerial drones and sophisticated image processing to help growers manage yield, pest and disease in their farms through artificial intelligence.

    Speaking at the upcoming Spinnaker Summit in San Diego, Aerobotics’ Head of Software Nick Coles, shares with us how his company evolved from making drones to map orchards into a software company using raw image data to create high resolution, georeferenced maps of orchards. Aerobotics technology is comprised of a map engine and tree engine. It’s both a fascinating problem space and exciting application of cloud-native technologies, including Spinnaker.

    This episode of DevOps Chats features a preview of Nick’s talk, “The Future of Farming with Aerobotics.” Nick’s talk is on Sunday, November 17 12:30 PM, at Spinnaker Summit 2019 in San Diego.

     

    Transcript

    Mitch Ashley: Hi everyone. This is Mitch Ashley with DevOps.com, and you’re listening to another DevOps Chat podcast. Today I’m joined by Nick Coles, head of software at Aerobotics. This is a special edition of DevOps Chat, because we’re talking about talks at the Spinnaker Summit 2019, which is in San Diego this year.

    Our next topic is the future of farming with Aerobotics, aka drones. So you’re gonna be really interested to hear about this. This talk is on Sunday, November 17th at 12:30 p.m. Nick, welcome to DevOps Chat.

    Nick Coles: Hey Mitch. Thanks for having me. Really excited to be on this podcast.

    Ashley: Happy to have you here. Tell us a little bit about yourself. Tell us about what you do at Aerobotics and a little bit about the company.

    Coles: Cool, so I guess just from the very beginning, born and raised in Cape Town, South Africa, as you can probably hear by the slightly strange accent. [Laughs]

    Ashley: Detected. We detected a slight accent there. [Laughter]

    Coles: Yeah. And but yeah, born and raised Cape Town, South Africa. Studied at the University of Cape Town, where I did a electromechanical engineering degree, which was kind of, you know, embedded systems, microcontrollers, processes and stuff. And that’s kind of why I got interested in drones and robotics. And, yeah, just over four years ago joined Aerobotics and sort of–at the time it had just been funded, so there were essentially two people, and I kind of joined in a software engineering role, not really knowing what I was doing.

    Ashley: [Laughs]

    Coles: And yeah, kind of been there ever since heading up the software engineering team. Which obviously a huge component of it has been DevOps and back-end processes. And so that’s kind of why I sort of have been exposed to Spinnaker and, yeah, kind of what led me to this today.

    Ashley: Excellent. So it’s the true startup experience, which means your job is you do whatever needs to get done, and you kind of evolve into your current role, it sounds like.

    Coles: Yeah, pretty much. I mean I joined–back in about four years ago when we joined it’s basically we were a company that was building drones, building the hardware, sort of soldering the motors to the propellers. And essentially drones kind of transformed throughout our journey, and we ended up having to move out of the hardware space and peel into the software space, because companies like DJI came up with these commoditized perfect drones. And it was quite hard to compete with them when you’re, what, five engineers in a garage soldering drones on a piece of [Crosstalk]–

    Ashley: There are a lot of drones available and you can differentiate in the software. So I read from the description of your talk that Aerobotics uses aerial drone imagery to help farmers, growers, manage their yield, pest, disease, that kind of stuff on farms, using some AI. Is that a problem that you started initially with, or did the company evolve to that kind of problem? How did you get started, and the company get started around that area, specifically?

    Coles: So, I mean, the company has actually had quite an interesting sort of journey in that regard. So the idea in the beginning was we are drones. We build drones. We use drones for agriculture. We use drones for security, game counting, mining. We tried to essentially just throw drones at any sort of problem.

    And sort of as we progressed as a company and more and more players sort of entering the field, and we sort of started honing in on our value proposition, and started specifically focusing on tree crops within the agriculture space because it’s such a high value. And so it actually then makes sense for the cost for specific tree crops.

    But originally we weren’t using any AI. We were kind of just trying to use raw sort of computer vision and object detection. The data that we were seeing is so vast, and case-by-case is so unique, that we kept having to change the parameters, slightly tweak things. And so the only sort of long-term solution could’ve been machine learning. And so that’s kind of what we embarked on about two to three years ago and sort of been, yeah, what we’ve been using ever since to try to essentially generalize the imagery we were receiving and sort of try to replicate the human behavior to the best of its ability.

    Ashley: Okay, excellent. So I know your software staff appreciate that about the company in kind of the broadened space. I know your software stack is a combination of, what, Kubernetes, of course you’re using Spinnaker, I think Circle CI for your CI/CD. Tell us a little bit about how you got involved with Spinnaker initially. Was that something that you chose or kind of evolved there kind of by accident? How did you happen down that path?

    Coles: So, I mean, it is–it did happen by complete accident. Traditionally when we were processing all this data we were just spinning up EC2 instances. And so we were essentially just sending SQS messages and spinning up instances. And instances would essentially be able to sort of, I don’t know, kind of retrieve these messages and then figure out what sort of processing to do. You know, it was an absolutely terrible solution for instance _____ a drone with a code. We’d have to SSH into the instance, patch it, figure out what was going on.

    Ashley: Oh boy.

    Coles: At this time also it wasn’t–like, DACA hadn’t really sort of like exploded. And or maybe it had in sort of like San Francisco and everything. But in Cape Town we weren’t really exposed to all these sort of advanced kind of tech solutions. So we had quite an archaic little approach going on, which was working, I guess, with R Scale.

    And then in the beginning of last year we got accepted into Google Launchpad, which was really exciting. Four of us went across to San Francisco, and we basically went on this launchpad program where they kind of helped us all the way from technical to business. And it really was inspiring to kind of go to San Francisco for the first time and sort of see like just the scale of things and just like the intensity of the tech companies there and really what they were doing.

    And we kind of got put in touch with a couple of mentors. And one of them, based on sort of what the problems we were trying to solve were and the problems that we were facing, recommended Spinnaker. And at that time we were kind of on AWS’ stack. And so we kind of then got incentivized to sort of try, set up a system on Google. And you know, we had like Spinnaker set up, Google’s Kubernetes’ engine, and kind of we just took it from there.

    And just it was an interesting journey, ‘cause there was quite a lot of iteration within like Spinnaker itself and in terms of just how the community’s progressed over the last sort of two years, but also just sort of like where we were at in terms of not really understanding how Spinnaker worked, the containers spiraling out of control, realizing we needed to stabilize our Redis pods. Like our Redis pod basically caused so many problems early on.

    But yeah, so that kind of was the journey in terms of how we got involved in Spinnaker. So it was basically just by chance somebody mentioned it, and we kind of were like, wow, this shows the problem we’ve been having.

    Ashley: Like a great solution.

    Coles: And we kind of just ended up, yeah, just going with it.

    Ashley: Fantastic. So from what I understand is the drones that–just giving our audience a little bit of context–the drones that are flying around the orchards, for example, are collecting all of this data. And that goes up into some data processing in the cloud, correct? And it does, I guess, splits into two areas. One is a map engine that creates–takes that raw imagery and creates multilayered geomaps of the orchard. And then the tree–a tree engine, which also then looks at specifically where exactly are the trees. And that’s how you do your processing. Is that a correct description of how this works at a high level?

    Coles: So it is basically quite a good description. So just to maybe give like slightly more detail on like the map engine side, we are–I don’t know if you mentioned–but we are using multispectral cameras attached to the drones. And from that data we can get information that isn’t necessarily visible to the human eye. And that kind of gives us all a health and powerful readings from the plots.

    Ashley: Is that like using infrared kind of things, or what?

    Coles: Exactly. Exactly. Infrared sensors. And so, yeah, so the map engine side is essentially like the big data processing side of things where we’re taking thousands of thousands of images and stitching them into these high resolution maps of individual orchards. I mean, just to give sort of some context on kind of what the data is there, we generally produce about like these five gigabyte high resolution images, which is of a specific orchard. And the kind of process around getting the raw imagery to that five gigabyte sort of image, we use about 64 gig RAM and 16 CPU instances. So that’s kind of just like the scale of what you’re running in. It can take anywhere between two hours to 24 hours to form that stitching process.

    And then moving onto the tree engine, this is sort of where our machine learning models are running in production. And that’s essentially taking these high resolution maps and segmenting the image to get individual trees from that image. And from that we can then calculate additional metrics, such as the height, the health, and the area of the individual trees.

    And one thing that, I guess, we left out because we are still developing it, is we now have a fruit engine, which is essentially now like kind of our new product focus area where we’re going from the drone, which is kind of taking a high level of the orchard, and now we’re going right up to the individual trees. And from those trees we’re starting to detect fruits and sizes from the fruits. And the goal here is to give the farmers an accurate sort of size distribution of the fruit in the orchard so they can plan accordingly when it comes to harvest time.

    Ashley: They’re all–it’s all about yield, of course, and quality of the yield as well. And by the way, I come from–I’m not a farmer, but I grew up in the middle of Nebraska in the U.S., so I’m around a lot of farmers. So I have some idea of what you’re talking about, at least an appreciation for it.

    Well how did–tell us a little bit about why you chose to do this talk at Spinnaker Summit and some of the things that you want to communicate beyond kind of the problem set or the solution that you’ve come up with.

    Coles: Okay, so one of the reasons why I thought it would be quite cool to speak at the summit was, I guess, just based off like chatting to some of the Spinnaker guys on the Slack channels and everything, it feels like we’re using it in quite like a unique sort of way. I mean, we’re using it very much to manage essentially our data pipelines. And I guess we’re almost using it in a similar way to how someone may use something like Apache Airflow or something.

    And I thought that the combination of the uniqueness of how we’re sort of using it, and sort of just to kind of explain how it has completely changed the way we’ve been able to develop and iterate super quickly, I thought it’d be worth kind of sharing that with the community and sort of seeing how other people were using it in comparison. And so I guess, yeah, that was kind of just the main thing, just the type of data that we’re sending through the system is quite different. It’s quite unique, in comparison to the rest of the world.

    You know, we process these large images which come up with a–which have a whole bunch of different problems with them. You know, we have to ensure that our containers are responsible, they’re not using too much RAM, they’re not spiking in terms of, you know, being out of memory because they’re loading an image all at once. And there’s just been a lot of interesting things that we’ve had to sort of develop to kind of handle our case. So I thought it’d be cool to share that with the community and take it from there.

    Ashley: You know, I think it’s super relevant, and not everyone may have an agricultural problem domain, but with a massive quantity of data that we’re collecting through sensors, whether it be drones or IoT and home or IoT and the business or any device, any systems that are collecting all this data, one of the real challenges is how do you process this much information? How do you combine it together? How do you take different sources like your map engine versus the tree engine, look at it, and then do that analysis and produce valuable, interesting results?

    I think a lot of businesses, whether they be startups or enterprises, have those kinds of projects and challenges, or at least they’re thinking about it, if they’re not already doing that. And I bet you’ve got some valuable lessons that you’ve learned over time about why you set up the pipelines the way you did or how to handle some of the production challenges.

    Coles: Yeah, you know, it’s also we had an interesting space, also, because we’ve learned so much over the course of the last two years. Like when you’re doing things in production, you also very quickly start figuring out what it should be. And so there’s even more and more of an end-goal, if that makes sense.

    Ashley: Mm-hmm.

    Coles: So like as a small example, kind of, you know, we’ve set up all of our Spinnaker pipelines, and it’s been amazing. And the devs have been able to iterate really fast. And now we’re starting to see that we want to maybe start introducing some stability to our pipelines. And so to achieve that you want to start setting them up as infrastructure code. And like just starting to build that whole process into the development cycle is obviously quite challenging and takes time. But it’s allowed us to sort of think forward and continually improve on what we’ve been doing.

    So you always feel like you have kind of found the best solution at a point in time. You’re like, wow, this is absolutely incredible, and it’s going so well. And then six months from then, you’re kind of like, wow, it could be so much better. There’s so much more we can still keep doing to improve again. So I guess that’s what’s been quite an awesome part about using Spinnaker. It’s like at every sort of milestones it’s kind of like you can keep iterating and making it better and using it more efficiently.

    Ashley: That’s excellent. When you use a tool like Spinnaker open source to a software like that, that you feel like you’re just getting started sometimes. You thought you knew what you could do with it, and you find out there’s eight or ten different things that it evolves to from where you started.

    Coles: A hundred percent.

    Ashley: Well good. I wish you the best of luck on your talk. You know, I think you may get some folks attracted just to come hear about the drones. I hope you’re gonna have some pictures of maybe some of the orchards and the maps and some of the output that you do, is that correct, just to give folks an idea of kind of how this works?

    Coles: Yeah, we’ll definitely, I think, do a very brief sort of couple minutes on the product and just kind of explaining what we’re trying to do, and for sure. ‘Cause I guess it’s always nice to sort of give context of what Spinnaker is actually producing at the end of the day.

    Ashley: Mm-hmm. Well very good. Well it’s been great talking with you, and I wish you the best with the talk. And hopefully you get a lot of folks coming that are excited to hear about what you’re doing. Is this the first talk that you’ve given at a conference like this, or you’ve done that before?

    Coles: No, this would be the first talk, so I’m quite excited for that.

    Ashley: Really? Excellent. Well you know it’s–there’s lots of ways to give back to an open source community, and of course, writing code is certainly one of ‘em. But most people don’t write code. And I think one of the great ways of giving back is doing exactly what you’re doing, is going and talking, not just in the community and online forums and Slack channels or whatever they are–that, too–but participating in talks like this.

    Because it–I’ll predict you’ll have a lot of folks come up to you after the talk and want to know more or talk about what they’re doing and tell you about their idea or ask your advice on something. So it’s a great way that advances the software and the use of it, because you’re doing things that probably other people never expected or predicted. So congrats. That’s awesome you’re doing it.

    Coles: Thank you. Yeah, I guess that’s one of the things I’m most looking forward to is just sort of meeting a whole bunch of new people and kind of, I guess, like we learn so much, like especially kind of being in South Africa, not kind of in the tech hub of the world, I would guess, is when you go there and you start speaking to some people who are kind of leading the way in terms of the industry, it’s so valuable just to kind of hear what they have to say and what they’re using and how they’re solving problems. Because it’s so relevant and it can translate so nicely back home. And so, yeah, it’s always so much value in just meeting the people and just chatting through things.

    Ashley: Well excellent. Nick, thank you for joining the podcast today.

    Coles: Thanks Mitch. Will you be at the summit in a month’s time?

    Ashley: I don’t think I’m gonna be able to be there. I’ve had several invitations [Laughs]. If I can I will be.

    Coles: [Laughs] Okay.

    Ashley: But I’m like back-to-back for the next month going to conferences. So we’ll see. Hopefully. If I make it I will definitely look you up.

    So I’d like to thank Nick Coles, head of software for Aerobotics, joining us today. Again, he’s speaking at the Spinnaker Summit 2019, the dates are November 15th to the 19th in San Diego. By the way, Nick, you’ll enjoy San Diego, too. It’s a great city like San Francisco is. His topic is the future of farming with Aerobotics, aka drones. And on Sunday November 17th at 12:30 p.m. So please check out his talk.

    And thanks to all you for joining us today on this podcast and listening to Nick and I chat about his talk. This is Mitch Ashley with DevOps.com, and you’ve listened to another DevOps Chat. Be careful out there.

    — Mitchell Ashley

  • When Gateways Go Away with Cellular IoT

    When Gateways Go Away with Cellular IoT

    Gateways have been an essential piece of three-tier IoT architecture for years. Their traditional spot between the edge and the cloud is in flux as cellular IoT technology rolls out. When are gateways still the right approach? How will gateways go away with cellular IoT? Here’s the trade-off between traditional three-tier and cellular IoT architecture for DevOps teams.

    Spanning the Gaps

    IoT edge devices and enterprise networks are often incompatible. Enterprises and clouds run on IP packets and heavier protocols such as HTTPS, TLS and XML. It takes processing power to run these–power often beyond the reach of smaller battery-powered edge devices. Even with improvements, Wi-Fi is enterprise network compatible but too heavy for many edge devices.

    That’s why wireless sensor networks such as Bluetooth, Thread, ZigBee, Z-Wave and others evolved. These compact, efficient stacks run on tiny microcontrollers, sipping power as sensors send data in small bursts. Alongside wired control networks are more wireless technology such as 6LoWPAN, ISA100 and WirelessHART. Real-time protocol conversion in a gateway brings data from these devices into IP-based enterprise networks.

    In some cases, a gateway might be as simple as a smartphone, tablet or a small board. Some gateways have faster processors, AC power, better cooling and packaging for harsh environments. Faster gateways can also pre-process data streams in an edge computing role. This reduces network traffic and speeds up decision-making without relying on cloud analytics.

    Setting up a few gateways inside an industrial facility is easy. Clusters of far-flung sensors call for many gateways spanning the gaps. As IoT applications grow, gateways carry development and deployment costs. Every time another gateway drops, DevOps must secure and update it.

    A Towering Alternative

    There was no alternative to three-tier IoT architecture until recently. Wireless sensor networks appropriate for edge devices lack range for many use cases. What if instead of extending device range one could extend network coverage? Low-power, wide-area network (LPWAN) technologies take on that challenge.

    Three main classes of LPWAN technology exist today: Sigfox, LoRaWAN and cellular IoT. Sigfox is a low data rate uplink solution connecting devices and Sigfox towers within 30 to 50km in rural areas. LoRaWAN uses unlicensed spectrum limiting its duty cycle to around 1% and requires a wireless gateway for a five to 7km rural range. Urban ranges are shorter for both technologies, still a few kilometers. Both work for sensors that mostly sleep and transmit small amounts of data.

    Cellular IoT technology got a late start, with good reason. Specifications for faster, yet low-cost, low-power radios with cellular-grade range and security was a massive undertaking. The 3GPP defined two paths: LTE-M and NB-IoT. LTE-M offers a 1Mb/s data rate and lower latency. NB-IoT concentrates on lower data rates without duty cycle limitations. With about 200kb/s data rates up and down it is still much faster compared with Sigfox or LoRaWAN. NB-IoT also penetrates buildings better, avoids interference and targets a 10-year battery life in devices.

    Mobile network operators (MNOs) worldwide are racing to get NB-IoT and LTE-M networks deployed. In the latest GSMA Mobile IoT Rollout Report, NB-IoT is leading in adoption. These rollouts are not tied to expensive 5G infrastructure, so MNOs are investing incrementally.

    After towers are ready, the last piece is support for Remote SIM Provisioning (RSP). Cellular IoT devices typically work with an eSIM like in the latest Apple iPhones, with one major difference. An iPhone user scans a QR code, pulling a profile over RSP.

    Pushing Across Networks

    Cellular IoT devices use a push model for RSP. When an edge device with an eSIM powers up, it uses a bootstrap network profile. It can then communicate with an RSP server to load an operational profile of choice. With this over-the-air profiling one device configuration can go practically anywhere in coverage. It opens powerful use cases such as agriculture or oil and gas, with wide-spread sensors in both indoor and outdoor settings.

    All this happens without a DevOps team planning and investing in infrastructure. MNOs are making the major investment. The variables for IoT application developers are network coverage, operator profile creation and setting up devices for streaming. If one MNO proves costly or unreliable in a specific location, devices can receive another profile over the air.

    Cellular IoT can deploy one sensor, or many, without a gateway. The cellular IoT advantage becomes even stronger with more dispersed locations. A simplified network architecture looks more like the IoT should look–with every device addressable.

    Alternatives exist because they serve some use cases well, with some persisting for years after new technology arrives. For some DevOps teams risk is a strong factor, and they may prefer the control a gateway-based architecture offers. In tight sensor clusters, the life cycle costs for a few gateways may turn out lower. If gateways aren’t cutting it for an application, they may go away quickly with cellular IoT rollouts.

    I see ubiquitous coverage driving cellular IoT momentum. Providing IoT services is a priority for mobile network operators as consumer growth flattens. There are plenty of resources for understanding cellular IoT technology in depth–get in touch with me if I can help point you in the right direction.

    — Don Dingee

  • Survey Surfaces Uneven Approaches to DevSecOps

    Survey Surfaces Uneven Approaches to DevSecOps

    A ZeroNorth survey shows implementing DevSecOps is rife with questions for many organizations, with no clear answers

    There’s general agreement that digital business transformation initiatives are driving an overall acceleration in the rate at which applications are developed. At the same time, however, given the critical nature of those applications, cybersecurity has never been more of an imperative for DevOps teams. The challenge they are encountering is not so much a lack of tools to address that requirement, but rather a lack of clarity in terms of what tool to use when.

    A survey of 57 cybersecurity professionals conducted by ZeroNorth, a provider of a platform for orchestrating vulnerability scanning tools, highlights the extent of the DevSecOps challenge. The survey finds 63% of respondents said their organization currently employs six or more scanning tools. The most widely employed are network scanning (53%) and vulnerability scanning (51%). However, a quarter (25%) don’t know if their organization is using interactive application security testing (IAST), while 19% don’t know if they are using software composition analysis (SCA) tools.

    As far as DevSecOps is concerned, there’s little to no clarity in terms of where to primarily focus scanning efforts. Build/CI environments (68%) receive the most focus, but 46% are focused on scanning within integrated development environments (IDEs). Container/artifact management (67%), source code repositories (58%) and deployment (56%) all fall somewhere in between, the survey finds.

    There’s also no clear consensus on the merits of open source versus commercial testing tools Open source software (OSS) tools were identified as a priority for less than half of respondents (47%). However, 27% of respondents said they expect to begin using open source tools in 2020. Of the respondents currently employing OSS tools, 14% said believe these tools are more effective than commercial test and scan tools. Well over a third (39%) said they believe they are more effective when combined or customized. Just under a third (32%) said OSS tools are equally as effective as commercial options, while only 9% said they are less effective.

    The survey also shows disparity when it comes to the various areas that make up a digital business transformation, with the most mature being cloud migration (80%), followed by DevOps (67%), continuous integration/continuous delivery (CI/CD) (62%) and microservices (62%). Overall, 79% of respondents said they have a digital business initiative underway.

    ZeroNorth CTO John Steven said it’s clear that in many cases, the need for faster iterations of application development is outpacing the operational capabilities of IT organizations, especially when it comes to DevSecOps. Given the chronic shortage of cybersecurity professionals, there may be an average of only one cybersecurity professional for every 100 developers. Having cybersecurity professionals participate in every scrum session isn’t feasible, so there needs to be a way for cybersecurity professionals to provide guidance to developers specifically when it comes to what scanning tool should be applied and when, said Steven.

    The survey finds network (53%) and vulnerability (51%) scanning are the most broadly employed. However, that also suggests that many IT teams involved in digital business transformation initiatives are not making use of scanning at all.

    The good news is that survey respondents said identifying bugs, flaws and vulnerabilities throughout the software development life cycle (SDLC) is either “extremely” (58%) or “very” (42%) important to all participants involved. A total of 47% said it was either “extremely important” or “very important (35%) to improve visibility around operations by integrating security earlier into the software development life cycle (SDLC). However, while the DevSecOps spirit may be willing, the ability to implement best DevSecOps practices is still clearly weak.

    — Mike Vizard

  • Privileged Access Management at the Speed of DevOps

    Privileged Access Management at the Speed of DevOps

    Privileged access management (PAM) is clearly a very important element of effective cybersecurity. PAM has been ranked number one on Gartner’s Top 10 Security Projects for two consecutive years, and it is number four on the CIS Top 20 Critical Security Controls. The struggle for many organizations, however, is they have also embraced DevOps culture, and the traditional approach to PAM clashes with the principles of a DevOps environment. Thankfully, it is possible to effectively manage privileged access in a DevOps environment—it just takes a new approach.

    Challenges of Privileged Access Management

    Despite advances in identity and access management and the existence of things like two factor or multi-factor authentication and biometric authentication, most organizations still rely on a simple username and password to authenticate an individual and grant access to network resources, applications and data.

    The concept of least privileged access—ensuring that users only have access to things they really need access to—has been preached since the dawn of cybersecurity and, when done right, can be an effective strategy. The problem is it’s tedious to do right and it’s very easy to lose track of who has privileged access to what.

    That’s where a PAM solution comes in. The whole point of privileged access management is to provide a way to track and manage who has access to what—to grant access when it is needed and revoke access when the need no longer exists. Unfortunately, there is a lot of confusion about PAM and the effort to manage privileged access is challenging for many organizations.

    Enterprise Management Associates (EMA) conducted a survey on the state of privileged access management. The survey included responses from companies representing different company sizes and industries around the world and focused on IT and cybersecurity professionals—most of whom are familiar with PAM and are directly responsible for managing or granting privileged access to users.

    There were some concerning findings from the survey regarding the perception of PAM. Twenty percent of organizations that reported using a dedicated PAM solution believe it somewhat or greatly reduces user productivity. Many respondents also expressed frustration about the amount of time required to manage privileged access. Half of the survey participants cited manually granting temporary privileges as either very (29%) or extremely (21%) time consuming, and half also said manually revoking temporary privileged access as very (33%) or extremely (17%) time consuming.

    PAM and DevOps

    As challenging as traditional PAM solutions might be for businesses around the world, they pose an even greater hurdle for organizations that have embraced DevOps. A recent episode of the Defense in Depth podcast, hosted by David Spark and Allan Alford, focused on some of the challenges of PAM. A listener had written to complain that “the traditional approach to PAM breaks everything that is DevOps. Regardless of what your PAM provider says about their ability to scale with your dev cycles, they’re lying about the real level of effort.”

    That seems like a fair assessment. Pretty much every company is somewhere on the cloud journey—and working within a DevOps framework on some level. Companies often face backlash from the DevOps team—with some going so far as to boycott efforts to introduce security tools that can’t keep up with the pace of DevOps in the cloud.

    DevOps developers express frustration about trying to build an automatic scaling, horizontal infrastructure and being dragged down by demands from the security team to install agents and change authentication modules. They complain it often means rewriting all of the scripts, resulting in significant and unnecessary effort for a solution that ultimately can’t scale properly in the DevOps environment.

    That is, unfortunately, true when it comes to traditional PAM solutions. Next generation PAM solutions, however, are built with the cloud and DevOps in mind. They are lightweight, automated, scalable and capable of integrating seamlessly with common tools and platforms.

    Rethinking Privileged Access Management

    Based on the survey, organizations understand the importance of privileged access management, but they struggle with finding a way to implement it effectively. The question from the podcast illustrates how PAM is also a significant issue for DevOps environments because traditional PAM solutions do not integrate or scale effectively.

    At the same time, we all know that PAM is a crucial element of effective cybersecurity. It’s not acceptable to just not manage privileged access, but it also doesn’t make sense to suffer through the headaches and frustration introduced by traditional solutions. Organizations need to find new privileged access management tools that work in the cloud and can scale automatically to provide PAM at the speed of DevOps.

    — Tony Bradley

  • CircleCI Achieves SOC 2 Compliance for DevOps Platform

    CircleCI Achieves SOC 2 Compliance for DevOps Platform

    CircleCI has achieved a SOC 2 compliance rating for the DevOps platform it makes available via a software-as-a-service (SaaS) model.

    Tad Whitaker, security manager at CircleCI, said CircleCI is the first provider of a SaaS platform for DevOps that has invested the hundreds of thousands of dollars required to achieve SOC 2 compliance.

    SOC 2 compliance requires organizations to pass an annual audit based on the Trust Services principles and criteria defined by the American Institute of Certified Public Accountants (AICPA). That criteria evaluate IT environments on everything from the cybersecurity controls they have in place to the integrity of the data management processes employed. A SOC 2-level certification means DevOps teams can have confidence in the fact that their data is being kept completely confidential, said Whitaker.

    With interest in best DevSecOps processes on the rise, Whitaker noted more organizations are starting to ask questions about how data is managed and secured on the cloud services they rely on to build and deploy applications. Cybersecurity professionals who are now participating in those processes are starting to ask challenging questions. To address those concerns, Whitaker said CircleCI created a team within the company to first attain SOC 2 compliance and, now, maintain it.

    That may lead to additional processes and controls being put in place, but DevOps teams can be confident that everything possible is being done to secure their data from prying eyes, including employees of CircleCI.

    A lot of the data being employed to build new applications is among the most sensitive an organization is likely to possess. As organizations embrace DevOps practices to drive digital business transformation initiatives, there’s a much greater need to ensure the DevOps environment is secure end to end. However, most of the DevOps platforms delivered as a service today are not able to validate the level of security they claim to have put in place, said Whitaker.

    It’s unclear how many organizations are going to insist of SOC 2-level certifications before agreeing to develop applications on a specific DevOps platform. However, SOC 2-level certifications are routinely required for cloud service providers so it’s only a matter of time before the same audit requirements are applied to other cloud services. The challenge will come when DevOps teams have to adjust their existing DevOps processes to accommodate the security processes that SOC 2-compliant cloud service providers are required to make.

    In the meantime, the days when DevOps teams could employ cloud services to bypass cybersecurity policies are coming to an end. Cybersecurity teams are finally catching up in terms of figuring out how to enforce cybersecurity policies beyond an on-premises IT environment. Not every DevOps team may appreciate the impact those policies may have on productivity. However, if the alternative is to have sensitive data that DevOps teams are now being held accountable for exposed on the web because of careless processes than the time to come to terms with cybersecurity has finally come.

    — Mike Vizard

  • IBM Zones in on DevOps for AI

    IBM Zones in on DevOps for AI

    IBM this week revealed it has added a drift detection capability to the Watson OpenScale platform to govern artificial intelligence (AI) models that will become a foundational piece of IBM’s approach to defining best DevOps practices for building AI-infused applications.

    Rohan Vaidyanathan, program director for IBM Watson OpenScale, said one of the biggest AI issues organizations face today is determining when to update or replace an AI model. Announced at the IBM Data and AI Forum event, the drift detection software added to Watson OpenScale provides a continuous monitoring capability that detects how far an AI model has moved from its original parameters, Vaidyanathan said.

    Drift in AI models usually occurs over time, especially as use cases change in ways that are unexpected. Once that drift is detected, organizations eventually want to either retrain that AI model or replace it with a new one. The process challenge organizations face when building AI applications is first assembling the right data to train the model and then integrating that model within an application as part of a continuous integration pipeline.

    With each interaction with an AI model, the result returned to the application might be different as the machine learning algorithms embedded in the AI model continually learn about the process the application abstracts.

    As it turns out, Vaidyanathan said, only one in 20 of the AI models being built make it into production applications, largely because organizations have not bridged the divide between DevOps teams and data scientists effectively. The drift detection capability IBM has developed is a “missing link” that will enable those two teams to begin collaborating more closely, he said.

    IBM has already defined a set of best practices for building AI models as part of its Watson Anywhere initiative, which seeks to drive adoption of the various elements of the Watson platform on multiple clouds. Rather than forcing organizations to load data into an IBM Cloud to use Watson, IBM is working to bring the various engines and application programming interfaces (APIs) to wherever data resides.

    Naturally, IBM would prefer organizations employ the opinionated DevOps and DataOps processes it defines as best practices for building AI models using its tools. However, Vaidyanathan acknowledged there is likely to be plenty of instances in which organizations will prefer to define their own DevOps processes. The hope is those organizations will still access Watson services and metrics using the APIs that IBM has exposed.

    The challenge IBM is encountering in terms of driving AI adoption are manifold. In addition to trying to get data scientists to appreciate DevOps, IBM recognizes AI models are only as good as the data employed to train them. Unfortunately, many organizations have been lax when it comes to data management. As a result, many of them are now revisiting broken DataOps processes. IBM Watson OpenScale and IBM Cloud Paks for Data, a set of portable data virtualization and management tools deployed as microservices, are part of an effort to bring both explainability and order to the building of AI models.

    Obviously, it will take some time for organizations to extend best DevOps practices to incorporate AI models. But at this juncture, it’s more a matter of when rather than if that goal will be achieved.

    — Mike Vizard

  • Virtual Instruments Changes Name to Virtana to Drive AIOps

    Virtual Instruments Changes Name to Virtana to Drive AIOps

    With the formal launch of a software-as-a-service (SaaS) to monitor cloud platforms and optimize cloud, Virtual Instruments today renamed itself Virtana.

    The company’s CloudWisdom platform is based on technology Virtana gained via the acquisition of Metricly earlier this year. In addition to being integrated with existing on-premises offerings from Virtana, CloudWisdom has been expanded to include a self-service option. Downloadable trial versions are also available.

    Virtana CEO Philippe Vincent said the name change reflects a transformation from being simply a provider of storage I/O performance testing tools to becoming a provider of an IT operations management platform infused with artificial intelligence (AIOps). As part of that effort, the CloudWisdom offering represents the first time Virtana has extended the reach of its offerings beyond on-premises IT environments, he said.

    CloudWisdom will differentiate itself, Vincent said, because it combines cloud monitoring with built-in tools for optimizing cloud costs. Rival offerings require IT organizations to acquire two separate services, he noted. The CloudWisdom platform monitoring capabilities span databases, messaging platforms and containers, as well as cloud infrastructure services from Amazon Web Services (AWS) and Microsoft.

    In general, Vincent said IT organizations are moving away from a reactive approach to managing IT to a more proactive approach that will require increased reliance on automation. As IT environments become more complex, too many IT organizations are trying to compensate by overprovisioning IT infrastructure resources to make sure application performance doesn’t deteriorate or applications crash. That approach not only drives IT costs higher, he said, but it also makes those costs unpredictable.

    To address that issue, Virtana is combining CloudWisdom with an AIOps platform designed to be equally applicable in legacy IT service management (ITSM) and emerging DevOps environments. Organizations that have adopted DevOps will be at the forefront of the transition to AIOps because of the inherent fluidity and velocity of those environments, Vincent noted. Machine learning algorithms coupled with real-time monitoring, big data analytics, workflow engines and automation frameworks will enable IT teams to streamline ITSM and DevOps processes to become more efficient. The opportunity for Virtana is to disrupt a highly fractured monitoring category by leveraging AIOps to unify monitoring at an unprecedented level of scale and scope, he added.

    Virtana is not the only IT management platform provider that has identified the same opportunity; much larger incumbent providers of these platforms and a raft of startups are moving in the same AIOps direction. Vincent said Virtana will differentiate itself by pursuing a more application-centric approach to delivering on the promise of AIOps.

    It’s too early to say to what degree IT operations can be automated using AI. There’s general agreement that AI will play a significant role in automating IT, and the more standardized the IT environment is, the easier it is to accomplish. The challenge is, most IT environments today are still anything but standardized.

    — Mike Vizard