Hello, I'm Rob Hirschfeld CEO and co founder of RackN, and your host for the cloud 2030 podcast. This episode was fantastic and fun and interesting. And you will want to hear the end. Because we got into protecting API's with NF T's. And how we got there is also interesting. We were talking about civilization technology. So how do we create standards and regulations, and expected API's that allow us to create ecosystems around the infrastructure that we build, we see this all the time in railroads and building electricity, you know, consumer electronics, we haven't yet seen it emerging cloud, or even an open source. And we had some really significant conversations around the interactions between these systems that would, would or will drive standardization and resist it. I know you will enjoy this discussion. So the topic for today is building codes for the cloud with this idea that, and we've talked about this before, using standards creates market power, or creates market ecosystems rather than the single dominant players. Yet we're we're sort of seeing a whole bunch of challenges in our and I have the notes I have for this our team Corp industry, global standardization, how that would help us what's what's holding us back from that, why it's important. The Tyranny of naming challenges. I don't remember the background on that one. But I think it's important, and there's a link for the technology, S curve, adoption curve. I'll paste in for everybody to see, which outlines the idea of systems, you have sort of reaching an obsolescence peak before the thing that replaces them is mature enough to absorb that. So there's a there's a gap. From that perspective, what what I would do is, there's a story I love to tell about this, that's really useful is that back when we were getting we, as a civilization were getting central heat, there were no standards for how boilers and heating systems were built. And boilers are basically, pressure systems. And if you design them wrong, they will explode or catch on fire. Same with electrical systems, electrical systems were wired in, you know, without any standard components or standard rules. And there were a lot of fires from electrical systems. And so, at some point in the process, we came up with building codes, some of them voluntary, some of them industry, some of them regulatory, in which we actually built the systems to those codes, and then relied on it. And at that point that the safety of the systems improved dramatically. But also the industries behind those systems, were able to now interconnect and you could build all sorts of follow on things behind them. Right? You could you could sell appliances, because there was a standard plug. I'd say that we're seeing the same thing with USB now, where a lot of devices don't bother having, you know, we used to have custom plugs for everything was a nightmare. And now we're just using USB plugs for everything. And that's, you know, wasn't the intention of USB to be a universal power adapter, but providing that service, because the standard, so there's places where we get these building codes, or, like, you know, everything in our life, and as they progress, the there's an accelerated component. And, yeah, it's a count on these, some of these standards are crazy. So the topic for today is to think, you know, as to talk through how do we get there, in in cloud, you know, is there should we be there? What does it take to get there? You know, are we are we what are we missing out on? I don't know, there's there's a lot of ways to go on this, to sort of see the standardization. Or even if you agree that that's a inevitable path for where we are the cloudtech that'll open the
floor. I generally say that it's still still way too early in the evolution of tech and for building and supporting what's called Cloud for that to be standardized. I mean, there's Certainly Kubernetes is the latest, quote unquote standard, but it's quickly going to be replaced by something else. We just don't quite know what what yet probably something kata or firecracker related, but who knows? Now, it could be five or six other cool related technologies that will come upon me that see the stuff is cyclical. So
do you think that open source communities are replacing the need for standards bodies? No,
I think I think their Opposite.
Opposite. Yeah, that's a stronger statement. Okay.
Yeah, no, I wouldn't
like each other. Which is a good thing. I think it's a healthy conflict. And the more that we embrace that, that, you know, IETF and cn, CN CF examples, perhaps, are in conflict, but we should embrace that is it's good.
Isn't it true that because we have such large vendors, in the cloud service providers face standards for cloud services are less critical, because you can get so much work done with any one of those groups, those companies API set, or standard build strategies. On the other hand, it's also counterintuitive for them to search for standards, because they don't want to move to commoditization of what they deliver any faster than they absolutely have to. Because they would assume that they're giving up their IP. If they were to standardize, do they win? If there are standards, or do other companies win? That would be in the wings, if the cloud providers were to provide a standard set of tools and API's for everyone to use?
That's something that that we've been discussing on and off on Tuesdays, actually that like, what is the barrier for for CSPs to deploy interoperability and the other the common thread usually leads towards to be the, the CSPs, they want standardization in order to absorb the user base from other CSPs. But they don't want standardization because they want don't want to let go of their own user base.
And we're, as we slowly get boiled a lot of fragen frog in warming water by the cloud service providers. We accept that situation. Because if there were 100, cloud service providers that all offer different standards, then it would be much more of a pain for the individual buyer.
Having said that, there was also the discussion about de facto standards like for example, s3, it it's it's not an on paper standard, but everyone assumes that if you have s3 compatible storage, it is compiled with your API and you just need need to use the appropriate host names for it. I'm
ubiquitous i I'd also throw into the mix o i n and bandwidth alliances both those organizations exist because of kind of a I was gonna say forcing function to that's not right. It's it's like a velocity of activity forces people into partnerships that they didn't really want or expect. Oh, I N, basically just I don't I think majority of the companies that got involved in ODN, one point or another did it out of kind of a desperation to lower their legal and their legal costs from patent trolls, but also just future, unproductive competition. But then also the bandwidth Alliance, who would have thought that organizations would start banding together to, quote unquote, save on network costs where that was, continues to be one of the ways that they tried to keep their customers Stuck. Stuck is not the right word, but encourage them to stay within their ecosystem, but they're now creating. It's gotten away from them. So now that For in the bandwidth alliance to try to lower the cost of their customers. It's
weird. And can you give some background on the bandwidth and alliances because I'm not familiar enough?
Oh, sorry. You can find it's something that Cloudflare. Amazon, Google, I think vultures involved with it. Now, there's there's probably about 20. Org CSPs that are involved in it now. And essentially, what it means is that for certain types of traffic, they will charge you as a customer to move it between those bad points. So for example,
if you use CloudFlare, to peer with your Amazon back end, you get, again, you get no draft, you also get faster peering in many cases as well. So as opposed to accessing s3 directly. So it's largely useful for one year user distributing content. Because you get the power of Cloudflare is catching on until under flexibility of having your back end your storage files still in Amazon, or for you all the CSP stuff are part of the lines.
And for some, okay, sorry, I have a question. Then how widely adopted are ISO 17 788, and 17 789? Because those are the ones that are going to be enforced by NIST and through the government, as well as three new ones that are in IEEE and IETF. on security?
Did you remind us what those represent?
I don't? Yeah, I don't know what they are.
Oh, okay. Um, I can put a link in the in the chat. One is for cloud architecture. And one is for cloud services. They were defined by NIST in 2018 2019 2020. And the latest updates are for 2021 will be released, I think, in June, and has little fingers in them.
Your assumption is that these will be a standards, these will be enforced in some way or?
Yeah, yeah, there, there was legislation passed last December in Congress to force the implementation under the NIST guidelines. I can't quote you chapter and verse on us legislation. But I can certainly tell you that they did receive a high levels of approval in the first go round of voting. And there's people that I work with in NIST, on an occasional basis that are pushing like crazy to have these things adopted into law.
Is it around like power efficiency standards, or no,
one of them is around security, the other two are around, I asked, pass, etc, what those standards should look like. Just give me two seconds, and I'll put it in the chat. But being
interested in seeing it.
I can't imagine his industry would think this is a great idea to have NIST tell them how to run their business, but
you're talking to the choir.
Yeah, I think the CSPs would resist like crazy, but I think that the customers who are in
the mosque never was adopted in 2018. I'm sure it's incredibly generic when they wrote it. Now, it's probably not even applicable, three years later.
Well, but just agreeing with you, Sean, I'm just telling you that there are a lot of people that are pushing for these things, because they believe that there's too much of a dominance of the larger players are the same people who are pushing for, let's break up the big tech monopolies, etc, etc. So where I participate is in the development of the actual standard, the technical standard, and the work that goes along with it. So from that perspective, I have a modicum of influence, but also not being a US citizen. I can't say very much. That being said, however, the same thing is translated worldwide if it goes up to ISO, and for those that are no make this very quick, that are unfamiliar. It's the small groups that start the movement. And they all have steps stage processes that bounce it all the way up to ISO and to get the ISO blessing takes a while, but it doesn't take that much in the sense of, you know, people pushing back to say, No, we're not going to make this a standard or yes, we are. So from that perspective, if it doesn't transfers into legislation or gets into the Congress in some way, shape or form. NIST stands behind it and starts pushing it big time. And since it seems the administration listens to them to a certain degree, that's where you get these things coming from.
I want to posit something that might be its Harris it, I'll just say it is heresy. That the idea that something that's regulated, stops all innovation. I think that that assumption is a marketing statement, more than it is a I think there's places where it has, it has limitations, but we've been doing cloud infrastructure for a long time, the idea that we need to keep tweaking the cloud it, you know, the basic parts of the cloud API, translate into an incredibly challenging environment for the users of those environment. Right, we're adding changes around the edges that don't necessarily benefit, you know, they benefit the the provider of that technology. But it's, it makes it incredibly hard to use and build on top of those systems. If one they're still drifting into there, there have all this vendor variant. And part of me that doesn't agree with that statement. And there's a part of me that, you know, strongly agrees with that statement, as I'm doing all this, the work around multi cloud and hybrid. Cool, thank you joy.
Interesting, like, be more, I can be more specific, like, because the OpenStack stuff OpenStack started with a vision to create API standard across multiple clouds, so that you had, you know, basically, this even playing field of all sorts of providers could set up OpenStack. And then the, the power would transfer back to the users where they could, you know, clouds would be interchangeable from that perspective. But the operational differences between OpenStack installs were so high, and the operational differences between the clouds themselves is so high, not a matter of the API's. Right, Mark's example, about the plugs from the chat, where, you know, we have all these different plugs. But fundamentally, the, it's alternating current of, you know, fairly narrow band of voltage and a fairly narrow band of hertz. So, the plugs are a nuisance, but the appliances that, you know, it's, that's easy enough to it, that that can be adapted. The, it's not like that with cloud stuff. You can't just say, Oh, I'm going to skim the API for Amazon versus Google or OpenStack, or VMware, and things are gonna be the same Richard shaking his head, um, and then expect that your automation and your your systems are going to work the same way. It's not, they're not that compatible.
Isn't that the value proposition of companies like Hashi Corp? S? Ah, right. Right, that, you know, I, you know, I just, you know, I just to go with your electrical plug analogy, you know, I just got back from Europe, you know, and I had my little I had my little box of plug adapters, where I could plug, you know, whatever I brought with me into whatever plug I was in, you know, whatever, whatever place I was in. Yeah, is that, you know,
it's, it's not the same, like, if you look at if you look at at TerraForm. Right, you can use TerraForm on any cloud, but each TerraForm provider is unique. It is it is completely impossible. And I know because I've been trying it's not impossible, it's incredibly hard to write air form plans in a way that is actually cloud agnostic. Perfect, you can't do it. Because the clouds themselves are too different. So you can use TerraForm against every cloud, but your your code your plan are operationally distinct for each each cloud environment.
So why would it so why would I bother to use TerraForm? That
because if you live within the same cloud ecosystem, it does make your your bills for participants. The problem with TerraForm is it's not within the same cloud. It's once you've crossed clouds.
But I mean, if you know I'll put my executive My IT executive hat on, but that's what I'm buying right now, the whole point of that, you know what, you know, what I'm trying to avoid? Is cloud lock in. Right. And TerraForm, you know, was sold to me as a path to avoid that.
It's yeah. And I think there's two answers from that perspective. It is demonstrably a better API than the cloud providers are providing or for interfacing to their their clouds. Sorry, demonstrably is is maybe Vega word it is it is easier to use than a CLI because it accomplishes multiple tasks at the same time. And so if you can learn you can learn it and and your skills and using TerraForm will be portable, even if the plans aren't. So there's a there's a benefit multicloud benefit from that perspective, but it's operationally distinct.
It gives you a common DSL to do work across the different costs, even if the plugins to the need to use are different. Trying to think of an analogy like that this might be like. Like TerraForm is more like comparing it to a programming languages. Like if each cloud is a different programming language. TerraForm is a promise from paradigm like object oriented or functional or, versus another language. Like going from C to Java, you still need to learn the various nuances about the new language, but you have your foundation already. So the effort two switches less, they're still effort.
Yeah, it's sort of to me. Maybe this is I'm looking for a good non tech example. And reach out if I can pause if you want to jump in. But otherwise, go go ahead. Um, everybody can drive a car, right? If you if you learn to drive a car cars, in some cases, have relatively standard interfaces. And I believe that's a regulatory standard, right steering wheel, blinkers, brakes gas, it's, it's, it's pretty standard, until you get to things that aren't actually standardized, like how to turn on the lights for the car, or even how to shift which frindall is pretty standardized, but where they put the shift lever, or even how it locks or unlocks. It's not always that that similar. So that quickly devolves if you actually opened up the hood and looked at the operating characteristics of the engine behind the scenes, you wouldn't expect and maybe this is an interesting aspect to this, because we don't have to mess with the engine of cars, particularly anymore. But you know, you wouldn't expect to show up with you know, frankly, even tools that work in one type of car do not work in another type of car, we have English and metric tools. But the way an engine is constructed depends on the vendor, right? If you sit down with a Subaru, it's the piston layouts completely different than if you sit down with a regular gas car, which is different than say, a Mazda RX seven. I'm not but there's still nations,
that the humans are the the both variable and the constant here because people still need to fix them. They still need to be repaired by human beings that read manuals and use tools. And the humans are the things that go into a car. You know that? Are they both the cost and the variable? Yeah. So it if you don't have the tools to generically can fix these things that mechanic can use, then people won't buy the cars, right though the
breakdowns where we do the interface, like this is where like OBD got standardized, because we needed that and that was regulatory. Because we needed a single way to pull data out of every cloud.
Yeah, but the industry kind of accepted that when that came out there was because there was so much push, because of the smarts and cars. The tooling that was being built to actually manage that in the aftermarket was becoming unwieldy. So the common interface just became There's enough push that everyone just kind of accepted it had to happen. I'd almost make the comparison of it's probably a stretch, but the Google Oracle API drama that just went to the Supreme Court and is kind of mostly resolved, that API's shouldn't be, you know, copyrightable. But with most legal cases they didn't, they didn't completely nail it down is that's the actual 100% of the time, the case. So there's, there's still going to be litigated quite a bit, I'm sure. But much in the same way that it appears that API's are now free of being encumbered. But it also directly goes back to there's this push and drive to, for certain organizations to make sure that it's is as easy to use for their customers and difficult as possible for competitors to, to copy or utilize, much to s SPL that the elastic and elastic and Mongo are are pushing, which is gonna kind of break that we're trying to pick
it up pause, because there's a couple people's with hands up, but I'm
sorry, I kind of know.
Exactly, right.
Well, Richard, like to suggest that we have to bucket a few of these can these considerations. If I were to draw a distinction between the standardization of what's exposed to consumers, Users, customers, and those that are required for the interconnection of a reasonably small or at least well defined community, for example, I mean, go back as far as you know, railway, railways and the standardization of gauges, which would allow once you put a you know, a gauge, a certain gauge railroad in place, you can move across that track anything from a hand powered cart to a modern electric diesel. In between, you can have wood fired, coal fired, you know, everything else is there. But, yeah, hold on a second, the next thing you do is you standardize the switching of on railways. And then you standardize the signaling. And that is to the end user, the driver of that, of that, that engine to let him know, to, to continue not to continue to slow down. There's a problem. And in point of fact, that's pretty much how railways ended up, you know, getting the standardizations they got they had their adapters in the old days, where you they literally took railway cars and put them on a sled that that that will allow the the railway car to accommodate a different a different gauge railway when it crossed into a new a new service that was simply not useful but usable and became the basis on which standardization was driven by this community of suppliers. I think we're in the same boat with respect to the CSPs. We need to establish what is standardized for the benefit of interconnection in interoperation. And what standardized for the purpose of exposed surfaces to consumers.
It's interesting that you mentioned railways because I did The in the in the US that the reward system was the contributor for standardization of time slots like it was because they needed a system to keep their trains from crashing on shared tracks. Right. Yeah, just going back to what something is. Before Roberto was change of topics. Sorry, Richard, if you wanted to do this, like the dimension of OBD. And Rob, you mentioned as a standard with OBD, the standard is, is a very tenuous one. And I think it's actually a very good analogy for for TerraForm. Because you're plugging your plug is standardized, your pin out is standardized, but the voltage changes, the data that the bus provides is completely different, not only found from a manufacturer to another, but from a model to another.
Yeah. So, so yes, forming the OBD of upcloud. Yes,
it already let you know, you can use OBD to get data from from the engine of your vehicle, and in some cases, provide data to the engine. That's it. After that, everything you need to do is tinker around manually and reverse engineer it until it works.
But that's going to be very interesting with the multiplying factor of code in cars as they're coming out. Now.
This been fun. I noticed from well, I don't work on his first time, but the company I've worked for, we do telematics reverse engineering OBD is one of our main have one of the main things that we do, and we do it well, I do a lot of work.
It's a huge amount of work. I mean, there's going to have to be translators. Can you imagine, as you know, if you look at what GM and even now Toyota, and you know, many of the automotive makers around the world, the closer they get to autonomous vehicles, the more code is being put into those systems. It's not the device anymore. Patches tweaks without standards, or interoperability of that code. Yeah, it's gonna be pretty risky, no pun intended.
And they're scoring government requirements as well, what like, for example, the New York recently announced that they're going to adopt the requirements for for, for transportation efficiency that California set out. So does that mean that they're going to use the exact same data? Not necessarily, but but, but it means that in that you need to collect the data from the same sources and to function effectively do an ETL to make it meet the standards of that particular jurisdiction?
What a mess, it is going to be your roads standardization point?
Well, you know, I think part of the issue also, and I think we're gonna see this with edge as well, is that we're going to have certain requirements that are going to be like bare bones that will have to be met. And I think that's being driven a lot in large part by security folks that are looking at it from their perspective and saying, if we don't put our foot down now and develop a standard that everybody must comply with, we're gonna have just a quagmire to deal with going forward. So whatever is coming out of cloud, and certainly with respect to the TerraForm discussion, I see it becoming something that by next year, we're going to have issues around edge deployments as well, just because of things like telematics and LiDAR, and any other sort of vision based, you know, requirements that have standards attachment, have no security attached to those standards. So it's going to be a very interesting time. In that regard.
It'd be very difficult to convince the business community that not only of what the standard should be, because there's going to be just well Just what the standards are around security, but the reporting and the data security aspect of reporting on that data, you know, who's gonna own it? lifecycle that data, who's gonna use it and for what? I can't imagine that's going to be an easy discussion, an example, to this date, there's still not, at least to my knowledge, there's no standard or even attempt at trying to come up with a standard for all the data that all the police departments just in the US gather for body cams. You know, the privacy around that there's, as far as I know, there's been a lot of debate about it, but there's no standardization. That's a huge amount of data that's floating around there. And obviously, incredibly important, for court cases for privacy for liability. And nobody's been able to figure that out. At least not yet. So I think we're years or decades away from those will stop people from debating and talking about it, which I think is an important topic, but
without without, without a regulation or some need. There's it's not a feature that has high business value to develop. Yeah.
But with regulation, I mean, for autonomous vehicles, I think there is already some legislation pending. And there are certain standards that are being evolved, where the carmakers are definitely, you know, part and parcel, the thing where I side even more recently is, there's an organization that was set up for digital twin development, because asked 10 engineers what they mean by a digital twin, and you'll get 12 different answers. And there's a lot of scope creep, you know, in a variety of different ways. That being said, though, the digital twins are what what are being used by municipalities to be able to regulate the driving of autonomous vehicles, and even those that are semi autonomous buses, taxis, whatever, the more of them that are, that are pushed out into society, the more the regulation needs to happen. And telemetry, of course, is a major factor in that, as is security. So I think you're gonna see that push, and it's gonna, it's gonna, sort of what's the word dz chain, if you will, or domino into other sectors of business in a very significant way. And by the way, even though it was kind of tongue in cheek, I actually have a client that's trying to put their API out as NFT. So that that becomes their stake in the ground. And there's two markets that are opening up just to do that for the big tax.
But getting back to your you're talking about telemetry,
a whole topic about that. In the list on my head is my head is really confused.
So is my S key.
The notion of a standard as an NF t just, um, what does that what the excuse me, but what the fuck does that mean?
Give me occasion.
You're excused. You're excused? No, not a not a standard as an NF. T. It's that they want to encode their API's as NF T and then licensed them that way. But it's their proof of stake, no pun intended, that it's theirs, and it can't be forked or changed without you paying a fee for it.
For it, so as a means of enforcement.
Yes.
So they're, they're looking to use blockchain as a way around copyright. Well, I was seeking a way to prove license ownership, which seems fun. I don't think I would use any FTEs for that. But it certainly seems interesting approach. It also would mean that license could be transferable. But you can well talk to someone else
some licensing.
Yeah, that's exactly why they want to do it. They're looking at monetizing their API's in ways that have never been done before.
What's an interesting idea oh, I hate to be implemented. So whoever implements your API, effectively could fork it to, you know, be something slightly different. But, yeah, interesting.
Well, if along with that there are there's a license with regard to Terms of Use, including drill works, then you start to get to that point. In other words, that's enforcement ends up being, you know, going to courts, as opposed to a technical technical enforcement,
which gets back to the recently, the recent court case between Google and Oracle. Exactly, I think that specifically that specific type of implementation makes suing somebody over a forked implementation of an API, tenuous at best. You have to have some pretty deep pockets to be able to want to do that, because it's definitely going back to the the Supreme Court and us in
these cases, you know, taking things to court, it is a it's a deterrent. But ultimately, if you've got enough money, if there's a big enough difference in the in the, the two sides of the of the case that side that's got the most money is going to end up willing or willing to spend, no more money on it is probably going to win. Well, it's just
the opposite of us. Breeding ecosystems and markets where we have an actual civil as this is the opposite of the civil challenges. We're so moving so fast as the opposite of civilization technology, where we have places where people can collaborate and build together. We didn't talk about this, but standards are aren't really owned. Part of the reason why the government actually helpful to have the government involved is it's the community asset when the government enforced as a standard, or one of these bodies.
Yeah, the whole point is for the common wheel. Yeah. Yeah.
Well, I was not only did my head explode when I heard about this, but it was kind of like, why. And really, what they came down to was, they felt that too many people were taking the use of an API so far afield that they were actually losing money on it. So rather than, you know, get the money back in some way, shape, or form in a more conventional ways. They decided, well, we'll put it up as an as an NFT. Let people bid on it. And you know, if it's a community of people find, they don't really care. And I don't know that this is actually legal to do. But
this is, what's the name of this company? I'd be really interested to look into this more.
I can't tell you because of NDA. But I can tell you. He put it this way. Insofar as I know, it is it was the original idea of one of the big exchanges in the Bitcoin field. Okay. It's not an Aetherium company Association, where they were looking at it and they decided that as an exchange, they would really use this as, as a value add and give content creators, anybody who goes after copyright or design patent. Or rather than industrial design, as opposed to patent, a means to archivally regulate the use of their intellectual capital and property. And I thought, well, more power to you for being creative about it. But Jesus, I can't imagine how you're going to create a developer community.
Yeah, I find it interesting limiting thing that they chose to go with NF T's versus smart contracts.
I think they're going to evolve it into a smart contract. But I think what they're trying to do is test the waters to see if this gives them more capability than copyright might or licensing might to prevent people from knocking it off. I can also tell you that the reason that they're doing this is because of rampant tax security, etc, etc. And they're more like a layer three, that a layer one. If you understand that terminology, Shawn, I'm not sure
Yeah. Well, it points for creativity. So it's, you know, certainly, certainly in the crypto space being the most creative wins you adherence, a lot of cases. So it's still the idea
of using it as a, you know, DIY copyright. The replacement is, is is interesting, but, you know, the terms of use that go along with that NFT, you know, can span, you know, the full spectrum, everything, to your point of, it's open to the public, and, you know, everybody can use it, because that's the, this is the way we, you know, we set it up to, you know, what happens with derivative works, what happens with consolidations, all add new modifications, and so forth. So, you know, it's, it's kind of, I've got a new, I've got a new weapon, or new Cajon, here, the point at which I start to use it on on the community is not defined at all. So it's a, it's a, it's a work around copyright, which arguably, has needed a revamp for a long time. So
I'm actually wondering, go ahead. No, no, go ahead. I was saying like, I, from what we've discussed, I can see how the NF T's or the use of NF T's would prefer would benefit the consumers of the API's, again, like making the X strike transferable? And so on. I kept rocking, trying to wrap my brain around, like, what? How would the would the API provided benefits? Right? And the only thing I can think of right now is sidestepping payment processor locking. Because, yes, because then you're you're not limited to the jurisdictions that the payment processor serves. You can, you can, via the blockchain, do funds transfer from any jurisdiction to any jurisdiction. Right. So it can increase. It can increase your user base, without significantly increasing your cost of doing of providing the service.
It's gasless.
I don't know at last statement, yeah. Yeah. I mean, you can do the transfer without going through conventional means. The problem is at the at, at ie ingress and egress you've got the exchanges that are going to be charging you for anything and everything in there.
If you don't need to go through the exchange, you've shifted the
business models to a different different point in the in the light in the in the path.
If you're doing transfers on on the blockchain or payments on the blockchain, you don't need to go to the exchange and exchange a service. But okay, so So longer later on when when you're converting your your your crypto funds to fiat cash, yes, then then there is a cost but
I think that have they're going into total cost of operation kinds of considerations.
But I can tell you from firsthand experience in the field, that it is viable that there are companies that take payments only in crypto aren't they do no wars? I thought done one stop that. Do it only see it? Yeah. Okay.
Well, until Bitcoin keeps dropping like it is right now.
thing though, like that, until you actually
have a real currency instead of an investment asset that that will
hold me Well, unless you happen to live in Ecuador, which I'll tell you the other 10 countries that are central banks are issuing their own digital currency though no
currencies and cryptocurrencies and two different things.
No, no, I don't disagree. I'm just saying In digital currency terms, if it's a central bank that chooses to do it the it's a different story
with you all the way there to deny that a Bitcoin? No. Folks, I'm sorry, I gotta run. But
yeah, we take over this was spirited, not expected direction thank you for bringing in that API NFT thing we will bring it back up in the future. Excellent. Thanks for sharing guys happy New Year. Happy New Year.
Wow, this discussion and it's a theme for us of standardization and the evolution of standardization in cloud technology is a critical topic. And we keep uncovering new and interesting ways in which that technology will emerge. But there's clearly forces that are pulling apart rather than together in some of these instances. And how that will get resolved is going to be fascinating to watch. Keep joining us, you can come and add your voice into these discussions at the 2030 cloud. We'd love to have you in and participate or just listening live as we have these fantastic roundtable conversations. I'll see you there. Thank you for listening to the cloud 2030 podcast. It is sponsored by RAC in where we are 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 laying out your thoughts and how you see the future unfolding. All part of building a better infrastructure operations community. Thank you