Tag: CNCF

  • CNCF Elevates SPIFFE Spec to Secure App Services

    CNCF Elevates SPIFFE Spec to Secure App Services

    The Technical Oversight Committee (TOC) of the Cloud Native Computing Foundation (CNCF) announced that the open source Secure Production Identity Framework For Everyone (SPIFFE) specification and the SPIFFE Runtime Environment (SPIRE) have become incubation-level hosted projects.

    Andrew Harding, SPIRE maintainer and a principal software engineer at Hewlett Packard Enterprise (HPE), said the elevation of a potential standard to authenticate software services using cryptographic identities that are platform-agnostic could go a long way toward advancing the adoption of best DevSecOps practices.

    At the core of SPIFFE specification are short-lived cryptographic identity documents known as SVIDs that are invoked via an application programming interface (API). Workloads employ an SVID when authenticating to other workloads by establishing a TLS connection or by signing and verifying a JSON web token (JWT).

    Previously a sandbox level project, the SPIFFE specification is designed to reduce reliance on hard-coded secrets to authenticate application services, Harding said. Instead, developers will be able to more easily invoke multi-factor authentication to issue and verify identities for any type of application service. Each service is given its own identity, he noted.

    Amazon, Bloomberg, Google, HPE, Pinterest, Square, TransferWise and Uber are all contributors to SPIFFE. Since joining the CNCF last year contributors to SPIRE have added support for Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure, Kubernetes and bare-metal servers.

    SPIFFE and SPIRE are designed to work across both monolithic and microservices-based applications. The latter are not likely to completely replace the former anytime soon, so IT organizations need a consistent approach to authentication regardless of how an application is built, noted Harding. SPIFFE and SPIRE together enable an IT organization to implement a zero-trust architecture spanning multiple applications, he said.

    Ultimately, Harding said the goal is to enable better application security without compromising flexibility. As an added benefit, SPIFFE and SPIRE don’t require developers to share application secrets to enable interoperability between services running on different platforms. That’s because SPIRE doesn’t generate SPIFFE identities that can be used to authenticate to other systems nor does it store existing keys such as a database password on behalf of a workload. Each SVID generated is unique to the service use case.

    As the number of services and platforms being employed continues to increase, it’s not practical to continue to rely on approaches to authentication that rely on hard coding. The level of dependency that exists between services requires a more frictionless approach to authentication.

    It may be a very long time before reliance on tokens such as passwords disappear. However, it’s clear specifications such as SPIFFE, in the long run, will transform application security. The challenge now is not only getting developers to appreciate a new approach but also convincing skeptical cybersecurity teams that long have relied on some form of hard or soft token to secure applications. Given the number of times those tokens are misplaced or lost, there are more than a few IT help desk professionals wishing tokens would become obsolete sooner than later.

  • 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 devopsy.kinsta.cloud’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 devopsy.kinsta.cloud 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, devopsy.kinsta.cloud. Thank you all. Thank you for watching. We’ll see you on the next DevOps Unbound, soon. Bye-bye everyone.

  • DevOps Chats: Kubernetes is the New Compute, with Rancher Labs’ Sheng Liang

    DevOps Chats: Kubernetes is the New Compute, with Rancher Labs’ Sheng Liang

    Rancher Labs is a great example of a startup that was smart enough to sense the way the market was moving and adopted a strategy to capitalize on it. And, if you know Rancher co-founder, CEO Sheng Liang, you should not be surprised. Sheng has been seeing the market and staying one step ahead for a long time.

    In this DevOps Chat, we sat down with Sheng and spoke about the recent momentum at Rancher. We also spoke a lot about Kubernetes becoming the industry standard for compute.

    It is always a good learning experience speaking with Sheng, and this conversation is no different. Have a listen.

    Transcript

    Alan Shimel: Hi everyone, this is Alan Shimel for devopsy.kinsta.cloud and you’re listening to another DevOps Chat. I’m really happy to be joined by a good friend of mine who I’ve known probably more years than we want to admit to, my friend Sheng Liang who is the CEO of Rancher Labs. Sheng, welcome.

    Sheng Liang: Thank you very much. I’m glad to be here.

    Shimel: I’m glad to have you here, my friend. So, Sheng, the news with Rancher, I guess we call it a momentum release, right, you recently put out.

    Liang: Yeah.

    Shimel: Why don’t you just share some of the highlights with the audience?

    Liang: Yeah. Every January, early February, we tend to look back the year before and see how we’ve done, how the whole industry has done, and it’s just been remarkable. I guess the top-level thing is our business, our recurring revenue grew 169%, so that’s like high three-digit growth. It’s way exceeded our expectation. That itself is good news for us, but it’s not really–I don’t think an average person in the industry needs to care about it as much.

    What I want to, Alan, spend some more time talking to you is some of the underlying technology changes and industry movement that’s kind of enabling us to thrive in this environment.

    Shimel: Absolutely. Let’s be fair, congratulations. A hundred and sixty nine percent year-over-year growth is nothing to sneeze at. You’re right, there is a little bit I think of a rising tide lifts all boats when we’re talking about the Kubernetes market. Nevertheless, 169% is still 169%. You and I both come from that startup world and congratulations.

    Liang: Thank you.

    Shimel: It’s something to be proud of.

    Liang: Yeah.

    Shimel: Also, for our audience out there who are not familiar with Rancher Labs and Rancher OS, it’s a great startup story. Sheng, your background, cloud.com, all the things you’ve been involved in, you’re the perfect person to have led this. But Rancher Labs came out there originally with the Container Revolution, right?

    Liang: Yes.

    Shimel: With an OS for running containers. You were agile, nimble, adaptable enough to see Kubernetes and say, “Hey, we’re not gonna–we’re shoveling sand against the tide, right, if we think we’re gonna beat Kubernetes. If you can’t beat them, join them.” You incorporated Kubernetes into the Rancher Lab system.

    Liang: Yes, and in a fairly unique way as well. I’d love to share the story a little bit if you don’t mind.

    Shimel: No, you’ll tell it better than I will.

    Liang: We’re just over five years old, over 200 people now. We operate in 14 countries and we’re open source business. It’s 100% open source. Every single product we ship is available free in source code form, Apache open source, and it really worked well for us. I know in the industry there’s actually been a lot of talks about “Is open source even a great business anymore in the context of cloud?” But we continue to believe so, at least especially in the industry we’re in, and we can talk a little bit more about that.

    But let’s talk about the business and market and Kubernetes. The great opportunity we see with Kubernetes is Kubernetes for once has become an industry standard for compute. Now, think about it. We all know compute these days is everywhere. Computing is on cars, in ATM machines, on your phone, certainly on the server, in the cloud, but really, before Kubernetes where the world was getting into was quite challenging for a lot of organizations.

    Because these clouds as good as they were, as good as they still are, they’re just different. If I’m a CIO, say if I wanna be efficient, I wanna maybe go all in on one cloud whether it’s Azure or Amazon or Google, but until the day comes, now I merge with another company and now bringing a whole different set of infrastructures, and I don’t really wanna worry about that because my whole point is develop the apps, transform the business, help the–all the stuff I’m doing to worry about infrastructure is just plumbing, and that’s the true power of Kubernetes.

    I don’t think enough people in our industry are promoting Kubernetes this way yet, so I’d like to make a strong point with you, that in my mind, Kubernetes is the TCPIP of compute. Now, think about it.

    Shimel: It’s the stack. It’s the [Crosstalk] as you say. It’s the protocol.

    Liang: It’s a stack and a protocol because before TCPIP if you and I could remember back in–

    Shimel: I do remember.

    Liang: There were a handful, almost a dozen different network protocols, and after TCPIP we had 3Com, we have Cisco, we have Yahoo!, we have Google. All that stuff happened, internet. Revolution happened because finally–

    Shimel: I remember when you had to add the TCPIP stack separately. It didn’t come with Windows, so you had to add that in. That was an add-on. Early open source stuff.

    Liang: That’s exactly what’s happening because–this is a great point you brought up. Someday people will say, “Oh, I remember there was a time I had to talk to vendors like Red Hat and Rancher just to implement Kubernetes, whereas today if I get infrastructure like from Amazon, Google, from VMWare, from Dell, wherever, it comes with Kubernetes.” That’s exactly the same thing that’s happening. You see that, right?

    Shimel: Yeah. History repeats itself. When you get old enough, Sheng, you realize that. Let’s talk something else. I wanted to talk a little bit about CNCF because that’s their mission to make sure that Kubernetes is part of the plumbing. Truthfully, it’s not just Kubernetes. When you look at CNCF’s mission, they truly are trying to develop a stack or at least help foster the development of a stack built on several open source projects.

    Beyond Kubernetes, for Rancher now, what are some of the other CNCF projects that you see making their way into Rancher either now or in the future?

    Liang: I would say pretty much the whole stack. We’re very deeply involved in CNCF. We’re very early member of CNCF, and my co-founder Shannon Williams is elected to the CNCF governing board. Just this week I was elected to the CNCF TLC.

    Shimel: Really? Congratulations.

    Liang: So, I have some power kind of deciding what projects are gonna go into CNCF. CNCF fundamentally is a governing body for projects, and really our goal is anything and everything that–we wanna provide basically the complete software stack that organizations need to complete their cloud native transformation. Kubernetes is really just the start. Beyond Kubernetes you see everything else that’s going on from monitoring to logging. I’m talking about projects like Prometheus and ____.

    Those are some very mature projects now. Some of the more recent projects, things around security and policy management like OPA. I think those are very, very–

    Shimel: Love OPA.

    Liang: Yeah, and service match Linkerd. That’s also part of our CNCF. We last year contributed to a project called Longhorn. It’s cloud native storage, Kubernetes storage into CNCF. It’s a CNCF sandbox project now. So, it’s pretty much really the whole stack. If you think I was saying Kubernetes is TCPIP, then the rest of the CNFC, it’s the rest of the software stack, from the platforms to some of the key applications to some of the tools and equipment that more people have used.

    They’re gonna build this cloud native ecosystem. So, I’m really excited about it. I’ll be serving this CNCF technical oversight committee for the next two years and play a role in really growing the scope, further grow the scope of CNCF.

    Shimel: I just wanna say one other thing about CNCF, and that is we did a virtual event here called Predict last month where we took a look at a year in the future, and one of the points I made is that to me, CNCF is sort of the poster child for this third generation of open source that we’re in. I call it the first stage, sort of the cathedral in the bazaar back in the day. I know you know about it, Sheng.

    And then we moved from the cathedral and the bazaar to what I call the big brother era where every open source project was really owned by one company, and everything that that project did was for the benefit of one company, and that discouraged others from joining in and helping do it. Now we’re in sort of the foundational era of open source where you have foundations managing these projects for the good of the whole community with multiple vendors involved, people like you on the board who are doing it.

    Yes, it’s good for Rancher, but it’s good for all of the community, and that’s a very different–as I said, it’s the third generation of open source and it’s a great thing. Let’s focus in on Rancher a little bit though, Sheng.

    Liang: Yeah, absolutely.

    Shimel: So, we’ve got all these great projects. You’re literally building the stack or at least distributing the stack, your distribution of the stack. Fantastic revenue growth. What are people doing with Rancher that this demand is in such high demand?

    Liang: Yeah, I know. It’s one thing that Rancher of course supports and distributes a lot of CNCF technologies including Kubernetes and Prometheus and Linkerd and Fluentd, and we’re gonna soon be doing OPA. That’s all valuable, but fundamentally, a company like us really only have a reason to exist if we innovate. We basically create things that people can uniquely get from us and not from anywhere else.

    There are two pieces of content or two technologies that we created that actually help put Rancher on the map. One is K3S. It’s one of the most–if not the most–popular open source project in the Kubernetes ecosystem today outside of Kubernetes itself, and it’s just got tons of momentum. What K3S achieved was it took Kubernetes that was already proven in data center and cloud, and we brought it out to Raspberry Pi’s and surveillance cameras and set top boxes.

    Shimel: This is K8 lite. I remember we spoke about this, the one in the KubeCons. I remember.

    Liang: We launched GA at KubeCon, so it’s very big. We’re very excited about it. You remember, again I keep using TCPIP as an example because in the 90s when TCPIP just came, it was obviously a computer networking standard, but nobody probably could’ve imagined like a phone would also be talking TCPIP, right?

    Shimel: They all do.

    Liang: They all do now. I can see in ten years every phone, every camera will be running Kubernetes as well. Every car will be running maybe multiple Kubernetes. So, we’re very excited about that. Then the other big piece of innovation that really Rancher helped to make it happen is this thing called multi-cluster management. We believed Kubernetes again is a protocol. It runs everywhere, so you kinda need something to tie them all together.

    It’s not really good enough to be able to operate individual clusters. You need to treat all the clusters as a resource pool. In fact, you actually kinda have to treat every single cluster as a cattle or as a pet. That’s where the Rancher analogy came in.

    Shimel: I remember talking to you about that three, four years ago.

    Liang: I know.

    Shimel: It’s cattle, not pets.

    Liang: Our namesake product Rancher, which is named after our company, is a Kubernetes management platform. It takes all of your Kubernetes clusters in the cloud. In the cloud, that could be GKE, EKS, AKS. Could be Kubernetes clusters on-premise. It could be RKE. It could be open shift. It could be Project Pacific, PKS. It could be K3S clusters on the edge in cameras.

    We present it to your DevOps teams and ITOps teams as a unified computing platform, so you can manage access, you can deploy apps, you can run CICB, and that’s what Rancher is. It really started to resonate last year, even though we’ve been building it for three, four years, and that’s ultimately what propelled our tremendous business growth last year.

    Shimel: Great. Sheng, we’re coming up on the end of our time. I’m gonna throw one more kind of topic question out at you we can discuss, and that is really what does the future hold for Rancher not necessarily from a product deployment point of view but you’ve started and had exits with multiple startups now in your career. Where do you see Rancher in two to three to five years? Do you go public with this? Is this something maybe some larger entity wants to acquire to kinda own the stack if you will? What do you think?

    Liang: I think these days I probably think a little less about ultimately how Rancher will exit, just making sure we build a great business. I think we’ve kind of grown past the point that sort of an early stage easy equal hire or a technology would be viable.

    Shimel: It’s not a tuck in.

    Liang: We’re big enough to be sustainable by ourselves, and honestly, I absolutely believe it’s a big enough market. We solve a big enough problem that there’s a potential for tremendous business. Think about people actually all talk about hybrid cloud and multi-cloud, edge computing, but I think a lot of these terminologies are very attractive from a market demand or business case perspective but always lack some technical meat to actually bring it to reality. That’s actually been the problem.

    Of course, we all know hybrid cloud is a real business need, but the problem is because there was no fundamental consistent experience that could actually implement that. So, as a result, no big businesses have been built. We kind of approach it a little bit differently. We’re very much centered around Kubernetes as a common protocol for compute.

    I think by building on that, I really believe there’s a tremendous business opportunity here because fundamentally, we’re gonna solve these multi-cloud, hybrid cloud and edge computing problems. Those are business problems with Kubernetes as the common compute protocol. So, I think that will keep us busy for the next five, ten years, and I think this business has lots and lots of room to grow.

    Shimel: Let the chips fall where they may. Sheng, we’re about out of time. I wanna thank you for taking time out of your busy day and joining and talking to our devopsy.kinsta.cloud and Container Journal audiences. Always a pleasure to speak with you and get an update on what’s happening at Rancher Labs. I will see you in about a month and a half in Amsterdam for KubeCon.

    Liang: Thank you. Thank you, Alan. It was great talking to you.

    Shimel: Always a pleasure. Sheng Ling, CEO, co-founder Rancher Labs. This is Alan Shimel for devopsy.kinsta.cloud and Container Journal, and you’ve just listened to another DevOps Chats.

    — Alan Shimel

  • CNCF Graduates TUF Project to Secure Software Updates

    CNCF Graduates TUF Project to Secure Software Updates

    The Cloud Native Computing Foundation (CNCF) announced today that an open source specification for securing software update systems has graduated to becoming a top-level project.

    The Update Framework (TUF) is made up of a set of libraries, file formats and utilities that can authenticate files and images before they are downloaded from a software repository. Justin Cappos, associate professor of computer science and engineering at NYU Tandon School of Engineering who led the development of TUF, said the framework enables IT organizations to better secure their software supply chains.

    In addition, TUF isolates artifacts in a repository in a modular fashion that not only limits the amount of damage that can be inflicted by a breach of the repository, but Cappos said it also makes it easier for IT organizations to roll that repository back to its last known good state.

    For a CNCF project to graduate it needs to demonstrate thriving adoption, an open governance process and a strong commitment to community, sustainability and inclusivity. TUF was developed at the University of Washington in 2009 by Cappos and Justin Samuel. TUF has been based at New York University Tandon School of Engineering, which makes a reference implementation available to any interested party, since 2011. It became a CNCF project in 2017 and is now the first security-oriented project to graduate among the eight other CNCF projects that have graduated.

    TUF is already employed within Notary, a separate CNCF project that provides a mechanism to both certify the validity of the sources of Docker images and encrypt the content of those images. TUF is also employed within Uptane, which is employed to deliver software updates to automobiles. Other organizations using TUF in production environments include Amazon, VMware, Google, IBM, Red Hat, Datadog and DigitalOcean.

    Cappos said he would like to see TUF adopted more broadly to secure software supply chains in medical systems as well as critical infrastructure systems such as the power grid. As cyberattacks targeting these systems increase, Cappos said it’s apparent there is a need for a more resilient approach to securing software running on these types of platforms.

    Longer-term, as organizations embrace best DevSecOps processes, it’s now only a matter of time before organizations focus more of their time and energy on securing the software supply chain. However, Cappos said right now there is too much focus on trying to discover application dependencies and scanning images. While those are important tactical tools, Cappos said there needs to be more focus on strategic approaches to securing software supply chains.

    It’s not clear to what degree DevSecOps will ultimately push organizations to embrace a more holistic approach to building and managing software supply chains or whether larger concerns about the security of software will push more organizations to embrace DevSecOps. Regardless of whether the impetus for building and deploying more secure software comes from the top down or the bottom up within an organization, the important thing is that in terms of tools and processes rapid advances are finally being made.

    — Mike Vizard

  • The Foundational Era of Open Source

    The Foundational Era of Open Source

    Contrary to popular belief, software is not eating the world. Open source software is eating the world. This was very apparent at the Linux Foundation’s KubeCon + CloudNativeCon event recently in San Diego. Driving this phenomenon is what I call the Foundational era of Open Source.

    This Foundational era of Open Source has replaced what I call the Big Brother era that came before it. The Big Brother era itself replaced what I call the Cathedral and Bazaar era of open source.

    The Cathedral and Bazaar Era

    I first became involved in open source software in the mid-90s. I might have dabbled and used open source software before that as I searched for free tools using WAIS and Gopher. But I really became aware when I founded TriStar Web, an early hosting company. Back then, web server software came in basically three flavors: 1. Netscape Web Server, from the people who brought us the Netscape browser (it was my choice); 2. Microsoft’s Internet Information Server (ISS), which was that era’s version of the Evil Empire; and 3. Apache (I don’t even think there was an Apache Foundation yet), the open source web server that was taking the web by storm. Besides being free, it was a lot more flexible and capable than the other two.

    During this time there was, of course, another open source software vying for dominance in the market. Something called Linux developed by a guy named Linus Torvalds was taking on all of the giants that had their own flavors of Unix, while Bill Gates’ Windows was fighting it out against IBM’s OS/2, which he also developed.

    Yes, those were heady days for open source software. I call those days the Cathedral and Bazaar days of open source. The Cathedral and Bazaar, of course, refers to the collected essays and then the book of the same name by Eric S Raymond. It, more than anything else, laid out for me the power of open source software and the tensions between the worlds of open source “free as in beer, free as in freedom” versus closed source software.

    Let’s be clear, the open source software world would not exist but for the lessons learned, battles fought and wins and losses of this era.

    Anarchy, Chaos or Freedom?

    In those days you had people such as Dr. Richard Stallman advocating for free, open software that you could use, distribute and modify as you wish. There were intellectual debates over the pros and cons of various open source licenses (Apache, GPL, etc). Most of all, it was very difficult to bring open source software into the enterprise. No support, no training, no SLAs … how was the enterprise to use open source?

    Nevertheless, open source prevailed—sometimes on sheer quality, other times on the love of developers who relished in the freedom of open source. It became a force in the tech world. Companies such as Red Hat, Suse and Canonical capitalized on Linux. Other companies tinkered and experimented with models to try and become commercially successful with other open source tools. By and large, it was a rough go, but some did succeed.

    In my own case in InfoSec, we had great open source tools including Snort, Nmap and Nessus. The folks at Tenable did stop developing an open source version of Nessus, but they still offered a free version of it. Yes, it was a great time in open source—or so I thought.

    The Big Brother Era of Open Source

    Sometime in the early 2000s, we passed into what I call the Big Brother era of open source. This was characterized by almost every open source project having a managing or controlling commercial entity dictating its direction and code. While this didn’t happen with Linux, it became the de facto standard.

    Companies were spun up by the founders of an open source project and while the project itself remained open, it was owned lock, stock and barrel by the commercial entity. The company would sell training and support and in some cases open core versions of the software with “freemium” modules available for a price. Eventually, SaaS-based, hosted versions of the open source software would be another business model companies used to monetize open source.

    Issues regarding who owned the code, who contributed to these projects and where the community fit in often caused conflicts. But by and large, the open source communities counted on the benevolence of the Big Brother to make sure the open source versions of the software remained viable.

    In retrospect, though, this era stifled contribution by other entities: Who would want to contribute code to an open source project for the benefit of the controlling entity? Many companies forked their project so they could control their own versions, resulting in the Balkanization of many of these projects, with the community being the big loser.

    The Foundational Era of Open Source

    Between 2012 and 2015, though, we passed into a new, modern era of open source software that I call the Foundational era of open source. Open source projects were given to community-owned, non-profit foundations to manage and nourish—organizations such as the Linux Foundation, the folks behind Cloud Native Computing Foundation and the Continuous Delivery Foundation; Cloud Foundry Foundation; The Apache Foundation; and the Eclipse Foundation (one of the early entrants, even if IBM did come to dominate it) took over the stewardship of many open source projects.

    This has ushered in a truly golden age of open source software that has seen open source become the dominant form of software in the world. The Foundational era of open source has flourished for several reasons. For one, now multiple commercial entities can contribute code without worrying that it is for the exclusive benefit of just one company. What’s more, these foundations have a mix of vendors, practitioners and large enterprise users that really do allow for the democratization of open source at levels not seen before. Also, there is a process of incubation to graduation that these projects are put through that help them evolve and grow.

    Not to be underestimated is the new generation of developers who have grown up with open source and only want to work in open software. They are putting their influence into practice. Instead of sneaking open source in the back door, they are knocking down the front door with it.

    There are other reasons, but the result is that open source today is now in use at well over 90% of enterprises and it is by far the dominant form of software. It is leading the way in the move to the cloud and in business transformation, and it is literally changing the world.

    Long live open source.

    — Alan Shimel

  • 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

  • Identifying and Abstracting Business Intelligence from Kubernetes Workloads

    Identifying and Abstracting Business Intelligence from Kubernetes Workloads

    In the age of big data, businesses are inundated with data points. While they know there’s an abundance of valuable resources available to them, making sense of this data to derive actionable insights is often still a challenge.

    CNCF industry survey data shows workload complexity and monitoring remain top challenges for enterprises in terms of using and deploying Kubernetes. Many understand there are valuable resources within these environments, but struggle to best identify and extract meaning from machine data. While most of this data is readily available, it just takes the right tools to gather and view intelligent insights.

    The Benefits of Open-Source Data Collection

    Perusing the CNCF website, there are a wealth of tools built around Kubernetes to enable not only monitoring but networking, storage and security. There is even a Kubernetes-specific package manager, Helm, to make the deployment and management of these resources easy and consistent.

    There are a couple of key benefits to taking advantage of these open-source collectors:

    1. They stay up to date. Each of these tools benefits from deep community support. As new versions of Kubernetes are released, the extensive use of each of these tools ensures they are quickly updated.
    2. They integrate with everything. Prometheus, for example, has an impressive list of integrations and exporters.  Regardless of your unique stack, it is likely that there is support for what you might want to export data from. The importance of these integrations cannot be overstated, as they enable the flexibility needed to grow and evolve a Kubernetes deployment over time.

    Ensuring Complete and Organized Metrics Collection

    Prometheus–endorsed by the CNCF–is the de facto tool of choice for metrics monitoring with extensive support for anything you might use to collect metrics data.

    Prometheus works by pulling data from all of the components and jobs running in Kubernetes since every component of Kubernetes exposes its metrics in a Prometheus format. The processes running behind those components then serve up the metrics on an HTTP URL. For example, the Kubernetes API Server serves its metrics on https://$API_HOST:443/metrics.

    Prometheus is particularly good at auto-discovering the jobs and services currently running in a Kubernetes cluster. As pods are added, removed or restarted, the Kubernetes Service construct keeps track of what pods exist for a given service. This auto-discovery capability is one of the primary reasons for Prometheus’ popularity, ensuring that all new and existing components are monitored.

    The Importance of Cluster Level Logging and Event Collection

    Kubernetes does not define a single standard approach to log collection, but the most common method is called cluster level logging. Cluster level logging deploys a node level logging agent to each node which then funnels data to a separate backend for storage and analysis of logs. The primary benefit of this solution is that if a pod dies, the logs detailing what happened are retained. Implementing node level logging, without funneling data to a logging backend, will not retain log data if pods die or are evicted, while cluster level logging ensures that data is captured and retailed. A common tool for implementing cluster level logging is Fluentd—or Fluentbit, a lightweight version of Fluentd—which acts as the node level logging agent funneling data to a logging backend.

    Events provide insight into decisions being made by the cluster and unexpected events that occur in Kubernetes. Events are stored by the API server on the master node and collected using the same method as log collection—via a node level logging agent like Fluentd.

    Establishing a Continuous Intelligence Dashboard

    Finally, collectors for logs, metrics, events and security can be easily deployed using Helm—an open source Kubernetes package manager. Helm can significantly simplify the setup process, reducing hundreds of lines of configuration to one. These collection plugins can be used on any Kubernetes cluster, whether one from a managed service such Amazon Elastic Kubernetes Service (EKS) or a cluster you are running entirely on your own.

    According to Sumo Logic’s recent Continuous Intelligence Report, enterprise adoption and deployments of multi-cloud grew 50% year-over-year, and 80% of users across multi-cloud environments are now utilizing Kubernetes architectures. As Kubernetes continues to become mainstream, it’s essential that businesses understand how these workloads operate and how to best extract valuable insights to inform business decisions.

    — Katie Lane

  • CNCF Advances CloudEvents Specification

    CNCF Advances CloudEvents Specification

    In a move that portends well for future cloud interoperability initiatives, the Cloud Native Computing Foundation (CNCF) today announced that the open source CloudEvents specification for describing event data had achieved a version 1.0 milestone.

    Doug Davis, senior technical staff member of IBM and co-chair of CNCF’s Serverless WG and the CloudEvents project, said CloudEvents will make it possible to not only define common attributes of an event to facilitate interoperability, but also make it easier to share those attributes between, for example, a repository such as GitHub and an application or tool that needs to consume those events.

    With that foundation in place, it also should become easier to build tools spanning serverless and event-driven architectures, he added.

    Work on the CloudEvents specification began in May 2018 as a sandbox project. With the release of CloudEvents 1.0, the CNCF Technical Oversight Committee (TOC) is now designating CloudEvents as an incubation project. Active contributors to the CloudEvents project include Amazon Web Services (AWS), Google, Microsoft, IBM, SAP, Red Hat and VMware. In fact, CloudEvents has already been implanted within the Eventing framework of Knative, an open source middleware project led by Google to integrate Kubernetes with various serverless computing frameworks. Other platforms that support CloudEvents include Microsoft Azure Event Grid, Red Hat EventFlow, Eclipse Vert.x and Debezium, SAP Kyma and the Event Gateway from Serverless.com.

    Davis said given the level of support for CloudEvents project, there is reason to be optimistic for future cloud interoperability initiatives. Cloud interoperability has been hampered by a dizzying array of application programming interfaces that often are proprietary. CloudEvents represents one of the few interoperability projects that has drawn support from all the major cloud service providers. Part of the success CloudEvents has enjoyed in that regard can be attributed to the limited scope of the initiative, he noted.

    It may be a while before organizations don’t have to worry about being locked into a cloud. However, as a general rule of thumb the more they focus on de facto specifications and application programming interfaces (APIs) exposed by platforms such as Kubernetes, the easier it will be to move applications from one platform to another. In many cases, DevOps teams today routinely struggle with moving applications that might have been developed on a public cloud onto an on-premises production environment. Longer term, it’s also expected IT leaders will want to be able to negotiate lower rates from cloud services providers by threatening to move workloads between cloud service providers.

    In the meantime, as event-driven architectures such as serverless computing frameworks continue to become more popular, IT leaders can take some comfort in the fact that interoperability across these architectures is advancing. Of course, it’s too early to say when the CloudEvents specification will become a fully graduated CNCF project, but it is already apparent many cloud service providers are not waiting on that official recognition before implementing it. The challenge and opportunity for DevOps teams now are to figure out how best to employ this capability to create new applications that previously would have been too difficult even to attempt.

    — Mike Vizard

  • DevOps Chat: OPA and the CNCF, With Torin Sandall

    DevOps Chat: OPA and the CNCF, With Torin Sandall

    The Open Policy Agent (OPA) was accepted for incubation by the Cloud Native Computing Foundation. In this DevOps Chat we spoke with one of the founders of the project, Torin Sandall, about OPA and why the CNCF is the right place for OPA. We also discuss the company he works for, Styra, which works with OPA.

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


    Transcript

    Alan Shimel: Hey, everyone. This is Alan Shimel, MediaOps, the people behind devopsy.kinsta.cloud, Container Journal, Security Boulevard and DevOps Chat, and you’re listening to another DevOps Chat.

    I’m really happy to have as a guest for this DevOps Chat, Torin Sandall, and Torin is actually one of the co-founders of the Open Policy Agent (OPA) open source project, which recently came under the guidance management of Cloud Native Computing.

    So, let’s welcome Torin. Torin, you there?

    Torin Sandall: Hey, Alan. Yeah, great to talk to you.

    Shimel: Great to have you here, and a pleasure to have you joining us on this podcast. Torin, let’s first start off with, maybe there are people out here who don’t know what OPA is—what Open Policy Agent is, right? There’s some great, if you go to—actually, if you go to CNCF.io, there’s a blog article all about it and I’ll put it in our show notes. But for those who are following along or listening to this in their car or what have you, talk to us—what’s Open Policy Agent?

    Sandall: Yeah, that’s a great question, and it’s a good way to get started.

    So, Open Policy Agent is a domain agnostic policy engine, okay? So, it’s general purpose, meaning that you can kind of take it and use it to enforce all kinds of policies and governance regimes across a wide range of technology.

    So, for example, if you want to say that, you know, all of your containers have to be sourced from an internal image registry, you can express that kind of a policy with OPA, or the Open Policy Agent. If you want to do something like say that certain users can only see certain pieces of data served by a micro service, you can also do that with the Open Policy Agent. And if you want to restrict who can SSH into a server or run a pseudo command on a server, you can also do that with the Open Policy Agent.

    So, the idea is that we give people this engine that allows them to unify policy control across various pieces of their stack.

    Shimel: Excellent. And you know what’s interesting? I was talking to someone the other day and we were talking about, you know, how does Kubernetes fit into this whole Cloud Native thing? Because Cloud Native and the CNCF is bigger than just Kubernetes. And they gave me a really good analogy. They said, “Think of it as like, you know, a fleet of warships or, you know, a U.S. Navy fleet and maybe Kubernetes is the aircraft carrier. But there’s more to the Navy than the aircraft carrier. There’s more to a fleet than an aircraft carrier. There’s battleships and cruisers and destroyers and subs and frigates and amphibious landing ships,” and you know, I’m not a Navy expert. [Laughter] But there’s all these different elements that make up the fleet—and it’s a huge fleet.

    And so, you know, when I look at OPA, you know, Open Policy Agent—and we’re gonna talk about joining Cloud Native Computing Foundation—it’s a necessary ship in the fleet, right? That really makes it easier and more practical to use a lot of the tools that are not only in the fleet, but a lot of the commercial tools that kind of exist on the periphery as well. Fair?

    Sandall: Absolutely, yeah. The CNCF is a collection of projects that provide a lot of value within the overall ecosystem, and there are a few things that kind of bind them together, and those are kind of high level principles. So, you know, they’re all open source, they are all, you know, they’re oriented around containers. They’re oriented around very dynamic systems that you need to manage at scale.

    And so, one of the interesting things about a lot of the projects within the CNCF is that they are kind of building blocks. You can think of them as libraries or building blocks for the overall system, right? And so, you know, they integrate together, you can plug them into other systems and so on. And so, that’s how we kind of look at OPA. That’s how we think about OPA, is as a building block or as a library for enabling rich, fine grain control across a variety of parts of your environment.

    Shimel: Absolutely.

    Sandall: And, yeah, and so, policy is particularly important when you start to talk about adoption of technology within large organizations, right? As Kubernetes has matured and enterprises have really started to run with it and deploy real production workloads on top of it, they’ve recognized the need for not just simple best practice kind of security measures, but much more sophisticated and rich and fine grained rules and constraints that need to be enforced in a system in order to keep everybody safe. And so, that’s where OPA fits into Kubernetes.

    Shimel: Yeah, absolutely. You know what? I realized, and I apologize, I really didn’t do a good job of letting you introduce yourself to our audience on top of [Cross talk].

    Sandall: [Laughter] That’s okay.

    Shimel: So, Torin, I apologize. In addition to you being one of the co-founders of the project, why don’t you share a little bit about what you do in your day job and the rest of your life?

    Sandall: For sure, yeah. So, I think what’s relevant here is that I’m the co-founder of the Open Policy Agent project. I’m also a software engineer at a startup called Styra. We’re the makers of the Open Policy Agent. We founded the project about three years ago—a little over three years ago, actually, and yeah, so we’re kind of like the stewards of the project today. That said, we’re starting to see a lot more people from the community kind of come in and start contributing to Open Policy Agent and related kind of projects in the ecosystem.

    So, that’s sort of what I do. My focus is kind of on Open Policy Agent, but I’m super interested in the overall Cloud Native ecosystem and security and policy and all that kinda stuff.

    Shimel: So, you know, and I should also mention—I did a terrible job laying this one out, Torin, I apologize. We should also mention that the big news coming out—I guess it was this week, or maybe late last week—was that OPA, Open Policy Agent, has now become or come under the auspices of Cloud Native Computing Foundation (CNCF).

    Sandall: That’s right, yeah. So, we actually, we joined the CNCF as a sandbox to your project last year, in 2018. OPA was added into the CNCF sandbox. So, the CNCF has multiple tiers, and right now there’s sandbox, incubation and graduated.

    And so, this year, basically, they do a review of projects, you know, every year, and they check in on how the projects are doing and how they’re growing and how their communities are evolving. And that’s just useful, right? To kind of maintain, kind of, you know, good hygiene within the ecosystem. But this time around, we felt that—everybody kinda felt that OPA was growing quite a bit and it kind of deserved to move up to the next level incubation within the CNCF.

    And so, the move from sandbox to incubation is really a reflection of the progress that we’ve made over the last year in terms of both production users as well as proof of concepts and integrations, and new external contributors joining the project.

    Shimel: Got it. And, you know, I will just mention that, you know, CNCF has really done an amazing job of shepherding these projects, from sandbox into incubation, and then from incubation into graduation. I forgot the number, if it was five or six projects they’ve graduated now.

    Sandall: Yeah, I think there’s about five graduated projects today. You know, Kubernetes is one of them, it’s kind of one of the flagship projects, and there are others. And so, yeah, so, they’re really doing a good job of curating a very important set of building blocks, like I said, that are gonna help organizations get to cloud native.

    Shimel: So, let me ask you a question—and I think this is something our audience would really enjoy. How did you, as a co-founder of the OPA project, right, what was your sort of motivation for, you know, bringing it under the CNCF?

    Sandall: So, yeah, that’s a great question. What we found was that after, you know, the project had been around for over a year, or rather over almost two years, I guess. And what we found with talking to users and potential users was that they wanted to see OPA as part of a kind of vendor neutral organization, right? So, Styra, the company that I work for, had kind of built OPA, and it’s been open source since day one, but people really like to see these kinds of projects, these kinds of core infrastructure components a little bit decoupled from, like say, any particular organization.

    Shimel: Mm-hmm.

    Sandall: And so—

    Shimel: Well, not decoupled from any particular organization. Decoupled from any one particular vendor.

    Sandall: One vendor—yeah, sorry. One vendor.

    Shimel: There’s not a single vendor.

    Sandall: Yes. And so, you know, we looked around and we looked at the CNCF and we really liked what they were doing and we figured that that was the right place for OPA to be.

    So, you know, the CNCF basically provides us with this kind of vendor-neutral home for the project, and it allows us to kinda create a rallying point around policy in the cloud native ecosystem. So, that was the main, high level motivation for joining CNCF.

    Shimel: Got it. And it makes perfect sense. I mean, I’ve gotta tell you, you know, I don’t know if you’re familiar, but recently, the CNCF launched—not the CNCF, excuse me—the Linux Foundation, right, which is kinda the parent of the CNCF, right?—

    Sandall: Right, yes. Yes.

    Shimel: —launched another foundation called the CD Foundation, Continuous Delivery.

    Sandall: Yes, yes.

    Shimel: And CloudBees, the folks at CloudBees and the Jenkins project was given under to the CD Foundation. Jenkins had Jenkins X, Netflix put in Spinnaker and Google put in—I forget its name now, with a T.

    Sandall: Tekton?

    Shimel: Tekton. They put, you know, put Tekton into the thing. And I had a good chance to interview some of the CloudBees folks with this, and I asked them the same kinda question I just asked you. You know, and it was a very similar answer, that not only do end users perhaps shy away from a single vendor supported project, but it’s very hard for a project to break out of that mold and get other vendors or talent at other vendors to contribute, because they think they’re doing it for the benefit of one of their competitors.

    So, by putting it under a neutral party like this, you know, not only is it more palatable to your end users and to the community as a whole, but it’s especially more attractive to that segment of the community that are made up of vendors. And whether you hate vendors and you think they’re all commercial slime who sold out to the man or not, the fact of the matter is, those are the people who have the resources to put into these projects and to move the needle and to keep that ball moving forward and push the rope up the hill and all of that. So, can’t live with ‘em, can’t live without ‘em, and this is a great kinda middle ground.

    Sandall: That’s a good point, and I think that, you know, what we’re starting to see are more and more security vendors getting interested in OPA or Open Policy Agent. I like to call it OPA. It’s hard to call it O-P-A when you’ve got that OPA word that you can use, but anyway—

    Shimel: Yeah, yeah, yeah. [Laughter]

    Sandall: [Laughter] But yeah, so, we’re seeing more and more security vendors get interested in OPA and, you know, that is gonna be instrumental in the long run to achieving the goal of unifying policy control across a number of different systems, right? There’s never gonna be one vendor that rules everything and there’s always gonna be an amalgamation of different technologies. And so, you know, the best that we can do, I think, is provide this building block that can be embedded all over the place and that has, like, the fundamental kind of groundwork that enables unification. So, very exciting times.

    Shimel: Absolutely. So, I’m gonna ask you now to put on your entrepreneur’s hat, right? As a co-founder of your company as well, and let’s look at it Torin from that point of view. How is this helping—and I’m not familiar with your company, so I’m gonna apologize in advance. Say the name for us, again?

    Sandall: Sorry, the name of the company is Styra.

    Shimel: How do you spell that?

    Sandall: S-T-Y-R-A.

    Shimel: Got it. So, how does this help Styra?

    Sandall: That’s a great question. So, yeah, when the founders—I’m not a founder of Styra, I’m an employee at Styra.

    Shimel: Oh, I’m sorry. Okay.

    Sandall: But anyway, when the founders of Styra started the company, one of the things that they observed was that, in order to unify enforcement of policies across a wide range of technology, there would need to be kind of like a language based approach applied to the problem domain.

    And so, that’s one of the things that the Open Policy Agent provides—it gives people this high level declarative language that they can use to codify policies. And so, that was kind of recognized as something that would be needed, and what you quickly kind of—the conclusion you quickly arrive to is that, this was in 2016, 2015, and even more so today, it’s true, but what you quickly arrive at is the realization that that kind of a technology needs to be open source, right? It’s unlikely that organizations are going to want to adopt a proprietary, closed source language. It’s just not going to happen.

    And so, right from the very beginning of the company, it was recognized that an important part of the technology was going to be open source. And so, that’s how the kind of project sort of got started.

    Shimel: Got it. Got it, got it, got it. You know, I don’t wanna put you on the spot, but a little Styra background—Styra’s venture backed or bootstrapped, or?

    Sandall: Yeah, we’re venture-backed, and we recently did a bit of a launch at the RSA Conference a few weeks ago.

    Shimel: Really?

    Sandall: And so, that was very exciting, yeah. And so, you know, you can think of Styra as a control plane for policies. So, OPA kind of acts as the data plane, right? It’s this thing that you can embed into applications, you can embed it into Kubernetes, you can put it all over the place. But, what you need is also the ability to kind of manage those OPAs that are running all over the place.

    And this is what we see within the OPA community—the people that are using OPA building it into their systems. Companies like Netflix that have built an internal security platform around OPA, what they’ve ended up doing is creating a centralized management plane for policy and for security.

    And so, that’s what we’re doing at Styra is, we’re helping people kind of think about distributed enforcement of policy and centralized management of policy.

    Shimel: Got it.

    Sandall: So, we’re focusing today on Kubernetes and you can check out the website, we’ve got a bunch of information on there, but yeah, that’s the high level.

    Shimel: Excellent stuff. As a matter of fact, just looking at the website, I didn’t realize this but Styra is Bill Mann’s company.

    Sandall: That’s correct, yeah, he’s the CEO.

    Shimel: So—just to show you how old I am. I’ve known Bill Mann a really, really long time, like, I remember the day he joined CA.

    Sandall: Bill knows a lot of folks, yeah. [Laughter]

    Shimel: Yeah, he gets around. Bill’s been around, and so have I.

    Sandall: Yeah.

    Shimel: I don’t know if that’s a good or a bad thing, you know? But hey, we’re still kickin’. So, tell Bill I said hello, he’ll get a chuckle out of it.

    Sandall: Yeah. I will do that, yeah. And we’ve got a great founding team. They are some of the folks that did Nicira, which is one of the very, you know, basically, the first SDN kind of company, right? They [Cross talk]—

    Shimel: Yep, I remember that one as well.

    Sandall: Yeah. So, we’ve got a deep background within the security and policy space, and we’re kinda taking that and really bringing it into the cloud native ecosystem.

    Shimel: Very cool. You know, I don’t wanna make this about Styra because we really wanted to concentrate on OPA and CNCF, but maybe we’ll still, maybe we’ll schedule something, a second one, and we’ll talk—we’ll dive more into Styra.

    Sandall: Yeah, that would be great.

    Shimel: You guys are gonna be at KubeCon in Madrid—or I mean, in Barcelona?

    Sandall: We are gonna be in KubeCon, yes, in Barcelona in May. There are going to be a bunch of talks about Open Policy Agent. There’s gonna be, I think there’s at least three or four sessions that are happening. There’s also a little thing called Cloud Native Rejects the weekend before. [Laughter] These are the talks—like, the BSides Talks, basically for—

    Shimel: Yes. Well, that’s how Security BSides started.

    Sandall: Yeah, exactly. And so, there’s gonna be a session there with OPA content in it. So, yeah, it’s gonna be a great event.

    Shimel: Excellent.

    Sandall: And, of course, we’re gonna have a Styra booth at the event, so.

    Shimel: So, we will have a, you know, Digital Anarchist is our video platform, and we’ll have a Digital Anarchist set there where we’ll be doing videos. So, be sure—we’ll talk offline, but we’ll get you guys in for a video. We’ll follow up more on that.

    Sandall: Perfect! Yeah, looking forward to it.

    Shimel: So, is there a timeline for graduation from incubation at CNCF, or that’s kinda open?

    Sandall: It’s open. So, you know, they do a yearly review of the project, and it’s kind of up to, you know, the community and CNCF and everybody to kind of decide when that’s right. And so—yeah, so right now, one of the main criteria for graduation is around external contribution. And so, you know, over the next year, we’ll see how external contribution around OPA evolves and if it’s in the right place, then we’ll go ahead with that.

    But we’re really happy right now just with the move to incubation because it brings more visibility to the project, it lends more credibility to the project—you know, in addition to all the people that are using it in production, having it more prominently represented within the CNCF is great. So, we’re really happy with where we are today.

    Shimel: Fantastic, man. Hey, Torin, I had promised you we’ll do this in 15 minutes, and that was 25 minutes ago.

    Sandall: [Laughter]

    Shimel: So, I apologize for running over, but I thought we had a good conversation here.

    Sandall: Yeah, yeah. Thanks a lot, Alan. Yeah, I appreciate the time to talk about OPA and Styra and I look forward to—

    Shimel: Oh, it was really my pleasure. I’d like to—we’ll continue this at maybe KubeCon in May. But before we sign off—so, Styra is Styra.com, S-T-Y-R-A.com. The OPA project, right, is—

    Sandall: Yep.

    Shimel: —OpenPolicyAgent.org?

    Sandall: That’s correct, yep.

    Shimel: And, of course, you can find more information on it at the CNCF.io site, right?—

    Sandall: Absolutely, yeah, and it’s on GitHub and we also have a blog if you go to blog.OpenPolicyAgent.org, you can find out more there. So, yeah, check it out, and—yeah.

    Shimel: [Cross talk] It’s all good. Hey, Torin Sandall, co-founder of the OPA, Open Policy Agent project, which is now being incubated by Cloud Native Computing Foundation, as well as an employee at Styra—for my friend Bill Mann.

    Sandall: [Laughter]

    Shimel: So, good to have you on there. Say hello to Bill for me. Best of luck with OPA.

    Sandall: Will do.

    Shimel: And look forward to seeing you in May at KubeCon.

    Sandall: Looking forward to it. Talk to you later. Bye.

    Shimel: Alright Torin, thanks. Hey, this is Alan Shimel for devopsy.kinsta.cloud, Container Journal and Security Boulevard. You’ve just listened to another DevOps Chat.

    — Alan Shimel

  • Cequence Security Joins Cloud Native Computing Foundation (CNCF) To Collaborate On Projects That Will Strengthen Application Security

    Cequence’s container-based, microservices application security architecture leverages open source technologies supported by CNCF members worldwide

    SUNNYVALE, Calif., April 9, 2019 — Cequence Security, a provider of innovative application security solutions for today’s hyper-connected enterprises, today announced that it has joined the Cloud Native Computing Foundation (CNCF). The CNCF is a global, vendor-neutral organization with a clear mission: make cloud native computing ubiquitous by fostering and sustaining an ecosystem of open source, vendor-neutral projects that contribute toward that goal.

    “Moving to cloud-native and particularly the continuous integration and continuous development that goes along with that is the most important process that you can do to help secure your infrastructure,” explained Dan Kohn, Executive Director at CNCF. “The technology developed by Cequence Security aligns perfectly with this process and we welcome them as CNCF’s newest members.”

    Cequence Security provides today’s hyper-connected organizations with a cloud-native, container-based software platform that enables its patented, AI-based security to be “baked in” to the web, mobile, and API application services that customers rely on to connect customers, partners, and suppliers.  Its award-winning CQ botDefense is one example of a cloud-native security application that can be rapidly deployed in multiple private and public clouds, as well as on-premises data centers. CQ botDefense solution runs on the Cequence Application Security Platform and features an unmatched ability to automatically detect and defend against malicious bot attacks, including account takeover, business logic abuse, financial fraud, application DDoS, denial of inventory and other potentially catastrophic business disruptors.

    “We’re seeing most large organizations transitioning very quickly from legacy monolithic applications to cloud-native architectures where these apps run as container-based microservices,” said Shreyans Mehta, CTO of Cequence Security. “We’ve developed an application security architecture specifically for this cloud-native environment.  And we joined CNCF so that we can collaborate with other members that share our vision.  We seamlessly integrate our application security capabilities with Kubernetes and Envoy to help ease the transition for customers adopting these cloud-native architectures.”

    About Cequence Security

    Cequence Security delivers an award-winning, game-changing application security platform for today’s hyper-connected organizations that rely on web, mobile, and API application services to support business processes and enable customer engagements. The platform leverages an AI-powered analytics engine to consolidate multiple functions that strengthen the security posture of these organizations against a broad range of application attacks. The automation within the analytics engine also improves the productivity and efficiency of IT resources. Cequence’s management team includes Larry Link, CEO, Ameya Talwalkar, CPO and Shreyans Mehta, CTO. Larry led the worldwide sales team for Palo Alto Networks from 2007 to 2012. Ameya and Shreyans led the development of Symantec’s anti-malware platform. The company is venture-backed and headquartered in Sunnyvale, CA. Learn more at www.cequence.ai.

     

    #