Solomon Hykes is an icon (creator of Docker, Docker Swarm, and an innovative new project called Dagger) He helped create software that revolutionized how people ship software and gave the power of containers to the masses. In this our 75th episode... Solomon Hykes gives us HIS story and answers all that i asked him with brilliance, humility, and grace. I could not have asked for a better guest than him as he delivered and then some!
Timeline/Topic
00:00 - Openers (Thank you Sponsors!)
00:13 - Episode 75 and Introduction to Solomon Hykes
00:54 - Solomon's Journey
14:30 - POP's Docker Story... Getting Turned down by Docker....
15:41 - Docker Swarm origins
18:13 - Copying and the Narrative of Innovative Technology
21:51 - Rumors Part 1
27:30 - Rumors Part 2
29:52 - Contributions to Cloud Native and a sense of pride
31:39 - Solomon takes a hiatus
35:01 - Dagger- What is it and what problem's does it solve?
39:47 - What is Cue and its benefit
43:30 - What work is Solomon most proud of?
45:03 - Thank you Solomon from POP and the Community.
Please leave a comment if you enjoyed the episode! it helps the show!
Brought to you by:
***Teleport***
Teleport allows engineers and security professionals to unify access for SSH servers, Kubernetes clusters, web applications, and databases across all environments. You can download Teleport at https://goteleport.com
***Sysdig***
Run Confidently with Secure DevOps Security for containers, Kubernetes, and cloud
***COCKROACH LABS***
Discover @CockroachDB the most highly evolved distributed SQL database on the planet.
Kubernetes-native and built from the ground up to help companies of all sizes including Bose,
Comcast, and Equifax scale fast, survive anything, and thrive everywhere.
Sign up for a free 30-day trial and get a free t-shirt at https://cockroachlabs.com/popcast
***Styra***
Learn how to operationalize Open Policy Agent at scale with Styra: https://hubs.ly/H0Pnkm20
***CIVO***
Civo is an alternative to the big hyperscale cloud providers.
They've launched world's first managed Kubernetes service powered by K3s.
With sub 90 second cluster launch times, a simplified Kubernetes experience,
and predictable billing, Civo is on a mission to create a better developer experience.
Get $250 free credit to get started. Sign up today at https://civo.com/popcast
Episode Links
https://dagger.io/ (Get involved with Dagger)
https://cuelang.org/ Configure Unify Execute
https://www.docker.com/blog/au-revoir/ (Solomon's Docker Goodbye Blog Post)
POPCAST SHOW DETAILS
YouTube: https://bit.ly/3xgmmCj
Audio Podcast (Apple, Spotify, and others): http://bit.ly/35MXfte
Follow us on (Twitter): https://twitter.com/PopcastPop
Follow us on (Linkedin): https://www.linkedin.com/company/the-popcast-with-danpop
- [Announcer] This episode of "The Popcast" is brought to you by these sponsors.
- Hello, everyone, and welcome to "The Popcast." Episode 75. Listened, I called in the bigs, this is the big guns here. I have talked about my respect for this man for many episodes. I actually have tagged him and sent him, "Hey, I said this because I feel so strongly." He's a dream guest. He's a prodigal son. He's the creator of Docker. This is Solomon Hykes.
- Hello . Quite an introduction. Thanks for having me.
- Thank you for being on the show. And we're gonna talk about all the things we're doing now with Dagger and all the great things. I'm really excited for it. I really want to start as I start with any of The Popcast with, let's talk about your journey. I mean, you weren't doing containers out of the damn womb, at least I don't think so, but let's talk about early, where you are from. Okay, so talk to me about your humble beginnings.
- Sure. Well, I grew up in France. I was born in the U.S., but grew up in France. And then, you know, from an early age I wanted to be a computer person. I didn't know really how it worked, but I liked computers. And then eventually I found my way to a school called Epitech, which is a programming school in France, in Paris. And, you know, I just sort of loved it, and it was atypical because, you know, you started it right from high school. So you could jump right in, it was very practice oriented, which is unusual, which was unusual at least at the time in France. You know, usually if you want to be an engineer in France, you have to do lots of theory, and then eventually you get to code, but that school was different. They just let you code right away. And you learned by doing which I really loved. And you know, that led to a series of jobs, first in France, then in California. And then eventually I made some observations at my different jobs, pretty junior jobs really, that led me to kind of on a, not really knowing what it was doing, led me to leave my job and then just move back to France, moved back at my mom's, and start a company out of a basement. You know, we rarely have garages in Paris. So it's usually the basement . And that became that dotCloud, and later we became Docker.
- No, no, no, no. This is too fast.
- That part is well documented.
- I want to talk about this, wait. So you're like, no, no, no. This, we're getting deep. We're in the basement in France.
- In the basement, right.
- We have our baguette, we have our nice, I don't know, you know, whatever orange, I don't know what you all drink in France, right? And you're thinking to yourself, "I need to do something that is going to revolutionize how people deploy, consume, you know, from a speed perspective, software." That's not, that's not glance, and then we did dotCloud, no, no, no. I want to understand that problem. You were like, "I'm in the basement, and I'm like I want to solve this problem." Let's talk about that.
- Yeah, so it would evolve over time, but there was sort of, you know, the kernel of the idea was there for a long time. It just was emerging in a very unexperienced mind. So I had to sort of, my experience had to catch up to the intuition in a way, but my initial interest, which became an obsession, was with the idea that you could have lots of servers, and they would somehow work together as one to run your code, you know? And at the time that was, it was, you know, or we're talking, you know, 2006, 2007, 2008. So it was the term cloud was around, and it was up and coming, but it was still kind of very, very early adopter, was still a hipster thing, you know? The only people that were really doing clusters of computers that worked together as one were either the HPC people, you know, high-performance computing, which was a very narrow field. And, you know, some, some tech companies like Google and Amazon already had some stuff under, you know, internally, but even that was very bleeding edge, you know? It wasn't just like, "Oh, yeah, they do cloud. Of course everyone does cloud." So that concept was very exciting. And I started out doing a bunch of CIS admin work in my different jobs, and, you know, you end up writing scripts and you end up automating the provisioning of machines and the configuring of machines, and then the deployment of code on those machines. And, you know, what I realized at my different jobs is that everyone basically does it all over again from scratch and everyone has their own secret thing. You know, some people do with Pearl or Python scripts, or, you know? One job I was at, it was always, it was custom made Debian packages. They were these reusable building blocks for deploying things, and I thought that was really cool. So this concept kind of emerged over time. So the initial focus was configuration management, you know? Puppet was around, it was pretty new. I don't know how new it was, but it was around. Chef was not around yet. Salt, I think, was not around yet. There was this thing called, and then there were a lot of tools that are not around anymore. There was one called Isconf, and there was this guy who wrote Isconf, and I forget the names. You know, I'm not a historian .
- You're more of a get ya done type of guy. Right? Just get it done, right?
- Get things done, yeah, yeah, yeah. One thing I like is I like to discover bits of research, and past research, current research, and even though I'm not the, you know, I'm not a specialist or expert, you know, I like to dive in just enough to understand what's different about it, and then look for ways to apply it that maybe others haven't seen yet. So I like to bridge the gap between, you know, new research, new components, and problems that a lot of people have, you know?
- I want to talk to you about that. And I want to talk to you a little bit more deeply about that, because look, I came from the same CIS admin background, right? And it was like at the time, we had this in memory database, work for an investment software company, right? And it was like, "Okay, I heard about things like Solaris Zones at the time. And then you heard about LXD," right? And what I saw again, that whole, you know, the early stages of dotCloud Docker was like that ease of use. And I've said this in countless interviews that I've sent you snippets of it, and I was happy to have you on, but basically like what you did was bring that technology into a way that somebody can easily adopt it. Because it was, it's painful. Those technical LXD was hard at the time, you know? You know, containers from that perspective, that, a concept. So you know, these are the things that, again, is you seeing these papers, like you saw like, "Let me container that for you," or some of the things that Amazon was doing, all of those things, and it's like, look, there would be no modern deployment mechanisms that we have now, you know, what they doing with Container Day, what's going on with Docker and all those things, had you not taken that step, had you not done that.
- Yeah, I think that's true.
- You're humble. I just want to kind of that impact that you've done for all of us. It's like the respect factor that I have for you is beyond reproach. You were on the Rushmore of cloud native.
- Well, thank you. You know, I appreciate it. You know, it's kind of abstract because the day-to-day work was not that different, but between the moment where no one cared and the moment where a lot of people thought it was awesome. You know, it definitely felt like a continuum. And also it's just hard to, I mean, it's kind of a trite thing to say, but it's hard to emphasize just how much teamwork went into it. And it took so long. I started out like obsessing over this idea in 2006, and, you know, Docker launched in 2013 and took off over the next five years, you know? So that's 10 years, well, more than 10 years now. Yeah. Anyway, I don't want to count, that scares me, but my point is a lot of people have come and gone, and some people have made an individual impact along the way that is now three, four, five generations of code and products removed, and no one, you know, even the Docker expert historians, I've never heard their names, you know? And it's impossible to list them all. So it's just always, that comes to mind whenever the emphasis is put on me, because, you know? Ideally I would have a long list and just kind of recite the whole list, but I can't. So anyway.
- We'll put it on the liner notes of the episodes if you send them to me.
- The credits. Yeah. But, you know, yeah, just to give a snapshot, 'cause you talked about, you know, how much things have changed, when we started working on this, LXD did not exist. It was, yeah, it did not exist. VServer existed. So there was a patch for the Linux kernel. Well, first of all, Linux did not have containers. Solaris, of course, had Zones, as every Solaris hardcore fan loves to remind the whole world that they had it first. FreeBSD, I think, had jails, and Linux had the VServer patches, the OpenVZ patches, which were the best available. And then separately from that, there was also the Zen patches because at the time there was no virtualization either. You know? So either you ran Linux in VM-ware or if you wanted to pair virtualize, which was a thing, there was no hardware support either for virtualization that I know of on x86, you had to patch through Zen. So one thing, the thing that we did, that the first thing that we did that blew our own minds and it blew nobody else's minds because no one cared what we were doing, was to combine the Zen patches and the OpenVZ patches. We started that on VServer, and then we just switched to OpenVZ 'cause it was better. And basically no one did that because what was the point? You know, you had, you had this benchmark of different ways to virtualize. You know, you attempt virtual servers, you could use this new VM thing with Zen, or you could use the container, the, you know, whatever it was called. I don't know what the container was called, but you could use OpenVZ, why the hell would you use both? You know? And we wanted to use both because we thought they could each play a different role in the stack, you know? That one would be infrastructure and the other would be an application, the unit of application deployment. But that was just sort of, that was of course what we got right very, very early, and probably because we had so little experience. We had just enough experience to kind of get excited about that idea, but not enough experience to realize that it was obviously flawed and it would never work. And, you know, we got lucky, and our ignorance allowed us to overcome that bias. Now it seems obvious, but I have an email in 2009, I think. So we had our little startup, we're still in France, and we're trying to do this open source container thing called dotCloud, which never worked. Then we pivoted to a PaaS, like a competitor later, and then pivoted that back to an open source container thing, you know? So we went full circle, but at the time 2009, we were trying to, you know, succeed as the makers of this open source container thing called dotCloud. And we emailed Jeff Barr, was an evangelist at AWS. He's gone up the ranks. I mean, I think maybe the chief evangelist now. I mean, I see his name a lot is. He's a big deal at AWS. And so I emailed him and said, "Hey, could we have early access to the custom kernels on EC2? 'Cause there's this kernel, we really would love to run on EC2." Wow, sorry about that.
- That's all right. I guess there's a storm coming .
- It's okay.
- Wow, we're having some atmosphere here.
- So go ahead, Jeff Barr.
- It's going to happen every time I say something important. Maybe Jeff Barr is angry at me. No, it's a good story. So I emailed him and said that I would like early access to custom kernels. Like can I load a custom kernel on EC2 because at the time you could choose between maybe two kernels, I don't remember, and we just tried so hard to get a container-enabled kernel on EC2 so we could try doing containers on top of this new VM thing called EC2, and, you know, he passed it onto the team, and I don't know what happened. It never happened. I mean, we were nobodies, right? So anyway, we, that was just very early, and there was just a lot of stuff to build to get to the point where Docker was possible, starting with getting containers in the kernel. Because as long as you need to patch your kernel, who's going to adopt your thing? Nobody, you know? That was the biggest obstacle I think.
- And then, you know, there's the concept of obviously C groups and all of that fun stuff. And so like, you all like was able to tap into that kind of like that space. And I'll say this, like early on, and I told you the story on the thing, but I was literally the first Docker-certified sales professional in the world, one of the top three or whatever, right? And I was explaining to customers what containers were versus VMs was literally like the common thing. I'm sure you had that like down. There was a talk track, right? And now it's so commonplace, right? And you know, so like containers can do X, Y, and Z. And by the way, let me tell you this story, you all. This is a little sidebar. So I actually interviewed at Docker, okay? And this man changed my life.
- Not with me.
- Not with you. Yeah, maybe I would have had better. So I got turned down from Docker, right? And so I made this my life's ambition to prove them wrong. And now I just have a little show in my basement. So I haven't done much, really have to do that. So anyway, I'd always had much respect for Docker from that perspective. I want to ask you.
- I can relate to that. I can relate to that. Proving the world wrong is this is a very strong motivator. It's a big motivator for me too. So you picked the right fuel.
- And so I want to ask you about this because, you know, again, Docker swarm, I thought, again, going back to that original thing, you wanted to run different things on multiple computers. I feel like Docker swarm was such a great, like, and it was, or even early on customers, I was working at, you know, at Sysdig. I was like, "Yeah, we're not looking at doing anything bigger than, Docker swarm does our thing, and does it well." What was the concept between like coming up with Docker swarm?
- Well, Docker swarm was really just the result of people asking us for clustering of containers, of deployment of containers on a cluster of hosts, as opposed to just one host. So it was just one more thing on the roadmap, you know? And in our minds, we were out to build the complete platform to deploy your applications as containers, you know? And even beyond that, the context for us was we built a PaaS. You know, we build a whole PaaS. It was called dotCloud, and it ran your applications from zero. You pushed your source code, and then we took care of the rest. And it was hosted too. So there was a lot of stuff in there, including a container runtime. And so the initial strategy for Docker was let's blow up this PaaS in components, and let's open source each component and one at a time, and let's start with the container runtime, and then let's continue on to, you know, the build, the service mesh. What was it? You know, I guess, the monitoring, I can't remember the list, but you know, the individual elements of a PaaS, and we never really made it past the first component because, you know, it was Docker, and it became successful enough on its own right. But the idea was, okay, we're here to, there's a puzzle and it needs to be assembled. And the Docker container runtime is one piece of that puzzle. And so that was the plan, right? For Docker to be this overall modular platform. And yes, swarm was part of that. Did that answer your question?
- Yeah, no, no.
- That was the motivation for it. You know, you mentioned also, you know, swarms good enough for what for what we need implicitly, I think, compared to other more complicated and more scalable things. We put a lot of work into making it simple and easy to use, which was not easy. And I think we did a good job.
- I think others emulated that kind of join function. I think others emulated that to a certain degree. So yeah, it's really cool.
- Yeah, oh, there was lot of copying, man. Don't get me started. A lot of copying and a lot of crediting. You know, that's how it goes when you're successful. But, you know, I think we were more, what's interesting is how narratives take hold, you know? Like there's a positioning and then there's a story that emerges. People, human brains, I think need, they need a story to make sense of everything. And once a story makes it, it kind of really propagates. You can't really. The connection to reality is kind of secondary, that the story is the reality. And so sometimes that's good for you. Like the story of, hey, it's like shipping containers for your code. That was a really powerful and sticky story. And you can not get that out of people's brains. You just have to repeat it. 'Cause it was such a good metaphor. That really contributed to our success. And then there's stories where, you know, it's not less good for you. Like, oh, Docker is really insecure, you know? Or Docker swarm is not as scalable as Kubernetes. So once those stories, it's also hard to stop them, but we were actually much more scalable than Kubernetes for much longer than people realize. Because Kubernetes was a lot of air until it became like a real good software, you know? And eventually the biggest ecosystem wins. But yeah, it just struck me.
- I think Docker was an enabler to Kubernetes. Now that's the piece of it. You talk about all of those pieces put together.
- It launched at Docker Con. Yeah, it launched at Docker Con. And, you know, in retrospect, you know, we were, again, lack of experience. This whole platform that we set up to build, you know, and it was, we set out to build more of the pieces ourselves than was realistic. And I think because of that, we didn't think carefully enough about which pieces we needed to build and which pieces we did not need to build ourselves. Because we just, we thought we had the capacity to build more ourselves that we actually did. And so we just sort of, it's almost like we picked randomly. And then, you know, we picked wrong sometimes. The one of many mistakes we made, but honestly, I don't know, if we have to go back, I don't know really how much better we could have done it even knowing what would happen. Because once something takes, once your project takes off in adoption, you know, it takes you by surprise, and it becomes so popular so quickly, it's really difficult to keep up, you know? Because we were not ready at all. The code was not ready. The team was not ready. And then we were basically playing catching up for a long time, and catching up takes effort. So while you're catching up, you're not, you know, strategizing and anticipating and, you know, you're just trying to catch up. You're in the middle of the tornado.
- [POP] Civo is an alternative to the big hyperscale cloud providers. They've launched the world's first managed Kubernetes service powered exclusively by K3s. With sub-90-second cluster launch times, a simplified Kubernetes experience and predictable billing, Civo is on a mission to create a better developer experience. Get $250 free credit to get started. Sign up today at civocloud.com/popcast. That's C-I-V-O dot C-O-M slash P-O-P-C-A-S-T. Go check them out.
- Tornado.
- Can I ask a question about some rumors, and then just rumor killer.
- Sure.
- All right, there is a rumor.
- I like rumors, like maybe I don't to kill them.
- Yeah, maybe you do. So like there was one where like basically you were coding over people's shoulders. Like I heard that one. I was like, "Hey, this is our," you know? That it was like some of that was happening at Docker. And, you know?
- Oh, you mean? Oh, so wait, what does that mean, coding over people's shoulders? Like someone's coding and I tell them exactly what to type?
- Yeah.
- No, I don't. I don't, that doesn't. I don't think that's true. Maybe I did it, I don't know. It doesn't seem like. I don't know. You should ask someone else who knows me. I don't know. Generally.
- I worked with Theresa, and we had some stuff that like got right, and I didn't see that, so I don't know. Like I'm just spotting. Somebody on the show said that.
- Okay, so if I put myself in the shoes of someone who's annoyed by me, I could make a guess at what they would say. One thing they would say probably is I'm being really annoying about details that don't really matter. And I think that's often true. Believe it or not, it's now raining on me. I did not think this through, hold on. I will continue to talk.
- No problem.
- Sometimes too detail oriented, I think is one. And sometimes the details turn out to not matter, but you know, sometimes they do turn out to matter. So that could be one. So it could be not so much, "Hey, I'm going to write this line of code." That's that doesn't really sound like me, but it could be, "Hey, I want this, I want the feature to look very slightly different. And I'm sorry it's going to take you a whole day to redo it." Maybe that could be me. I think there was also a period of time. I'm guessing, you know, but, so one thing that happened, I mentioned we were not ready. I personally was not ready. And when one situation, I was not ready for was finding myself basically the chief maintainer of this open source project that, you know, took off, and with very little help, because we were all stretched very thin. We were a tiny team, and also, you know, it was not. I'm a programmer, you know? I wrote a lot of the codes in there along the way, but it's not like I'm the super hacker who single handedly built it, you know, carried it. I'm not Linus, you know? I'm not what in Linus is to Linux. But I found myself in a situation where I kind of, I had to play that role, and I tried, and, you know, some things I did well, and other things I did not do well. And the worst part about that job is that you're the guy who always has to say no, and it doesn't matter how right or wrong you are. Some people are always going to hate that you said no all the time. And you have to say no like 100 times a day to almost everything. And so your job becomes basically to justify to people who are upset with you saying no why you're right. And I know a lot of times you're doing that with people who are technically more competent than you, but still, they can't, they're not in that seat of having to reconcile all these different expectations and design constraints from all these different people in all this context. And so that context has sort of happened to land on me. And so that was difficult. And I think, you know, I tried to be Linus for a while, and that led to things, you know, to situations where maybe I was too invested in some technical decisions that, A, didn't matter, and, B, I was not competent enough to really make, you know? And so over, yeah. So that like, maybe that's the coding over the shoulder thing, but, yeah, it became a bottleneck for a lot of things. Anyway, a long answer, but, yeah.
- It's profound. It's a very profound answer. It's like you're, I'm a Virgo, right? People have said that to me. It's like you, you know, sometimes you're just very like detail oriented. And sometimes like, you also have, you're the captain of the ship, right? And so you have to kind of make those decisions. So it make sense. What you build and where it takes you shouldn't be limited by your database. Cockroach DB helps developers build and scale apps with fewer obstacles, more freedom and greater efficiency. So you can forget about the database and trust that it just works. Kubernetes friendly, open source, and indestructible, Cockroach DB makes it easier to build and scale apps. It gives companies the freedom to serve customers anywhere, and it's backed by world-class documentation and excellent dedicated support. Discover Cockroach DB, the most highly evolved distributed SQL database on the planet. Kubernetes native and built from the ground up to help companies of all sizes, including Boes, Comcast and Equifax scale fast, survive anything and thrive anywhere. Sign up for a free 30-day trial and get a free t-shirt at cockroachlabs.com/popcast. That's C-O-C-H-R-O-A-C-H-L-A-B-S dot com slash P-O-P-C-A-S-T. Let me ask you about one other rumor, and then we're going to move on to, I think, what's an awesome tool, Dagger. One rumor is in terms of like there was a ton of offers for Docker, and somewhere, obviously not in your specter hands, right? I mean, you know, and there was, you know, some offers that are out there for, you know, for buying Docker, and they were turned down. You like, again, it's not solely on your hands. I'm sure you had a board and all of that fun stuff. Is that something like you look back like in hindsight, 'cause that's a rumor. Some of them were really ridiculously high numbers, but.
- I know. Yeah, and some of them were very specific and kept coming back, and I never understood that, but none of those were true . That was the funny part. The more specific the rumor is the less likely it is to be true in my experience. But yeah, no, I think, I think if we wanted to, if we had made a strong decision to sell along the way, I think we could have probably, but who knows? But I mean, the way, I think beyond a certain point, what happens is it's not like you get the full closing documents with the price, and you just have to sign at the bottom, and you can say, if you say no, that's it. Usually what happens is, you know, someone expresses interest, and then you talk, and then you keep talking, and then you decide like, okay, are we really doing this, and if so, you're going to switch to a mode. We're going to continue talking for several weeks, at least. And it's kind of an investment of time and energy. And then you're basically shopping your stuff at this point. It's a process. And we made a conscious decision not to open that door. So it's very different from someone saying, "Hey, I'll buy you for this much." And we say no. I think actually my favorite version of this rumor, I kind of wish it were true, is that Microsoft calls, and they said we want to buy you for whatever ridiculous number. And then Solomon personally was very rude on the phone and said no and hung up. And I, you know, that one I liked, but it was also not true, sadly. Not that I want to be rude on the phone, but it's kind of like, okay, that's bad-ass, I wish I had done that . So, no, those were not true.
- [Announcer] Run confidently with secure DevOps, security for containers, Kubernetes and Cloud. Learn more and sign up for an upcoming webinar at sysdig.com. That's S-Y-S-D-I-G dot com.
- So let me ask you this, in terms of, you know, I think we talked a little bit about just, you know, the cloud native space and your, moving off of the rumor stuff. Let's talk about like the contributions that you all have made, but you specifically, but like you looking back now, 'cause, you know, you started, we're going to talk about Dagger in a second, but like, hey, you're looking at this cloud native ecosystem right now, and does it give you a sense of pride? You know what I mean? Like there's so much really cool technology and stuff happening out there.
- Yeah, I think it's great. I mean, I'm. I think there's two individual things. I'm proud of a lot of, I'm proud of the stuff we built, and I'm proud that a lot of people use it, and individually is separately from that, I'm just sort of really amazed that that ecosystem just blew up, you know? And to compare what was there when I started working on this stuff in this general space like when I became interested in it, and what it is today, you know, boy. I mean, it's fun in a kind of a nostalgic way to say, "Oh, there was nothing, and we sort of built it from scratch." But I think I would've preferred to be a beginner now, you know, and discover things now. I mean, I can't even imagine how, you know, the stuff you can do. Like the other day I was reading an article about students who experiment with the cloud and they end up accidentally racking up huge bills because of infrastructure. You know, that's the, like if someone had told me that will be a problem for students in 10 years, you know, I would've been, "Wow, that's crazy." Also terrible, but crazy.
- [Announcer] Learn how to operationalize open policy agent at scale with Styra. To get started, go to the link at https://hubs.ly/h0pnkm20.
- So post Docker, right? You kind of took a little hiatus, and this also could be, you know, sometimes it's good to reenergize, right? And this is where I want you to talk about Dagger, the current project you're working on, that you took that step back, and you're like, "Hmm, there's a need. I want to do this." So let's talk about when you got your mojo back. Let's talk about it.
- Yeah. So, well, yeah, it took a long time because I was pretty burned out. I mean, I don't know if we'll have time to talk about that,
- Let's do it, yeah.
- But, yeah, I was pretty burned out. Well, I'll leave it that for now, at least. And it took me a while to recover. I initially had a false start, and within three months, I was like, "Oh, I have all the ideas, you know, let's go." And my wife actually, you know, helped me out. And she said, "You don't look ready at all to do anything right now." And she actually, we basically left San Francisco and stayed in Hawaii for a month and a half in the same place doing nothing, which is very unlike us as a family. And that was really, that was, that made me realize, "Okay, this, I really needed this rest, and I'm probably going to need a lot more rest." And so then, you know, the focus became being a full-time dad basically. So we had two babies, and, you know, one is two and a half and the other is four months old. And I got to be a full-time dad for a while, which was amazing. And, you know, things sort of happened. After awhile, I was briefly a visiting partner at Ycombinator. You know, they kind of bring you in as the intern partner kind of, which was fun. And around the same time, my two really close friends, Sam and Andrea, from dotCloud and Docker, also, they had left Docker around, within a year of me, I forget who left first, but, and they started working together on something. And so we started talking about working together, and we didn't even really know on what. I mean, they had an idea, but they were pivoting anyway. So it was sort of a blank slate. What's funny is we did not initially talk about the idea. We talked about us and what it meant to work together and what kind of team we want it to be. And, you know, looking back also at how we work together in the past and how we would like to improve things, you know? So it was, we talked more about ourselves and our feelings in our lives than a product, which I thought was great. And so that's the foundation upon which Dagger is built. It's a team first, and then it's a product second. It seems weird, but it makes a huge difference for us. And so eventually we did, you know, find an idea, and we found it by just talking to a lot of people and asking questions, and maybe unsurprisingly, we got pulled back into DevOps and cloud native, but we were open to anything, I'm telling you, we could have been doing, like, I dunno some consumer app. I don't know. I can't see myself doing that, but. Yeah, so that's the process.
- Explain though, let's talk about Dagger. Like what is this problem this thing solves? What is it, you know?
- So Dagger solves the problem of the deployment of apps to the cloud being a shitting experience. It's just really painful for everyone. And it's painful for small teams and large teams, and it's painful because there no longer is a standardized platform to deploy to. Everyone's sort of stitching things together and essentially building a custom platform for each app. Sometimes you get to cheat and use a PaaS, but it never lasts long, that you can only use a PaaS. Usually you have to expand beyond a PaaS or migrate off of it pretty quickly. And by PaaS, I mean, I mean, you know, this platform as a service, Heroku, Google app engine, et cetera. And so the model of the winning platform, basically it is not, is failing in the cloud. And so I think a lot of platform companies are maybe not realizing this, and the smart platform companies are embracing this, and by this, I mean, the fact that the cloud is fragmented, and it's only gonna get more fragmented over time. It's not going to consolidate. So when I talk to, you know, Kubernetes maximalists or Amazon Lambda maximalists, or, you know, a sales engineer at OpenShift or Cloud Foundry or anything, there's so many platforms, they're all great. They're all good, you know? All at least good. Some of them are amazing, but all of them are specializing, and there isn't one that's going to win and kill all the others. That's outdated thinking, you know? It's just not the way it's going to be. Everyone's just gluing together, they're picking and choosing. So how do you deploy to that? And the answer is lots of glue scripts. You know, everyone writes their own scripts, and that part is just, that's the painful experience because those scripts, as your application grows, as your team grows, your scripts grow, and your scripts become a platform. And now you have a platform team, and it's like 50 engineers if you can afford them just building a platform that's 90% the same, except it's a slightly different, And so that's the problem we're trying to solve. So Dagger is basically a Lego set to assemble your own platform for deploying your application exactly the way you want, but out of standardized components with the real assembly experience. And in our world, when you're assembling Lego, you're developing. So we're making it a real fun programming experience to assemble your deployment platform.
- So I'm actually a contributor to it, everyone. Yeah, he invited me in.
- You are.
- Yeah, and so it was awesome.
- First five contributors.
- It was awesome because like I saw the original examples to where we are now, there was like two examples, right? And now it's literally a litany of examples where you start from like a hello world, all the way to deploying to an AWS, EKS or those types of things. It's really cool, incredible technology. How does somebody get, how does somebody get involved with this, Solomon?
- Well, right now you can go to dagger.io, D-A-G-G-E-R, by the way, and you can request early access. And then from there, we bring you into our little Discord chat room, and we give you access to the repo, and it's still, like you said, it's moving fast, it's early, it's rough. But you know, that's why it's really important data, an early community of people who don't mind trying something out before it's fully finished. And they don't mind just telling it like it is. "Oh, this was broken. I didn't understand that." And then we fixed it. We like to move fast, and eventually, soon, I hope, fingers crossed, we're going to open it up, and it still won't be finished. But even more people will be able to try it out and tell us how broken it is. And over time we'll improve it more and more, and it will be more, more accessible to more and more people. But it's a programming environment. It's the goal is to be a programmer, programming Dagger, except what your programming is not an application, it's the code that ships your application.
- Teleport allows engineers and security professionals to unify access for SSH servers, Kubernetes clusters, web applications and databases across all environments. You can download teleport right now at goteleport.com. That's G-O-T-E-L-E-P-O-R-T dot com. So I want to say this. I think everybody that's contributed thus far, I feel like we all owe you a debt of gratitude for what you've done to enable us. I would not have had a career. I'm dead serious. I'm being absolutely serious. I wouldn't have a career if it wasn't for you. Like in terms of what I'm doing now is all based on your shoulders. And so what little contribution that I've done, and that is literally a drop in the bucket. So again, I appreciate you.
- Thank you.
- So I will say this, another thing is I want to ask you, like there's this language you all are very fanatical about it, and it's really cool. It's called CUE. Can you kind of peel the art for everyone? What's CUE, and what's the benefit?
- Sure. So CUE, it's spelled C-U-E. CUE is the language, that it's the front end to Dagger. So when you're programming Dagger, you're writing code in CUE. And the reason we're excited about it is that it's a perfect fit for what we're trying to do, which is automate the deployment of applications. So it's a declarative language. It's data first. So when you're not actually writing instructions, you're not telling the computer do this, then do that. You're describing a configuration. You're describing the state of what you want. And specifically you're describing a graph of all the different nodes in your delivery plan, right? So if there is, you need to build a container and upload it somewhere and then generate a config file and then push that config file to a Kubernetes cluster, for example, those are four nodes in your graph, and they connect to each other in a certain way. There's a dependency graph. And to express that in an imperative language is just a pain, but to express it in CUE is very, very easy and simple, so it's a perfect fit. And basically anyone who's had to deal with YAML files, JSON files, templating them, generating them, validating them against a schema, assembling them from different sources, reusing them, all of that stuff is just so painful because YAML and JSON don't support it out of box, but CUE does. And the last reason that we love it is because of who wrote it. So Marcel van Lohuizen, who works at Google, he developed, he coauthored the configuration language, the Google configuration language that basically configures board. And so if you want to deploy anything within Google, you need to write something in that language and then you push it to their platform thing, and then your code will be deployed. So that language had , you know? To get that language to do that level of usage, that's a level of learning that is hard to match. And it's been in production for 15 years, And so all of that experience and all the pain was basically condensed in CUE. And so when Marcel wrote CUE, he wrote the language that he wishes he had written the first time around. And that kind of experience, you can't, you know? You can't replicate it, you know? And so I think we're just lucky. Earlier on in the show, I said I love to find sort of interesting bits of research and components that are under, you know, poorly understood or under utilized. CUE is definitely one of them. I think even, yeah, CUE is just, has so much potential, and it can be applied to so many problems and deployment. What we're doing with Dagger is one of them, but it can do even more.
- We'll have a link to the liner notes to CUE and obviously Dagger and all those fun things. I'm going to ask you the last question. And that last question is, what work are you most proud of?
- Oh, man . You know, actually it's unrelated to computers. Is that allowed? Yeah, I'm a big believer in working on yourself, you know, and improving yourself first, and yeah, trying to be, to apply discipline in your own way of living your life and following some sort of practice. And I think that, I'm a long-time practitioner of martial arts, and it just had such a huge impact on me early on. I don't know if proud is the right term really, but yeah, I guess I'll give myself a pat on the back and said, you know, I stuck to it and developed discipline in doing so, and that discipline and I guess ethic and outlook is what allowed for my work in computers to be successful I think. Because you have to kind of persevere in the face of just constant failure so much. You need some sort of internal guiding system. Otherwise, the world isn't going to tell you which way to go. You have to kind of have your own opinion on that. And yeah, for me, that came out of my martial arts practice. So I guess that's what I'm most proud of.
- Well, this has been, I appreciate you, again. What I will say to you is this. It's over the last couple of months, we've gotten to be very good friends at this point, right? So I appreciate you.
- Thank you.
- And the profound effect that you've not only made on my life, but everybody's life that's out there in this cloud native space. We owe you a debt of gratitude, and we appreciate you, and we can't wait to see what's going on with Dagger and whatever we can do to contribute to help you.
- Thank you, thanks so much for having me.
- Always, thanks for coming on "The Popcast."