Category: DevOps in the Cloud

  • EP 3: Open Source and DevOps

    EP 3: Open Source and DevOps

    In the third episode of our DevOps Unbound streaming broadcast on TechStrong TV and DevOps.com’s sister site Digital Anarchist, Alan Shimel is joined by Kevin Dunne of Tricentis, Tracy Miranda of CDF and Alon Girmonsky of UP9 to answer the question: Can we have DevOps without open source?

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

    Transcript

    Alan Shimel: Hi everyone. Welcome to another episode of DevOps Unbound. DevOps Unbound is sponsored by Tricentis, so many thanks to them. But it’s our show here at MediaOps and we try to explore, you know, just some of the areas around DevOps and not just dev and ops but DevOps as a framework for the way things are being done, the way application and software is being made and deployed today, the way it’s being hosted, the way it’s being operated and maintained and observed, and so many other aspects of how we’re doing technology. 

    It airs every other week and this episode is episode number three of DevOps Unbound. Hope you’ve enjoyed the first two.

    With that let me introduce to our panel today. First of all, well, it may not be right or left on your screen, because so it makes no sense to tell you how it is on my screen, but let me first start off with my friend, Tracy Miranda. Tracy is the executive director of the Continuous Delivery Foundation, which is a Linux Foundation and a sister organization to Cloud Native Computing Foundation. Got that all out of the way. Tracy, welcome. 

    Tracy Miranda: Hi everybody and thanks for having me Alan. 

    Shimel: My pleasure to have you on Tracy.

    Joining Tracy and I today, I have Kevin Dunne, who has been on our TechStrong TV in the past. Kevin is with Tricentis and runs their open-source communities, as well as some of the open-source projects that are now under their management, some by acquisition over the years, some they’ve developed themselves. But Kevin, welcome to DevOps Unbound. 

    Kevin Dunne: Thank you, Alan. Happy to be on and glad you’re having us back with you again. 

    Shimel: That’s our pleasure. 

    Then last by not least is my friend, Alon Girmonsky. Alon is the CEO/founder of UP9, that’s U-P-9. He’s going to tell us about that when I ask everyone to introduce themselves here in a moment, but Alon was also the founder/CEO of BlazeMeter, a very well known open source or player in the open-source testing world acquired by CA, which of course became Broadcom. 

    So, today’s episode ladies and gentlemen is around DevOps, cloud native and open source more importantly, most importantly, and how important open source is to this whole DevOps movement and this whole — Someone today, I had someone from Deloitte Cloud on and I was doing an interview called it a “revolution” that we’re seeing, especially since COVID, right? IT has undergone a revolution of cloud transformation, digital transformation, acceleration and so much of it is made possible by open source. So that’s our subject today. 

    Before we hop into it I wanted to give each of you like 30 seconds, just in case our audience wanted more than the cursory kind of introductions I did. Why don’t we start with you Kevin? Give them who you are, your background and we’ll jump through all three of us from there. 

    Dunne: Yeah, that’s great. My name is Kevin Dunne. I’m with Tricentis as Alan mentioned. My main focus is on our open source and sort of community products. I’ve been with Tricentis for seven years. Prior to Tricentis I was at QASymphony, which merged with Tricentis about two years ago. So very passionate about open source, it’s been sort of a new area that Tricentis has been getting into. 

    There was a lot of work around Flood, which was built on top of JMeter and Gatling and now Tricentis has acquired TestProject which is built on top of Selenium and Appium and most recently SpecFlow which is an open source project based on cucumbers. 

    So I’m really excited to see how these tools are helping to kind of shape the Tricentis roadmap and sort of broaden the community in the open source supports, so very exciting projects going on so far. 

    Shimel: Alon, how about you?

    Alon Girmonsky: Hey everyone and Alan thanks for inviting me. I’m a big fan both of Tricentis and obviously the CD Foundation. Alon Girmonsky as you mentioned my current company UP9, which I have the privilege of being cofounder in, deals with microservices and cloud native in respect to testing. Testing is something that is becoming harder and harder to do, especially when you know you talk about service testing and API testing. So UP9 provides a solution for somewhat autonomous, mostly automatic you know service testing. 

    As you mentioned prior to that my previous company, BlazeMeter, was all about load testing and stress based on the open-source tool JMeter. You know I had the pleasure over the past 10 years to be involved in the open-source community and understand or at least try to understand what’s the place of open source and why is it so important specifically for developers. I’m very happy to have the opportunity to discuss this in this forum. 

    Shimel: Last, but not least Tracy how about you?

    Miranda: Tracy, I’m the executive director of the Continuous Delivery Foundation or CDF, which is an open-source foundation with the mission to improve the world’s capacity to deliver software with security and speed. The CDF is home to the open-source project Jenkins, JenkinsX, Tekton and Spinnaker. 

    Before that I was leading open-source community at CloudBees. In general I’m a 15-year veteran of open source, so I love all things open source, open innovation and building communities. 

    Shimel: Excellent. So folks, here’s my opening premise and we’ll let — it will be our jumping off point. 

    I also have a long involvement in the open source world. I first got involved in open-source security related projects 2002, 2001 and we were blessed in security to have some amazing open-source tools at our fingertips. Products like Snort, which was developed by Marty Roesch, who then started Sourcefire, acquired by Cisco, was the de facto standard for intrusion detection. The NMap and Nessus scanners, Renaud Deraison, who’s cofounder over at Tenable Network Security and Ron Gula, who started Tenable with Nessus. NMap has been out there. There were many others, ClamAV and so many commercial companies actually sprang up just by using that open-source software under the covers putting a UI on it and stuff. 

    So I’ve seen open source. I remember talking to CIOs and I remember speaking to you know a DOD agencies about their use of open source and they would tell me that they don’t have any open source, they don’t allow open source and then you would go look at what their developers were working on and it was all open source, you know it was Linux and everything else that they had, just didn’t bother telling them about. So I’ve seen open source become from a gorilla-type of operation in many environments, to the dominant form of software and software development today. 

    When I got into DevOps it became really apparent to me and this is my jumping-off point, we wouldn’t have DevOps without open source. I just don’t think — I think so much of what we can consider not only the tools of DevOps, so specific open-source projects, but the culture of DevOps, the collaboration, the sharing of knowledge of DevOps is based upon that open-source mindset, on the open-source culture that you couldn’t have DevOps without open source. 

    Tracy, you ran the open-source community of CloudBees first and only ED at CDF, part of Linux, what’s your feeling on that? Why don’t you kick us off? 

    Miranda: Yeah so definitely as a big fan of open source I’ve seen how it’s been really instrumental to DevOps. I think you know one of the things that open source does really well, like sometimes people focus just on the code, but it is really all about that collaboration, how people work together. I think at the heart of DevOps really what it’s trying to get at is building bridges, getting people to work together even if they are in slightly different spaces, whether you know it’s DevOps COPs who are trying to bring security practitioners closer to developers or ops people closer to developers. I think open source really captures that spirit of collaboration and that’s why it’s become almost synonymous with DevOps. 

    Shimel: Kevin, Alon, what do you think? 

    Dunne: Yeah, I mean I would definitely agree with that. I would say one other thing that you know of the many benefits of open source, right, is kind of just the transparency and visibility. I think you know a lot of companies were finding like DevOps in the CI/COVID process especially is kind of integral to business success, right? So a lot of companies are very hesitant to put a tool in place that is going to be that critical to their success unless they’re able to you know fully understand what it does, you know any limitations that it has, you know extended where needed and you know kind of have that ability to build on top of it as well.

    I think way too many companies kind of got burnt a bit by you know solutions that were completely closed source, didn’t allow customization and things like that. Then you know they kind of get stuck when you know something breaks. So they reach the limits and the vendor is not able to you know update that for them. So I think that was one of the big things about you know the whole Jenkins’ community, right, as you just see how many plug-ins and other you know ways people come up with of extending the tool that you just would never see from a closed-source product, right. So I think that’s been something as well as just kind of like the ability to have the transparency into how something works and be able to extend that to fit your own needs is pretty critical to DevOps success I think. 

    Shimel: Yeah, I, I agree. Alon, you more than I think even Tracy and Kevin I mean you built a business with a successful exit on an open-source kind of business model if you will. You know what’s your view on… Is, can, is it a chicken and egg? Can you have DevOps without open source?

    Girmonsky: I think if we go back even in more than a decade there was open source and there were commercial offerings, right? There was an inherent conflict between the two. 

    I think that if you fast forward for today it’s about product market fit. I think open source needs to be part of any product as long as it involves developers, maybe even more than developers, but developers as Kevin kind of mentioned we talked about transparency I think developers need to have control. They cannot rely on someone else to have a black box. So anything from transparency, having control, not having dependency. You know if you think about speed to market the more control you have your ability to change quickly you know the faster you can go.

    So what we’ve learned over you know the past decade the developers they need to have the open source not because it’s free. I think that’s the last aspect of open source. It was in the past it was free and a poor man’s solution. Today you want to have open source because you want to maintain control, visibility, transparency and reduce the dependency on other vendors. That’s kind of my key learnings you know from my experience. 

    Shimel: Yeah. I mean that reminds me of something I’ve always been taught and heard about open source and that is look with open source it’s free as in freedom and free as in beer, right? It doesn’t cost, it’s free as in beer, right, free beer for everyone. But really though that was a big driver, you’re right Alon that was a huge driver and remains a huge driver that people can just pick up this software and run with it. And if at some point they want to buy an enterprise license or an enterprise version or go to a vender that has a supported version they can pay for it, but they can use it for free today. But more importantly than that is the freedom as in freedom, right? In that it gives them the transparency, it gives them the ability to see exactly what it is they’re getting themselves into as Kevin pointed out. 

    But to me that’s almost turned the original problem on its face. Tracy you’ve been in these, in this open-source world longer, as long enough, right? In that originally that was also one of the big shortcomings of open source, right, is that everybody, everybody sees the source code, hackers or whoever will more easily exploit that source code or can break in or can see what’s going on. And whom am I going to call, Ghostbusters, right, for support and to fix this thing, right? 

    And so how can I as an enterprise you know based my business on open source? Is it reliable enough, secure enough, supportable enough? But yet we seem to have overcome that. One of the reasons I think, Tracy, is because of the advent of foundations like the CDF, right? So talk about that if you will a little bit. 

    Miranda: Yes, yeah, no absolutely. Like I think well first of all I want to make it clear like you can still have DevOps with a proprietary CI/CD stack and there’s plenty of offerings out there. But I think the key thing where open source plays a big role is it’s really in driving the innovation across the industry, making it so people can leverage it in different ways, combine it and get that interoperability to you know produce things that solve their problem. 

    And the way foundations have really helped is dealing with some of the issues or you know sometimes there have been misconceptions with open source, but sometimes they are genuine problems, which you know fall in the gaps of well maybe the developers on the projects want to focus on the code and there are other things we can do across multiple projects to help you know whether it’s focusing on security or focusing on building communities that are diverse. So open-source foundations have just added that extra layer to give the industry confidence that these are trusted projects that are being well sustained and people can rely on them to either build products or use in their own CI/CD stacks and really just kind of push, push things further I a good, positive direction for the whole industry. 

    Shimel: I’m going to comment or not disagree, but I wanted to distinguish and clarify something you said there Tracy and that is yes there are closed source or commercial or whatever you want to call it CI/CD solutions out there. But even they and we report on them at DevOps.com right, even they rely on open-source integrations, open-source components. 

    I mean you look at Alon with what you’re doing with UP9, with UP9, with what you did in BlazeMeter. Kevin when he talked about the three or four different open-source kind of based tools that Tricentis is doing, they’re all based on open source. When you go under the covers they’re closed source but they’re based on open source, things like Selenium and these kinds of things. 

    So you know even in the CI/CD space and I’m not here to name names, but we know the closed source you know CI/CD players. I don’t think they’re product works well if you didn’t have an open source kind of framework that they plug into. I think it’s especially true in the testing world. I think Alon you’re living proof of that, right? Could you have had a BlazeMeter without having some of those great open source? Kevin all of the projects you mentioned are based on open source, right? Can you have any of them without open source? It’s a real you know … 

    And guys don’t wait for me to ask your name, feel free to jump in here. 

    Dunne: I think it’s a good point. It’s becoming more of the model like Alon was you know mentioning is it’s kind of you stand on the back of giants a lot of times, right? So I think you know you see a lot of the at least in the testing space, right, BlazeMeter, Sauce Labs, BrowswerStack, you know a lot of these bigger companies they’re succeeding by basically doing what you were talking about with the security tools 10, 20 years ago, right? 

    Take an open source community and kind of you know build something on top of that, right, that provides value, but still is kind of using this known currency of this open-source project. I think people like that because you know by the time they get to buying that commercial solution they’ve got a lot of confidence in the open-source components that have reached a you know critical kind of juncture where they’re bought into those tools enough that they’re willing to invest in something you know commercial to help support it and you’re solving real problems, right. 

    You mentioned you know free and open source being free, but you know everyone knows one of the big challenges with open source is just the amount of time that you have to invest a lot of times to customizing it, deploying it, you know patching it, upgrading it, dealing with security concerns. And so you know a lot of these vendors come in and they solve a real problem, but I think it is a little bit of a you can put the cart before the horse, right? 

    The people need to adopt the open-source tool, see that it works, feel the pain of you know what it’s like to manage it on their own and then you know usually graduate to these commercial solutions. I think when people come and try to present the commercial solution upfront without that open-source community you know it kind of fails because you haven’t proven the value yet, right? And it’s a big jump for people to make and that’s you know been a good thing in the market having open source. It’s kind of put the power in the hands of the users that you know users get to call the shots first and the user expects you’re going to give me some value in this open-source tool before you start to charge me an arm and a leg, right? 

    Miranda: I like the analogy, free as in free puppy, so we can have it, but you still have to take care of it, feed it, and keep it from pooping on the carpet. 

    Dunne: Exactly yeah. 

    Girmonsky: Yeah. 

    Dunne: And that takes a lot. 

    Shimel: Alon? 

    Girmonsky: I think I’ve learned a good concept a couple of years ago, kind of the open core concept. It wasn’t there ten years ago, but then you understand okay this is what, what we’ve been doing all along. The ability to open your core, the core of your platform, the core of your offerings. So you know your user will have more flexibility. Maybe the use case is a bit different than what you had in mind initially, right, by having an open core or an open-source project that you’re basing on, right, you allow the users to build their own use cases and then bring value that again the product market fit is in my view better than anything that has close and this is what you can do with it and that’s it. 

    Shimel: Agreed. So Tracy you know the CDF is a great model for the kinds of stuff we’re all three of us are talking about, right? You have in essence this four main properties or projects that CDF manages. Each one of them is closely tied to one or more commercial entities that solutions are based upon, right? But yet the community revolves around the CDF. By the way it’s the same thing in the CNCF, right, where you have Kubernetes and you have you know a lot of Kubernetes service providers that manage Kubernetes, but the community lives around CDF. 

    What are you seeing here? Like where is that handoff? Where is the you know passing the baton from that open-source user to the commercial entity? 

    Miranda: Yeah, no I think that’s a great question. What we see, well certainly what I’ve seen over the last 15 years is it’s an ever-changing line if you like. So when we talk about innovation you know we have these open-source projects and we don’t want people to be reinventing the wheel over and over again. Like take something like pipeline orchestration. You know when it gets to a point where that’s pretty ubiquitous then that’s a good thing to have as an open source you know kind of standardized in one project. 

    Then we can move up the stack into new innovations and vendors can lead that charge of take open-source projects and try to build things on top of that that add new things to the industry. As those become more and more ubiquitous then you know it probably eventually will get an open-source solution and then people will sort of move onto the next thing. 

    So I think it’s always kind of this tide as such where the more kind of proprietary things will test out the beating edge and where they can get value for using some things that haven’t been done and then open-source projects become like the infrastructure, the roads, and the bridges and things like that. 

    Shimel: Fair, guys any comment on that?

    Dunne: Yeah I think that’s true. It’s kind of tough though puts vendors in a tough position, right, where it’s like you know you have to – it really raises the bar, right on delivering innovation, right, because you know all of the… It’s kind of a commoditization, right, that you know things that have been in the market for 10, 20 years you know the market, the commercial market for those sort of erodes and you know it gets replaced by open-source tools. And so it’s always kind of playing that game of being the you know next hand-up on the baseball bat. 

    You know it’s just like your always – if you stop innovating there’s… I think that’s why you see you know the SAS model being really popular with a lot of these software companies is just they need to keep innovating, right, and you can’t just like you know expect to sell a tool, a licensed tool and you know have a customer use that for ten years and collect maintenance from them. Like these are – all the tools that are you know demanding good budget from companies are really you know evolving quite quickly. So it’s really put a lot of pressure on vendors to innovate, otherwise they’re going to become stale and replaced by open source pretty quickly, which is a good thing for the uses of these tools I think at the end of the day. 

    Shimel: I also think that’s to Alon’s point that’s why OpenCore is such a great model for this, right?

    Dunne: Yep. 

    Shimel: Because you can’t – you can keep innovating at your core and then have your freemium, premium, whatever you want to call feature set kind of revolving around that core and keeping people, “Okay now that’s why I should pay money.” 

    Dunne: Right. 

    Shimel: So –

    Miranda: And I think –

    Shimel: Go Tracy. 

    Miranda: And I think we’ll increasingly see companies kind of use that to change the dynamic in the market and then they can use open source almost as a weapon to drive commoditization by saying, “Okay well this thing that was a premium feature for a number of vendors, we’re going to open source our vision” and you know suddenly change the dynamics. So it is real interesting because, yes, I think SAS services will make a big difference and everybody in the industry has to be on their toes constantly. 

    Girmonsky: Absolutely. By the way a way to compliment this is think of you know we used to live in an industry where the big vendors provide point tools, value, do something that you haven’t done before. Today, with developers it’s very hard to think of having an infrastructure that is not open source, right? So let’s assume the entire infrastructure is open source whether by vendors, by developers, or by big cloud like you know Netflix, Amazon and others. Then the next layer is efficiency and productivity. Then the commercial vendors they can provide impact by, you know, this is what I have done in BlazeMeter. It wasn’t — BlazeMeter wasn’t a load-testing tool. I think Flood was the same. It’s JMeter was the testing tool. 

    Dunne: Yep. 

    Girmonsky: BlazeMeter back then was all about making JMeter more efficient and the developers more productive. So suddenly LoadRunner wasn’t like, okay there is an alternative to what was de facto commercial tool, okay it’s the open-source tool, but as you said open  source on its own it’s pretty tough. So you know here come the vendors that make our lives more productive and use of open source more efficiently. 

    Shimel: Agreed. Kevin, Alon I’m going to put guys on a hot seat here for a second. You know what CNCF has been wildly successful in so many of the projects that they’ve incubated and now graduated and have been tremendous successes. Tracy, CDF is only what about two years old now? 

    Miranda: Yeah, not even. 

    Shimel: Yep, they’ve got four pretty amazing CD tools that are kind of de factor standards, right, that people are gravitating around. With such a strong heritage of open source and testing and continuous testing, automation, why haven’t we seen sort of the equivalent of the CDF in the testing world? Right? Why hasn’t the Linux Foundation or some other, Eclipse or Cloud Foundry or something or a new one sprung up that says, “Hey, we’re going to take these individual projects you know out of hands of individual company and do a community thing”? It may be a case of what, don’t break what’s, don’t fix what’s not broken, right, because it seems to be working the way it is. But why don’t we see a foundation for open-source testing? 

    Dunne: That’s a good question. I mean I think you know if I had to guess the main reason probably is just that you know testers are sort of developers, but sort of testers, right, and like an automated tester kind of falls in between the gap of maybe both and some view themselves as developers, some view themselves as testers. 

    I feel like it’s starting to happen. If you look at some of these tools like Cypress for example. You know the newer tools that are emerging definitely they’re communities have much more of like a developer feel around them and there’s much more structures of the open source contributions and whatnot. 

    But you know historically it was definitely very fragmented and you know the load testers all kind of rallied around JMeter and Gatling and you know the web testers around Selenium and the mobile testers around Appium. There’s really no common thread. I guess it’s kind of more like more siloed, right, versus my guess would be you know these tools like Kubernetes and you know Spinnaker or Jenkins, I mean those are ubiquitous, right? I mean everyone whether they’re building you know a web app you know in Java or in you know C# or whatever can use these tools versus I think a lot of the testing tools because they’re kind of like a thought you know into the decision that’s made after you make some decisions oftentimes on your kind of app infrastructure. That’s why they’re sort of thought of as maybe – they were historically thought of as more of an afterthought and the communities got more fragmented as a result of that. 

    But I think that is starting to change. I mean we know and we talked about these results on the last time I was on with you, Alan, you know that testers are becoming more and more like developers and becoming more technical, right? So I think the tools you know are going to demand to change this community structure, but it will take time but I think we’ll start to see that over the next few years my guess. 

    Shimel: Alon?

    Girmonsky: Yeah I think that if you look at the industry, the open-source industry for past second decade you know prior to CNCF there as Apache, right. 

    Shimel: Yeah.

    Girmonsky: Yeah and it was kind of you know in many ways the collection of open-source tools that if you’re in Apache open-source tool you’re probably in good. And now we see it’s not about open sources, it’s about what you do. Right? CNCF started mostly as Kubernetes and you know other tool and now the CD Foundation I think the focus is kind of all you know on the development lifecycle, as opposed to point tools and use cases it’s about the entire flow. 

    Actually I feel very comfortable. You know if testing finds its right position under CD because in CD you build, you test, right, these are the operations you do day-in-day-out. I would hesitate from having too many because it will kind of defocus many people, “I may do this,” “I may do that,” “Is it different?” Having like you know a family to belong to which is the continuous delivery continues deployment maybe in the future. I think it’s actually you know not a bad direction to take. 

    Miranda: Yes, absolutely and I think you’ve hit spot-on like CD continues deliveries is a process and I think that process does include testing and although we started off with these tools, which are all pipeline orchestration I’d love to you know CDF to future more open-source testing tools and certainly a lot of the conversations we have around interoperability testing comes up a lot. You know people are like, “Why isn’t there a standardized way to show pipeline results, the test runs” and why don’t we strive for that? That’s you know a problem that lots of end users highlight. So yeah, I’m all for you know having CDF be a place where we can have more of the testing community come together, seed, expand beyond kind of the traditional developer or and just make folks feel included in that community. So yeah, we should definitely talk. I like the direction [crosstalk]. 

    Shimel: So you heard, you heard it here first on DevOps Unbound. Alon, Kevin you have her contact info. 

    Dunne: Oh yeah. 

    Shimel: Let’s see some testing projects being part of CDF, right? Let’s bring it together. 

    Alon, the next line of questioning starts with you, but Kevin and Tracy feel free to jump in. So Alon you’ve been there, done that, you did BlazeMeter as you mentioned. You build it on JMeter and some other open-source stuff, but you didn’t want to duplicate what JMeter did, you were supplementing it and building on top of it. 

    Your present company, UP9 is new, not a lot of people are as obviously familiar with it as BlazeMeter. But I remember interviewing you when we first started talking about UP9 and you said, “Look this is for now, right, this isn’t what BlazeMeter…you know we took a lot of lessons that we learned and a lot of things that we saw, but this is for today.” What makes it for today, especially from an open-source perspective, right, that was different than when let’s say BlazeMeter you know first started with JMeter. 

    Girmonsky: Yeah. So BlazeMeter dealt with a problem that was irrelevant for 2010 or 2012, it was again it was kind of moving to the cloud, the Web-scale system, but mostly around service oriented architecture, right, and WebUp monolith of the time. At this time let’s say 2020 and going forward we’re talking about cloud native and containerized system. The industry took an approach to build the system that scales horizontally, right, with microservices. When you have than a few microservices you bring in Kubernetes or Docker Swarm or ECS sometimes, right, to orchestrate. 

    But this entire new tech stack it is far more complex than it was n the past and still you need to test. You have you know you call it not reliability, you have to have reliability case. You know you develop software you don’t want to develop faults that become failures, right? So and again it’s far more scalable in the past. If we used to do one service, now we have 200 services, dependencies, individual roadmaps, what do you do? 

    So UP9 takes care of it. UP9 provides a way to first test each and all microservices, like to provide the complete test coverage, but also do it you know use machine learning to offload a lot of the work from the developers. 

    Now to connect this with open source again I’m a strong believer that it’s not this or that, it has to be both. You have to start with open source because you first need to onboard your users, right? The only way to onboard them for them to have confidence is by giving them open-source tools and not because it’s free or because I want to make a name for myself in the open-source community, because that’s the only way to start you know the operation and then you make their lives, the developers’ lives more efficient.

    So this is UP9, UP9 start with open core solution that enables testing microservices in a Kubernetes ECS Docker kind of environment, but making it no matter how many services you may have, how many endpoints, whether it’s thousands of endpoints and hundreds of services you know you get things going pretty quickly, because you know this is how you would do things these days. 

    Shimel: Understood. Kevin, Tricentis I mean Alon’s example applies directly to Tricentis, right? You have three or four projects that you’ve spoken about, acquisitions that you manage, you know you’re managing these open-source communities and project, but yet there’s, you know there’s commercial or closed-source Tricentis. Where is the integration, where’s the overlap, where’s the leverage from one to the other? 

    Dunne: Yeah it’s a good question. I mean I think we’re kind of starting to see two different I would say maybe like communities of practice you know coming out of large IT organizations, right? You have definitely what Alon was talking about which is like kind of people building these I would call “systems of engagement,” right, which are customer-facing apps, that you know have all of these challenges around how to deal with containerization. So that’s where we really target a lot of our open-source tools, right, and open-source friend tools so that those people who really developing these web apps, mobile apps, you know web services in-house. But we’re also seeing that you know there’s this other large community as well, which is kind of all the systems of record, which should be maybe your main-frame systems, your package apps, like SAP, Salesforce, you know Workday. 

    And some of those communities, like some companies are starting to really start to try to do CI/CD and things like that around Salesforce and some of these more cloud-friendly apps, but for the most part a lot of those communities that kind of work differently they have different expectations, they usually are less technical and a lot of times would actually prefer sometimes a closed-source tool to kind of match the closed-source ecosystem that they’re supporting. 

    So that’s where I think you know when you look at it you kind of wonder, “Well hey how, why does Tricentis have both closed-source and open-source tools?” But I think you’ve got to have the right tool for the job and the right tool for the user, right? And so we see that you know you can-to-go and bring a highly technical tool to you know a nontechnical user that’s trying to test you know a very legacy package application. And vice versa you can’t bring you know a commercial tool a lot of times to a developer that wants to be you know able to write code and you know implement it into their DevOps pipeline and things like that and force them to take that approach. So rather than trying to you know have one or the other group suffer we’re sort of trying to bring together a platform which provides you know different tools for the different approaches. 

    Shimel: Tracy how does that jive with what you see with some of the pipeline tools and projects and companies in the CI/CD world with CDF?

    Miranda: Yep, no I think it’s really interesting and it was great to hear that distinction. So when look at cloud native and particularly Kubernetes and things sitting on top of that, I think the state is today that you still have to be highly technical to stitch a system together and to make it work and to keep up with all the updates. So it’s far, far away from being used very effectively by folks who are less technical or folks who want to be a bit more removed and just get a certain job done, but still take advantage of you know all the benefits of these containerized cloud-native systems. 

    So I think where the open source has to evolve there is to make that a lot easier. We talk a lot about kind of the developer experience and what that looks likes, because today like it’s really confusing if you had to come in new and figure out you know what tool to start with, how to put it together, take Kubernetes itself it’s got hundreds of distributions, which one do you even start? And then there’s a lot of confusing information as well for how you make decisions. 

    I think there’s a lot we can do in open source to drive some clarity on you know what are you trying to achieve, how do you get there, and how do you make the tools work together effectively and not leave it as an exercise to the user to figure out what goes with what. 

    Shimel: Agreed, agreed. Guys were coming … You know I could sit and talk about this with the three of you for the rest of the day, but we’re coming up on 45 minutes, which is kind of our cutoff here. Tracy you’ve heard what Alon and Kevin have said. So first of all guys I’m going to hold it to you. I’d like to see you reach out to Tracy and start and I’ll help, I’ll introduce some of my other friends in the open source and testing world and you have my commitment Tracy on that. I’ll do an e-mail intro. I’d love to see some testing projects become part of CDF. I’d like to see it expand beyond the pipelines to the real tools that folks are using in these things. 

    But you know Tracy CDF as you mentioned is less than two years old. We just last week we had KubeCon CNCF, Virtual Con, whatever I think it was called, what’s in store for CDF? What should our listeners be looking for? 

    Miranda: Yes, yeah, no, we are having our first big cdCon which will be virtual. It’s a first stand-alone event we have for bringing all the communities together. Because of COVID you know we’ve had to pivot quickly to going virtual. So you know it’s not going to be the same as in person, but it is going to be a really good way to bring people together and get that interaction. 

    So cdCon which October 7th and 8th and registrations are open now. That will be yeah just a really good way to come in and figure out what is the state of continuous delivery today and lots of different tracks on specialist topics and cloud native and of course lots and lots of open source. 

    Shimel: Don’t miss it. So that cdCon, October 7th and 8th, highly, highly recommend it. I’m sorry my Apple watch was ringing. There we had to shut that off quick. 

    Thanks Tracy. People can get information at that at CDF? 

    Miranda: Yes, as cd.foundation and find details there.

    Shimel: Great. Kevin, news around Tricentis open-source projects and products. 

    Dunne: Yep, yeah. I think for us you know like Tracy mentioned we’ve got to go virtual this fall as well, but we’re having our annual Accelerate conference this time online. We had one that was focused in kind of May on more of the US area, but we’re having more of a global one to come in October. So we’re going to be showing off a lot of exciting new stuff about a lot of the tools that I mentioned like test projects, SpecFlow, Flood. A lot of new integrations kind of between those tools and the core platforms. So starting to develop that story that I mentioned about sort of one platform to fit various different approaches, whether that’s more of the technical users or the nontechnical users. So that’s definitely one to check out. I’m just checking the date. I think it’s the 21st and 22nd of October is when we’re planning that for it I believe.  

    Shimel: It’s going to be a crazy October of virtual events. Alon, how about you and UP9?

    Girmonsky: Yeah, you know and the UP9 is a new startup. We started almost two years ago, but we are working diligently to complete our software. We already released our first version, but you know the work, still a lot of work ahead of us. So I hope to show you a lot of new cool things down the road. Now we are heads down you know building and building. 

    Shimel: Excellent. Guys I want to thank all three of you for being on DevOps Unbound with us today. I wish we had more time to dive into this. You know there’s so much. Even the idea of having a CDF versus let’s say five or 10 years ago if I told you we were going to have something called a “CDF” you wouldn’t believe me, right? You would think, “What do we need this for?” And you know so we’ve come so far in DevOps and continuous delivery and Kubernetes and — well Kubernetes itself is open source, but this whole revolution honestly around open source and community it’s what makes, it fuels so much of what we are seeing. You know where would we be in COVID without a lot of what we’ve, open source has enabled us to do you know using technology? So I do think it is, it is an integral, it’s a precursor to having the DevOps world that we live in today is open-source software. 

    So, thanks for joining us. We have to have you back on. I’m serious about testing tools in CDF though guys. I think that’s some, long, long overdue. Tracy, thank you and best of luck now that you’ve moved fulltime into the CDF. I know you’ll make great things happen there. Kevin, Alon, best of luck to both of your companies, UP9 and Tricentis. This is Alan Shimel for MediaOps, DevOps.com. Thank you all. Thank you for watching. We’ll see you on the next DevOps Unbound, soon. Bye-bye everyone.

  • Oracle Adds APIs to Java SDK To Advance DevOps

    Oracle Adds APIs to Java SDK To Advance DevOps

    Oracle announced it is making available the Java 14 software development kit (SDK), which provides access to several additional capabilities designed to help advance DevOps adoptions within IT organizations that still rely heavily on Java to build enterprise applications.

    Those capabilities include a set of application programming interfaces (APIs) to enable continuous monitoring of JDK Flight Recorder data and a set of APIs that make it easier to access foreign memory.

    In addition, via an incubator module Oracle is now providing access to a Packaging Tool that will enable developers to package Java applications and runtimes for distribution in platform-specific formats. That capability is being exposed as an incubator module because the associated APIs have not been finalized, which means they are subject to change in future releases.

    The Java 14 SDK adds Java language support for switch expressions to be used as either an expression or statement and extends the availability of the low-latency Z Garbage Collector to macOS and Windows.

    Finally, Oracle has added support for a Pattern Matching capability that eliminates the need for boilerplate code and a preview of a tool that makes it simpler to declare data immutable.

    Aurelio Garcia-Ribeyro, director of product management for Java SE, said a lot of the capabilities being added to Java SDK were developed as part of the ongoing Panama and Amber research projects that in some cases have been in development and testing for years.

    Despite the rise of rival programming languages, Garcia-Ribeyro said enterprise IT organizations continue to rely on Java to build most of their applications, especially mission-critical backend systems.

    The challenge is modernizing the processes via which Java applications are built and deployed. Many organizations, for example, are embracing containers and microservices to build next-generation applications. As that transition occurs the need to embrace best DevOps practices becomes more apparent because applications themselves are becoming more complex. The upside, of course, is that microservices also make it possible to build more robust applications faster, which has become a critical requirement as organizations embrace digital business transformation.

    Of course, no two organizations are likely to be at the same point on the DevOps maturity curve. In fact, in many cases, DevOps adoption is being driven from the bottom up as developers embrace new capabilities being added to familiar tools such as the Java Development Kit from Oracle. In some cases, the SDK will be used to build new applications while other members of the development team employ it to modernize legacy applications. Before long, however, IT operations teams start to realize how monitoring APIs and packaging tools are transforming how IT operations are managed.

    Naturally, Oracle is hoping all these new capabilities will help keep organizations focused on Java as the primary means for building enterprise applications at a time when developers have more options than ever. The one thing that Oracle has most in its favor is that most organizations don’t want to retrain developers to learn how to master a new programming language unless it can’t be avoided.

    — Mike Vizard

  • Mission Makes AWS Expertise Available for Free

    Mission Makes AWS Expertise Available for Free

    Mission, a provider of managed services for the Amazon Web Services (AWS) cloud, this week announced it will make its cloud optimization expertise available free of charge for any IT organization that acquires AWS licenses through it.

    Alex Beal, director of product for Mission, said as cloud sprawl continues to be an issue, many internal IT teams simply don’t have the expertise required to rein in those costs. However, rather than charge extra for the expertise Mission will now make its tools and consultants available for free under the auspices of the Mission Cloud Foundation service to any organization that employs Mission to acquire AWS licenses, he said, noting every Cloud Foundation customer will get access to a designated Mission Cloud Analyst who will provide regular account reviews and guidance on implementing best practices.

    Mission can provide the free service because it acquires licenses from AWS at a lower cost. Effectively, AWS is paying for the services being provided by Mission, said Beal.

    As more workloads move into the public cloud, IT teams are struggling to navigate a complex mix of service levels from AWS that range from spot pricing options to reserved instances that can be licensed for specific periods of time at a deep discount. However, determining which workloads lend themselves best to various AWS pricing options can be challenging to determine, especially for developers who spin up virtual machines without consulting with internal IT teams. Collectively, organizations are wasting millions of dollars each year because of suboptimal usage of public cloud resources. Beal estimated that the average IT organization is wasting about $5,000 a year on cloud infrastructure resources that could be better allocated to other IT initiatives.

    Beal said Mission will work with those internal IT teams to identify unused resources and rightsizing candidates, set up budget alerts and recommend better options for specific types of workloads using a combination of monitoring tools from third parties such as CloudHealth and one developed by Mission. Those monitoring tools are also employed to enforce budget constraints and run security checks.

    Mission Cloud Foundation also includes tools to reallocate charges, reference purchase order numbers and set up automated custom reports.

    Most IT organizations could develop much of this expertise on their own. However, Beal said most IT teams also have better things to do with their time that add more value to their organization. Instead of acquiring licenses direct from AWS, Mission is making a case for an alternative approach that provides a level of service and support that AWS generally only provides to Global 2000 customers.

    Other managed services providers (MSPs) may or may not also provide tools and expertise free of charge. Savvy IT teams, however, may soon force the issue. After all, while public cloud represents the most widely employed form of IT infrastructure as code, from a cost perspective it’s also clear public clouds can also quite easily become too much of a good thing.

    — Mike Vizard

  • Extending Cloud to Enable Intelligent Edge

    Extending Cloud to Enable Intelligent Edge

    In the last few years, with the emergence of 5G, IoT and AI, cloud providers have recognized the value and the importance of edge, and started building the infrastructure technologies to provide computing and connection between cloud and edge, as well as edge based intelligent services as part of their total cloud value proposition. However, this is a relatively new area of cloud computing with great opportunities as well as challenges.  

    Top Scenarios of Cloud-Edge Computing 

    The new set of applications such as 5G, IoT and AI, and maximizing cloud computing resources have been driving the development of edge computing as extension of cloud.

    Here are the major scenarios for such cloud-edge computing development: 

    1. Low latency: For latency sensitive services such as 5G and IoT, running on the edge provides much lower latency and faster response time. We have seen more and more latency sensitive services being built around the public cloud ecosystem.
    2. Massive data: With the rapid growth of devices and users, we’re generating massive amount of data every day. It is very costly to move device or user generated data for services to run on the cloud in real time or on a regular basis. Instead, it is more efficient to run services on the edge and to perform local data processing. In some cases, it is the only viable option and can save tremendous network cost.
    3. Privacy/security: For some businesses or regions, it is required to store sensitive and/or confidential data locally on the edge (without moving to cloud) to comply with privacy law and/or security regulations.
    4. Distributed cloud architecture: At the same time of adopting public cloud services, many enterprises have needs to run part of their business on locally edge servers, which challenge cloud providers to design and provide a distributed cloud architecture to their users. 

    Top Use Cases: Edge Analytics and Edge AI 

    One of the top cloud-edge computing opportunities is edge analytics, which allows data analysis and decision making closer to where the data is generated such as IoT devices, edge and gateways while the cloud is still responsible for the overall service life cycle management, service scheduling, data storage or warehousing, and more comprehensive service or data analysis such as big data analytics. The key benefits of edge analytics are reduced latency and increased security of the analytics, and hence, quick business decision making and so on.

    Similarly, edge AI enables applications such as autonomous navigation, remote monitoring using NLP or facial recognition, video analytics, and etc. by embedding AI algorithms in AI devices connected to distributed, low-latency and reliable AI services on the edge, while cloud resources can be pulled in for more in-depth analysis. Here is an image recognition example using both edge and cloud resources and technologies: The edge renders the initial image collected from the device, performs initial analysis and determines it is a dog in the image, then the edge sends the extracted dog image, rather than the whole original image file, to the cloud for further analysis. The cloud then utilizes a bigger data set and determines the breed of the dog and sends the information back to the edge as a more detailed description of the image. 

    Top Challenges 

    Cloud-edge computing obviously brings many technical challenges to cloud providers, especially in support of heterogeneous computing, network instability and security on the edge.

    Here are top challenges we have seen:

    1. Limited amount of resources on the edge. The services deployed on the edge need to be more lightweight and less resource intensive.
    2. The IoT devices on the edge can be massive and diverse, which can lead to device management challenges for the edge.
    3. The connectivity between the cloud and the edge can be unstable. It is important to implement well thought-out network protocols to ensure the reliability of data transmission between the cloud and the edge.
    4. There needs to be a streamlined security strategy connecting IoT to the edge, and to the cloud.
    5. Since this is still a relatively new area with great promises and competing visions, there are many disconnected technologies, point solutions and fragmented communities addressing this space. This can be challenging for users to determine the best architecture and solution stack for their edge cloud computing use case.   

    KubeEdge and Volcano, Cloud Native Projects that Extend Kubernetes to Edge and AI

    Cloud native computing has been considered as the de facto approach for the cloud, edge and AI application and service development, and Kubernetes has been proven to be the cornerstone of cloud native computing today. KubeEdge, a CNCF Sandbox project launched in July 2018 with increasing user and developer support, extends Kubernetes to the edge. KubeEdge 1.2, just released in February 2020, includes many reliability features that addresses the cloud-edge network challenges and improves the cloud-edge connectivity. Volcano is an open source project that extends Kubernetes to meet the AI and deep learning workloads. Volcano has recently received the CNCF Runtime SIG approval, and is currently applying for CNCF Sandbox status.

    Please join KubeEdge and Volcano, and let’s work together to complete cloud-edge-IoT streamlined solutions to meet the opportunities that 5G and AI can bring us today and in many more years to come.

    — Anni Lai

  • The Cloud Is Booming — But so Is Cloud Waste

    The Cloud Is Booming — But so Is Cloud Waste

    Fueled by the growth in cloud spend, cloud waste will exceed $17.6 billion in 2020.

    Over 90% of organizations will use public cloud services this year. In fact, public cloud customers will spend more than $50 billion on Infrastructure as a Service (IaaS) from providers such as AWS, Azure and Google. This boom is, of course, due to the broader adoption of public cloud services. But, it is also caused by the expansion of infrastructure within existing accounts. Not surprisingly, the growth in spending often exceeds the growth in business. That’s because a huge portion of what companies are spending on cloud is wasted.

    Cloud Computing Is Expanding

    Before getting to the waste, let’s look a little closer at the growth in the cloud sector. Gartner recently predicted that cloud services spending will grow 17% in 2020 and will reach $266.4 billion. While Software as a Service (SaaS) makes up the largest market segment at $116 billion, the fastest growing portion of cloud spend will continue to be IaaS. This will increase 24% year-over-year and surpass $50 billion in 2020.

    Typically, I find that about two-thirds of the average enterprise public cloud bill is spent on compute, which means about $33.3 billion this year will be spent on compute resources. Unfortunately, this portion of a cloud bill is particularly vulnerable to wasted spend. 

    Cloud Waste Is Also Expanding

    As cloud computing growth continues and cloud users mature, we might hope that this $50 billion is being put to optimal use. While I personally do find that cloud customers are more aware of the potential for wasted spending than they were just a few years ago, this does not seem to be correlated with cost optimized infrastructure from the beginning. The fact is, it’s simply not a default human behavior. 

    I frequently run reports for companies having issues with cloud waste. Invariably, I find wasted spend in these accounts. For example, one healthcare IT provider was found to be wasting up to $5.24 million annually on their cloud spend—an average of more than $1,000 per resource per year.

    Below is where the total waste is coming from.

    Idle Resources: Idle resources are VMs and instances being paid for by the hour, minute or second, that are not actually being used 24/7. Typically, these are non-production resources being used for development, staging, testing and QA. Based on data collected from our users, about 44% of their compute spend is on non-production resources. Most non-production resources are only used during a 40-hour work week, and do not need to run 24/7. That means that for the other 128 hours of the week (76%), the resources sit idle, but are still paid for.

    So, I find the following wasted spend from idle resources: $33.3 billion in compute spend, times 0.44 non-production, times 0.76 of week idle, equals to $11 billion wasted on idle cloud resources in 2020.

    Overprovisioned Resources: Another source of wasted cloud spend is overprovisioned infrastructure—that is, paying for resources are larger in capacity than needed. That means you’re paying for resource capacity you’re rarely (or never) using. About 40% of instances are sized at least one size larger than needed for their workloads. Just by reducing an instance by one size, the cost is reduced by 50%. Downsizing by two sizes saves 75%.

    The data I see in client infrastructure confirms this—and the problem may well be even larger. Infrastructure I see has an average CPU utilization of 4.9%. Of course, this could be skewed by the fact that resources I deal with are more commonly for non-production resources. However, it still paints a picture of gross underutilization, ripe for rightsizing and optimization.

    To take a conservative estimate of 40% of resources oversized by just one size, we see the following: $33 billion dollars in compute spend, times 0.4 oversized, times 0.5 overspend per oversized resource, equals to $6.6 billion wasted on oversized resources in 2020.

    The Extent of Wasted Cloud Spend

    Between idle and overprovisioned resources alone, that’s $17.6 billion in cloud spend that will be completely wasted this year. In fact, it could well be higher. Other sources of waste include orphaned volumes, inefficient containerization, underutilized databases, instances running on legacy resource types, unused reserved instances and more. Some of these result in significant one-off savings (such as deleting unattached volumes and old snapshots) whereas others can deliver regular monthly savings. 

    That’s a minimum of about $5 million wasted per day, every day this year, that could be reallocated toward other areas of the business. 

    It’s time to end wasted cloud spend. Perhaps acknowledging the extent of this problem is a good first step.

    — Jay Chapel

  • JFrog Delivers on Hybrid Cloud Promise for DevOps

    JFrog Delivers on Hybrid Cloud Promise for DevOps

    JFrog announced the availability of what it claims to be the first available hybrid DevOps platform capable of spanning multiple clouds.

    Dror Bereznitsky, chief product officer for JFrog, said the JFrog Platform integrates a range of DevOps tools within the context of the continuous integration/continuous deployment (CI/CD) platform that the company previously developed, with the goal of making it possible to continuously release software originating from any source on to any platform.

    Announced late last year, the JFrog Platform also provides DevOps teams with the first universal package manager with JFrog Artifactory along with support for both REST application programming interfaces (APIs) and a command line interface (CLI), he said.

    In addition, the JFrog Platform provides a common integrated user interface to access all capabilities and has been integrated with JFrog Pipelines for CI/CD, which is based on code JFrog gained via its acquisition of Shippable last year. The JFrog platform also enables DevOps teams to now also deploy applications on Kubernetes clusters.

    Finally, because the platform is managed by JFrog, DevOps teams can count on high availability and cybersecurity updates that are automatically delivered, said Bereznitsky.

    Bereznitsky said thanks to the rise of microservices based on containers and other cloud-native technologies, organizations are reaching a tipping point in terms of the amount of complexity their existing DevOps platforms can absorb. As such, many organizations that have already adopted a DevOps platform will be re-evaluating them. JFrog is betting that rather than spending more time on managing their underlying DevOps platform, more organizations will prefer to divert more resources to application development.

    It’s too early to say precisely how application development will evolve going forward. There is certainly an opportunity to centralize DevOps processes in a way that will make organizations more efficient. Most organizations today employ multiple platforms for building and deploying applications that often conspire to increase total costs unnecessarily. The challenge those organizations will face is overcoming the cultural issues it is likely to create within their organization.

    In the meantime, JFrog rivals clearly see the same opportunity. The race to become a de facto standard for building and deploying a new generation of highly portable applications is now on, at a time when many of the providers of DevOps tools are starting to consolidate. At the same time, the number of applications that will be deployed across an extended enterprise that now spans everything from public clouds to edge computing platforms soon will dramatically increase. As the volume of applications increases, the level of friction associated with building and deploying applications will ultimately determine the DevOps platform any organization is going to be inclined to standardize on.

    — Mike Vizard

  • Ten Years Later — What Is Cloud Native?

    Ten Years Later — What Is Cloud Native?

    Ever since the term cloud native made its debut in 2010, its usage has grown in popularity. Today cloud native is used as a qualifier for innovative, leading edge applications, platforms and systems or cloud-savvy organizations and processes.

    However, what is cloud native exactly? There are some definitions, there are many opinions, but first and foremost there is a lot of confusion: Is my system already cloud native if I follow a microservice-based architecture? Is my system already cloud native if I run containers? Do I have to change development and operations?

    In this post, we cut through any uncertainty and ambiguity and provide an accurate and concise definition of cloud native systems.

    However, first, we have to discuss a set of prerequisite concepts.

    Application + Platform = System

    Frequently, in our day to day conversations, we use the terms application, platform and system interchangeably. Yet in this blog post, we draw a strict distinction:

     

    • Application: An application is the set of components that are designed and implemented for a specific use case.

     

     

    • Platform: A platform is the set of components that are designed and implemented independently of a specific use case.

     

     

    • System: A system is the combination of an application and a platform. Generally, we refer to an application as being hosted on a platform.

     

    End users do not interact with applications or with platforms only; end users interact with systems. Consequently, we will focus our discussion on system-level properties, not application—or platform-level properties.

    Application + Cloud Platform = Cloud System

    A cloud platform is a service provider that enables a service consumer to request and release resources on demand via an Application Programming Interface (API).

    According to this definition, a cloud platform is any service provider that enables a service consumer to request and release resources on demand:

     

    • Public Cloud Platform: A public cloud platform is a service provider that offers resources outside of its own organization.

     

     

    • Private Cloud Platform: A private cloud platform is a service provider that offers resources within its own organization.

     

    Consequently, a cloud system is any application that is hosted on a cloud platform. However, what is a cloud native system? 

    Responsiveness, Scalability and Reliability

    The distinction of cloud native systems versus non-cloud native systems is drawn along the lines of responsiveness, scalability and reliability. 

    In a nutshell, responsiveness is a system’s ability to meet the users’ expectations. In order to quantify responsiveness, we rely on a set of four related concepts: 

    • Service Level Indicator: A service level indicator is a quantitative observation about the behavior of a system.
    • Service Level Objective: A service level objective is a predicate (a function that yields true or false) on a service level indicator that determines whether the behavior of a system meets an objective.
    • Error Rate: The error rate is the ratio of the number of observations that do not meet their objectives to the number of observations in total for a fixed time interval.
    • Error Budget: The error budget is an upper limit on the error rate.

    Based on the above, we can now define responsiveness of a system as the ability of the system to keep its error rate below its error budget.

    These concepts are best explained with a tangible example: Consider a web application processing HTTP transactions, that is, accepting HTTP requests and returning HTTP responses.

    Service Level Indicators

    Here, we define two SLIs.

     

    • SLI Latency: determines the latency of a transaction, that is, the time when the request enters the system to the time the response leaves the system. 

     

    • SLI Result: determines the result of a transaction, that is, the status code of the response.

     

     

    SLIs are recorded at the edge of a system, here the Ingress component, to exclude any variation that is outside our control and focus on the performance of the system that is within our control. For example, we do not want to include any variation in observed latency or observed results originating in the users’ network connections. However, we do want to focus on the performance of the system once Ingress accepts the request until Ingress returns the response.

    Next, we define two SLOs.

     

    • SLO Latency: For this example, we define the SLO Latency to be met if a transaction’s SLI Latency is less than 250 milliseconds.

     

    • SLO Result: For this example, we define the SLO Result to be met if a transaction’s SLI Result is not in the HTTP 500 range.

     

     

    Finally, we set the value of the error rate’s time interval to a 30-day sliding window and the value of the error budget’s to 1%.

    By definition, this system is responsive if the ratio of the number transactions over the last 30 days that do not meet their SLOs to the number of transactions over the last 30 days in total does not exceed 1%.

    Scalability and Reliability

    At this point we have the necessary tools to define scalability and reliability:

    • Scalability is responsiveness in the presence of load.
    • Reliability is responsiveness in the presence of failure.

    So Finally, What Is Cloud Native?

    With the definition of cloud systems and the definition of responsiveness in place, we can now define cloud native systems: A cloud native system is a cloud system that is scalable and reliable by construction.

    The operator “by construction” is in stark contrast to “by requirement”: The design and implementation of a cloud native application guarantees scalability and reliability within the limits set by the service level objectives and error budgets.

    According to this definition a cloud native application must be able to:

    • Autonomously detect and mitigate the presence of load.
    • Autonomously detect and mitigate the presence of failure.

    Discussion

    This post defined the term “cloud native” as a property of a system, not as a property of organizations or processes.

    The defining criteria of a cloud native system are scalability and reliability by construction. Here, the employment of microservices (an architectural choice) or containers (a technological choice) is not a defining criteria of cloud native systems. If you want to know more, head over to—or better yet, get involved with—the Cloud Native Computing Foundation, a Linux Foundation project founded in 2015 with the mission to build a sustainable ecosystem for cloud native systems.

    — Dominik Tornow

  • HashiCorp Updates Terraform Tool for Azure Cloud

    HashiCorp Updates Terraform Tool for Azure Cloud

    HashiCorp today announced it has updated the instance of Terraform it created to automate the configuration of virtual machines on the Microsoft Azure cloud to give IT teams more granular control.

    Version 2.0. of Terraform (TF) AzureRM Provider will allow IT teams to separately configure virtual machines by type for instance of both Windows and Linux.

    In addition, version 2.0 of TF AzureRM Provider will allow users to specify custom timeouts for resources. Previously, timeouts were set for one hour by default.

    Finally, TF AzureRM Provider 2.0 removes resources, data sources and fields that have been deprecated. TF AzureRM Provider currently provides access to 374 resources and 119 data sources.

    Amith Nair, vice president of product marketing for HashiCorp, said the goal is to provide IT teams with a set of tools for automating the configuration of virtual machines on Azure that is more accessible than the tools currently provided by Microsoft.

    Nair said HashiCorp is seeing increased adoption of Microsoft Azure, which in turn creates demand for tools that make it easier to deploy virtual machines at scale. In fact, Nair notes that as more workloads move into the public cloud the less resistance there is to IT automation as administrators look for ways to manage IT at what is now unprecedented scale. Of course, many organizations gain their first experience with tools such as Terraform when they first embrace a set of best DevOps practices.

    Less clear is how many virtual machines are being configured on top of instances of Windows versus Linux. There is no doubt Microsoft has emerged as the strongest challenger to the dominance of Amazon Web Services (AWS) in the public cloud. Much of that success, however, comes from the fact that Microsoft supports distributions of Linux alongside Windows Server on the Azure cloud. There are, of course, many organizations, such as Walmart, that prefer to standardize on Azure simply because they view Amazon to be a competitor. At the same time, however, there are many companies that employ both AWS and Azure.

    Nair said most organizations that have adopted more than one cloud tend to manage them in isolation from one another. However, it is expected that one day more organizations will seek to unify the management of multiple clouds within the context of a truly hybrid cloud computing environment as the total cost of cloud computing continues to rise with each additional workload deployed. Naturally, many of those organizations eventually will gravitate toward tools that can be employed across multiple clouds.

    In the meantime, whether it’s IT administrators or developers themselves configuring virtual machines in the cloud, it’s thanks to tools such as Terraform that the amount of time and effort required to set up virtual machines in the cloud is now as negligible as it is. The challenge now is not so much finding tools to automate IT as much as it is navigating all the cultural changes that naturally ensue.

    — Mike Vizard

  • vArmour CEO: Cloud Security Needs Simplicity

    vArmour CEO: Cloud Security Needs Simplicity

    Cloud computing promised cost savings and simplified IT management, among other things. In many ways, the cloud has lived up to its ideals, and in other ways, such as API security, shadow IT and the securing of clouds across hybrid environments, the cloud has proven challenging.

    To get a sense of how enterprises and security vendors are adapting, we reached out to Timothy Eades, CEO at cloud application security provider vArmour. vArmour was founded in 2011 with backing from Highland Capital Partners, Menlo Ventures, Citi Ventures, Work-Bench Ventures, Redline Capital and Telstra. Timothy Eades has been the CEO since 2013; prior to that role, he was the CEO at Silver Tail Systems.

    Here’s an edited version of our conversation.

    DevOps: How do you see cloud architectures evolving over the years ahead?

    Timothy Eades: There is considerable evolution coming. At vArmour, we have a philosophy about this: Bet on the road maps, not against them.

    I think we are seeing a lot of security vendors starting to scratch their heads and wonder: Where do we invent new security technologies that can help us differentiate? The road maps for winners are going to be those that bake security into their products. This way, cloud technology will only get stronger and more secure. If one imagines an x- and y-axis and the x-axis is the strength of security capability and the y-axis is simplicity, the vendor road maps, for those who will be successful, will be about getting that balance right.

    Currently, there’s considerable complexity involved when it comes to configuring and securing the public cloud. If you are Tim’s Pizzeria and you are running on AWS, it has to be made simple and more intuitive. I was talking to some friends recently about the Windows operating system and how everything has become so simple. But back in the day when you and I were growing up, we used to say “RTFM” almost daily. Nowadays, there is no manual.

    That’s mostly thanks to Steve Jobs. Steve Jobs came along and made everything so simple that it shouldn’t require a manual. The worst-case was it might require a YouTube video to understand.

    The cloud has to go through that same transition. Everything has to be made simpler, more intuitive. Otherwise, we are just going to get very weak configurations, because people are not going to configure it right. They’re not going to secure them right. They believe that they are inherently secure.

    DevOps: What do you think will be the catalyst that will continue to drive cloud vendors getting the simplicity and security balance right?

    Eades: I think it’s going to be a competition. I think the market sees the need for the drive to simplify. And it’s going to take the competition to get there. That’s a real battle between AWS, Azure, VMware and others. The good news is that VMware is going to embed a lot of security capabilities, and that will force Amazon, Azure, and Google Cloud to respond.

    DevOps: Cloud can get complicated quickly; even that small pizza shop may run a dozen cloud services.

    Eades: Yes, they are running a bunch of different services. The funny thing is, there is always a lack of security skills at play, too. And we all know that when businesses put things in the cloud, that they think it just became secure. They don’t have the skills to understand that it’s not as secure as they believe. I think the regulators are still scratching their heads a little bit about all of this because Amazon has been preaching its “shared responsibility” model. But, as we now know, it’s not shared liability.

    And people haven’t woken up yet to that fact, that shared responsibility is not shared liability.

    DevOps: How do you see enterprises consuming the various modalities of cloud in the years ahead, on-premises, public, private cloud and the different mixtures of each?

    Eades: It’s just amazing. Consider a company located in Europe. They have to have data on servers everywhere. So they’re using AWS and Azure and others. I think the large enterprises will continue to be hybrid cloud, but they won’t have a private data center. They just won’t.

    A friend of mine runs cloud security at a large bank in New York. Their current data center will be their last data center. They’re not going to build another data center. They’re just not.

    It’s the lifetime of the applications that they look at, and they wonder: Do I still want a data center? It doesn’t take long for them to get to “no.”

    One of the banks we worked with over the last three years, as they were moving many of their applications into the public cloud, they were trying to understand the interaction of their apps. They wanted to know how stable the performance of their apps is in the public cloud. They will tell you now that they don’t see the difference between their Amazon cloud and their private cloud. There’s no difference because they’ve all the bandwidth that they need.

    If you can’t tell the difference from a usage and from a financial perspective, more enterprises are going to depart from their data centers.

    I think you are going to see a very, very long tail of private data centers among very large enterprises, but the cloud will consume the rest of IT.

    — George V. Hulme

  • Report Pins Cloud Security Woes on Flawed DevOps Processes

    Report Pins Cloud Security Woes on Flawed DevOps Processes

    By now it’s become apparent that the bulk of security incidents involving cloud platforms revolve around some type of configuration issue. An analysis of those cloud configurations published today by the Unit 42 research arm of Palo Alto Networks suggests that the root cause of the issue is most likely the templates many developers and DevOps teams rely on to configure cloud infrastructure. In fact, according to Unit 42’s analysis, more than 199,000 templates have medium-to-high vulnerabilities in use on public clouds.

    Matt Chiodi, chief security officer for public cloud for Palo Alto Networks, said the issue stems from the rate at which organizations now want to be able to deploy applications on public cloud. Templates greatly accelerate the process but very few of those templates have been vetted by a cybersecurity team.

    According to the report, the most commonly used templates are created using YAML files on instances of Kubernetes (39%), Terraform and CloudFormation (24%). The most vulnerabilities were discovered in templates created using CloudFormation (42%), Terraform (22%) and YAML for Kubernetes (9%).

    Chiodi noted most templates are created through a simple three-step DevOps process: design, code and deploy. Unfortunately, in the rush to deploy most DevOps teams forget to scan for vulnerability issues. As a result, Chiodi said cybercriminals have become very adept at siphoning off cloud resources to mine cryptocurrencies at low-enough consumption rates to go unnoticed by many IT organizations.

    Other significant cloud security issues surfaced in the report include the fact that 43% of cloud databases are not encrypted and that 60% of cloud storage systems have logging disabled, which Chiodi noted makes it impossible to know whether those systems have been compromised. In addition, the report finds 76% of cloud workloads expose SSH (port 22), while 69% of organizations expose RDP (port 3389) and 27% are using outdated versions of Transport Layer Security.

    Overall, the goal now needs to be to make it as simple as possible for DevOps teams to do the right cybersecurity thing going forward, said Chioti.

    Unit 42 researchers employed a publicly available GitHub Searching application programming interface (API) to find AWS CloudFormation files, Kubernetes YAML files and HashiCorp Terraform files. Hundreds of thousands of templates were then downloaded and analyzed by the Prisma Cloud infrastructure-as-code (IaC) Scanner to identify the insecure configurations. Each IaC file was also sent to an IaC resource checker to analyze the cloud resources being used in the template. Researchers also used Palo Alto Network’s proprietary AutoFocus and Wildfire tools to identify and investigate cybercrime groups through their usage of custom toolsets (malware samples). Those samples were dynamically and statically analyzed to ensure indicators of compromise.

    The Unit 42 research makes it clear there’s a lot of room for improvement when it comes to employing best DevSecOps processes in the age of the cloud. The challenge, however, may have little to do with the tools available. Rather, it’s the absence of a structured set of processes through which DevOps teams and cybersecurity professionals can collaborate that appears to be inflicting the most damage.

    — Mike Vizard