|Featuring special guest Yoav Landman, CTO and Co Founder of JFROG, this episode takes a deep dive into various infrastructure practice from on prem, to cloud, edge… and everything inbetween!|
Announcer: [00:01] Welcome to the Cloudify Tech Talk Podcast, taking a deeper dive into all things DevOps, all things toolchains, all things automation, and all things orchestration.
Nati [00:14] Hello, everybody, and welcome to episode 19 of the Cloudify Tech Talk Podcast. I’m here with a distinguished guest Yoav from JFrog, the CTO in JFrog. I’ll let Yoav start with a quick introduction of yourself. Yoav, welcome to the podcast. And thank you for accepting the invite.
Yoav: [00:32] Yeah, sure. Thanks, Nati for having me. So just an intro about myself. I’m Yoav Landman. I’m CTO and co-founder of JFrog. And JFrog is a software supply chain platform, this is what we do. And the way that we manage your software supply chain is through binaries, we call it BinOps. And if you think about it as a developer, the first line of code that you write is importing some kind of third-party library. So you start working with binaries from the get-go. And then once you created your first commit, you create a release. And then you need somebody to host this release, you need to test the quality of this release, you need to test the security of the release, whether it has vulnerabilities or license compliance issues. And finally, you have to distribute the release to remote locations or to your data centers, and then you have to run it and deploy it sometimes on the edge, sometimes on the data center. So JFrog is a platform [where] we are well renowned for Artifactory, which is our main flagship product for managing software packages and binaries in general. And then we have X-ray for all the security scanning, both binaries, and also to the left in your source code and so on. Distribution, which is distributing the binaries, pipelines is on CI/CD, and finally, Upswift which is a new acquisition for managing edge deployments.
Nati: [02:18] Excellent. And Yoav, I know JFrog from the Maven days, and before we’ll get into prediction and what’s expected to us in the future, maybe you could walk us through a little bit of the journey of how JFrog became what it is today, from the Maven days into where we are today, and how binary became such a category.
Yoav: [02:42] True. So we’re both veterans, we have the history of still remembering the old Maven days, in which binary management was almost nonexistent, it was also very unreliable. So JFrog really started as a remote proxy and Artifactory was initially a remote proxy for a myriad of Maven repositories that were up there. Since then, they consolidated under Maven Central. And slowly, we moved to being everything binary, so we became universal, we have expanded our support for numerous types of binaries, I think approaching 30 types of different ecosystems of binaries in Artifactory. And then since we are acting like, as we like to call it, the database of DevOps, we hold all your binaries that you will ever push into production or discard them, because 99% of them just become CI garbage. So we expand it to the other domains that I was speaking about before, just because we are in control of the main pipe of your software releases. And we also expanded from on-prem to the cloud, so we are also a hybrid company. And yeah, so since then, a lot has happened. But I think binaries became a very focal point in what software is today. I mean, it’s the most tangible asset for any software release.
Nati: [04:28] And as you said, we’re both veterans and I’m trying to kind of look retrospect again into JFrog and the history and what was really the thing that kind of became the main jump point maybe. From at least my perspective, container was one of those points in time in which binary became very, I would say, commonly adopted as something that everyone uses. Before that, it was RPM, and again, Maven was using Java developers. And it was very kind of, I would say, placed in different niches in the stack but not necessarily something common across many users. And containers really made binaries much more common across many ubiquitous use cases. And I think you were smart enough to identify that, as opposed to Docker, for example, which was the one who maybe created containers, but didn’t see the opportunity of managing them. Or at least not managing them well.
Yoav: [05:42] Yeah, I think Docker has two life cycles, there is the Docker of the old days and Docker of nowadays. But to your point, I fully agree, I think containers has dramatically changed the way that people are actually putting something around releases that didn’t exist before. Before that, it was just maybe a collection of files that were not really managed or managed in a very proprietary way. And actually, when we started with containers, it was after Karl Quint drew our attention to this technology, and then we started to support containers. Even before Docker had done a public registry, we were working against the source code of Docker to support the standout, which was still shaping and it was still a proprietary stand out back then. And yeah, it completely changed and created the evolution in the world of software management, artifact management, even in terms of economy. The bytes that are been transferred over the web, since it’s all about reshaping immutable infrastructure from point A to point B, this changed also the economy of [inaudible 07:10].
Nati: [7:13] And maybe that would be a good point, I know that this is a bit kind of off the course of the discussion but since you brought it up, it’s interesting to talk about that. You said that there is a Docker of the past and a Docker of today. Can you kind of give us your perspective on what happens to Docker and how do you see Docker evolving today?
Yoav: 07:36] Yeah, I think the market talks a lot about it and you can find many opinions about this on the internet, but I think that what happened really is, as a company, it’s great to have an open source technology, but you also have to care about being a company. And I think this was the main issue. Docker of today is very different, and we really appreciate this company.
Nati: [08:17] I see. Okay.
Yoav: [08:19] And also, they made a huge contribution to the world of computing and to DevOps in general.
Nati: [08:31] I personally think that one of the things that– And I think you brought up a couple of interesting points about it, and I see that you’re trying to be careful I’m assuming here, and I’ll try to be a little bit bold about it. I think that when I look at the history, they kind of tried to expand. And I remember my discussion with Uri from now Elastic, it was Cloudify back then. And he said they were trying to kind of win the entire stack, moving from Docker to Swarm. And the move up the stack was the point in time in which I think the industry started, especially when you look at the big companies like Google, Microsoft, and others, and obviously RedHat, they saw that as a huge threat. I mean, as long as they were kind of in the category of containers, I think there were still okay. But as soon as they started to kind of move up the stack and started to be this dictator kind of thing, that created the motivation by other companies to compete with them, and basically provide the glass ceiling, a low glassing, which is called Kubernetes, on how far they can go beyond the stack. And obviously, RedHat started to attack from the bottom and kind of commoditize them both on the top and on the bottom and that’s where they kind of got squeezed, where I think in your place, you identified the need within the realm of binaries to focus on delivery and managing binaries, which I think was the right thing to focus on. And maybe if they would be as smart as you in that regard, they would probably be in a different position as they are today.
[10:24] Now, that really brings me to the next point of our discussion. And that’s what I liked about this discussion, why I reached out to you is, I think JFrog represents, both in the history and in the product line today, an interesting perspective on where the market was going. And second, since you now have a fairly large portfolio of tools that covers not just the boundaries, but the rest of the pipeline, in the demos there are very good, I’d say, insights on where the market is. And therefore, I didn’t want to talk just about JFrog, but also take your brain and ask you, Yoav, as someone who’s seen the industry, how do you see the main trends. And we’ve kind of broken into the following categories. The obvious one is infrastructure as code, and how well that’s been adopted and will be adopted. And we know that there are always changes there. Kubernetes itself, and where are we seeing [it]. And I quoted a few statistics here that we’ll talk about. CI/CD would be another category, and also continuous development and culture. So we’ll try to break it down into those categories and try to get your brain on how you see the industries on each of those categories. So let’s start with Terraform. Do you think that Terraform will remain the only player in town or do you see that market becoming a little bit more fragmented, with things like Pulumi or cloud providers like CloudFormation and Azure trying to take their piece in the market?
Yoav: [12:05] Yeah, it’s funny. Today, at least from what we’re seeing, Terraform is the most predominant player. We can also see that from the number of startups that are forming around Terraform as the standard. And I think they made something quite right in terms of the extensibility and simplicity to the user. So I think that they’re still good, especially because the ecosystem is thriving around them. And I know that Amazon, besides CloudFormation, they also have another– I forgot the name, but another Pulumi-like project that allows you to do infra as code but as real code, not declarative, but actually real programming language. I still think Terraform is going to prevail until something else comes in, because also their declarative nature allows you to develop on top of it much more easily because the model is clear. So you can do things like analyze the drift and do some language analysis to apply security rules. This is where we see most of the startups. Some of them were actually using JFrog to add value on top. I’m a little bit surprised that Hashi themselves didn’t add this value out of the box. Maybe they will, I don’t know.
Nati: [13:44] So you touched on a couple of things. Let’s talk about the declarative nature allows you to model things because it provides you a structure that is very domain-specific. It provides you a structure in which you could analyze, like doing a plan and drift you mentioned. For those who are less familiar with those terms, drifts allows you to see the delta between the intent, which is what’s defining the plan. And the plan allows you to see before you’re executing, what is about to be executed. Those things are more easily dealt with when you have declarative language than when you have native code. The benefit of the native code approach is that it caters to developers, you could write the same if you like, business logic of automation in fewer lines of code. That’s kind of what developers like. But it’s harder to synthesize and it’s harder to write, to build an ecosystem behind it that can analyze it and understand what’s going on because it is a code, and the code can be expressed in so many ways that it’s much harder to analyze and provide those things. And I think you touched on the right tradeoffs between the two approaches here right now. It would be still interesting to see how this market evolved, but I do agree with you that their declarative nature and the fact that it opens up such an ecosystem behind it is a very sticky point in the market and not something that the market I think will change very easily from right now.
[15:21] I do see that– and that’s kind of interesting why this is happening, but I see that the cloud providers still stick with their own native orchestration. And even though they do support Terraform, they don’t want to be dependent on Terraform. So it will be interesting to see if, at some point, they will exceed what Terraform provides in terms of coverage to the point in which it will be harder to use Terraform. And I’m seeing some areas where this is already happening. Because one of the challenges I think of working with something like that is that there’s always this catch-up, where you have to map all the resources of the cloud into that common language. And since cloud APIs and services are moving so fast, there’s always going to be some delta and gap between what is covered with the providers and what’s actually available in the cloud. And that’s I think, the area where the native cloud orchestration plays with, they’re always on par with all the cloud services. And that’s good for the delta, but it would be interesting to see where that’s going to lead. I do agree with you that probably, in the near future, we’re still going to see very high dominance of Terraform covering that space, by large, if you like, landscape in terms of adoption, and developers’ experience with that.
Yoav: [16:56] On the other hand, I wanted to say that Terraform has a larger community than the cloud vendors, which are always cloud-specific even if they claim that they aren’t. They usually develop cloud first for their own cloud. And not everyone is on the latest and greatest all the time, so the catch up– Usually, if something is popular, it happens quite quickly. But you’re right, if there is something specific–
Nati: [17:26] That’s actually interesting–
Yoav: [17:29] Go ahead.
Nati: [17:29] Yeah, that’s actually interesting, because one of the things that I keep on getting asked is, “Why can Amazon do that? Why can’t Azure do that?” For many differences. And I’m saying there’s always a need for vertical focus, and I think you’re playing in that category, as well. And part of the value of vertical focus is not being dependent on a cloud, and second, it’s providing something that is much more focused in certain areas. And what we’re seeing is that, in cloud providers, they become kind of a supermarket – too many things, not necessarily the best at any category, but the value is being the supermarket, where vertical focused solutions would provide a very, I would say, deep solution in a certain area. And that’s why we will never probably be at a point in which we’ll see everything now managed by cloud and the entire market is now being done by the cloud.
Yoav: [18:26] I’m not sure that the real value is being the supermarket. I mean, at the end of the day, like you said, the solutions, sometimes they fill the bill, but not the best upgrade. And more than not, they are not integrated. I mean, there is no common model or a way to integrate the solutions in an opinionated way, just a collection of tools. I’m talking mainly about things that are brought in from the open source and wrapped in the cloud provider packaging. But what they will tell you, and they talk about it openly, all the three of them–
Nati: [19:17] When you’re saying “they”
Yoav: [19:19] “They” is the public support, the big three – Amazon, Google, and Azure. For them, it’s just a vehicle to generate more traffic in many more compute in the cloud. So if they need to give you certain services in order to keep them closer to your compute, even if they sponsor them and subsidize the cost. And they don’t see themselves as competing with the other tools head-to-head on quality. It’s mainly the convenience and even the financial convenience of being able to pay with the same credit line that you have with a cloud vendor. Sometimes this is convenience is leading the decision to take a cloud solution.
Nati: [20:13] Now, you mentioned the ecosystem around Terraform, and before we move to Kubernetes, there’s a skill that is required to build those templates, and definitely at scale, and well. It’s obviously relatively high, you need to be a very skilled engineer to write those things. And what I’m starting to see in the industry is different attempts to address this complexity and reduce the barrier to entry, provide more flexibility on how you write those templates. There is also kind of an opposite trend called no-code. And obviously, that works in a completely opposite direction to the S code, type of mentality. How do you see that kind of evolving? Do you see the two living side by side or is one going to dominate the other?
Yoav: [21:09] So I think it’s all a matter of convenience. I think most developers will prefer procedural coding, rather than doing configuration as code. On the other hand, in terms of being able to, and this is the convenience part, being able to guarantee the correctness of something, to do what we spoke about before, the drift detection, and being able just to review something and immediately understand. So it’s easier to read than write, in a way, because you cannot really automate on it, and if you are, it’s usually a lot harder to understand unless you’re just manipulating a couple of variables. Yeah, so I think this is one of the reasons why it’s so popular. It also leads to some kind of anti-patterns like being able to patch the configuration. So because of this simplicity, and because you need this simplicity with configuration, I think this is why this approach wins big time.
Nati: [22:34] I tend to agree. I think that what we’ll probably see, that’s at least my two cents into that is that, obviously Terraform is there to stay and probably will keep on dominating the infrastructure as code thing, but we’ll start to see this ecosystem starting to build around it. Some of it will be focused around that simplicity that you mentioned, which is not everyone needs to be a skilled engineer to use those stuff. And the other thing is really to enable organizations to organize all these templates. Because we’re starting to see as [with] any new technologies, you start at some point where using a CLI to run Terraform was good enough but as you start to scale, and we’ll touch on some of the use cases when we’ll talk about edge, running things through a CLI is not good enough, because it’s becoming very quickly a wild west and it’s hard to understand what’s going on. So I think that what we’re probably going to see more is an ecosystem built around Terraform, not necessarily by Hashi, [but] by an entire industry, a new industry that will be built around it to provide this simplicity, added value services. We’re already seeing it in security, for example. There’s a lot of companies now, building solutions for analyzing Terraform templates, HashiCorp is starting to grow in that area as well. So I think we’re looking beyond the IAC thing. IAC becomes a reality and now we’re probably going to see ecosystems built on top of it to address some of the challenges, especially scale challenges behind it.
[24:11] That brings me to Kubernetes, where I don’t know how many years, I think if I would count, probably at least six years that we are in Kubernetes. And one of the things that I was surprised to see in the latest survey– It’s not actually the latest but it’s the latest public one. So CNCF is doing a yearly survey between its developers and one of the questions that they ask is rate your top challenges of using Kubernetes. And on the 2020 survey, which again, it’s the latest public one, I was really surprised to see complexity still being the number one. Actually, I think it was reduced a year or two years ago, and then it became high again, and I wasn’t sure why. Why are we still at that point?
Yoav: [25:17] I think orchestration is hard. It doesn’t matter how you turn it, it’s a complicated job to achieve. So the number of metadata points that you need to manage in order to manage these complexities is high. And you need to take care of different deployments, how services are being restarted. And everything is declarative: how they provide their health, if they need to scale or not, and how do you abstract things like file systems, and how do you abstract things like databases. This is all very complicated. And at the end of the day, it also runs on the Ingress rules, they run on regular “software”, so they are going to tweak your NGINX config in order to achieve the mapping between the declarative roles. And every abstraction like that also comes with its own problems. So the complexity of the syntax, the richness of it, together with how it gets applied in reality, this is, I think, what contributes to the complexity.
Nati: [26:51] But do you see it getting to the point where OpenStack was that at some point, it was so complex that people started to ask, “Why should I bother?” and went to something else? In this case, it was Kubernetes. But the question is, are we at that point, or are you still seeing people adopting Kubernetes regardless?
Yoav: [27:16] Well, I hope it doesn’t end up like OpenStack. Some of the default implementations also in OpenStack were not all that great. We ourselves spoke to JFrog at the time. With some of them such as the Swift object storage, it wasn’t the highest quality piece of software so that also impacts the adoption. So I don’t think so, because I think that the implementation of Kubernetes is still far more mature and also gets a lot of engineering power behind it. On the other hand, I think it will get more complicated and it will get disrupted. To tell you that I know by what, no, but it’s getting more and more complicated. And we’re sometimes seeing customers moving away and choosing lighter solutions, such as Serverless, going to Lambdas, or to Cloud Functions and Cloudflow workers and adopting a management fee execution service, which always comes with some kind of price. You need to have a different mindset about how much a computer can suck out from such a lightweight compute instance. And also, people moving to simpler solutions, such as Fargate or ECS. So it’s not uncommon, to be honest, but the majority of the market adoption that we’re seeing is no doubt around Kubernetes because it still solves a lot of problems.
Nati: [29:15] So what you’re basically saying is that, again, for those who are less familiar, when you’re talking about, Lambda services and Serverless, in general, as a managed solution, one of the things that I think they do pretty well, and I heard it, I think you’re right to say, by multiple startups is managing the scale. So the main complexity of running on Kubernetes is that managing scale is still something that you have to deal with. I mean, they do provide the replica set and another feature around it, but it requires a very good skill set on writing a good scale policy. Definitely when you’re going through your redundant type of scenarios. Well Lambda services and Fargate, I think in that context, kind of takes care of all that for you, and you don’t have to worry about scale when you’re going in that kind of direction. That’s, I think, what drives some, especially when they’re getting into the scale point, to look into alternatives, because the complexity is still sometimes too high.
[30:20] There’s a podcast about Optibus here with Eitan that was talking about his journey around that, and he was specifically referring to using Kubernetes for things that require heavy business logic, but for all the rest of the processes, he was starting to move into Lambda services. Again, it’s not free of complexity, because then troubleshooting Serverless can itself become complex. But scale is definitely easier. So I do agree with you that if the complexity wouldn’t get lower, and your prediction, and I think it’s right, that it’s actually going to be higher, probably before it’s going to be lower, that for sure will start to drive disruption into this. And we’ll definitely see alternatives coming, not just Lambda services, but probably something else because I’m sure there’s going to be many use cases in which that complexity is going to be too high for the value that it brings. But that’s probably not going to happen in the next two, three years, at least not at the high level, it’s probably going to take some time until we’ll reach that point. But it’s something to worry about, especially when you’re starting to bet everything on Kubernetes. You need to also think about the day after and kind of think of how to manage your stuff, not just in one platform.
Yoav: [31:54] Server is not a question of alternatives because if you look at what’s out there, like you said, there are some alternatives that are taking the server management completely away, but they come at the price. And the alternatives for Kubernetes today are not that great if you are looking at automation, and it has a learning curve. If you decide to automate instead of hard coding, it comes with a learning curve. And what we’re seeing with all the adoption of new CRDs is that many people choose to apply the Kubernetes feedback loop to manage the on setup, it’s not easy to use. You can say a lot of things about the elegance of the pattern but it’s not extremely easy to use to run … control apply for every single configuration, it’s like the hammer symptom.
Nati: [33:03] Yeah, the golden hammer. Yep. I agree with that. And I think again, if I kind of look at the trends, one of the things that is still playing very strongly, I would say towards Kubernetes is the fact that every cloud now supports it and it provides this layer of abstraction between clouds. So if you do need to run your workload in a hybrid kind of stack, where you don’t want to completely be locked into a cloud provider, that’s still the best option right now for doing it. One of the trends, I think would need to be discussed here, when we talked about cost with Martin Casado in one of the podcasts, was repatriation. I think that things like repatriation or even Multicloud couldn’t be done. I don’t think that people would even think about it if it wasn’t for Kubernetes, because running workload, let’s say, outside of the cloud without Kubernetes, I wouldn’t even think about it. But with Kubernetes, it does give us the option. And what I’ve seen in this survey, which was also interesting is the trend in which the number of organizations that are running Kubernetes outside of the cloud, not necessarily private cloud, outside of the cloud, this is actually growing. And I thought that was surprising because you would expect that everyone would be using a managed Kubernetes by the cloud but there’s some cost factor associated with that, that makes it still beneficial to use Kubernetes also, outside of the cloud. And that’s still one of the main value propositions of Kubernetes that I think justifies the complexity today. But when it comes to scale, I think that’s kind of where if you’re using Kubernetes to manage scale, that’s where you would probably find the value starting to be marginal, especially when the alternatives that you mentioned. Yeah, go ahead,
Yoav: [35:10] I can actually speak to it because first of all, JFrog is both on-prem and in the cloud, and our stack is full Kubernetes. So on all three cloud providers, but also on-prem, we’re actually seeing a lot of customers running Kubernetes on-prem and using […] anywhere else approach of Kubernetes. Normally, it’s in the cloud, but it’s still self-managed so in my view, it’s similar to an on-prem. Even the compute is released from the cloud provider. The other area where we’re starting to see this is, and I think we will speak a little bit more about this, is edge. We’re seeing Kubernetes running on Pi’s and on kind of low-end hardware. And because of the abstraction, because of this ease of deployment, and ubiquity of deployment, it becomes also popular.
Nati: [36:16] I agree. So if I summarize it, I think the complexity is mostly in managing scale, and that’s where I think there’s still a weak area in Kubernetes. Where I think Kubernetes still shines, and probably will continue to shine is in the portability aspect. And that demand is not going to go away anytime soon, in my view. And what’s going to keep Kubernetes still high in the adoption curve, in my view, is as I think you mentioned already too, some of them we’ll talk about later in this discussion like edge and others, and those cases are not going to go away in my view. So for those who are looking at the future of Kubernetes, I think, one, it’s not going to go away but when it comes to scale, that’s probably where you’re going to hit some limits, especially in terms of complexity and Kubernetes. And at that point, if you’re in a very high scale, you may need to consider alternatives because the complexity would be too high. Second, if you do need to look for simplicity of Kubernetes, I think you mentioned a couple of options, Fargate, Spot, I think, an Israeli alternative, and others are starting to get into this game and trying to abstract some that scaling complexity by changing the Compute Engine behind Kubernetes and providing still the abstraction without the complexity. So we’re going to see both Kubernetes itself starting to address the complexity of scaling. The fact that Kubernetes provides that portability is going to keep it a viable option and highly in the adoption curve. And Lambda services, if you’re looking for simple scaling, probably is going to gain more adoption in those use cases. But Kubernetes is definitely [inaudible 38:07] go away.
[38:08] That brings me to the next topic. And as you can see, we have a lot of ground to cover here, Yoav, because you are especially in the context where you are touching all those areas, the CI/CD itself. Now, I was looking at the survey again and other reports around it, and I was surprised even myself to see the number of tools that keep on growing there. I would expect that CI/CD is there for how many years, that we would see some consolidation happening in the market. And what I’m seeing is circles of consolidation.
Yoav: [38:39] Mutation?
Nati: [38:40] Yeah, it’s like it’s looking like it’s going to consolidate, and then it opens up again. It started as a pipeline, like in Jenkins, and then all of a sudden Kubernetes came in and change the entire ecosystem. And there’s been a lot of startups starting to address the container-based pipeline, and that opens the market again, and now there’s GitHub and Git Actions and all those different approaches that are trying to address that. Maybe you could give me at least some view of all those strains and what is really happening here.
Yoav: [39:17] I can attempt. So I think what has been commoditized is CI. And even at JFrog, what we’re seeing here among customers is that – and we have our own solution for CI here and CD JFrog pipelines – it’s no longer such a big threat to move from one vendor to another. I’m not talking about old-style Jenkins, but the modern declarative CI. The model of the CI itself became almost a commodity. Everybody knows how to model it, everybody knows what the different concepts that they need to work with this, and the tools are also very similar. If you take a [inaudible 40:04] of one tool and the [inaudible 40:06] of another tool, it’s mostly syntactic differences and some features that you will have to adjust to but for the most part, it’s not all that different. I think the market is now not even consolidating, it’s just trying to find a way is the realm of CD. Because, for me, what happened is that since we started with CI, it was very easy to say, “Okay, I have some tool that knows how to do workflow, that knows how to do orchestration, and we’re going to take it to the world of CD, and we’re going to use the same tool to deploy.” And I think this world is very, very different.
[40:57] First of all, you don’t need a lot of compute to do CD, you don’t need a farm of builders, in order to run. You can easily, from a single machine, provided you’re not the one providing the binaries but pulling them from a registry, you can do thousands of jobs in parallel, you don’t need a farm of workers. And also the concepts in CD and the need to track what’s going on and to do progressive work, there’s a lot of feedback that needs to be in the loop that doesn’t necessarily exist in regular viewing of the CI logs kind of notion. It also goes by the way to IoT and fleet management and deploying to remote devices, you still need to get this almost visual feedback of how things were working, and if it failed, you need to run different policies, and it becomes very different from procedural CI. So I think this domain is fluctuating right now. Also, I think that if there isn’t a domain where almost all of them are consolidated around these, the fact that they are based on running Docker images, which is not ideal, to be honest. Because of the way that you sometimes need to wait for the scale, it still takes a little bit of time to fire up. And it is also very dangerous. And I’m not sure if you followed but almost all of the CI/CD vendors now protect, including JFrog by the way, they protect their free offering with the [inaudible 42:59].
Nati: [43:00] Oh.
Yoav: [43:01] Yeah, for Bitcoin miners, it’s like they’re all waiting to get into it. So it’s very creative.
Nati: [43:10] No, I didn’t follow that. That’s actually interesting. I never followed that one but now that you’re saying it, it makes so much sense because it’s like a compute power that is just waiting to be–
Yoav: [43:23] Yeah. Definitely compute if you can. Abuse it.
Nati: [43:26] Yeah, definitely. Interesting. Wow. And in terms of the list here, I think that the survey itself is misleading because you see Jenkins at the top, but I think that’s not representing the trend. I think it’s probably more representing the history because it has been the most dominant one, but the trend is actually shifting away from it from what I’m seeing. Would you categorize Git Action as a CI tool or CD tool?
Yoav: [44:10] I think CI mostly.
Nati: [44:14] CI Mostly. And where would you categorize GitHubs? Like [inaudible [44:20]
Yoav: [44:21] Yeah, probably around CD.
Nati: [44:23] Around CD? Okay.
Yoav: [44:24] Yeah, because it’s CD and also, in a way– I mean, if you factor in infrastructure as code into CD, it also falls under this category, because it’s all around creating the [same 44:40] group and changing your configuration and pulling in the right pieces of software into it as an event coming from it. I mean developers love it because they can control everything using the Git common interface, but it’s a very simplistic way to model things.
Nati: [45:09] Yeah. When I’m trying to look into that trend and why it’s adopted, I do agree that it’s very convenient for developers because it basically– Again, for those who are less familiar with GitHub and what it means, it means that instead of going to CI/CD and starting a job, your event starts run, commit, merge, all the lifecycle events that are happening at Git, and then triggers indirectly, those processes, kind of behind the scenes. So from the developer perspective, you don’t have to deal with another tool, you just use the development tools, and that kind of triggers it. But as I think, Yoav, you mentioned it’s a simplistic view, because those processes can be very complex. And when you’re doing it in such a level of abstraction, when something goes wrong, and the process is relatively complex, it’s very hard to know what’s going on and what’s wrong, because it’s sometimes one obstruction too much. And for simple use cases, it’s probably very straightforward, but for more complex use cases, I think it’s going to be pretty dangerous. And also, it’s it can be a leaky abstraction, leaky in the sense that because a user may not know that he’s triggering a workflow behind the scenes, he may do the wrong event and trigger a workflow that it wasn’t really expecting to happen and that could have dangerous effects. So it does require a lot of responsibility. And I think, despite the adoption trend, and it’s fairly high on the hype, I think there’s a lot of maturity that needs to happen here before it will get to the mainstream, like Enterprise, and whatever. That’s my view on that. What’s
Yoav: [46:58] Yeah, I fully agree with you. Also, not all events are coming necessarily from Git commit, sometimes you have external events, such as you pushed your releases into some external system that is running tests on them, and you need to get the event once the test is completed. I know you wanted to speak about it further down, but sometimes there is a man in the loop. Sometimes you have a blackout window that you cannot deploy anything and if you have to, you have to get– It happens, especially with the largest commercial vendors. JFrog has some customers, for instance, that will never push out anything before Black Friday, or a big sales event that is happening because of the risk. But still, if something needs to be pushed, you need to have a man in the loop. And there are some other systems that may trigger events that actually make deployment happen. For instance, somebody may approve a ticket in ServiceNow automatically to trigger an event and then doesn’t get reflected in GitOps. On the other hand, for the most common cases, it makes a lot of sense. But it’s an implementation detail for me, really.
Nati: [48:31] So just again, to elaborate on what you just said, for those who are less familiar with that or didn’t follow, when we talk about continuous integration and continuous deployment, the whole idea is to push code out into production with no human intervention. That’s kind of the promise at least. And the reality, though, is that the cases in which that intervention is required, either by regulation or because, as you mentioned, Black Friday and whatever, there is an opposite trend, which is related to the security aspects. When you push code into production, it has to be highly governed and regulated, so those processes do require some intervention in that process. And therefore, what we’re seeing is, and I think he catered to that, is that there’s actually a decline in the amount of organizations that are pushing code completely automatically into – and that’s actually reflected in the survey – production. And they’re recognizing that they do need to have some control point in the process. I wouldn’t say that continuous deployment wouldn’t happen, but I think we’re probably going to see the hybrid kind of mode where some of the things will be completely automated, but some of the things will need to have control. And that touches on the tools that are not necessarily good at controlling those processes. We talked about GitOps as one option. It’s much harder to have those types of intervention in that process and other tools around it. But if you look at that, again, are we expecting to see any consolidation happening soon, or is that still going to be in 2022? What do you think will happen in this market?
Yoav: [50:21] In the CI/CD space you mean?
Nati: [50:22] Yeah, in the [CI], CI/CD or CD, wherever, you pick.
Yoav: [50:28] CI, I think definitely. I think we’re going to start to see consolidation happening quite rapidly. I think even within the next year. CD, I still think that the market is immature. I think that if you look at the solutions that are out there, for me, being there before, it’s reflective of the state of CI in the beginning. The tools are so different from each other, the feature set, even though there’s some commonality, the way that the tools are implementing them– For instance, progressive deployment, and what do you do when something breaks, which is, by the way, a good example as well, Git Ops is not always that easy to understand. Whether you let some AI take control over the process, which, at least in my view, you need to have a lot of data to train your AI to actually trust it blindly to roll back things. So, even in terms of the UI, if you look at Harness and Argo CD and Flux, they are all very, very different.
Nati: [51:59] Yep. Totally agree. And in that regard, where do you see JFrog placed in that kind of spectrum? JFrog pipeline, I’m assuming,
Yoav: [52:09] Yeah. So it’s also something that we’re also a competitor in this market, both CI and CD. And also, with our Upswift now, we’re doing CD to edges and IoT devices. So it’s definitely an area that we invest a lot. We have our own philosophy and way that we think about it, that is actually modeled on what we’re seeing. And we can speak about the maturity in the market but it’s based about what we’re seeing, the majority of customers that really care about the quality of the software, because I think this is a major trend that’s going to shift the market in the next year, the whole software supply chain security. So what we’re seeing in the market and how it’s connected to CI/CD, is that it’s all related to the binary releases, to a collection of releases, it can be Docker images with some Helm charts and other microservices that are bundled together, the quality of this release, the immutability of it, and the whole what we call chain of custody of how this release came to life, whether it passed certain checks, in terms of the pipelines and so on. So this is where we’re pushing stuff.
[53:42] So in pipelines, for instance, there are features that maybe other products have them, I know that you can achieve them by integrating some open source tools and building the floor by yourself. But let’s say that you have a build that created a Docker image, and you push another tag by the same name with a different checksum, we will identify it in a downstream build and we will forbid this image from being deployed. And I think this is the biggest fear of everyone working with Docker, having this tag being replaced underneath them. And the way we achieve it is we have a blockchain of [inaudible 54:29] its transparency login [inaudible 54:31] that captures everything that happened in your pipeline, including this signature of the Docker image. So this is how we are able to know.
Nati: [54:41] So basically, you’re saying that the differentiator is really being able to control not just the process itself, but also the content, in this case, of the binaries within that process and scan it and provide some guarantees in terms of security around it. And that’s kind of an interesting thing that is looking agnostically–
Yoav: [55:02] Yeah. And let the customer do it, because, for everyone, it’s always a snowflake. It’s always a different pipeline, and different workflows for different companies, and you have just to provide the building blocks in order for them to do it. It’s like driving on the highway, you want to proactively avoid accidents, and you want to allow customers to drive at high speed and get the stuff to production as quickly as possible. And some customers will say, “Okay, I just want to be able to interrogate and see if something is suspicious. I want to know exactly how this release came to life.” Some of them will actually want to block or apply more strict policies around the binaries that they are promoting and pushing to production.
Nati: [55:55] Interesting. So that brings me to the next point, which I titled to be culture, but it’s actually I think, if you even look at the term DevOps, and I think both of us have been covering that market for a while, it was talking about the silos between dev and ops back in the years, and I think everyone who has been following it kind of, I think already understands it. But the question that I have is, how far are we from those silos? Because when I still look at what Seesaw is using, and what IT is using like ServiceNow and all the security solutions that Seesaw is using, the billing, the cost analysis. And on the other hand, DevOps, you still see a completely different set of tools and, if you like, even the ecosystem around it, and they’re still very not connected, I would say. They are still very much in silos. Still, even how many years we are already on in that kind of market, it’s still surprising me to see that we haven’t got to that point where it’s all part of the same thing. Now, there’s this shift towards [inaudible 57:17] called ShiftLeft, which kind of try to take all of those things back into one world, which is the DevOps, and try to say IT is now DevOps and Seesaw becomes DevOps and security becomes DevOps. And FinOps, which is the new thing become DevOps. So the consolidation is really trying to push everything to the left. And trying to get into that. So again, from what you see in the market, where are we on that trend?
Yoav: [57:49] So you touched on three main things. You spoke about DevOps, so it’s Dev and Ops, but you also mentioned the Seesaws and security guys of the world. What you just described is something that we see very clearly at JFrog. So the developers, they just want to code, want to create great stuff, want to work uninterrupted. The ops, and this is a result of being able to do everything as code, they don’t really trust the devs when it comes to going to production. This is, I think, one of the reasons why you’re sewing this server that– Actually there is a drawback in automation of pushing to production automatically. It became so easy, and I can even remember things that happened in our past, that a very simple mistake can consume a huge amount of compute, or otherwise break the production because the developer didn’t fully understand what he was doing when he was changing the configuration of the Helm chart or something like that. I’m not even speaking about the Kubernetes configs and things of that sort. So this is the lack of trust between the ops and developers. Security guys, it’s their job, they don’t ask anyone. So they will shift left, they will tell you– The example I’m using is airport security.
[59:47] So if you go to the gate, the guys at the airport security will tell you to take any liquids out and to make sure that you don’t have any materials that you’re not supposed to bring on the plane, but they will never trust you. Nobody will tell you, “Okay, you look like you’re a nice guy, don’t go through the detector or through the X-ray scanner.” So they have to know. And it’s their job. They have to scan, and they have to know everything. And this is where they come with the tools. Sometimes they consolidate, they work together. And this is if I have to identify one time, I think this is one of the strongest ones that Seesaws and DevOps are working much more closely together around the tooling that are integrating into the toolchain. But there’s always going to be because of this lack of trust, which is inherent. And ideally, we wouldn’t need it, but they’re always going to come with the tools that want to integrate with minimum cooperation with developers. I’m speaking about tools like all kind and ways that you don’t need anything. In a way also, Artifactory X-rays is a little bit like that, because you can just click a button and everything in your Artifactory gets scanned, you don’t need to get permission or the collaboration of developers for that. So this is where they come in, they view all the information and they don’t ask you with production, whether you’re a dev or an op. So it’s a high-tension triangle that we live in. I think it’s going to change. I think we’re going to see less and less of the traditional Seesaw and I think they will become more closer to DevOps. And, of course, there’s always going to be the IT kind of Seesaw.
Nati: [01:01:54] So if you look in retrospect, in The Phoenix Project, which I think, kind of was one of the inspirations for the DevOps industry for a long while, how far are we from that to where we are today, in terms of the culture?
Yoav: [01:02:14] I think we’re getting there but I think as technology advances, we didn’t have this all configuration as code. I don’t [inaudible 01:02:22] when The Phoenix Project was written, it was that on the radar like it is today. I don’t think so, right?
Nati: [01:02:34] No, no, I definitely wasn’t. Yeah, definitely, the tooling definitely advanced. And I think if I kind of look at that, in retrospect, and trying to see a trend, the shift left wasn’t there as well. And I think that realization that you mentioned about Seesaw, and other parts of the IT starting to basically adopt the DevOps mentality or the DevOps mindset, I would say, as part of the way to go, hasn’t been there. So, again, I’m thinking out loud here, as you’re talking, if I look at that as a trend, instead of trying to glue all of them together, in a sense, and then trying to see how we bring all of them together, they are all moving towards DevOps, they are all becoming part of DevOps. And DevOps becomes the dominant thing and then everything is starting to consolidate into that. And the things that we’re seeing, and I think you mentioned the security companies, as a very interesting trend, is all the new startups came in and kind of conquered very high adoption in such a short amount of time is the biggest indicator of proprietary takers in a very conservative area like security. And all of a sudden, you have new players that are getting into this and winning on Palo Alto and winning on all of those established players, mostly because they can’t take the outsider developer approach and the kind of low touch approach towards that rather than the Seesaw approach towards things, that it’s more high touch, more, I would say, conservative and less adaptive to changes and things of that time. And that is definitely an indication, a huge indication even, that this is still going to be the dominant trend towards consolidation. So we’re not there yet, yeah, there’s still silos and frictions, but if you look at what happens in security, that’s probably going to happen in the rest of the part of the IT and those who are not going to realize it in time are going to miss the market in that regard.
Yoav: [01:04:55] It’s very natural, Nati, because, with automation, it’s very easy also to penetrate your software in different points. I’m not sure if you follow the domain, JFrog, because of the video acquisition, and because we have X-ray, we are very much obsessed with this domain right now. So the sole software supply chain security, it can be an existential threat to a company. If somebody managed to get over your software, you can really be out of the market, it can be a game over for companies. So this is why there is big money in it. And this is why it’s so hot. I just came back from CubeCon two or three weeks ago, and software supply chain was the hottest subject of Kubecon. If I told somebody this, I don’t know, three, five years back, nobody would have thought it’s possible. It’s like the so uncool topic that people can deal with. And you see the whole open source movement with the Open SSF Foundation that is just about creating tools to verify your supply chain, and Google SLSA project that is all about your maturity level of what points in your supply chain you are actually protecting and validating in order not to be hacked. And a little bit like Kubernetes, it’s innovation coming from the giants because of the market forces that are forcing the giants to dictate standards to the whole market around that because of the risk.
Nati: [01:07:03] Yeah, that’s actually very interesting. I think that’s worth a topic of its own, and definitely, something that keeps me thinking even while we’re recording right now. So probably something to come back to. So that brings me to the kind of the future of DevOps and kind of opening it up to you, to your mic, and kind of run with your thoughts and dreams of where we’re going to see the market evolving towards 2022 and beyond. Definitely, you already kind of touched one area, which is also a favorite topic of mine, which is kind of talking about edge and distributed. I would say the entire distributed world is fascinating. And what we’re seeing is that while we’re seeing all this shift in technologies, we are also seeing a shift in workloads, that the workload itself doesn’t stand still, and it becomes more distributed, more complex. It’s very typical today to have an application spread across multiple zones, where a couple of years ago, it wasn’t that common. I mean, you would do that, but mostly for geo-redundancy. But today, for latency, you have to be distributed in many areas. And obviously, everyone knows today that your TV, your car, everything is connected, and there’s a software behind it, and it gets updated somehow. So it becomes part of the cloud, in a sense. And the cloud kind of opens its boundaries to your house and to your devices and to your home. And that realization is not there yet, even though it’s part of the reality already. When I look at the reality of where we live today, and how far it’s got adopted, and then I’m looking at the tooling, and all the discussion about CI/CD tooling, there’s a huge gap there. The tooling and these use cases that I just mentioned, doesn’t really match. How do you see this gap? What are the challenges there? How do you see that gap being addressed by the tooling vendors or the CI/CD market?
Yoav: [01:09:17] Yeah, so you’re absolutely right. I mean, what was even considered uncool to not be on the cloud and have some regional execution points is now becoming a reality because latency is the real thing, quality is a real thing. Just imagine going into a store and they tell you that they lost connection to Amazon or there is some issue with the connection to the cloud and you cannot complete a transaction. So this is one thing, or the regional edges. This is a very, very common use case. By the way, with COVD, it became a lot more popular. This curbside pickup that people got used to, it’s not going anywhere, because I think in general, people prefer less interaction when it comes to purchasing stuff. And maybe in general–
Nati: [01:10:18] Yeah, I definitely see it on my kids more than anything else. I mean, it’s amazing to see how the COVID generation evolved and adopted into that, even us as the older generation adopted to that very quickly. But it’s amazing. It’s interesting that you kind of made the connection between that and edge. Go ahead.
Yoav: [01:10:39] Yeah. I think at the end of the day, it also says that you have to have computed the edge and you also have to be able to provide this ongoing digital experience no matter where you are. People also expect the shortest latency, especially in very interactive applications. And even on a webpage, when you think about it, if you have a few hundreds of resources, instead of going into trying to optimize how resources are built and how they are being served, and sometimes the resource itself is dynamic, why not put the compute closer to where your consumer is? Today, it sounds to most people like it’s almost an anti-pattern. But why? If you can do it, if you can fully automate it, why not do it if you can deploy your application to hundreds of nodes? And this is, I think the cloud providers also realizing that and getting into edge computing and deploying, Even the Kubernetes stack [inaudible 01:11:51] on the edge some. Google started, I forgot the name of the project and–
Nati: [01:11:57] Outpost. The Outpost Project.
Yoav: [01:11:59] Yeah. And now, Amazon is doing the same.
Nati: [01:12:04] Sorry, Outpost is the Amazon one. It’s Anthos.
Yoav: [01:12:08] Anthos. Exactly, Anthos.
Nati: [01:12:09] Yes.
Yoav: [01:12:12] So this is one use case. The other use case is just, you want more speed, so you have this thing about gaming and stuff like that. So this is another one. And the other is connected devices. So you want your devices to be always online, always connected. So I think edge and IoT in general– It’s not just me, I mean, every analyst on the market is realizing that; I think it’s going to boom. You can also see the CDN providers going into this space of offering you local endpoints that provide– This is a completely different domain of solution. You see companies like all the CDN providers Cloudflare, and Akamai, and Zscaler, which is not a CDN provider but still providing you local endpoints to have security on and to mitigate your network traffic as close as they can to your local endpoints. So these are two main domains that have security on the endpoint and edges, which are going to evolve dramatically. This is also why we bought Upswift actually. One of the main reasons was that the DevOps loop normally stops there. And you have your CI/CD, everything is fully automated, and you have all those nice tools. And then when you need to deploy to those edges, you’re faced with– it’s not a black hole, but you have to move to another tool that is more often than not completely disconnected. And you have to work with the UI and bring in the software, upload it to this tool. And it’s very non-DevOps native. And for startups [inaudible 01:14:22]
Nati: [01:14:25] There’s a couple of good things that you mentioned that I think are very interesting. One of them is that when you think about edge, I kind of look at Netflix as an example. Look at what happens to media, right? We used to have local media players, and now all of a sudden, if you make the experience of serving media such that no matter where you are, you get the same service, you could win a global market, like Netflix. So it’s not just latency in the context of fast response. It’s latency in the user experience perspective, which latency can also provide the ability to have a global reach and a global service and kind of disrupt the entire market. So there is a direct business value attached to it, not just say, technical value. The other thing that I think you mentioned, and let’s take Zscaler, as an example for security companies. Now, before that, we used to have a firewall on-prem or even a firewall on the cloud as a virtual entity, but it was still owned by you, it would run under your own network in your cloud. But as you start to have these security clouds where [inaudible 01:15:38] was providing the service because no one has the ability to manage it anymore and it becomes all managed, all of a sudden, all your traffic needs to go through some other entity, while your internet now goes through this. And obviously, if the latency is high, your entire access to the network is going to be high, and everything would be compromised. And so as this, I would say, moves towards more global services versus local services, including securities, media, and I’m sure that it’s going to apply to others, you have to have this local presence and you have to kind of build this distributed network. But explain to me why still, people and I think you touched on it, why CI/CD haven’t evolved to deal with it, why people are still building all this continuous deployment in a custom way today and not thinking of using a tool for that?
Yoav: [01:16:40] It’s a good question. If I’m trying to analyze, I think the domain has always been deploying to devices and embedded, it’s not entirely new, the booming effect is new. But traditionally, you would write embedded software in C or things like that, and this domain is not enjoying the same degree of automation that other languages or other domains do. I’m generalizing. Some companies take it to a full automation. And part of it is because of that, and part of it is just because it’s new and solutions are not keeping up. So there are more legacy solutions that were out there before DevOps, and they were retrofitted to solve the problem. Normally, they fit enterprises. So if I’m a small startup, and I’m getting successful, even half successful, I will be facing scalability that if I’m not developing to the edge, if I’m just developing to the data center, maybe I will have one, two data centers in the worst case, if I’m developing to the edge all of a sudden, I have maybe 300,000 run times if I’m successful. How do I manage that? There are no tools to manage it. And to tie it up to traditional CI/CD and DevOps tools, it’s almost nonexistent today.
Nati: [01:18:33] And that’s also an opportunity, right? It’s a question of timing when the market will realize that. The reality is already there but the market didn’t register yet that it can be done generically. And that kind of opens up–
Yoav: [01:18:48] Security is accelerating a lot.
Nati: [01:18:50] Exactly.
Yoav: [01:18:50] Security accelerates a lot of the automation and the innovation in the market because all of a sudden you need to care. You cannot stop caring or just do things in an undirected way. If I have to know what’s running on my edge devices, I have to connect it to my CI/CD pipeline.
Nati: [01:19:08] Interesting. So first of all, Yoav, thank you very much for walking us through this entire journey. Maybe as a kind of a closing remarks, you could tell us– Again, I will open up the mic to your dreams, anything that we didn’t cover, things that you’re seeing in the market that you want to touch on. Go ahead.
Yoav: [01:19:33] Yeah, actually, I think we had a very broad conversation. It’s hard for me to think about something we haven’t spoken about. We spoke about security. We spoke about edges. Yeah, I think this is the most exciting stuff.
Nati: [01:19:50] That’s good. I think we already kind of gave our listeners a lot of foods to think about, and definitely hearing it from the source, it’s quite fascinating. I think there’s those who would listen carefully for things that you’ve said [who] will, I think, identify some interesting areas of kind of trends that could also be an opportunity in the market right now, but also gives us a good glance of JFrog, where it’s coming, where it’s going, which is always an interesting and fascinating journey by itself. For those who have been there, at least myself, who has been following it, it’s definitely a very interesting company to follow. And thank you very much, Yoav for–
Yoav: [01:20:36] If I–
Nati: [01:20:38] Yeah, sure. Go ahead.
Yoav: [01:20:39] Okay, so if I can use this opportunity as a shameless plug for JFrog, we are recruiting. If you want to work on exciting technologies, such as B2B distribution using gRPC and stuff like that, and the more advanced security and edge solutions, then reach out to joinjfrog.com. It’s been great speaking with you.
Nati: [01:21:05] Thank you very much, Yoav. It’s been a pleasure. Very interesting, as I expected. And we’re sure going to meet again, both physically and also virtually. So thank you very much.
Yoav: [01:21:16] Thanks, Nati.
Announcer: [01:21:16] This episode has been brought to you by Cloudify, the one platform you need to accelerate, migrate, and manage your multi-cloud environment for faster deployments, optimized costs, and total compliance. Head to cloudify.co to learn more.