Bryan Cantrill: [02:13:49.08] I mean – and we’ve got a couple of these, which is great. I’m just blessed with [unintelligible 02:13:51.20] verticals, but folks that are either significantly on prem today, or want to do big on prem experiments, that are like “I’m currently – I’m public cloud born, but there’s some big strategic reasons why I may want to go on prem in a very big way.” Cloud-educated, for sure. Like, “I understand cloud computing, I know the public cloud, but it’s not a fit for this use case.” Deeply technical is extremely helpful, not because the product – the product itself, I mean, we pride ourselves on the fact that it’s API-driven, CLI-driven, UI-driven [unintelligible 02:14:28.06] terrific job, making the product easy to use. But I think it’s important for teams – to really appreciate the transparency that we bring, it helps for a team to be technical. Because if a team’s like “I don’t understand why you guys keep disparaging Dell, because they’re fine for me”, there’s a certain degree where it’s like you’re just not deploying enough of it. You know what I mean? Where it’s like, if you have had nothing but great experiences with Dell or HP or Supermicro, you just have not deployed at sufficient scale, or in sufficient depth, or with sufficient bluntly attention to availability… So you just haven’t hit these issues.

So you kind of you need a team to be [unintelligible 02:15:09.12] enough to appreciate Oxide’s differentiators. And fortunately, we’ve been blessed by a bunch of those, which is great. This is a real – the value of kind of connecting with people at kind of a grassroots level. There are a bunch of folks out there that fit that bill.

Chris Benson: I agree. By the way, I’m going to make a prediction… I’m predicting that a large cloud computing service provider will purchase Rabbit.

Matteo Collina: [32:06] I was waiting for it. So first of all, I created a framework called Fastify, which is at this time maybe five to eight times faster than Express on Node.js, and Bun. Node.js with Fastify in Bun, it’s faster in Node than in Bun. But both Jarred and myself thinks there is a memory leak somewhere in Bun, that Node is triggering. Sorry, that Fastify is triggering. Fastify is pretty tied to the Node API. So if there is some mishaps on how those are implemented, then things can go sideways. So yeah, it is a problem, and this is the fundamental gist.

Node.js – okay, the problem with performance is who is pushing right now a lot of investment in software development, open source but also everything else? Cloud computing companies. One way or another we are all tied to Amazon, Google or Microsoft, or GitHub, or whatever, that are investing in some of our technologies and providing funds, in various ways. I’m not saying it’s a direct thing, but they have their own cloud products, and they are pushing these now. Now, the surge of serverless and a lot of other pay by millisecond thing, pay by consume, has made it absolutely damaging for those companies to invest even one dime in performance.

Steve Tuck: But we didn’t talk about Oxide at all. And I think the morph into Oxide and Friends was not specifically just to talk about Oxide more; there’s plenty of topics on there that have absolutely nothing to do with the space and some of the problems in computing, and cloud computing… But to provide a forum where we could go deep into areas that no one talks about. No one talks about bringup, because bringup is ugly, especially on first boards, first systems. And no one talks about compliance, because again –

Austin Gil: [50:02] Exactly. On top of that, on top of the trouble with distributed systems is what happens when you start receiving large files and you have a server that’s maybe like a lightweight server, and totally enough for your application to run, but it has smaller disk space, and all of a sudden, large files are taking up a lot of the disk space, you run out of disk space, you have to upgrade your server. Now, if you have to upgrade your server because you want to add more compute, you’re getting sluggish, or you need more CPU - excellent reasons to upgrade a server. If you are running out of disk space, terrible reason to upgrade a server, because you may end up doubling the cost at a not very cost-effective way of essentially doubling the disk space. And before you know it, you’re running out of disk space again.

So Kball, you mentioned S3… S3 stands for Simple Storage Solution, I think. S3 was created by Amazon, along with their service. They created their own protocol for storing files, adding files, managing files, deleting, updating, whatever. And it’s been great. And that protocol has been adopted by a lot of other file storage solutions partners. I do work at Akamai, I feel like I should interject that we have an object storage service that we offer, that is S3-compatible… And the article that I write, again, speaks to fundamentals. Yes, I work for a company that offers object storage solutions, yes, in my examples I use that… But everything that I write, I try to do, again, at a fundamental level, so you can take this and apply it to anything that is S3-compatible. So anything that uses this protocol, take it and put that knowledge where you want it. Very important to me.

But one of the big factors for object storage, S3-compatible object storage, is that they are designed for these files. So they’re highly available, easy to access, they store it in one location, and they’re very, very cost-effective. So for the same price that you would get 25 gigabytes more on a VPS to upgrade your VPS, you can get 250 gigabytes, at least with Akamai’s cloud computing services. So that’s a 10x difference. And that applies – and again, that would be across different service providers. I’m only saying the numbers that I know off the top of my head, but… Not trying to turn this into a sales pitch.

Jeffrey Sica: True. But in that case, the TOC isn’t like picking one technology over another, at least with the sandbox. What’s usually happening is they’re judging maturity, whether it does fit – like, whether it is a cloud-native thing or not. If my transcoding software, or some other random project that has nothing to do with cloud computing gets submitted to the sandbox - which that happens - TOC doesn’t want… Like, that’s not the CNCF. They’re the filter.

Justin Searls: Yeah, so I think of it in terms of like a sine wave, sort of, is like how the industry – it might get better overall over time, but we go through these cyclic patterns. And when you’ve been through a few of them, it’s hard not to see them. And when you’ve come out the other end of a few of them, it’s hard not to become a little bit jaded about it, because it sort of feels like we’re not going anywhere, like we’re just walking in circles.

I’m not there yet. I’m not jaded, and I’m not cynical about the industry. An example - when I was coming out of college, and I was working in big enterprise Java stuff, there was a lot of J2EE, Java 2 Enterprise Edition, which I think they kept calling J2EE until Java 5 came out… It was such a complex, burdensome, multi-person… Everything about it was this assumption that you’re going to need 18 layers of striation to do a Hello World, to build the most basic application. And the answer to the question, “Why do we need this?” is, well, someday, when you’re a big application, you’re gonna need to be able to do that. Or if you’re like IBM, or BEA, or Oracle, who are selling these things, the answer was, “Well, our proprietary Java application server has some feature like hot swapping the application in production without having to restart any servers, or something, and in order to do that, it has to be packaged in a certain way. And at really high scale, you just need that, and so that’s why we have these architectural decisions. And I pushed back against that.

[44:08] How I got into JavaScript frontend development was I was working in those environments, and I was like “Nope, I need to move a lot faster.” And so I was building full-blown applications in JavaScript, and just like sipping data however I could, to get the user interface the way that the customer needed. And I think that that spirit of an eclectic set of small tools solving very specific problems of the JavaScript open source world, as much as people look back and see all this churn as we moved from framework to framework and tool to tool, there was a certain pragmatism about “Look at all this stuff that I can solve, and bypass the really silly, complex machinations of my enterprise, because they just literally don’t care about what happens in the frontend, because it doesn’t matter.”

But when I say like there’s cycles, like – I get my years mixed up, because it’s bleeding together a little bit… But once React became dominant, and once you started seeing Amazon and Google, in addition to Facebook, really start to push open source, like their favorite open source tools, through paying developer evangelists to kind of like just press the flesh at conferences around the world, and convince everybody that no matter what scale you are, the answer is Kubernetes… Or our favorite tool for just coincidentally plugging into our cloud computing platform, right? So that’s why we want you to go serverless, on our servers. So there was a sort of enterprisification of open source that occurred by just marketing really heavily towards the same impulses that you’re expressing. Like “Well, I might need it someday, and I don’t want to throw all this out. So if it works well for Facebook, using Create React App and pulling in at a given point in time hundreds of small dependencies, then surely that’s good enough for me, or that’s like enough for me”, without thought of “Well, Facebook has a much larger group of people pouring over those dependencies, and keeping them updated.”

The complexity that you see now in frontend applications looks more to me like the average frontend application. Of course, you can write really lean ones. I strive to, with very minimal dependencies. But the average one, the average team, they just have this – it’s a disposition and a temperament towards looking to an authority, and pulling in tools, external tools wherever possible to solve problems, and the people who are kind of the loudest voices in that community are trying to solve problems at Facebook scale, Google scale, Amazon scale, and if you’re just some startup, it is YAGNI. You’re not going to need a lot of that stuff. Definitely not now, maybe not ever. But you’re either way saddling yourself with that level of complexity.

Amal Hussein: Honestly, that is the biggest pushback that I have ever gotten, from trying to always make that pitch to teams… It’s like “Well, it’s so slow to launch a browser.” Like, literally, that’s the excuse that I get. And I get it. I get it, people, I get it. But you know what - we have computers; we have compute. We have fast MacBooks. And there’s cloud computing, and there’s caching, and using ASTs to run the right set of tests, and such and such. I mean, we should leverage these things. I get it, it’s not one terminal window, but it is the right thing to do for our users at the end of the day, and the right thing to do for the help of our code and our applications… So you know, I’m just putting it out there.

Ganeshkumar Ashokavardhanan: Yeah, definitely. So for me it was quite a new paradigm for thinking about software as well, and even thinking about how code is run, and infrastructure in the cloud - it’s very different from what you do in college. Most of my courses were focused on running code on your machine, and when I was doing some training of ML models and so on it was using cloud computing and running on different machines, but not at the scale at which Azure operates, or a lot of production-grade software operates. So even a lot of the analogies that Brendan used and comparisons he did with previous technologies - I did not have that as a reference. So Kubernetes for me was also the first time in which I was learning about many of these concepts, around deployments and resilience, and so on.

So there were two parts, I guess. One part was even before Kubernetes, in my first internship at Microsoft, I got exposure to how rollouts are done, and so on, without using Kubernetes. And then, in my second internship, I had exposure to AKS and Kubernetes when I was interning in the team.

So for me, learning about Kubernetes I think has definitely been something where I explicitly spent time learning from docs, and actually even Brendan’s videos on YouTube, on Kubernetes, I watched them. For me it was also cool to actually meet the person behind the videos, too. So that was nice.

And I think also working on different projects within AKS has helped me learn about various Kubernetes concepts. And one of the things that I worked on is Kubernetes versioning for AKS, which is supporting new versions of Kubernetes on AKS. That process, especially for minor versions, involves many API deprecations, and flag changes, like Kubelet flag changes and so on that we would need to handle… So as part of debugging Kubernetes code there, looking at all these different components within AKS and so on, actually helped me become better at getting a framework of Kubernetes, and models of Kubernetes in my mind. And I think it’s still an ongoing process; there’s so much in this space, so it’s been a good journey.

Bryan Cantrill: Yeah, well, you should talk to some of those folks, because those folks are in excruciating pain, for a bunch of reasons. First of all, they are all generally cloud-aware. Sometimes people are like “Oh, I love that Oxide – you’re a contrarian cloud play.” It’s like, no, no, we are not anti-cloud. We are very, very pro-cloud. Elastic infrastructure is an incredibly important development, and we are very, very pro Elastic infrastructure, to be clear; very pro cloud computing. We just believe that you shouldn’t have to rent all of it. We believe that you should be able to buy some of it, because when you’re renting compute, the Moore’s Law dividend is going to your service provider, not to you. And we believe that there are folks who got compute at a scale where it makes sense to own a computer, and own a rack of computers.

So the folks that we are targeting are folks that are already on-prem; they are on-prem for good reasons. Those reasons - they may be security, maybe they’re latency… They’re very often economic. AWS is expensive. The public cloud is expensive, especially when you’re at a certain scale. And there’s a certain scale you get to where actually the public cloud is debilitatingly expensive. I can’t even contemplate the cloud of this workload. So those folks - they are cloud-aware, they’re running their own hardware, and they are stuck on this personal computer that hasn’t meaningfully moved in 20 years. And when they buy something from Dell, or from HP, or from Supermicro they then are responsible for putting the software on top of it. It’s like, you’re not running Dell on it’s own, you’re running Dell + VMware; you’re running Dell, plus VMware, plus Cisco, plus software to manage the network. And plus your distributed storage system, whatever that is. And whenever anything goes wrong - well, you assembled this thing, so this is on you. And every vendor points at everyone else. And boy, I lived this; we were Dell customers.

[01:04:19.09] I just remember – I mean, I told Dell a lot of things over the years. One of them is “Never tell me you’ve never heard of this problem before. I’m not interested. All that is telling me is that your most technical customers are leaving Dell”, which is actually what’s happening. And so when you are having a problem, it’s like “Yeah, Dell was telling me I’m the only one seeing this.” It’s like no, Dell was trying to gaslight you into believing you’re the only one seeing this, because Dell itself does not have the depth of competence to actually understand what’s going on, on their systems. Because Dell - and Supermicro is taking it to an even greater extreme, of… There’s this self fulfilling prophecy that this is commoditized garbage, so we’re going to treat it as commoditize garbage. But it’s actually really expensive. I mean, if you look at a racked-out Dell 2U server, it’s expensive. And we haven’t even got the software on there yet. We haven’t gotten VMware, or OpenStack, or whatever you end up putting on this thing to manage it.

For Oxide, not only are we taking the fresh approach to hardware, but also software co-design. We are actually developing the Hypervisor, the control plane. What you get is an actual cloud in that rack. You hit API endpoints, you provision. You don’t buy VMware to put it on this rack.

So for our target demographic, they have been grossly underserved. In fact, the existing infrastructure providers have denied they even exist. They’re like, “Well, every on-prem use case is going to the public cloud.” It’s like, *bleep*. I mean, I know about the public cloud, I understand the public cloud. This workload needs to run on-prem for economic reasons. But this is not a legacy workload; this is not going anywhere. And to be told that you effectively don’t exist, and then be more or less treated that way - it’s pretty aggravating.

So you know, our target demographic is kind of worked up. They’ve kind of had enough. Actually, when we were doing due diligence for the initial VC investment, and having VCs talk to some of our first prospective customers… They’re angry. So one of the feedback – we got some feedback from some of the VCs, like “Your early customers - they’re agitated.” I’m like, “Yeah, they’re pissed. They’re pissed. They’re definitely pissed. And don’t try to tell them that they don’t exist. That’s a mistake.” Because what they have seen is all of this innovation happening in all of these dimensions around them. And all of the innovation around Elastic Compute happening on the public cloud, and where they need to run it, they have been entirely deprived. So what they see in Oxide is oxygen. “Someone who understands what I’m trying –” And yes, I mean, the aesthetics are extraordinary, and the rack really is beautiful, I’ve gotta say. The rack - it is so good-looking; it is a really good-looking rack. But what we’re doing is much deeper than that. It’s much deeper than the aesthetics. It is a true first-principles approach that allows them to actually appreciate some of those advantages that folks have in the public cloud. And then they can go focus their energies on their business, and on building the software and supporting the software, supporting the developers that they need to go build a better product, build a better service.

And what we see is, you know, our target demographic is really started on those excellent enterprises, excellent Dell customers. The customers that we see on the horizon are those folks that are born in the cloud, and then wake up to a business that is actually not sustainable, because their margin is actually going to Amazon.

[01:08:00.27] And over the years, there have been many of these folks who have come up to the edge and like, “We’re going to build our own data centers”, and they’re naive about how bad the market is, so they go in like, “I don’t know, I’m gonna buy some Dell, or whatever.” It’s like, “Oh, God… Yeah, you’re gonna learn just how awful it is.” And they ended up vacillating; you know, going on-prem a little bit, but then staying on the cloud. And we believe that if you give those folks a real off-ramp where they can have the power of cloud computing, but with the economics of an on-prem data center, there’s real demand for that on these cloud-born SaaS companies. So that’s the future that we see.

Brian Kernighan: Yeah… And that summer I spent at MIT in 1966 was a revelation, because they had time-sharing. That is there was a central computer, and you accessed it from various kinds of remote facilities, some of which even used the phone system. So in effect, it was kind of like cloud computing.

Zac Smith: Yeah. And I thought “I could be the hosting company for classical musicians who needed a homepage.” So I started doing that. I found somebody online, on a webhostingtalk.com… You know, I pinged them about how to – 2 AM in the morning I started posting… You can go look at it there, it’s pretty embarrassing; I think I spelled Linux wrong… And started selling $20/month hosting accounts, to managing, figuring out how to run that, things like that. A couple months in I was doing pretty well; it turned out I was not bad at – what did they say…? If you know just slightly more than the other person, right? It’s all you need to know. So I needed slightly more than my musician friends about how to put up a homepage on the internet.

So that’s how I got into the business. And I went up this little town called Troy, New York, which is where my provider was based out of… I thought I was gonna meet some big company, and I wore a suit, I did all this thing… It turns out it’s just this guy named Raj, and a couple of his college buddies who had dropped out of RPI, and they were running this hosting company… Because he had worked for VA Linux the previous summer, and came back like “Linux is taking over the world. We’re gonna get into that.”

Anyways, we ended up becoming partners. So I was doing a lot of the selling and the ops stuff down in New York, and he was doing the engineering and whatnot. We built one of the first cloud computing businesses. Raj taught me a whole lot about how to think about software and open source; he runs a company called Grafana these days.

Eugenio Pace: I think one of the biggest components in what we call luck is timing. The time when we do things. In 2010, 2011, a couple years before starting Auth0, there was this thing that was becoming a thing, which is cloud computing. And my job, my boss at that time said “Eugenio, you have to go and find out anything that will stand in the way of developers building applications in the cloud, or moving applications to the cloud”, which is something that is gonna happen. And it wasn’t very obvious at that time, but I started researching that… And my first – what I’ve found as a big obstacle in that journey was identity and access management. That’s how I encountered authentication and authorization as a problem. It wasn’t a problem before cloud computing. Or it was a problem, but not sufficiently painful for people to pay attention to it in a way that made sense.

So I was lucky that I was tasked with that project. I ended up working with Matthias as a subject matter expert, so I got to know him… We ended up publishing two books on the problem. It was like “Hey, you’re a developer. Here’s what you need to know on all things authentication and authorization if you’re a developer building in the cloud computing world.” And that was actually the genesis of Auth0.

Jon Calhoun: Okay. Mihai described himself as a seasoned software engineer focused on cloud computing, scalability and open source Go projects. In his spare time he is trying to study bioinformatics and is helping people organize community events such as the C and C++ Dublin meetup group. So why not a Go meetup group, Mihai?

Mikeal Rogers: [01:16:04.26] First of all, coming back to that, differentiating between problems that are current technical limitations versus things that we actually have an incentive to solve… Everyone has an incentive to reduce the energy consumption. It is only a cost center. And if you look at what’s happening broadly in blockchains, we have figured out how to get the energy cost down. Those algorithms exist, they’re implemented in several chains… Ethereum is planning on moving to one of them, so Ethereum will be on one of these that uses significantly less energy…

It is totally unclear to me how and when Bitcoin would ever do something like this… So Bitcoin may be just always using this much energy, and maybe that’s the downfall of the protocol. Maybe that’s why people stop using it at some point, if they can’t make that migration… But I think if you’re looking at the ecosystem overall and the technology overall, we’re already moving past that particular problem, and we’re getting the energy consumption much closer to just what you use in cloud computing and mobile and stuff like that.

I don’t know when your first computer was, but mine had a power supply the size of about 20 iPhones, and it consumed about as much power I think as 20 iPhones maybe, for a fraction of the compute. That went down, and this is all just kind of coming down over time.

Abe Heifets: Okay. I also wanna take the opportunity to give credit to the chemists. Real transformation happens at the intersection of multiple different pieces. If you think about AI, there’s data and there’s algorithms that come together, but those wouldn’t be able to be run without a huge success by DevOps, and cloud computing, and GPUs, breakthroughs in the hardware, which are driving much of the –

I was just looking at this - because I’m a nerd, if we didn’t already establish this… The ASCI White, the most powerful super-computer in the world, and therefore in the history of our species, up to 2001, ASCI White, clocked in at over a hundred million dollars and a hundred tons. That machine peak FLOPS is an Xbox today. That’s an incredible transformation. So if you think about why are we able to do these things with AI today - it’s because of the massive success by hardware engineers; that’s driving a huge part of it.

So I wanna give a huge shout-out to the chemists. There’s been this equal exponential change on the side of the chemists, which is why we should care about AI. Here’s what they did. 15-20 years ago big pharma – like, if you and I wanted to order compounds out of a catalog, these commercially available compounds, there may be a million molecules that you and I could buy. And big pharma like Pfizer, Novartis and [unintelligible 00:51:19.28] Bristol Myers - they had maybe 3-5 million molecules in their warehouses. So in that world, it was better to be Pfizer and Novartis, because you had a better shot about finding something in your catalog, and then with an army of chemists you could iterate your way to a drug from that initial something. Remember, in Canavan, that’s what we lacked, was that initial something, and that’s what we were able to do at Atomwise.

Marcel van Lohuizen: Mm-hm. So the original problem that I wanted to solve with it is basically configuration. At my previous job I worked with natural language, and basically natural language grammars. And if you think about it, these are very large configurations. So if you see in cloud people that have 100k lines, configurations or more, it’s a struggle, and it’s really hard to keep these… Whereas if I looked at these grammars, it works fine. You have distributed teams, many people working on it… Not a problem. I mean, it was daunting, but it was not a problem. Essentially, if you look at it in cloud computing, it’s not solved. Configuration languages tend to be way too complex, and if you keep it simple, it also gets complex. It feels a little bit out of control. CUE was designed to get control back of configuration and manage it at scale, yet keep it simple.

Will Ramey: Sure. Let’s take those one at a time, and we can start with GTC. The GPU Technology Conference (GTC) is something that’s very near and dear to my heart. We organized the first one a little over ten years ago, and it has grown and evolved with our ecosystem of developers and researchers and data scientists and everyone else who’s learning and exploring how to apply the new technology. This year, with the Covid-19 virus, we transformed GTC into an online experience, and over 60,000 people joined us earlier this year for the very first one. In just a couple of weeks we’re gonna be doing what we call GTC Fall, the next installment of GTC, and it’ll have all of the usual elements that people have become familiar with in the GTC conference. We’ll have a keynote by Jensen Huang, our president and co-founder. He’ll be kicking things off on Monday morning, October 5th… But we’ll also have just hundreds and hundreds - I think it’s something like over 600 live and pre-recorded sessions available this year, talking about all of the amazing work that is happening out in the ecosystem.

Some of the talks are by NVIDIA engineers and experts and product managers to help people learn how to use these technologies, but a lot of them are by people who are using it to solve their own problems, and then sharing back with the community the types of solutions that they’re building in graphics, in ray tracing, in artificial intelligence with deep learning… They’ll be talking about hybrid cloud computing, they’ll be talking about the work that they’re doing in healthcare, in public sector and government applications… Just a really, really amazingly broad range of topics.

One of the most valuable things about GTC is it’s one of the very few places where there’s an opportunity for people from different disciplines, people working on completely different application domains to kind of cross-pollinate their best ideas, and inspire innovation in a large number of fields… Unlike most other events, where people who are working on the same kind of thing get together and there can be a little bit of an echo chamber sometimes.

[24:19] So some of the things that we’re doing to help facilitate that kind of innovative cross-pollination, even in a virtual environment, is hosting networking events for the attendees. We have this thing that we call “Dinner with strangers.” There’s basically a topic, that could be an industry-related topic, or a technology-related topic, and people who are interested in that technology and wanna talk about it with people maybe they haven’t met before, are invited to get together in small groups. We’ll have someone from NVIDIA, with some knowledge on the topic, host the gathering… But it’s not a presentation, it’s just a way for people with common interests to get together, maybe bring some dinner to their desk, and eat and have some social interaction, talking with other people who have common interests.

Stephanie Morillo: I have, because I was the editor in chief of two company blogs. I ran DigitalOcean’s company blog, and I did a short stint at GitHub also, running their company blog… And in both cases I was in the marketing department and I was sourcing, I was actively trolling Slack channels, and like “Oh, this engineer did this thing.” And then I would reach out to them and say “Yo, I think you need to write this blog post.” The process worked out well, and I’ll explain why…

There were a few things that I understood about what it meant working with engineers. For one, they don’t have all the time in the world to write their blog posts. They’re doing this in addition to their main job. So sometimes I would even reach out to engineering managers almost to advocate the value of having their engineers write for the blog, to get them excited and say “This is gonna be great for your team. This is gonna be great for your engineers. This will give people externally a window into what your particular team is doing.” Especially if it’s a team that’s working on platform stuff and things that are more internal-facing, that are not customer-facing, it’s awesome to give them an opportunity to talk to their work on the blog. So that was one important step for me - to reach out actively to engineering managers just to let them know what our thoughts were.

Secondly, I spelled out the process really – I was very transparent about what my process looked like, so I explained to them… I said “Listen, I know that you’re very busy, I know that priorities change within an instant… So what I wanna know is when is the earliest that you can get a draft? Should I reach out to you two weeks from now, or three weeks from now?” And if they said two weeks from now, then I’d put a reminder on their calendar, and I’d say “The only reason I’m putting this reminder on your calendar is just to reach out and ask if you have it ready. And if you have it ready, great. If you don’t, then I’ll come back to you at some later point.”

So in marketing, if you’re gonna do content management, you’re working on more than one blog post at one time. At any point I was having eight conversations simultaneously, just to get a blog post ready for two months from now… Because at any point, something could fall off. And then secondly, what I would recommend to the teams was if they weren’t comfortable as a writer, my recommendation was to record a stream of consciousness. “Record it and get it transcribed”, and I would tell them where to get it transcribed. Because then I told them “I can then take that and turn it into something with your feedback, and then we’ll shape it.” So that was one thing that I would tell people, especially for the folks that were really nervous about writing.

And then I always recommended that they had a technical reviewer on their team review the posts. Because we had blog posts on things like networking, and object storage, and a bunch of stuff, and no one person is gonna know all of that. You can be a fantastic technologist – there is this misconception, I think, from my experience, that to be a really good editor for an engineering blog post, you have to be deeply, deeply technical, whatever that means. But the truth is if you’re working in a company that has a bunch of engineering teams, with a bunch of different backgrounds, you’re not gonna know it all.

[15:57] We had people working with Go primarily, people working with Ruby, people working in all kinds of areas of cloud computing - no one person, no matter how fantastic or how deeply technical they were, were gonna know it all. So I told them very straight up, I am not the subject matter expert here, you are. But you need to get somebody on your team to review it from that technical perspective. So it would usually go through technical review with their team, and it made them comfortable, because these are people they talk to on a daily basis, they do code reviews with them… They’re used to certain kinds of communication. So at that point, then I would go in and I would edit and I would do heavy copy editing. It’s tricky, because you wanna preserve their voice. Sometimes I know some people get spurned by the editing process also, and I don’t know if this is what you were referring to, Divya…

Peter Wang: Oh, great. Yeah, quantum information and quantum computing and physics, and when I graduated, I decided to go into the software industry; I joined a startup. I’ve always been coding; I’ve been coding since I was a very young child, and I’ve always loved it. But just given it was the dotcom era, I thought that would be a good time to try my luck at that whole thing. But anyway, long story short, I ended up in Austin, Texas, working at a Python-based scientific software consultancy, and that was kind of the early to mid-2000’s… And it was there that I really – since ‘99 it was when I first started getting into Python, but then over the course of the 2000’s, when I started doing a lot of work in the scientific Python, scientific numerical computing with Python, that was… Basically, I was using Python before NumPy existed; it was still numeric, or NumArray, and those kinds of things… But basically, over that time I started seeing through more and more of my work and my consulting jobs that Python was being adopted in places that were outside of what you’d consider scientific computing.

We were initially thinking “Oh, this is a cooler alternative to MATLAB.” Then we started seeing it in business environments, started seeing it going to investment banks, and just see it being used everywhere to do financial modeling. I’m like “Okay, well this is very interesting.” So around the turn of the decade, I guess - the last decade, the 2010s - I think many of us in the community were having this realization, but personally as an entrepreneur I started realizing “Hey, with the joint evolution or transformational things of cloud computing, as well as big data, the big data creates a demand to do bigger analysis, if you will, and traditional SQL is not gonna cut it when you have the four V’s of messy, big data - SQL doesn’t cut it.” And then if you look at what hedge funds do, and hedge funds are usually kind of the leading edge of numerical modeling technology, they’re all doing very sophisticated kinds of predictive analytics, and they were choosing Python all the time. So there was that.

And then I realized with cloud computing - it meat that every company on the planet would be able to rent computers to do… Their data would end up in the cloud, and they would rent computers to do massive-scale, supercomputing-scale jobs, that would have been inconceivable before, because you’d have to ask IT, wait five years, and they might build your data center. So with these two combined transformational forces happening, I realized “A-ha! Python is actually a thing we should be pushing for data analysis.” So in 2012, when I founded Anaconda - of course, at the time it was called Continuum Analytics - I also started the PyData community movement, and that branding, if you will. It was kind of a branding exercise. Because all the tools are basically SciPy. Of course, you have Pandas in there and a few others, and stats models, things like that, but ultimately, it’s basically SciPy rebranded for a business audience…

But that pushing of Python for data analysis was something that me and a few other people - I’d say we were the pioneers, we were the vanguard, and everyone else was looking at us like we were weird. It was either Hadoop, or maybe it was gonna be R as the successor to Sass, but we came on the field and I was very vocal at that time like “Hey, Python’s the thing. Python’s awesome!” and then people would be looking at me weird. But now, I think we’ve proven that Python is a thing, and it’s a good, useful thing. Of course, it has its warts… But anyway, that’s kind of how I came to founding the company. And we creating, actually, Anaconda Distribution as sort of like a thing we had to do. We were interested in creating distributed computing, and interactive visualization, and compilers, and optimizing all this, and that, and the other, but we couldn’t get any of that into people’s hands, because they were still struggling to install SciPy or Matplotlib. So we built a distribution called Anaconda to make that problem - a particularly nasty problem, even to this day - easier. So that’s just kind of continued to be a thing… So yeah.

Adam Stacoviak: Yeah. We’ve been able to really help a lot of businesses like that. A recent example that I was really stoked about was KubeCon. The Cloud Computing Foundation has this conference (I guess) a couple times a year, sometimes in Europe, sometimes in United States, and we’ve been very good friends with the Linux Foundation over the years, and then that also bleeds into the Cloud Native Computing Foundation and their conference KubeCon, which we’ve gone to and we love going there. We’re actually going back this year. Gerhard Lazu is representing us this year, so that’s awesome…

But we have just ran some promos for them to promote “Hey, if you’re thinking about attending, use our code. Save 10%. Get the early bird pricing for extended times, whatever it might be, and join this kind of community.” We helped them share that invitation with a larger community, and their feedback to us was like “Your code was the most used over all the people that we used in these promotional ways.” And I just love that, because for one, everybody attending gets to save 10%, but then two, it’s proof that we actually can help willing community people in the software world to hear something on a podcast and actually take action. And it’s not like I’m selling Jerod something he doesn’t want, with money he doesn’t have.

Carmen Andoh: So after this big break, what were (if you can remember) some of the growing pains, so that now Go is starting to get adopted, and is now the language of cloud computing? Do you think that there’s any growing pains that you can think of? Or, alternatively put, is there anything that you wish you could have done differently, given those growing pains?

Daniel Whitenack: Yeah, sounds good. I’m not sure if you knew this, but I had a very brief interaction with the HPC community back after – well, I started out in Academia, so in Academia if you’re in any sort of computing research field, oftentimes you’ll interact with HPC clusters… But then after my undergrad I did an internship with the National Center for Atmospheric Research in Boulder, Colorado. They operate several – I’m not sure actually at the moment what they operate, but at the time they operated several big supercomputers, and I was doing some benchmarking of vector computing on a new IBM POWER6 computer.

It’s been a while for me, so I’m interested to kind of – like, I have some concept back in my head of my interactions with the cluster at that time, and what people were doing, but I’m sure it’s just vastly different now, so I’m really interested to hear how things have progressed and how that intersects with AI.

Maybe to begin with, on that subject, could we define what is high-performance computing or HPC? How is it different than some things that might also be in people’s mind, like cloud computing, or something like that?

Ron Evans: [39:46] I think there’s a huge opportunity for bioinformatics. Bioinformatics and cloud computing is not a problem that’s been solved at all. Material science I think is incredibly interesting… Things like shape-memory alloys, which are polymers that have the property which is opposite of normal metals. Normal metals, when you heat them, they expand, and when you cool them, they contract. SMAs have the opposite - when you heat them, they contract, and when you cool them, they expand. So they are very, very strong, and could be used for artificial muscles, new kinds of solar cells, other kinds of conductive materials, flexible electronics… That’s the kind of stuff I’d like to be working on if I wasn’t doing what I’m doing now.