Hello, I'm Rob Hirschfeld CEO, co founder of rockin and your host for the cloud 2030 podcast. This episode is about the changes that we have the payment systems. Originally we were going to talk about PCI V four. But we became interested in the intersection in augmented and virtual reality, Metaverse, NF T's and micro payments, which definitely intersect with PCI with how we handle process payments. We had a fascinating conversation about how all of these technologies intersect, and how one will actually drive the other. I know you will get a lot out of it. And the conversation will shift as you listen to it. Definitely go to some fascinating places enjoy it.
I've had a couple of conversations last couple of weeks about using Jenkins inside of DevOps organizations. And like when I've talked to people about, about, like, their DevOps stack that they never mentioned, like I've been doing this for years, and nobody's ever said, oh, yeah, Jenkins. And like, somebody, like somebody said, oh, yeah, we use a Jenkins server for get ups or for orchestration or something like that. And then I started feeling like, really, that's, that's weird. And they're like, No, for a long time, and I've been pulling people. It turns out, like everybody we talked to, at some point has been like, oh, yeah, we have this Jenkins server, but nobody ever thought about it. Control it or managed it. Like we didn't think of it as part of the process, which strikes me is really weird. But it's been escaping all the DevOps conversations I've been in. And now, I'm asking people, it seems ubiquitous. So I'm curious if people agree that it's something that they've seen in practice. If not, should it be like,
specifically for in terms of talking about the bill,
or the Deploy? Actually not the bill, like, like, right, like, this is actually people who've taken a Jenkins server, and then
the Get get ops post image packaging, part right?
To, or to connect, like, a cert, like, like, I finished provisioning, and I have to connect in another system. Like, like, if they're using it as an orchestrator, because it's a general purpose tool.
So we definitely see some aspect of that, for sure, but one of the I think this is one of the things that is kind of, we talked about this before, I think here, right, is that CI and CD are truly separated. At most of the larger organizations that we've worked with, they're not the, this the same tool, they're not the same organization that owns it necessarily. Um, and so. So you know, there's there, I think there's a searching of the right technology to use for deployment, although in the Kubernetes space, that search is probably a little bit less. You know, there's, there's probably more mature choices in the Kubernetes space than there are for, say, deploying the bare metal. And so, Jenkins works really, really well if you have to string a bunch of things together. But if you if, if you use something like Jenkins, or kind of hard coding per graph, what that process is, in a lot of ways. And so things like what cartographer does begin to say, well look at it more as a set of sort of services that can be chained together for different workload types. That acts more like maybe like, I guess the best analogy would be like a freeway you know, we're everybody comes on the on ramps, and they go off the off ramps when they get to their destination. I hope I hope that makes some sense, but we're seeing definitely see Jenkins but we also see the issues with Jenkins at scale. And so we're starting to see people looking for alternatives to those issues.
Jenkins is the tool that everybody knows but no one admits that they've used in the past. There's there's a certain amount of stigma associated with changes and it's not completely unwarranted. Because check ins as it was a couple of years ago. It it did not lend itself well to the current configuration. They they made improvements since on the working on on additional improvements, but it is still the device On so that Jenkins is relatively old stack is still fairly GUI oriented. And that is where it, it has been in many cases superseded by the kinds of pipelines like what you can do in Git lab or GitHub actions, or concours or drone or any one of those. Going specifically to the topic of Jenkins for get ups. I feel like it's probably a when when people talk about that they probably talk about using doing the kinds of configuration would or declarative pipelines with Jenkins, which, again, it is possible, I thought it but it's still missing the key part and get ops, which is continuous reconciliation. Jenkins is event driven. And it does, it does not do the conservative reconciliation or the continuous reconciliation, unless you set up like a cron job
to do it. That makes sense to me, I guess. I mean, the thing that both of you are saying that is confirming this to me, though, is that there are like we've been stuffing Jenkins into this role. But then like doing it quietly. But I mean, I hear people talk about TerraForm and Ansible, and Puppet and Chef, right. But all the dev all the classic DevOps tools over and over again, the thing that's weird to me, it's like I just got back from a DevOps days, there was no like, managing your Jenkins server better. It's like a stealth, technology and people's infrastructure.
A lot of people it feels like Plumbing, in the sense of, obviously, there's nuance to it. But for a lot of folks, the thought becomes those the pipeline becomes interchangeable in the sense of, I can run a pipeline and get it back shins or Jenkins or wherever it might be. There's not a lot of focus there. Obviously, once you get into the actual details, it is quite difficult to swap unless you've done something like containerized, your actual executions, or some of those very intentional aspects to where you can easily swap. Yeah,
I think the other another part of it is that the developers were driving all of CI and CD at the beginning of the DevOps, like explosion, right? I mean, the whole idea was the Netflix model of if you, if you write it, you run it. In a large enterprise that doesn't scale super well, with many, many, many applications, that doesn't scale as well. And so having a whole bunch of different tools and processes that do deployment starts to fail. But I think Jenkins showed up because developers drove it, I'm guessing, and I'm sorry, rocky probably talked to a few old chairs.
Well, I was just gonna say that, essentially, like you said, came out of the developer world. And it's essentially a legacy that is probably not particularly well documented. And it's useful to people. So there's no drive to remove it from the system, even though it's legacy. And there's no money to actually document it. So it just exists there as something that's always been there for a lot of these places, because it did come out of the developers. And it was just easy to toss the tool with all the developer work in it to UPS and let them just keep it running.
I would actually disagree about it coming mostly of the developer world. And that is because I mean, this could be subjective, but But developers that I've met are historically very, very resistant to writing pipelines. They want to write their code, they want to compile it and then they want to hand it off to someone else to do the rest of the job. How is it that? Yes, it I agree with you, rocky that it that the environments that don't have Jenkins do have it because of legacy reasons. I don't think anyone who looks at existing CI CD systems would pick Jenkins as a first choice. It is perhaps the most well known one But but it's it's very obviously not the not the best choice at the moment.
So do you think that there's, like, just I mean, I'm using Jenkins more as a placeholder, and that there's really a variety of servers sitting here doing the orchestration role inside of ops environments. So we just heard talking about it. I mean, I could totally see that.
Whenever we talk CI, we talk check ins like systems is D, proto, typical CI
server? That's correct. That isn't it
comes out of release management, as opposed to ops. So it's literally this group that, again, has visibility to developers to on one side and a totally different visibility to operations on the other side. And a lot of places when they went CIC D thought they were removing, release management, but they were just grabbing their tools and eliminating the people.
But the truth of the matter is, is that most organizations will tell you what they use Jenkins for is the CI portion. And then they use some form of infrastructures code for the CD portion. But the in reality, it would not surprise me if developers who were given you know, the shift left as much of that deployment and operations piece of it to the developers that some of them would just use Jenkins to extend the automation. And
in many cases, might well be the Jenkins, is the one actually running Ansible jobs or TerraForm.
Right. Exactly, exactly.
Well, and also, but there's a date, you know, Jenkins and Ansible, TerraForm. And Ansible are not particularly even day two or reactive tools. So if you're like, Okay, I need to stop. When this happens, I need to take this action. Because neither of those tools is good at that. So if it's seems what what all of a sudden, I was an only because I was looking for it, like where's the orchestration happening, that when people have like a day to oh, I need to take something happened, I need to take this action. Then they're using Jenkins as the broker for that, when I could see like stack a stack storm or something else doing it. But Jenkins is more flexible.
Because it's already there. That's that's usually the natural process is that I need somewhere to run something. Jenkins is already here. Obviously, you mentioned stack storms in the space run decks in a similar space. But that then becomes another system I have to stand up. And so all too often Jenkins ends up being a catch all. Which is why when you look at the list of plugins that Jenkins has, where it starts to become a little unwieldy in terms of Jenkins can be that swiss army knife for a lot of things it should not be used for if if you if you want to use the best tool for the best job of preface it with that.
And the key is, is lots of folks have experience with Jenkins one way or another. And so it's easier to go to what you know, than it is to learn the right tool for the job.
Rob also, since you mentioned that day to operations like i i personally don't feel like Jenkins is a good news for that. But because checkings by itself does not have a way to hook into the day to events that you want to react to. Yes, it has web hooks that um, you can have another system triggered the the those web hooks based on events. But it's not something native to Jenkins, and it is very cumbersome system. So you're adding you're starting to play broken telephone, if you start getting into that a woman
that was the sense the sense I got was exactly what you're describing is that people like every what everybody said resonates right. It's there. I know how to use it. It's free. Like, you know, I just need to connect these, this hole to that hole and Jenkins is a multi purpose stuff and a tool to do it. Which is to me part of the reason why I think there's certain ops patterns where everybody does something but nobody talks about doing it. Because they all feel like it's not the best way to solve the problem or they must be the only ones who had To do this, and this has the feeling of that to me.
You know, it's interesting with that Rob is. So one of the things that we're seeing a lot of one of the reasons why white tends to application platform is getting some of the traction it's getting right now is release engineering teams, or, or platform teams that have been using something like Jenkins, for a period of time. And what they're running into is, they don't have a organization scale way of interacting with these applications through those tools. They're designed to be a process for an application, right, or, you know, maybe a, some process choices for an application type. But in the end, it gets applied application by application. So if you have something like the log for Shell, vulnerability that comes in, you have to go find all the teams and all the applications and all the processes and figure out what you're going to do to counter that situation. And so I think part of what you're seeing is that is that it's very team centric approach. It's very team and application centric way of doing process automation. And so it doesn't escape to the organization layer, it doesn't escape to oh, this is the way we do it at Ford, right? Because it's still seen as Oh, this is what we do for this application. And yes, we have a team that helps build templates. So we can do this for other applications. But it's still sort of application by application. So I'll throw that out there. I think part of what you're seeing is it doesn't get raised up to oh, this is the way our company does things. Because frankly, it's still something that a team feels like they have to put together or work with a small number of other teams in order to run it doesn't scale to an organization
scale. That's part what what got my radar up is that, you know, the people who have heard talk about it all, we're talking about it sort of as it's not exactly clandestine, or secretive, but it was it was to solve a problem or a couple of problems. And then it wasn't done in a scalable way, or it wasn't done in Infrastructure as Code way. And so, but yet, it seems, so far, and then y'all are only reinforcing this to me that it's it's a pretty widespread practice.
Yeah, but I,
I mean, I think it I don't
think necessarily specifically the Git ops through Jenkins, in the way that we mean, Git ops today, isn't necessarily as widespread. I may be wrong about that. But my sense is rather because some, some folks have done drops directly off of, you know, using something like Argo CD, like directly, you know, off of the repository to run a TerraForm job. Right.
And that's, I don't think people would call it get ops like the way the and that's what I'm trying to explore, I think that people would would look at it as sort of custom orchestration, or Yeah, and
CIC D, right, and CIC D, we're in, I think, in most cases, and please, everybody else, correct me if I'm wrong. But my sense in my conversations, folks is it's an extension of the way when when developers were trying to do the whole CI CD chain themselves. Jenkins was involved in orchestration of processes that were beyond just building and packaging code. And that's why it's there. That's my son.
Right. Well, that's I think you're making a distinction to me between the pipeline and orchestration piece, because there's an event there's an eventing component.
Yeah, I mean, that's, I think, I think that's fair to say that the pipeline is, again, that CIC, CI and CD are separating right are pretty clearly separate. And so you have pre packaging and Postback. And so yes, I think what I'm saying is the pipeline to package is one use of Jenkins, and they used to just extend that on and say, Okay, once I have my practice, go ahead and deploy it. But now in most organizations, there's a realization that no, we kind of need to, you know, version control the packaging, in a sense, and, and then orchestrate the deployment of that application, depending on a lot more operational factors than development factors, and do that separately. And so Jenkins may still be there for some of that, but it's going to get replaced.
Exactly It is essentially the application developer that's use Jenkins to do the CI part, and a lot of edits, still, a lot of developers perspective of deployment is it out there it runs, it's in production period, the end, it's just gonna run. And so it's easy for them to extend Jenkins to do that initial deployment, when it actually needs to be integrated with an ops zero through two day kind of thing. And so that's the whole packaging and, and release management, that needs to change on the back end, that for the companies that are still using that, that format, it's they haven't really migrated to the full mindset of get ups. It's still there's a release process that that they think they have control of.
I think there's a couple of things at play here. So there's, there's scenarios where we're talking to traditional dev shops, so to speak, there are also a number of organizations, I think, Robbie, we're hitting at hinting at a little bit of organizations that actually don't have developers that still have infrastructure and are using things like a Jenkins to facilitate deployments of actual infrastructure and management there. So I think there's aspects where it's the situation where there's use of Jenkins as just a pure orchestrator, not even thinking about in the sense of the traditional CI CD, we're talking about application development, where Jenkins is useful as a platform to actually orchestrate things from a systems administration standpoint, shall I say? So avoid conflating the the use of the term ops in this particular context?
That's a good point. i You're you're saying you're I agree with what you're saying. And in your you're hitting it when I'm when I'm trying to articulate to, which is that that, you know, because it's not all just had to code I deployed it is all of this up this system administration work, you know, distributing patches, making things, sure things are done. Just doing a simple inventory, or a conformance check. You know, we're when somebody files a ticket, you know, being able to say, alright, you know, if I think these systems are impacted, can I go pull a log, you can, like, those are simple things to automate. If you have an orchestration tool to do it. I just not hitting good use cases for this.
So I'd like to point out some ways the Bugaboo in the OpenStack ops folks kind of hit the Jenkins since they were using Jenkins, and they migrated away into what they called Zul and eventually eliminated all of Jenkins from their structure, but it was learning how Jenkins was more of an impediment. And taking the good parts of Jenkins and eliminating the parts that really weren't particularly useful for CI CD. So OpenStack did it in a painful, long term way. But lots of lots of corporate entities don't have the luxury the bandwidth or the resources to do that.
Select slight digression to we need to make a big differentiation between Jenkins so just Jenkins and Jenkins x, which even though it shares the same name, it's a completely different thing. Jenkins, Jenkins X, heavily leveraged with Tecton. And yes, it may be built on top of Jenkins but but it is fundamentally a different stack.
So I'm not familiar with the difference.
Jenkins is the prototypical CI pipeline platform. So you it gives you like authorization, it gives you web hooks. It gives your pipelines that country or other pipelines that that you can build you. You can build artifacts on either store them in Jenkins badly or store them elsewhere. Jenkins X is Probably the best to do the Think of it as a complete ground up refactor of Jenkins. So the doctor lessons learned. They, they said, Okay, we want to implement get ups with trying to reuse the tools that we have. So that sort of took the building blocks that made up Jenkins and started writing a new tool. Just Jenkins X. Which what is cloud native? Jenkins? For the most part, you see it running, running primarily on prem. So, so again, like it's, they share the same DNA. But they're fairly separate on on the evolutionary tree of CI CD.
Do you think has, do you think that people have been migrating? Because it's interesting, from that perspective, I don't hear people talk about Jenkins X, chicken,
Jenkins X. I think some people may have been migrating. Personally, I think a lot of the Jenkins user base has been shifting away to towards more holistic systems, like Git lab, like GitHub, like even even Azure DevOps. These are all I think core, they're our CI CD pipelines, but they have so many features added and bolted on that. Like the there were, what Jenkins is like the, the, the very basic car for four wheels on the four tires, and the stealing steering wheel kind of thing. All of these other ones have all of the bells and whistles that that make them more attractive on on the entry level scale, and checking texts does try to aim for that. Personally, I think that kind of missed the mark, because like being Tecton based, they do have a kind of heavy footprint. But I'm sure that there's some environments who who do prefer this kind of
stuff. I think one of the things to your point, right, and so I've been, I can't remember I've said that to this group. But I've been saying everywhere lately, look, if you're gonna build a platform that developers want to use, you have to do two things. And you have to do both of them, you have to reduce toil, unnecessary, or the necessary work that doesn't add value, but just makes things possible. And you have to reduce the risk, the possibility that you're going to do something that is going to either generate more work, or is going to create trouble in some way. And I think where people are moving in terms of these platforms, is do platforms that are conscious about that, that have either pre done integrations or make it easier, less toil less risk to integrate the tools necessary. You know, one of the big things that I think you'll see over the next five years is, is a compliance automation becoming more and more possible, A and B integrated into the into Ci CD chains. And then so make that less, you know, make that less work. And one way to do that is to have the services already integrated and ready to go. So Azure DevOps, I think, fits that mold really, really well. And I think both git lab and GitHub are looking at building an ecosystem around their environments where things are ready to go and easy to consume. And then I think what you have is, you know, from from, as well in terms of reducing risk is, you know, you need the ability to both not create problems like security problems or things you think of when you think of the word risk, but also the ability to adapt in the future, that you know, that that the future isn't a risk to what you're doing and so they're looking for or, I wouldn't say managed in the sense of, you know, hosted and kind of delivered to you, but managed in the sense of, there's a vendor who's consciously thinking about the evolution, what it means when new tools or new approaches come into play. And those things can become available to be consumed. reasonably easy. Bye bye, folks, that one that consume it. And so you know, as is probably not surprising, moving towards either a cloud model, or moving towards a shared services model, within an organization to do these kinds of things. Rather than, you know, every team kind of builds their own tool chain, because it reduces toil reduces the amount of work that developers have to do, and it reduces risk because the organization can address risks when they're known. And and put in guardrails and prevent those risks in the future.
I really like your summary with this. Right? Because I think you're entirely right, you know, toil and risk are are two things that developers work really hard to avoid. But I do appreciate the added piece here have some type of you managed? I agree, you were stumbling on managed I agree with you managed is like not exactly right. It's not curated either. Like, because developers use libraries, you expect that you're going to be able to keep getting updates and patches of your library and count on it not breaking you. And so as things happen, you're going to expect that whatever platform you're using is going to have to have some degree of
community evolution.
Sure, I think curated works, if you think about it in terms of a curated ecosystem, which includes curating the interfaces that allows the ecosystem to grow and adapt to new use cases. So I think to me, you know, the other thing that a platform needs to be successful is an ecosystem that consumes it. Right? So So one of the reasons Kubernetes is so damn successful is because there's a huge ecosystem of things that do CRDs and that consider or do use other forms, or API, and essentially consume Kubernetes to deliver capacity for whatever function that it's, that's providing. And therefore, there's a broadening of use cases where it's lower, lower toil. For developers, they may not even know Kubernetes is under it, I think. I was at a part of an O'Reilly Radar event this morning. And and Kelsey Hightower was the other kind of other headliner. And, and Kelsey was saying, looking because you know, the best, the best tools that have been built from Kubernetes are the ones where the users of those tools don't even know Kubernetes is involved. And so I think that that ecosystem thing is huge here. And when you look at building tool chains, you know, can I find a code scanner that I don't have to figure out how to write the integration using the API of the code scanner? Right, can I find a and I was talking about compliance automation, right, I think there's Policy Automation pieces that are beginning to be adapted to do certain compliance checks. But there's also vendors out there, they're trying to address certain compliance regimes directly by maintaining separation of duties by means by, you know, providing other capabilities with automation around. And so that ecosystem of things being kind of brought into play, I think, is really critical as well, for the direction things are going. And, you know, as far as many developers, as I hear going, I don't want anybody to restrict what I can do with my tool chain, I don't I want to be able to do everything up to production and own it all. We hear pro 10 times as many who go, I just want to check out my code and have it go. Right. I don't care how you do it, just when I check in my code and you accept my pull request, then it should be running in production. Next thing I know. And, and so getting to that state where an organization can address that does require more sort of managed elements that from a developer's perspective, are completely taken care of.
Does that eliminate the ops tooling on the other side? Because I agree with you, this is what I think I think Get up Get get get Ops is this ultimate statement to the developers
API. But you know, I think in the backend there, you actually have to operate manage the systems. There's still stuff going right but
but the more model that Kubernetes is bringing us towards that seems to be what a lot of people like. And frankly, what Mark Burgas did all those years ago with the CF engine was copied by Chef and Puppet in their own ways. Right is reconciliation, right? So day two becomes a reconciliation to an expected state.
Problem is those those aren't good orchestrators is I think that we're getting are saying,
right, they're not theirs. They're not orchestrators, those are. Those have a reconciliation loop and operational loop that's sort of running constantly, that's making sure that things are reconciled to the norm. And I think so people, you know, even people who use Jenkins to deploy software, I think once it's deployed, they don't use Jenkins, as far as I know, to react to negative situation, because that would be a bitch. I would I would, if somebody was doing forcing me to do that, I probably quit that job. Well, they do from
from a systems administration standpoint, it's a platform. That's the challenge that from which is why I am using the term systems administration very specifically, it's not bring it into the the more DevOps II space, so to speak. Because to Rob's point, if I do need to patch something, or I do need to automate a sequence of events that isn't tied to Kubernetes. It's bare metal, it's virtual machines. It's, it's all the other things. And it's that gap of what's the platform for that.
Yeah. And so you can use Jenkins to say, okay, I can automate the process of deploying over and over again and do upgrades and do you know, bluegreen, rollover, so you could probably build all that. But the problem of reconciling something going down. And fixing that problem, Jenkins would be horrible for that. Right. And
this is this is, this is why I'm scratching my head, and people are, are plugging it in, because it's available to do some of this work
to do that deployment piece of it. But I
I mean, it's getting more use than that, because it's there. And it can be adapted.
And so not just for for the context of developed in house apps. So let's say I get a commercial off the shelf application. And as a system administrator, I need to deploy that app. How do I care and feed for that?
Right, every night, you have to do some purge cycle or check the logs or do some cleanup action, right? I mean, that's normal, even on stuff you wrote, you're like, Okay, I need to know that every night, I need a job that cleans up the whatever, right? That's not a Chef or Puppet thing. And I actually I love what you were saying, you were describing those products using a reconciliation, loop versus orchestration. And, and so the things that, you know, even putting something on a timer is more orchestration than then a reconciliation.
Yeah. So if you're running a batch job, I could see it being, you know, being that being really, really normal. If this is the, you know, this is the cop, this is where it gets really interesting in terms of maturity of approaches. Because I could see, like, if you're still thinking in terms of, hey, I should initiate all action in the system, even if something goes wrong. Then, then, all this makes a ton of sense. And if you're saying, Well, I have to run this job every night, in order for my systems to have enough space to, you know, I have to clear logs so that my systems will keep running because of disk space. Now, that makes sense. I could see doing that with Jenkins. without too much trouble. I just think if you look at day two operations as maintaining availability, and maintaining performance, then then I get like, oh, man, that's ugly, right? There are way better options out there today. That are that are not that even ones that aren't necessarily Kubernetes based that are much better at doing reconciliation
left, because I don't think there are a lot of options, Chef puppet and Ansible. Ansible is a good orchestrator. It can be manipulated to do that. So let's say I need to restart five servers and push out a patch to those servers and then do some checks after it's those things like that, if what's the platform, obviously Ansible becomes that tool. But where do I execute the Ansible from in a centralized fashion?
Right now? Okay. That's I mean, and that's, you know, I just a tiny plug for what I'm for what I'm working on, right? The, the idea behind cartographer is very much to look at this from a very different lens and say, there ought to be, you know, sets of services that do key parts of what has to happen both in terms of deployment and in terms of day to day. But the general model is to coordinate a workload on Among a series of services that reconcile to, you know, to a desired outcome,
I just want to, I want to point out that this is actually a sign of the whole get ups and large apps maturing and that we're now talking separately about reconciliation. We even have the term reconciliation, which wasn't even on the map a couple few years ago, except in those folks heads, they knew what it was, but they couldn't actually put it into two terms, the folks that have been doing the heavy lifting, from Martez and Klauss. perspective that are in there day after day, doing the work. So reconciliation is part of the maturation and a next step to making the whole system actually operate. Well.
Hey, James, would you be interested in walking us through what you're doing cartographer, I'd love to hear it, if you want to, yeah, but to stay on the schedule, and just put your name in, I'm not on my
schedule, too. But I would be if we can line one up, I would be happy to come in and kind of talk through, you know, making
this time. And just let me know, and I'll go, we'll arrange the schedule.
I'll take a look at the next few weeks here. I'll get back to you rob, about that. That would be a delay, I'd
love to see, I'd love to talk to you guys through it. It's really interesting. We think it's, it's quite unique in a lot of ways. It also there's, you know, it's new and nascent. There may be problems with it that we haven't run into quite yet. But but we are seeing a, you know, a very large amount of interest from, from both previous pivotal customers and from new net new customers to sit have this kind of approach to debt platforms. And largely because it's, it's incredibly flexible, and adaptable. But we can also sell them a working solution out of the box to start with, it's a lot like, like content management, if any of you guys have worked with content management systems, right, everybody gets a content management system or buys it from Microsoft or whatever. Nobody uses it as it comes out of the box. Everybody customize the heck out of it. And that's what we expect people are going to do with with supply chain. So
just like JIRA to.
Yeah, yeah, exactly. Very similar,
just like Salesforce
model, although, I mean, I think that's what a platform, you know, this nobody took this is what I pushed it into yesterday that I couldn't get them to take up on it right away was look at a platform that will succeed in the long term is composable. And so what it ends up having to be is a box of parts that can be composed in numerous ways, but you don't sell the box parts, you sell solutions to real problems that are built with that box of parts that people can then customize to their heart's content. And if they want to break glass, they can break glass and customize. Or if they want to build something from scratch with a box of parts, they can build something from scratch with the box apart. But they have that flexibility to to own sort of the final form that the platform takes in terms of the tasks that it does the order those tasks have been whatever it may be. And on top of that, they get support up to the level where they where they customize something right they get support that the services will work and should work if they're put together in a way that that that the platform allows. But if they want to build something totally customer if they want to just you know rip and replace a chunk of the the the choreographer engine or orchestrator or whatever it might be on the platform, then they take on more responsibility, but they can do it if they want to. So I can talk more about that in
more depth. And no, this is this is great. Yeah. I'm looking forward to it. And we are we are over time. So I appreciate everybody since I saw this. This has been one of those scratches says it's just I'd hate to scratch it figure out what's going on. So
thanks. Good discussion. Good discussion. Definitely. Thanks, guys. Appreciate it.
Thank you, Jeff.
Well, what a fantastic conversation. This is the typical cloud 2030 discussion, where we start with one topic and bring in intersecting conversations that really enrich how we think about identity payments, virtual reality, Metaverse, NF T's and And cryptos all clearly interconnected technologies. But the cloud the cloud 2030 dot cloud is one of the few places that you're gonna get to hear this type of conversation, but even more, where you can participate in this type of conversation, please join us. The 23 dot Cloud has all the details, so you can be part of our roundtables and participate in the agenda to talk to you there. Thanks. Thank you for listening to the cloud 2030 podcast. It is sponsored by rackin, where we're really working to build a community of people who are using and thinking about infrastructure differently. Because that's what rec end does. We write software that helps put operators back in control of distributed infrastructure, really thinking about how things should be run, and building software that makes that possible. If this is interesting to you, please try out the software. We would love to get your opinion and hear how you think this could transform infrastructure more broadly, or just keep enjoying the podcast and coming to the discussions and, you know, laying out your thoughts and how you see the future unfolding. All part of building a better infrastructure operations community. Thank you
