>> From the Cube studios in Palo, Alto and Boston, connecting with thought leaders all around the world, this is a Cube conversation. >> Welcome to this Cube conversation. I'm Paul Gillin, Enterprise Editor at SiliconAngle. We've been talking a lot about cloud native on SiliconAngle lately, and my guest is someone who had a seminal role in defining the the principal architecture, some of the foundational technologies for cloud native applications. Ben Golub is the CEO of Storj, a company that has a really interesting new approach to storage management that we'll talk about in just a bit. Ben is probably best known to many people as the former CEO of Docker, which pioneered software containers and was one of the fastest growing companies in Silicon Valley, he's great. Ben, thanks for joining us, feel appreciated you being here today. >> Thank you, it's great to be here. >> So, let's get into the question of cloud native is a theme that we're focusing on right now. How important is it for organizations you believe that are moving to the cloud to choose to re architect around cloud native principles? >> Well, I think it's, I mean, two points. First of all, I think that the cloud native is sort of a spectrum. And for many people, there is a point along the spectrum that makes sense. At the far end of the spectrum is applications that are deployed on a massive scale. They're components to thousands of microservices, heavily orchestrated with things like Kubernetes, scaling up scaling down, and for many organizations, they don't need to go all the way there to get real benefits. And maybe the related thing is that I think, for organizations, there's absolutely, for most organizations, there's value in moving along that spectrum, but they should be thoughtful about where it is that they're going, and why they're going there. >> Either or thing and they applications can live along the spectrum. you submitted some comments recently for an article we did on this topic and among them you said that some applications may make sense being containerized or Dockerized but not being orchestrator with Kubernetes. Can you give an example of something that meets that criteria? >> Sure, well, I can I think that almost all applications can benefit from running on more cloud like infrastructure. There's certainly value in having infrastructure that that scales up, or that scales out there, where people are able to sort of dynamically use resources and not have it have to rely on big iron. But in terms of the applications themselves traditional applications can run well in cloud environments provided that some steps are taken. And often for many organizations, the first step with a traditional application is simply to containerize your Docker engine. That gives a lot of benefits including, ease of migration, greater ease of adopting things like CICD, and you don't necessarily have to take all of your traditional applications, break them into lots of micro services, start orchestrating them with Kubernetes on day one, for some reasons, case may never make sense because they're not going to be run at massive scale. >> Many people assume that containers and cloud native architecture are inextricably linked. Is that your opinion? >> Well, so I think that cloudy infrastructure tends to benefit from from containerization. But really, it's more of an application question. If you are breaking your application or you're writing applications that are composed of lots of different services, almost inevitably, you want to have those services in containers so that they have clean interfaces between them. And so, that you can do the things people want to do with cloud native, which is, make changes to your microservice A with a small team and do so rapidly without unintentionally screwing up microservice, B, C, D, et cetera. And Dockers in a containerization, among other things, provides that nice clean interface. >> All right, how have you seen I mean, since you left Docker three years ago, how have you seen the container technology evolve? What do you think are some of the most important evolutions we've seen in container technology since then? >> Yeah, so I think, what has been really important for us to see that the community continues to grow. So, once the Docker community continues to grow, there are now lots of other communities around it the cloud native computing Foundation, Kubernetes. And I think what you're seeing is really the maturing of this technology. So that applications can be written in a cloud native way much more more easily. The barriers to making an application cloud native really come down, but also the potential for running applications and really massive scale have have have increased and there are certainly a number of interesting things that have happened in the storage space in terms of persistent volumes. things that have happened in terms of service technology service measures, like STO these are all really great examples of how the community is filling in around containers. >> We've heard a lot about the benefits of portability that come from using containers. But being portable can involve some trade offs, because you have to give up some of the native functionality of branded cloud platforms. Do you think the goal of multi cloud is overblown? >> I think there is real value in being multi cloud. And I think that while you know, the larger stock traders have provided great services, it is in their names, of course, we're trying to get have all of the workloads run within their four walls. And I think for most organizations, locking is a bad idea, regardless, right? We're in a distributed world, most people want to be able to run their applications at scale in a distributed way and they want to be able to take advantage of spare cycles and the most efficient way and concise way of doing so. And so, having locking, I think is a bad idea. And for most organizations, the investment to become portable, while not trivial pays off in the long run. >> How about of the cultural issues is something that you also mentioned in the comments you contributed to us earlier, we hear often that the biggest impediments are not technical or even skills but actually changing the culture to adapt to a cloud native way of building applications. How should organizations prepare for that shift? >> Well, I mean, I think they should recognize what those differences are going to be. And if you're writing, the traditional method was you write a large monolithic application, because it's so big and complicated. Generally speaking, people follow sort of a waterfall procedure. They have large teams working on it, and you update the application once or twice a year. The cloud native approach is let's write applications that are composed of lots of smaller services produced by smaller teams that move very rapidly. And a lot of the testing and the deployment happens in a very automated way. And the cultural barriers are pretty large. I think most people are happy at the end of the journey. But there's a period in between where things are difficult that you're, you're breaking glass as it were. So, I think for a lot of large organizations, the approach that often works best is to have a few sort of isolated, Greenfield application approaches, where you have a small team that is sort of proving out and becoming good ambassadors for doing things in cloud native way. But there's also a an evolutionary way to bring the older applications along there for many organizations is really helpful. That doesn't have any running head on it. Other cultural issues with the traditional application. >> So, break them up into teams and have different teams at different stages of evolution. >> Right, and so, I think you can have a small advanced team that is working on new applications at Greenfield, cloud native way. But then the transition path for the teams that are working on the older application, traditional applications that were not initially architected in a cloud native way is to break them down in an evolutionary way, first dockerize, containerize, the traditional applications, then maybe break them down from a monolith into, say, three tiers, each of those tiers being containerized. And then potentially pull out one of those services if it's a common service across all the applications and start using that and the process. I think we find organizations get the sort of muscle memory around doing things in a more continuous way in a more agile way. And they get experienced with tools like CICD, Docker, Kubernetes te cetera in a more organic way. >> Do you find that people who come from the traditional waterfall development background eventually can't make that shift? >> I think some can, there are pluses and minuses. But I think that most organizations find that as they get more agile things that used to be very difficult become a lot easier, right? So, rather than having big masses of code that needs to be rewritten and changed, you change something in one area and it breaks things and unexpected way in another area. Right, then you're trying to get large teams of people to sort of agree on things which we know is not the way the world works. When you get to smaller teams working on more atomic pieces of the code with clean interfaces between them, and can iterate more rapidly without having unintended consequences. For most organizations that not only makes them faster, but it gives higher quote, quality, safer et cetera. >> Another topic we hear a lot about today is application modernization, what does that mean to you? >> So, I think for me application modernization means that you're re architect, you're making the application itself more cloud like, which doesn't mean that you made it full scale cloud native on day one, right? But that you, for example, taking a traditional application and Docker rising, or containerizing it, just containers in the monolith actually gives some real advantages. And that then sets people off to say, let's not only take the advantages that we now have in terms of portability, but let's start exploring the advantages that we can get from having more frequent deployments or more automated testing. And so, really it's modernizing the application but also modernizing the environment around it and in the culture for how you build and deploy applications. >> Let's turn to your current venture Storj. You've been CEO there for about two and a half years now. Very interesting decentralized approach to storj using blockchain. Just tell us quickly how you're re imagining Storj? >> Sure, sure, well I mean for, for of course, most of computing history storage was done, like people buying their own disk drives and then storing data on it. And if they failed or got lost as a problem, or if they had to buy too much, I was expensive. Then we move to centralized clouds where you were storing data on drives that one organization was running, we started taking it a step further, where we built a storage service. But we don't run your own any disk drives. We're sort of like ABNB, for restaurants, right? But we've gotten 10s of thousand people around the globe. Generally, data centers who have spare capacity enabled them to rent out that spare capacity. And we're offering our customers a way to do storage that is much safer, much more private, faster and far less expensive, than with the traditional cloud. >> Certainly intuitively, it would be less expensive. How is it faster? Well, it's faster for a lot of the same reason the the internet, if you will is faster than the traditional approach was landlines, right? We were able to take advantage of parallelism, right? So, we break every file up into a large number of pieces, which are then distributed across the network. And so, first of all, we don't get slowed down. If some of the drives are slow, or they happen to be in an area where there's network congestion. It doesn't slow down. We also end up having, generally speaking, have our data much closer to the edge. So, if you're in Kenya, and you're viewing a video that sort of serve from our network, chances are the data is getting served from graduate cluster view rather than driving or in Kansas. >> It sounds like there are some sort of cloud native aspects to what you're doing. In fact, are you adopting some cloud native principle on-- >> Well, so kind of we put our service in the cloud native way. But it really takes the cloud native notion of distribution and takes it even a step further, which is that things are highly decentralized. And so, we built our service in a very particular way because we are not directly controlling the disk drives, so, we basically use algorithms and math to make sure that we're resilient against any failure. and things are done in a highly automated and scalable way so that there's really no single points of failure. And there's infinite scalability, which is which is really the goal of cloud native, but we take it a step further. >> And blockchain is what knits us all together, right? Well, it tracks the location of all the all the data. >> I don't know, cause actually none of us 'cause we use blockchain for certain purposes, namely, compensating the people who are running the drives. So, they do cryptographic proofs to prove that the data they have, they shouldn't have to get compensated for running it. But then we've tried to use a large range of different kinds of peer to peer technologies. And even frankly, some very cool very old technology like racial coding which is on the on the Voyager spacecraft to make sure that it all fits together in a way that's safe, secure, private and super fast. >> All right, there other applications of this technology have developed be on Storj? >> Well, so we are working on decentralized storage. Other people are out there working on decentralized computing, where the application can be written and run on. Sorry, can be run on using CPUs that are all around the globe, we happen to think storage is probably the most important problem to solve first. Because, death, taxes and data are things that never go away. And the world's creating more and more every year, it would actually, the data created this year would have filled a stack of CD ROMs to orbit of Mars and back. It's going to grow from there. >> I love those analogies. >> Yeah, some of that's cat videos, but a lot of it is really super critical data on finding, therapeutics for COVID are the cure for cancer or new forms of energy. And so, find a way to use to give people the ability to store their data in a highly secure, highly efficient and very cost effective way we think is really important. >> And what should we be looking for from Storj for the next year, >> Let's say Storj is in production. We are adding end users. We're starting to see some larger users, which is a very 10 for us, today, we're used primarily for sort of second tier storage, but we expect to be moving into sort of primary storage and even CDN down the road. It turns out that what we built is a really great way to distribute large files, including video and photos and x-rays and satellite images and things like that. >> Well, Ben, thanks for joining us today. I know you're a Cube alum you've been many times on the Cube. I think this is the first time we've done it virtually though. >> I know, I do miss being in the same room as you and you're colleagues but this is a very nice thing too. >> So, do we believe me? Ben Golub, CEO of Storj. Thanks for taking time for being with us today. This has been a Cube conversation. I'm Paul Gillin. Thank you for joining us, be well. (bright upbeat music)