Fred Simon - Jumping into DevOps

Sacha Labourey:This is DevOps Radio. Sacha Labourey, CEO at CloudBees with Fred Simon from JFrog.

Fred Simon: Hi.

Sacha: Hi, Fred.

Fred: Hi. Nice to be here.

Sacha: Nice to have you here. So, this is actually your first recording of DevOps Radio, right?

Fred: Yes.

Sacha: And good news, it's mine as well.

Fred: Cool.

Sacha: All right? So that's going to be interesting. So, actually we know each other, so I thought we should talk a bit about that first. Right?

Fred: Oh. That sounds like _____ _____.

Sacha: I have pictures. Exactly. So I've known you for a long, long time back in France, right?

Fred: Ninety-nine. Nineteen ninety-nine.

Sacha: Nineteen ninety-nine.

Fred: Yes.

Sacha: Yeah. We were twelve.

Fred: Yes, exactly.

Sacha: So you want to tell a bit the story?

Fred: Yeah, well, there was this strange couple. I don't know what kind of relationship. The one was called Mark. The other one was Sasha.

Sacha: Right, Mark Curry, right?

Fred: Yes, exactly. And they believed that software should be open and they were some kind of religious about it. They were evangelists in the world and so I said, "Oh, we actually used and tested and do all kinds of JBoss testing." We were testing J-boss against Web Logic at the time and all kinds of _____.

Sacha: So what did you do back then? Where were you working?

Fred: So, I funded my first company in '98 on the AGB, so AGB Technologies, so we used T3 and DA WebLogic. It was WebLogic, not DA at the time. So we were in this Java middleware space.

Sacha: Right, and what's interesting about you is like you love the sun. You love beaches. Right?

Fred: Yes.

Sacha: And so you were a partner of JBoss, an early partner of JBoss and you decided to leave France to go –

Fred: To Israel.

Sacha: Exactly. And why did you do that, because most people go there for religious reasons, but that was not at all your driving force. Right?

Fred: Not at all. There was two big reasons. So the first one is actually the technology. So the amount of technical people that are out there, the amount of innovation and adoption in Israel is just off the scale. I mean, it's about what we're seeing here in the city _____ and – but it's a lot more concentrated in Israel because it's a smaller country. And so we decided to open the branch of this first company in middle of 2000, end of '99, beginning of 2000. And so, we opened the branch and I started to go there and we needed to recruit a general manager for the company and we recruited a beautiful woman that became my wife.

Sacha: That's easy. Right? Yeah.

Fred: And so I did _____ back and forth to see you again, I think, and to talk to you also, your other JBoss partner, which is still your partner today at CloudBees.

Sacha: Yeah.

Fred: That still remember my wife also. We did some good stuff together with JBoss. Was a good time.

Sacha: So fast-forward and you create JFrog?

Fred: Yes, 1998.

Sacha: Another –

Fred: Two thousand and eight, sorry. Ten years –

Sacha: Some other links with CloudBees, right, we both have a strange animal in our name and so – and again, attracted by the sun and by the beaches, you decide to move to California.

Fred: Yes. Not attracted by the sun and the beaches, attracted by the customers.

Sacha: Oh right. Okay. Okay.

Fred: So most of the customers of JFrog are actually the higher – I mean the web – early player in the DevOps market. I mean, it's like you for CloudBees and Jenkins.

Sacha: Right.

Fred: It's kind of start with the people that are willing to take risks and willing to change the way they create software. So, most of them are here. So, you manage to stay in Switzerland where a lot of things happen. I mean, the amount of activity, the speed at which Switzerland is developing is just – so it's radio. You cannot see the sarcasm in my voice, but so Sasha managed to not move here. I don't know how you managed, but it's quite a good success because the DevOps revolution at the end of the day started here, whatever we can say. There is quite a bunch going on in Israel, but it's not – it's really not at the same scale, the _____ order of magnitude. So that's my main reason for being here.

Sacha: Okay, and is that official? Are you going to come back or it's not official or –

Fred: Yeah, yeah, no, it's official.

Sacha: So you're going to go back.

Fred: It's official, so it's been three years and a half at JFrog Inc. and so JFrog US here is growing rapidly, very, very rapidly and we are supporting our customers, supporting our growth, so as a chief architect of JFrog and as the products grow and the number of products grow rapidly, my presence in Israel is highly needed. So, I'm still a traveling animal. I need to take my plane to Israel tonight, but yes. I'm going to spend more time in Israel.

Sacha: So maybe for people who don't know specifically what JFrog is doing, can you give us a short version of what is JFrog?

Fred: I'm going to use what you told me one day.

Sacha: All right.

Fred: That – don't _____. No, no, it's a really good one. It's that one day you told me I'm really happy JFrog, they take care of all those dirty bytes so that I don't have to.

Sacha: All right.

Fred: That kind of defines what we do in the DevOps and the DevOps platform. Jenkins is the shining new UI where you put all your jobs and you see all the little wheels cranking and all the different pieces going on, but at the end of the day, there are dirty bytes behind the scene that need to move from Point A to Point B and go all the way to production and someone has to take care of those dirty bytes.

Sacha: Right.

Fred: We decided to take this dirty job. Nobody wanted it. It was really good for us because it's turned out to be a very, very critical piece of the platform. And so we grew with the DevOps wave and we grew on this wave.

Sacha: So you're a repository where we can store binaries of all types of applications, packages and so on. Right?

Fred: Exactly. So we started with like Jenkins, with the developer side of things by providing help for the developers. So Jenkins started as a continuous integration platform, really helping the developers offload their own work into other computer or someone else's machines, so for us, it was really to help the developer aggregate all the software packages that they are using to create their own software. It started with Maven, which was one of the most popular package managers for Java at the time, but today, we are the universal repository manager and so we managed .NET and the NuGet stack very early on and then _____ and _____ for the Linux guys and Ruby, Python –

Sacha: Yeah, so what's unique about your stuff is that very early on, you decided to be agnostic, essentially, and support all kinds of protocols, all kinds of formats so that you can really be their repository. Right?

Fred: Exactly, no developer left behind.

Sacha: Okay. All right.

Fred: So yeah, we don't want to be technology specific. Every kind of software that helps automation, so it needs to help automation. Okay? It fits –

Sacha: Yeah, so that's the point where I wanted to go, which is where do you put this repository into the big DevOps equation, right? We're talking about agility. We're talking about a number of things when we talk about DevOps, so a repository has a very specific role to play. Can you describe this a bit more?

Fred: Yeah. So like I said, the first need for a repository is to aggregate the third party libraries that you use for your own software. So, today, there is no software that is created out of nothing, so there is at least DOS library, the operating systems libraries or the JVM, basic JDK libraries and things like that. So, for the developer to aggregate those libraries already, they're a pain and so we are helping them. But in terms of the DevOps wave, it's what, also as an analogy, we are the conveyor belt of the DevOps flow.

Sacha: Right.

Fred: So, right from the beginning, there is this third party and then there is Jenkins that are manipulating from the source code and trying to create. But it needs to go from the first build to the integration build to the QA build to the test build and all the way to production. And basically, transporting those bytes as fast as possible, as reliably as possible, as securely as possible to make sure that no malicious software is getting on the conveyor belt all the way to production is basically what we are doing and what we are automating. And so, what's funny is that we know a lot of customers and when we talk to developers, a lot of times, the developers don't even know that we are here, we are part of their DevOp stack becaue we are transparent for them. It's just the library appears, the packages are distributed automatically and they don't actually see how it got transported from Point A to Point B. They just know that it's there. So, that's why, by the way, about DevOps, to go back to DevOps Express and the DevOps Express initiative, right from the beginning of JFrog, by deciding to be agnostic and to integrate with all this technology, everything about JFrog is about integration. There is no such thing as a conveyor belt that will decide, "No, I don't want to talk to this robot or I don't want to talk to this test automation or to this deployment tool or to this pipeline and CI pipeline environment." So we need to integrate with all these players and we need to – and so like Jenkins is an open source platform, which allow a lot, a lot of plugins and Artifactory and JFrog and JFrog in every integration is open source and the community around the open source integration is critical for us and that's why it's easy for us to be part of this DevOps _____.

Sacha: All right, and so, as you said, Artifactory is open source, right, so you're one more open source company that makes business with open source and that's funny because actually a lot of the companies in the DevOps space actually have this model too. IT's like infrastructure is owned by open source and a lot of companies will you know, a few years back, it was a couple of companies who were doing open source, but we see now this huge emergence of open source companies. Right?

Fred: Yes. So, I mean, by – and so it has two effects, the open source. It's simplified adoption for the customer and the developers. It promotes basically the bottom up approach. So, you don't talk to the manager or whatever. You just provide the tool that helps and the developer is just using it and it's making his job easier and after he talks to his manager to get the enterprise version. So it is the adoption. And on the other hand, it pushes openness. It's really, really pushed openness and I think that's the big, big difference, even inside big vendors, companies that have a suite of tools that they own A to Z and they own all those tools, integrating those tools together is actually more difficult for them than if a customer is just taking a bunch of open source toolings and trying to integrate them together. This openness and this ease of integration of open source tooling is actually breaking their – I mean, we still have a lot of customers that say, "Oh, I'm going to take the whole stack from this vendor A or Z and I'm going to have my life easier in terms of integration." And what we find out is that it's not true at all. I mean, you see it with Jenkins. We are actually – I know for a fact that we are actually the integration piece between two software of the same vendors and by being there, we are helping them, integrating their own two products. So this open API and this open source environment really, really helps. And so it breaks this customer point of view that if I take the whole stack from one single vendor, my life will be easier. It's not true at all and it's really pushing DevOps rapidly forward. And people are sharing also, so the other thing is that whenever there is an integration that is done, say it's an integration between two open source products and if you are a developer and you did it, you're kind of a – so it's a family radio show – you're kind of an a-hole if you don't put it back to the community and to, oh, I did this great integration between –

Sacha: And it has no real business value per se. Right?

Fred: Yes, exactly.

Sacha: There is benefit in having a high quality integration. Yeah.

Fred: Exactly. So –

Sacha: So you're probably visiting quite a few customers and how do you see the evolution of DevOps or more specifically is the adoption of DevOps within organization, where do you think that it's still early versus where it's mature? What can you say?

Fred: I will define it as scary.

Sacha: All right, that's a good start.

Fred: For most – I mean, if you didn't already adopt DevOps and if you don't already have a DevOps kind of thinking in your organization, you should be scared.

Sacha: Right.

Fred: I Mean –

Sacha: It's getting late.

Fred: Yes, exactly. You better get moving.

Sacha: So what do you think? You think it's that – I understand it's scary, but do you feel like a lot of companies are already on the DevOps bandwagon or do they just sing the song, but don't really do the dance?

Fred: Yeah, no, most – I mean, once there is one competent or – I mean, it's because of open source, it starts with one developer. He says, "Okay, so my friend is working in this company." He's working like that. It's open source. Everything is just – and people are talking. They are going to those conferences and they see, "Oh, this guy is working like that." I mean, the first experience of this was really in 2004, 2005 so we worked on a big, big project, two million lines of code. All the managers say, "No, there is no way you can make this software agile and release faster and things. You're talking nonsense. It's not possible." And we did immigration in a month and a half completely and so we had full continuous integration and test and all these kinds of things. And it was 500 developers working on this project and so we started with a group of 25 developers working on this DevOps for the same project, on the same code base and they were working DevOps like. It was not called DevOps at the time. It was called continuous integration and continuous delivery, and those 25 developers, they loved it and all the 475 other developers, they saw what they were doing. They said, "I'm not going back to work if I'm not going there. That's just not happening." And so it's viral inside a company. It's viral from company to company. It's a big, big tsunami wave. So –

Sacha: Right. So what we don't say enough, I think, when we talk about DevOps adoption, it always feels when you tell the story that, hey, we're going to automate stuff because isn't more efficient for the company, but what's not said enough, I suspect, is that actually developers love it because they don’t like to be monkeys and do manual, boring work. Right? So once they go there, they don’t want to do that grunt work anymore. Right?

Fred: Yeah. Well, it's like, you know, with the blinders for a long, long time, the developer was saying, "Yeah, that's my job. I need to copy this file from this server to this server and I need to run these scripts and I need to run this stuff and I need to test and I need to read the log and to know," and so they were manually doing a lot, a lot of things. And they said, "That's my job. I'm paid as a developer. That's my job." And suddenly, there is a guy on the side there just push a button, go to take a coffee and in one hundredth of the time that it takes, he has a better answer. And he said, you know, "I mean, you are a developer. You know how computer works.” When you saw that, “Wait. Maybe I'm doing something stupid." I mean, you don't want to be stupid.

Sacha: Right, nobody wants to be stupid. Yeah.

Fred: Exactly.

Sacha: One topic that is discussed a lot for a few years now, for a couple of years, is really the notion of containers. So what's your perception on containers?

Fred: It's always like that in technology and I think for Jenkins it was the same. We had Cruise Control before and we had all kinds of continuous integration. It was not invented by Kohsuke.

Sacha: Let's rewrite history. He invented everything.

Fred: Exactly. No, it's a great way of analogy. I really think Kohsuke did the container revolution that we are seeing for the runtime environment, for the continuous integration flow. He made it easy to do continuous integration and he made it very, very fast. So there is a point where something that you used to do, when it's taking one-hundredth of the time that you used to do it before, even if you don't really do anything. So it’s spawning a Docker container, it's milliseconds. Spawning a VM, it's minutes. This is the kind of order of magnitude. Creating a new job on Jenkins, it's seconds. Creating a new job on Cruise Control, it's an hour. You know what I mean? So this is the same kind of speed shift that the VM really, really changed. It's really changed profoundly the way you do things.

Sacha: Do you think that this change, containers, is just a matter of speed or it's also maybe the packaging? How do you see that?

Fred: To get this kind of order of magnitude of speed, you really have to change completely the way you do things. It's a paradigm shift to get to this amount. So it changed the way you write, the way you want to build your container. It changed the way you execute them, the way you manage them, the way you – so there is a bunch of really, really strong changes that sometimes, by the way, go backwards. One of the main issues at the beginning of containers was security. So we want backwards in terms of security. We went backwards in terms of distribution sometimes in terms of the data store for vSphere or stuff like that. So there is some stuff that we went backwards, but it didn't bother us. The amount of things that went forward with the order of magnitude really, really pushed the technology. So it's generate a brand new paradigm, like the Jenkins plugin. There were a lot of plugins and a lot of scripts and a lot of command line tools that we were all using before Jenkins to actually automate our builds and automate our distribution. That became Jenkins plugins. At the beginning, the Jenkins plugin compared to the equivalent command line tool you'd say, "Okay, I'm really going backwards," but it didn't bother. I mean it was a lot easier to still do it with –

Sacha: The pages were really compensating.

Fred: Yes. So the container technology, the big, big shift compared is that it touched the operation. So it's really, really touched the runtime. Everything we did – I mean you were at JBoss, so you know what runtime means and having your runtime tools and runtime vendor tools means in terms of support and pressure from customers and things like that. But for the DevOps community and for the DevOps environment, it started to bring the DevOps processes all the way to the actual runtime to the real runtime because to manipulate the same object, which is the container that you created, and you bring it all the way to the runtime. For us, we were already doing YUM repository, RPM repository and Debian repository all the way to the runtime, but the container really, really exploded this kind of adoption.

Sacha: So you see it now.

Fred: Yes.

Sacha: When you talk to customers, there is a request for that, right?/

Fred: Yes. So we are already the Docker registry of huge, huge, tens of thousands of servers going to Artifactory to request the images for their Docker images on multiple datacenter and across datacenters and things like that. Like I said, we came from the developer side of things. So it's the DevOps way of pushing what is easy to do in dev, in QA, in pre-prod, in tests, configuration tests. Why don't I do it all the way to production?

Sacha: I know JFrog is growing very nicely. Yet, in the Docker space you have a number of competitors doing registry.

Fred: Yes.

Sacha: So what do you think makes JFrog remain strong? You could argue despite being born before containers when – so it can be an advantage. So from a perception standpoint, it might seem as a disadvantage. So why do you think that?

Fred: It's still for many, many companies choosing your operation tools and your operation servers and operating system and middleware and things like that is actually not the same person as the one choosing their developer tools.

Sacha: Right.

Fred: But the DevOps revolution kind of changed this equation. Usually when companies say, "Oh, I need a DevOps," you end up with this guy in the middle that starts to talk to the developer what they need to make their job faster, and to the operation what they need to make their job more automated and easier. So we and you, we are talking to those guys, to those new guys, and they start to interact between those two. So when this guy exists, it makes our lives a little bit easier. When it does not, it's a pure technical fight to get inside; only one gets out.

Sacha: I see. And you happen to win from time to time.

Fred: Yeah. When the fight is fair, we win. When the fight is fair, when there is no golf parties involved, usually we win the fight.

Sacha: You don't play golf, huh?

Fred: No. I'm French. I agree with you, which is a strange evolution, but which is also the proof of the DevOps, which is a really, really strong proof of the DevOps revolution. I mean we know for a fact that Jenkins is automating deployment in production, in closed environments. I mean of software that cannot be – I mean it will not be long that Jenkins will automate the deployment of software on mouth.

Sacha: Right.

Fred: You know what I mean? No, I'm not joking. We're going to see this kind of stuff going on.

Sacha: Also, really it teaches a container. You have this big fight going on these days between orchestration layers, the Mesos of the world, Kubernetes, Swarm.

Fred: Yes.

Sacha: Any perception on that? What do you see for the _____ of the repository when talking to customer?

Fred: It's a really, really nice war to watch for us. They are all a very, very good partner and we do really good integration. We have a really good Mesos integration and DCOS integration, which is actually quite popular and adopted by customers. We use Kubernetes and we have a very good Kubernetes. And Swarm is used by a lot of our customers against Artifactory on a lot of our environment. So this is a pure ops side kind of a fight, and I have to say that – so Docker with Swarm is _____ with DCOS. The fight is going to be now at the dev side. If you can orchestrate on your developer laptop, if you can run the same kind of orchestration on your own laptop to test how it's going to be an actual production when the orchestration is going to run, because there is also Cloud Foundry for example. So Pivotal Cloud Foundry is also in the – we have a very good integration over there also with all the orchestration. One of the main issues with Pivotal Cloud Foundry is that it was really easy to push to a Pivotal Cloud Foundry deployment and to do an automated deployment but to have the developer playground, the developer playground is something that they just did and they just started. They saw that it was actually missing.

Sacha: I see.

Fred: So it's basically the opposite fight than what we did. Instead of devs to ops, it's going to be the ops trying to convince the dev, "Here is my easy orchestration startup on my developer machine where you can have fun."

Sacha: Right.

Fred: By the way, Vagrant. Vagrant really, really killed this, really, really nailed it and really made work very, very good for that, to have the same stuff on your developer machine very easily and have almost the same environment in production and be sure that it works together.

Sacha: Right. It's interesting. What you're saying is that even though all of the attention seems to be on how to scale to the bigger cluster size, all of those guys tend to show that they have big deployments. They can scale to a gazillion clusters and whatever. You're saying what matters is how small you can be.

Fred: Yes.

Sacha: Right?

Fred: Yes, and it proves that you do efficient coding. If you always manage to – by the way, with Jenkins it's the same, the Jenkins that can run on the local machine and the _____ master with the 20 slaves automated and 20 huge N4 10x _____. This is what we want for all our slaves, with all the Docker containers running for Jenkins. So you can run from small to big, and this is the tool for me because you know that it can _____ the wait, so the same. So Kubernetes is doing quite a good job there. It proves that you know how to do the smaller STPI and the big environment. For example, Chef, they did Chef Solo right from the beginning. Puppet, also they tried to do some other stuff, Ansible of course with all their scripts. So all the DevOps tools – so for me, this is also one of the criteria of the DevOps tools. If you go to the DevOps tools and it's telling you right from the beginning you need 20 virtual machines and 70 gigs of RAM to do the smallest deployment of my DevOps tools, your barrier for adoption is very, very high.

Sacha: All right. Now let's switch gears to Fred' the consultant. Remember, you were a consultant.

Fred: Yes.

Sacha: Not long ago, like a decade ago.

Fred: Yes. I used to go to companies and tell them how to do things and how they should write their software, and make sure to leave before they actually do what I told them to do.

Sacha: Right. So what does Fred the consultant advise a company to do? Let's say I just joined a company. I'm the CIO, and I realize that my company is stuck in the past. Nothing is moving. There is no velocity, development and so on. Where do you start to make change happen? What would be your advice to that guy?

Fred: What we saw actually work is not to put any technical constraints, but just to put the delivery constraints. At the end of the year, I want you to release every week. I want you to have a stable new release of the software we used to do yearly every week.

Sacha: So just measures the outputs.

Fred: Yes. Some CIOs are even more – I mean they see that Netflix is doing 6,000 releases per day. So Bintray we are doing four releases per day. So everybody is doing daily releases. So you can put these constraints on your team or a new team or isolate the team and say, "Forget everything that you did before. I know that the same code base and the same piece of code and the same software, and I saw it out there, can be released, tested, delivered securely and with all the things every day. I want you to deliver that to me in six months, one year, whatever you want to put the pressure on the thing.” And they will start to look around. They will start to go to conferences like Jenkins World. They will start to look at the – the techies will start to analyze how the others are doing it. And by putting the pressure, it's really let them loose on not doing the same thing than what was done before. It never really worked to say, "Okay. Let's install a Jenkins," and suddenly you're _____. Jenkins is not there just to be installed, so that people can look at the beautiful UI or the butler. The end goal is really to release the software faster and do these jobs. So there will be a lot of bottleneck, a lot of people that say, "No, this is not the way we used to do things," but if the top management says, "Is this process or this tool really helping you in your process?" So there are some very old version controlled systems, for example, that are very, very problematic in an agile release and stuff. So you can go and say, "There is no way we can do what you just asked me if we keep this version control tool." So yeah, let’s remove it and put in another one. So things like that in the process that are on the _____. From the CIO point of view, after the main issue is that as a global company to have a release every week is also very, very scary for the marketing guys, for the product management guy, even for the sales guy. Technically speaking, you can release every week and you will release every week to the product manager, and so he will see what's going on in the feature, and you will cut a release every quarter to your final customer because you don't want to freak them out. But we know for a fact that – I mean you are doing it with Jenkins and we are doing it with our Artifactory. We have more than 15 actual releases to the end customer, but we do more than weekly releases on our cloud. So you start to build this kind of trust relationship between your customer and the vendor and the customer, and you start to have this flow of software, this continuous DevOps flow of software across the company.

Sacha: That's something that sometimes is not fully understood, which is a lot of organizations seems to initiate DevOps as a way to increase velocity within the engineering organization, but as long as you don't benefit from that, from a business standpoint it's kind of a local optimization. You're just spinning faster the wheel, but at the end of the day the output is the same; the benefits are the same and so on. Right?

Fred: Yeah.

Sacha: So it's really how do we involve the business to make use of that?

Fred: Totally. What's delegated to a machine, the work that can be automated of a human being, there is no way back. Once you have a calculator and once you have – you cannot ask someone to redo it. So once you did this kind of delegation, there is no way back on the automation and delegation. Then the product manager will start to see almost finished product on a weekly basis, which the customers are really, really waiting for. So he's going to say, "It's here. I see it. I want to give it to my customers. My customers are waiting for it." So usually it starts to put pressure on the business side and on the sell side, "I need to find a way to provide this patch or this new version or this technology to my customers. It will make them happy." So usually the changes can come this way. Going cloud, for example, for a lot of companies, going SaaS –

Sacha: That was where I was going.

Fred: For Jenkins, for cloud-based, it's both the same, the DEV@cloud. When you start to go DEV@cloud, you need to have really, really strong processes.

Sacha: I feel like we don't talk enough about that. We talk about those unique _____ that really is a lot of things every day. But for the most, if not all of them, actually they are SaaS companies. So it's easier for them to deploy a tiny bit, because the cost to the customer does not exist. It's on you to be automated while if you are releasing software that needs to be installed, there is risk involved for the customer, so there needs to be a compelling reason to do it. So the reason is that's the whole difference between those two models.

Fred: Yeah.

Sacha: Thanks a lot, Fred. It was a really, really nice talk. Next time we'll be on the beach again.

Fred: Exactly.

Andre Pino: Like what you've heard today? Don't miss out on our next episode. Subscribe to DevOps Radio on iTunes or visit our website at CloudBees.com. For more updates on DevOps Radio and industry buzz, follow CloudBees on Twitter, Facebook and LinkedIn.