Adam Stacoviak: You said “Most struggle to maintain focus today because they face an impossible choice with cloud infrastructure.” And you go on to say “They can either use legacy simplistic cloud platforms that fail to scale and constrain their technical choices, or they could dedicate substantial resources”, a.k.a. using AWS etc. “to manage unnecessary complex infrastructure on public clouds.” And they burn through precious time, resources, and ultimately just delay time to market, delay their application from existing. Render is in that middle ground there, and you said before that you were number 5 to join Stripe, so that means that you probably exited well, with some deep pockets… You didn’t have to go back to work. You said you and your wife said “Hey”, I’m paraphrasing some version of conversation you probably had, “What should we do here? Should we just hang out on this beach, or should we go and solve some problems?” What made you want to be in that middle ground there, to put Render in that gap that you described, to solve this problem? Why not just go off in the sunset?

Adam Stacoviak: You were talking about Tigris, and correcting yourself… Tigris is basically like the promise of object storage, but it allows you to actually build a CDN. Like, you can basically run a – you can write some JavaScript, use Tigris, and you have a CDN baked into your application. You couldn’t build anything like that before. You could try and do this with S3, but it’s so complicated to like manage multiple regions of data that it’s impossible. Supabase for Postgres is like this. Supabase is a Postgres that lets you build new kinds of apps, or build apps faster. It really gives developers power.

And so the Rebel Alliance idea was if the future is developers are picking cloud platforms, the best possible cloud platform for developers is 10 companies that have built a very special version of infrastructure, that makes developers more powerful by itself… And then obviously, developers would just use those 10 to 50 things together. Like, why would they use my object storage when they could use Tigris? Why would they use my Postgres when they could use Supabase? Why would they use my GPUs when they could use Replicate, for example? And I think it’s like – I don’t know, it’s one of those things that I could still rationalize it. It seems like a thing I’d really enjoy, but there’s actually huge structural problems with it, which is what people tend to want when they launch an app, is actually a really consistent UX, that solves a higher order problem than they can solve by themselves. So a PaaS like Heroku – Postgres isn’t a product. It’s actually part of the product. It’s a feature of the PaaS. And so you can do cool things like do PR reviews with your existing Postgres data, for example. And so there’s a UX issue here, where you can’t actually solve problems as well with 10 to 50 different companies as you could if you were just doing it all yourself. And there’s weird compliance issues…

One of the things about getting a HIPAA BAA, so you can do a healthcare app, is you actually end up having to sign with each of those 10 companies. You can’t just do one HIPAA BAA with us… Which I think is a real burden for developers. I don’t think they wanna do – even if you can unify [unintelligible 00:26:52.14] I don’t think they wanna do multiple contracts with companies, you know? It just creates more and more friction.

So there are actual practical issues with like a Rebel Alliance cloud. But also, I think that a lot of it is just politics. There’s just very few companies who have a low enough ego to give up a big chunk of potential revenue like that. Us saying “We’re not gonna take the Postgres revenue” is pretty big, because EC2 – I mean, most of AWS’es profits come from RDS. That’s like a huge market, that we just said “Hey, we’re not gonna have this. You can have this.” And that’s not a thing most companies would be saying. In some ways, we needed a company to come back and be like “Fine, then we’re gonna give up the compute revenue”, you know? And that was actually relatively rare, to find people who were that… Communist? I don’t know. [laughs]

Cherry Mui: Okay, sure. Yeah. In the past we had separate the compiler runtime subteam, and a separate Go release subteam. I think there was some time the release subteam was also known by other names such as open source project team, or the Go OSP team, or other names, as responsibility shifts… But it’s mostly related to Go releases. And I think it was during the pandemic, and partly related to team member change and other reasons, we decided to form a more integrated team called Go core. It basically consists of the compiler runtime tool chain aspects and the Go release aspects. And because the language itself and the compiler tool chain and runtime and Go releases, they all are in the very center of Go, other parts like tools, IDE plugins or platforms, cloud integrations, and all other things are built on top of that… So we call the subteam for the compiler runtime and Go releases the Go core team. That’s where it came from, I think.

Autumn Nash: The reason I asked is because I think that as developers we’re constantly inundated with different products, and they all claim to do the same things. But when you can hear the problems that someone’s trying to solve and how they got there, you can better understand the product and like the value prop, and how those – so how does Render differentiate itself from the different cloud platforms out there that do this kind of managed stuff? Or how is yours different? Why do you pick Render over the offerings that Azure, AWS and like Google Cloud have?

Jerod Santo: Redis adopts dual source-available licensing

Another open source project bites the dust. Here’s their explainer:

The success of Redis has created a unique set of challenges. Redis has been sponsoring the bulk of development alongside a dynamic community of developers eager to contribute. However, the majority of Redis’ commercial sales are channeled through the largest cloud service providers, who commoditize Redis’ investments and its open source community. Despite efforts to support a community-led governance model, and our desire to maintain the BSD license, delivering multiple software distributions simultaneously – across open source, source-available, and commercial software optimized for different on-premises and cloud platforms – is at odds with our ability to drive Redis successfully into the future.

When this news first dropped last Wednesday, I quipped: Gentlemen, start your forks. Drew DeVault must’ve been listening. (Probably not literally, but in spirit.) Enter Redict. Drew writes:

Like many of you, I was disappointed when I learned that Redis®1 was changing to a non-free licensing model. This is a betrayal of the free software community, but perhaps not an entirely surprising one. Forks are likely to start appearing in the coming days, and today, I would like to offer Redict to you as a possible future home for your needs, and present its trade-offs as compared to the other forks you’re likely to be choosing from soon.

In short, Redict is an independent, non-commercial fork of Redis® OSS 7.2.4.2 It is based on the BSD 3-Clause source code of Redis® OSS, and all changes from this point onwards are licensed under the Lesser GNU General Public license, LGPL-3.0-only.

Oh, and Microsoft also announced Garnet (a Redis client compatible cache-store) just two days prior to the Redis re-licensing. Fortuitous timing or did they know something?

Yaron Schneider: Yeah. So we donated Dapr to CNCF while we were at Microsoft. And the main reason why we did that was to really gain new contributors. Dapr had a lot of contributors, but being vendor-neutral is something that’s really important. If it’s a project that spins out of Microsoft, or AWS, or Google, and it remains under their proprietary licenses or control, then users of other clouds might not feel so much inclined to take a bet on it… Because they will go like “Oh, it’s a Microsoft thing, or it’s an AWS thing, or it’s a Google thing.” But when you’re doing it with CNCF, you get this vendor neutrality, and you gain these new audiences of contributors who are coming in from every walk of life; every cloud platform or technology that contributed to your project. So your end users grow, your contributor audience grows, and people see that this is really something that can adhere to many users, from many cloud platforms. We didn’t want it just to become an Azure thing.

Tim McNamara: I was on a roll. I was gonna say, I’ve been a vegetarian for like two decades now, and it was primarily for ecological reasons… And so I am not normal from that regard, but I still think that there was an argument that I feel quite persuasive; that we as a software industry can do better. We can respect our users by giving them secure software. We can respect our businesses by reducing waste, and also – and primarily from the Rust perspective, this comes in memory usage.

So a lot of these cloud platforms or cloud services are very – if you notice the way that their pricing structure works, typically compute scales quite well, so it’s quite cheap to oversubscribe CPU. You know this if you’ve ever managed your own Kubernetes clusters; you can kind of oversubscribe CPU quite well. But one thing that is much harder to oversubscribe is memory. Because if suddenly you have two applications that want to use all the memory, neither does very well. Whereas if you have two applications that suddenly require 100% CPU, things sort of slow down, but they don’t halt.

Yonatan Cohen: Yeah, so today you can access quantum computers through the cloud with several players. So IBM, for example, has a quantum cloud service that actually gives you access to great quantum computers. You can log in and you can actually run algorithms… But these are small quantum computers. Of course, they’re still a prototype of the technology. But you can actually run algorithms and you can see how they behave, as well as on simulators. You can compare, and then you can find that your quantum computer is doing not as well as the simulation, because it has a lot of errors; this is the main problem with quantum computers today… But you can do that, and that’s actually very cool.

IBM, for example, they give access to their own computers, but Azure and AWS have launched their quantum services in the last few years that give you access to third-party computers… So many different computers that are built by full-stack quantum computing vendors, like IQM, QCI… These are startups in quantum computing that build full-stack quantum computers, and you can access those machines actually today through the cloud, which is very cool.

And they also give you access to simulators, and you can run on those as well… Which I think is quite amazing, to be honest. I mean, there are certain experiments that I used to do during my Ph.D. at Weizmann Institute only 12 years ago that… It used to take a Ph.D. student maybe three or four years to set up such an experiment and to run it, and now I can just log into one of these cloud platforms and I could run the experiment that just ten years ago it used to take a few years to set up, I can do it probably in a few hours… And that I think is quite amazing.

Kris Brandow: There’s no general answer to that question, I think. It’s highly context-dependent. I think a great example of this would be Kubernetes in the current day. Kubernetes is amazingly popular, everybody is using it, it’s sort of becoming a standard of its own… And you kind of have a choice when you start using it. You can either keep your applications as they were before, running in whatever they were before, and just make them run on Kubernetes. Or you can start leaning into Kubernetes, build operators, tap into the API, get all this information, but then you’re tying yourself directly to Kubernetes. And it’s kind of hard to figure out which one of those things you should do, because Kubernetes has only been around since 2014; that’s about seven years… So seven years from now is Kubernetes still gonna be a thing? And if you lean into it very heavily, then you’re making the assertion that “Yes, I think that it’s still going to be a thing in seven years. I think we’re gonna benefit from having done this integration.”

If you don’t, maybe you’re saying “Well, maybe there’s a possibility that we could hook into something else.” But I think usually what winds up happening is that people don’t make a decision either way and you wind up with something in the middle, and in this case, being in the middle is bad, because that means you’re still stuck with Kubernetes at the end of the day, but you can’t actually move to something else, because you’re too tied into some of the things that Kubernetes is doing.

This also happens with cloud platforms. People are like “Oh, we wanna be multi-cloud” or “We wanna be able to switch away from AWS, and be cloud-agnostic”, and then you actually sit down and you’re like “Well, here are all the things that you’re doing that make it so that it’s actually gonna be a giant pain to lift and shift to somewhere else”, as they say.

So I think it’s one of those things where you have to gather as much information as you can, and then make a decision in the moment that makes the most amount of sense. And then realize you’ve made that decision, kind of more or less live with it, and then realize that at some point in the future when you have more information, that you should come back and potentially revisit that situation.

So if you’re building something today, I would say if you’re already using Kubernetes, lean all the way in. Use operators, use all these great features, because that will make your life a bit easier, it’ll make your current way of operating a bit easier. But just remember that some day down the road, maybe 4-5 years from now, those decisions you made won’t be making as much sense.

[36:05] You’ve gotta continually evaluate and reevaluate that decision that you made, which I think is kind of the theme that we’ve had this whole time, around just like “You have to bring in the requirements, you have to bring in the information, you have to gather all of that stuff.” And on that, I wanna raise the prospect of build vs. buy outside of just the code realm, and kind of bring it to our process and project management ethos and the things that we do… Because as we have been saying, we have to gather all of this information, we have to evaluate, we have to track time, we have to do all of this.

In my experience, I’ve very rarely seen people making explicit build vs. buy decision around this; it usually starts out as a buy. Someone’s like “Okay, we’re gonna do Agile. Or we’re gonna do Scrum. We’re gonna do X, Y or Z, and we’re gonna use these methodologies”, and then it morphs into some sort of built thing that doesn’t really look as much like the thing you started with… And new people come in and they’re like “Well, this isn’t how I did X, Y, Z, Agile, whatever, at my last place.” So it seems like quite a mess. So I’d like to hear your opinions on “Do you perceive this as a problem as well?” And where do you fall maybe on how we can start resolving this, or at least making it easier for people to make an explicit build vs. buy decision around this stuff?

Brad Van Vugt: Yeah, maybe they should switch cloud platforms…

Kelsey Hightower: That’s why I work in cloud! One thing I’m not gonna add here, but… Most of these cloud platforms - what makes them unique is that we’re trying to make people not have to do that trade-off. The reason why you don’t build your own car - because you will never have enough resources and commitment to build a car that meets all the safety standards.

[36:05] A lot of the systems we’re talking about these days - like VMware, for example; I’ll pick on VMware - they do a good job of saying “If you’re gonna get hypervisor, it needs to have all this stuff out of the box.” You go to Visa.. Hey, we’ve got all this stuff out of the box; we’re not gonna rely on your organization to try to figure it out.” So I think if you’re a platform person building platforms out there, how do you make it easy to have this stuff out of the box, without someone thinking about the cost it takes to put it in there? Do we want cars with optional seatbelts? Do we want airbags to be optional? Or do we try to figure out a way to get that cost of the car to incorporate those things and still be affordable?

Jaana Dogan: True. Also, there’s a lot of pre-packaged software and cloud platforms that can export a lot of telemetry, and there’s no standard around where they would export, or what data format it would be… It would be nice to have some sort of standard at least, so we can go and talk to all these open source projects or the cloud providers to export some telemetry out of the box… Because everything is a black box when you have a prepackaged something, or like a vendor solution, right?

Kyle Daigle: Yes, and I think if you look at Microsoft, Amazon or Google, you see them encroaching into the developer tool space, because if your value-add is a percentage of improvement on top of raw CPU, if that makes sense – so like CI, I would say, is primarily running the code. There’s all kinds of amazing features that get added on top of that that make that more valuable, but the real raw cost is that incremental improvement. It’s like AWS’s Git repo hosting - it’s an incremental improvement on top of CPU and storage. If your developer tool is just that, its primary market is a bit more than cloud hosting, you’re always gonna struggle, in my opinion, because those companies are gonna make more money on their own CPU than you will by buying their CPU.

So it’s really about how do you change the developer experience and give more than just what a CPU or an SSD can, with some incremental improvement… Which is why I think folks like ABI are doing something really interesting, where a company will pay dollars per user to get access to that tool, because it’s creating a new experience for that team, that will have a much larger effect on the overall productivity than, say, “I’m gonna create a CI that works across ANY cloud platform”, because those cloud platforms are all entering that space anyway.

Joseph Jacks: I have my own personal perspective on that, which is very different, and I’ve tweeted a little bit about this… It’s very different from the way that Redis has communicated their intentions behind the Commons Clause. As I mentioned, Commons Clause is a building block; it could potentially be getting some good conversations started, but I do not think it’s the destination. There’s a lot of additional work we need to do beyond Commons Clause to try and really move the state of the art forward here.

[51:44] I personally do not believe that open source authors or open source companies, like Elastic, Cloudera and many others, should be trying to protect against cloud providers from capturing value that open source software creates. I think that is fundamentally wrong; I’m very opinionated here. And the reason I think it’s actually wrong is very well-summarized by a tweet that Doug Cutting, who’s the creator of Lucene and Hadoop, sent out actually I wanna say a year or so ago… It’d be really awesome to showcase it in your show notes, but I’ll read it out here. I think it’s extremely profound and concise, and I completely agree with it.

His comment, and I’m slightly paraphrasing here, but it says “It is absolutely insane to expect contribution back to open source proportional to the benefit from it.” I think that is very directly related – it’s slightly orthogonal, but it’s directly related to this topic of trying to prevent cloud providers from capturing value around open source projects… Because they have no legal obligation. They’re actually delivering great user experiences and value to their customers, and they’re furthering the distribution of the open source software through their platforms. Cloud providers have millions of customers.

I don’t subscribe to this view that we should actually try and prevent the cloud providers from capturing value around open source. Instead, what we should do is try and make open source more widely distributed, more widely adopted, we should try and push for an open source future across the whole technology industry, across the software industry, and we should try and capture the value in the context of delivering differentiated customer experiences with different approaches, and I think that’ll make for a really great future.

Daniel Whitenack: Just to clarify, if I was a data scientist or a developer, or whatever I am, there’s a lot of APIs out there, both from the cloud platforms, like with machine learning, but also other things… Like, if I want to send an email programmatically, there’s a REST API for that, which uses HTTP and JSON… So you’re saying one of your goals is to really make the interface to doing something complicated - maybe like facial recognition or something - as easy as it is to send an email via one of those APIs. Is that kind of a good summary?

Daniel Whitenack: Just to clarify, if I was a data scientist or a developer, or whatever I am, there’s a lot of APIs out there, both from the cloud platforms, like with machine learning, but also other things… Like, if I want to send an email programmatically, there’s a REST API for that, which uses HTTP and JSON… So you’re saying one of your goals is to really make the interface to doing something complicated - maybe like facial recognition or something - as easy as it is to send an email via one of those APIs. Is that kind of a good summary?

Kelsey Hightower: These days I’m probably going to default to something that is container-based. And that doesn’t rule out things like Amazon Lambda, because the way I look at things like Lambda, which is a functions-as-a-service kind of event-driven platform - when I really look at it, especially now that they support container images for their packaging, I look at Lambda like I look at Ruby on Rails. Lambda is a framework for building applications, and if you use it, it is no different than using JBoss or WebLogic, where they say “Hey, we have an opinionated way of routing data to your application.” Some of those frameworks allow you to write just simple handlers, and ignore the rest…

So now as a technology company that’s going to be building services, number one, I definitely want something container-based, because we’ve proven - and I even have a GitHub repo - that shows you how to take a Lambda function and run it on Cloud Run. Because Amazon has a shim that would allow it to run as a normal HTTP server by just changing one of the entry points in your container image. So we’re gonna go with containers by default, and that opens the world up to platforms, or even low-level Docker on a laptop.

Next I’m going to think about my language framework. Do I want gRPC? Do I want something that’s REST-based, or do I want something like Lambda? But either way, I’m gonna be thinking about portability. I have business logic, and I’m gonna probably write that the same, regardless of the extremes.

But then, when we talk about protocol, I’m probably gonna have to support HTTP and REST. I do like the value of gRPC; it turns out you can do both of those in the same server, and they both call the same business logic. So that’s the way I’m gonna be thinking, because we have so much experience from the past that there’s no reason to go all-in on a single protocol. If you’re smart, you can just have an adapter pattern and support Pub/Sub, REST, WebSockets and gRPC, and not necessarily have to rewrite everything.

So that would be kind of my mindset going forward, and then I’ll just pick the most convenient platform. Maybe today Kubernetes is going to give me everything I need in terms of GPU access, custom hardware, but I won’t be afraid of platforms like Cloud Run when I need to just run some APIs that’s talking to a database.

Daniel Whitenack: So Chris, you were talking about the kind of diversity of environments and platforms… And cloud means a lot of things, and edge means a lot of things… I guess you’ve seen a lot of different types of edge devices and producers of data, and am I right that those could be – I mean, you’ve already mentioned sensors, but in a lot of cases, and I know I’ve looked at a little bit of this for my wife’s business too, specifically in manufacturing too, a lot of times edge devices are actually fairly beefy compute nodes that are just sitting in a factory. They’re not in the cloud or in a data center, but they’re sitting out on the factory floor, or something like that.

Wally Quevedo: I would choose NATS when I want to have low-latency communications. That is simple, right? When you care a lot about the simplicity of deployment, maybe having a lower collective overhead for your system, and you care a lot about the performance - that’s where I would look for NATS.

[20:05] These types of systems, like the Apcera platforms or Cloud Foundry, where you want to do basic communication and service discovery, I think it fits really well. The control plane use case, yeah.

Will Ramey: So in addition to the GPU hardware itself, and now the networking hardware, with the acquisition of Mellanox and Cumulus, and bringing them into the NVIDIA family… And then the systems - the HGX system designs that we’ve designed and worked with lots of our OEM partners to build and put into the market… And of course, the DGX product line - the workstations and the servers and the pods; the kind of data center scale computing solutions that we offer.

There’s a really, really rich collection of software, some of which we contribute to as open source projects. So whether it’s PyTorch, or TensorFlow, or any of the other leading deep learning frameworks - we have teams of engineers who are working on contributing to those projects to help them take best advantage of GPU acceleration directly… And then also take advantage of things like our TensorRT. This is the deep learning model compiler and runtime environment, so that once your deep learning model is trained, in the same way that we as humans – we put a lot of energy into training ourselves and learning a new thing, but once we’ve learned it, we kind of have like the mental shortcut.

Let’s say you were learning to juggle; it takes a lot more effort to learn how to juggle than it does to actually juggle after you’ve learned how to do it. And it’s the same thing for playing tennis, or playing piano, or anything like that. Same thing for deep learning. Once you’ve trained the neural network model, it turns out that it can be optimized and run at a much faster performance in an inference deployment environment, or at a lower energy profile, depending on what your needs are… And this TensorRT runtime is able to help with that.

But there are also higher-level tools and resources like NGC. The NGC catalog provides both containers with all kinds of accelerated computing, and deep learning, and data science software environments that are pretested, preconfigured, ready to go, can be deployed in your own servers, on your embedded Jetson-based platforms, or on cloud service provider platforms…

And it also includes things like model recipes. So maybe you don’t want the entire environment, you just want some deep learning models that are known to be good, and a recipe for how to use that, to train it with data, and things like that. So NGC provides a number of those things as well.

And then there are even higher-level services on top of that, that work with our EGX solutions, that are kind of combined cloud or on-premises, with internet of things. Say you’re a city and you wanna build a smart city type environment to be able to keep track of how many of which types of vehicles are running on your roads, so you can do predictive maintenance before potholes show up, or figure out where the safe and less safe traffic patterns are, so you can put in better crosswalks, or change the timing of your stoplights, and things like that. You might have hundreds or thousands of cameras, and you need to be able to do analytics on those video feeds that are coming into the system. This is the kind of thing that these EGX scalable systems are able to handle.

Colin Billings: Yes, and it actually shows you that feed of what’s going on on your doorbell, and it has a small interface for push-to-talk, or unlock the door if you have an automated door lock of some kind… You really start to pull the necessary pieces of those controls and interactions off of that.

Or say you wanna drop in from your bedroom to the kitchen to ask when breakfast is gonna be ready. Microphone, speaker - you can just intercom from one Orro switch to the other. There are really all the ingredients you need for a much more capable home, improved by the fact that it understands how you use your house. I think that’s where over the long-term we’re starting to connect not just the things that you do manually, but the things that you do regularly based on patterns, and have them actually happen for you… And then provide that layer that is the actual manual controls via the screen, or otherwise.

[36:20] The one thing to point out that I think hopefully is one thing that we’re interested in advocating for through our products and the ways that we go is that things like smart things and a lot of these other connected home platforms - they’re actually cloud architectures. So you have really naive controls or sensors that live in your home, and they require talking to the cloud to figure out “Hey, what does this mean?”

Johann Gyger: Yeah, absolutely. I like Kubernetes, even though there was recently a blog post, I think it was also on Hacker News, why Kubernetes is not recommended for startups, because it has some complexity. And I’ve also heard about Fly.io… So let’s come back to one thing, and it’s containers. Containers are a good thing, and they really – they were a game-changer. Kubernetes is one way to run containers, but there are many other ways, like serverless solutions, then public cloud providers have their platforms, there are PaaS solutions… So in essence, it’s containers.

Daniel Whitenack: I’m just looking at, for example – I mean, Google Cloud, AWS, all these platforms have different things… So they have categories, like in Google Cloud they have sight, language, conversation, structured data and Cloud AutoML these object detection sort of things… Language… Of course, translation is very much used these days, but also transcription and speech recognition, and then there’s conversation-type stuff, like chatbots, and like you’re saying, sentiment analysis.

Daniel Whitenack: I’m just looking at, for example – I mean, Google Cloud, AWS, all these platforms have different things… So they have categories, like in Google Cloud they have [unintelligible 00:07:55.17] language, conversation, structured data and Cloud AutoML these object detection sort of things… Language… Of course, translation is very much used these days, but also transcription and speech recognition, and then there’s conversation-type stuff, like chatbots, and like you’re saying, sentiment analysis.

Daniel Whitenack: That kind of leads me a little bit into a next question, which is around automation, and I guess more specifically around AutoML methods. I see AutoML mentioned quite a few times on the site, and also – I mean, there’s been kind of a general trend of AutoML platforms being released. Google Cloud AutoML, or H2O Driverless AI… There seems to be a lot of focus in this area. I was wondering - it probably makes sense to people… Like, one problem that AI people are gonna have is managing their GPU infrastructure, but maybe people think that the hyperparameter tuning and the modeling side of things is kind of their baby, and they don’t wanna mess with things like that.

What do you see as some of the major advantages of automating some of that piece of things, and utilizing some of these AutoML methods to automatically figure out architectures, automatically figure out the right hyperparameters, or automatically do other things…? What role do you see that playing in the future of AI infrastructure?

Gerhard Lazu: The one that convinced me to join CloudCredo. This was the OpenCredo office, you met me the first time, and you were sharing the vision that you had about platforms, and why you thought Cloud Foundry at the time was amazing…

Jason McGee: Yeah, yeah. And on one hand, that’s awesome; it means there’s just a ton of really amazing innovative work going on… But as the average developer or the average company assembling all those pieces, it’s hard… Maybe too hard, in some cases, to warrant. So you do kind of have to make this judgment call, and like what extra stuff do you want to bring into your environment… And I think that holds true with Istio today.

Today, if you wanna use Istio, you have to make a decision you wanna use Istio, and you have to install Istio into your environment, into Kubernetes, and you have to do some work to manage it and update it, and things like that… So there’s a cost to using it, and you have to kind of weigh off “Does the cost warrant it for whatever I’m getting out of it right now?”

I think what will happen with Istio in particular is there’s just a tremendous amount of excitement and energy behind Istio, and I really do believe – it’s hard to predict the future, but Istio has all the hallmarks of a key technology that will become kind of a de facto part of the environment that we all work with, and therefore it’ll start to get built in.

In IBM’s case, our intention is to build Istio into our Kubernetes environment… So it will just be there. If you use Kube to run workloads, the Istio pieces will just be there all the time, and you can just decide to turn them on or turn them off… And therefore, the kind of overhead of just choosing to use it goes down.

I think that’s what’s gonna happen in the industry in general; you’re starting to see people adopt platforms. They’re either using a public cloud platform, and that public cloud combines a bunch of the capabilities in that crazy picture, with all the icons, or they’re using a software distribution that kind of combines some of those pieces together… So you kind of defer that work to the platform provider to do the integration for you.