Utilizing Tech - Season 7: AI Data Infrastructure Presented by Solidigm - 05x18: Orchestration and Connectivity at the Edge

Episode Date: September 4, 2023

Computing and sensors have been deployed at the edge for decades, and this is certainly true in the agriculture sector. This episode of Utilizing Edge features Edge Field Day delegates Ben Young and Alastair Cooke discussing with Stephen Foskett the evolution of connectivity and orchestration at the edge. Governmental policies can have a huge impact on the deployment of technology, from connectivity to environmental regulations, as has the emergence of inexpensive sensors, batteries, and processors thanks to the mobile phone industry, along with solar power. Cloud-inspired automation and orchestration is another key enabler of technology in agriculture and at the edge, with zero-touch provisioning, management, and central maintenance. Containerized applications, caching, and cloud-derived control planes are very popular at the edge, though not exactly the same way as in the cloud. Hosts: Stephen Foskett: https://www.twitter.com/SFoskett Alastair Cooke: https://www.twitter.com/DemitasseNZ  Guest: Ben Young: https://www.twitter.com/BenYoungNZ Follow Gestalt IT and Utilizing Tech Website: https://www.GestaltIT.com/ Utilizing Tech: https://www.UtilizingTech.com/ Twitter: https://www.twitter.com/GestaltIT Twitter: https://www.twitter.com/UtilizingTech LinkedIn: https://www.linkedin.com/company/Gestalt-IT Tags: #Orchestration, #Edge, #UtilizingEdge,

Welcome to Utilizing Tech, the podcast about emerging technology from Gestalt IT. This season of Utilizing Tech focuses on edge computing, which demands a new approach to compute, storage, networking, and more. I'm your host, Stephen Foskett, organizer of Tech Field Day and publisher of Gestalt IT. Joining me today as my co-host is Mr. Alistair Cook. Welcome to the show, Al. Thanks, Stephen. It's good to be back on the show again. I'm an IT analyst and now an IT hands-on engineer, as well as writing about this technology for a while. Stephen, we're going to head straight into talking about my fellow countryman.

I believe you'll introduce him now. You're absolutely right, Alistair. Joining us is a fellow Edge Field Day delegate, Mr. Ben Young. Welcome, Ben. Good morning. How are we all going? Thanks for having me. Excited to be here. So you guys got talking last time at Edge Field Day about how this whole world has changed so much. You have a lot of experience in an area of Edge that we've kind of hinted at, but I don't think we've talked too much about, and that is agriculture. Ben, tell us a little bit about that. Yeah, it's funny. Earlier in the year, me and Alistair got talking offline at Edgefield and it turned out that around the same time,

sort of 15 odd years ago, we were both working for an agricultural company in New Zealand, different ones. We've got two main fertiliser companies here in New Zealand and I was working for one and Alistair was working for the other. And these businesses you would think would be relatively simple given they make fertiliser and farmers put them on the paddock but it couldn't be further from the truth um they had uh spreading facilities which means they've either got trucks running around in paddocks with differential gps to prove where the fertilizer went uh they've got branches or stores where the product is held which is all throughout new zealand um know, they've got planes and helicopters. I'm not sure about Alistair's company, but I know ours.

We certainly had Edgers in Australia. We bought a couple of companies over there, and that's a huge country, all the way even over in Perth, so very, very far from where we were. So, yeah, these organizations were, yeah, very spread out, lots of edge, lots of tech to prove where things went, health and safety, those sorts of things. And yeah, I mean, back then it was a matter of getting whatever it was, whatever edge device or solution into the IT office.

We would install things on it and configure it up and then send it out the door, which was obviously very time consuming but then the other challenges that we were really facing back then was connectivity i mean 4g and 5g certainly didn't exist satellite internet was very expensive and very very slow and and potentially not even fit for purpose fiber certainly wasn't rolled out so all these sort of things made it very difficult but also limited kind of the scope of what we could do could do out there and then I guess you fast forward to today and things are I'm not going to say completely different but you know the

connectivity is there we've got more options for that but also sensors are smarter they're lower power they're doing more but equally we're capturing more data on the edge so that's that's kind of I guess what we're sort of talking about here today and I'm sure Alistair's got sort of similar stories of things about that what sort of things were you dealing with back then Alistair? So going back probably 20 years for me I was more looking at new technology that we could could implement for the local fertilizer company here. And so they had some really cool technology. They had front-end loaders that had strain gauges in them

to identify how much fertilizer was being loaded at a time. And so they could very closely track how much fertilizer was being loaded. But then it became a paper process. And so I was involved in a project to put some sort of computer on those front-end loaders with connectivity and a user interface on it, those kinds of things. And this is something that we were doing 20 years ago with very rudimentary tech that probably wasn't really ready for it, wasn't quite fit for the purpose it was doing. And we had the luxury of being actually in the manufacturing facility, which had fairly

strong Wi-Fi. And so we didn't have so much challenge of that last mile hop. But things have definitely moved on. I think you're right in terms of one of the big enablers here in New Zealand for the adoption of agritech is that the successive governments have continued to support an effort to bring high-speed broadband to everybody living in the country, at least 90-odd percent of people living in the country. So fibre if you're in a metro area, and wireless if you're out in somewhere rural. And that, I think, has been really transformative for our agri-tech industry.

And it's also driven by the government's ideas that generating more knowledge, working in a more high-tech industry. And it's also driven by the government's ideas that generating more knowledge, working in a more high-tech way is really important for New Zealand's success. And again, successive governments have carried on with that. And I think, Stephen, your experience of the sort of adoption,

your view of the adoption of tech within the agriculture industry in the US is a little different from New Zealand's. Yeah, it's interesting. I don't live in Silicon Valley. I live in the heartland. I live in Ohio, which is a big agricultural state. We actually have some pretty large farms around here and a lot of technology. Also, a lot of not technology, too. There's a lot of Amish in Ohio, offline conversation unrelated to this. But it's interesting. In the U.S., the government has not

been as aggressively pushing forward connectivity, especially in this area. I mean, there certainly are initiatives here to connect schools and businesses. But in terms of wireless technology, especially, it's really left up to the industry. Now, I know that the government has been trying to encourage better and better wireless connectivity, 4G and 5G connectivity. The government has also, you know, here is very closely controlling spectrum auctions and forcing companies to deploy or, you know, encouraging slash forcing companies to deploy better coverage. is not quite as vast as Kansas or something like that. But even here, where we have pretty good 5G coverage, once you get out into the fields, there's very, very little. And it's very challenging here. I was just hearing a story on the news the other day about the fact that less than half of American farmers have implemented any kind of agriculture technology, precision ag tech. And it mainly comes down to two factors. One is the availability of connectivity. And the second

is the age of these farmers, since a lot of American farmers are getting older and aren't all that interested in technology. So it sounds like a very different situation, even though, you know, we're talking about very similar sectors. And also the thing that gets me is we're talking about an area where technology can have a huge impact. They were saying that, you know, crop yields, they're talking double digit percentage improvements, sometimes, you know, even, you know, factors of two kind of performance in terms of the benefits of this technology. And yet it's not widely used here. Yeah, interesting you said. So I know New Zealand is highly regulated in terms of, especially from an environmental standpoint.

Every other day there's a news story about, you know, farmers putting something they shouldn't in a river and now dogs can't swim in it or whatever it is is that the same over there because i suppose that presents a whole set of new challenges all of a sudden we've got devices having to capture data around where a product is going or being sprayed on a field or whatever it might be versus say telemetry going back in real time or near real time so what does the environmental thing do you know about that over there do you have the same kind of requirements from a farmer telemetry going back in real time or near real time. So what does the environmental thing, do you know about that over there? Do you have the same kind of requirements from a farmer to be able to record what went on where and with what level of detail? I don't know about the specific requirements on farmers, but I know that the U.S. generally, and Ohio specifically, has

become very focused on this issue. One factor is we have one of the Great Lakes here, and agricultural runoff is causing all sorts of problems with algae blooms. And so they're trying to get a handle on this. Also, you may know of the U.S. EPA and the Clean Water Act. Well, all that actually came from right over there, the Cuyahoga River that caught on fire 12 times in the 1960s and was a cover story in the newspapers. That's why we have the environmental regulations we have. But that being said, according to the things that I've seen, it's not quite like that where the farmers have to record and report. I think they're encouraging them to be more careful with fertilizer, but I don't know that it's actually working.

Right, yeah, it's quite different to here. We have to prove with very good accuracy, so much so that I know that this was back then, so it's probably moved on since then too. The spreading trucks were quite clever. They knew the fertilizer that was in the bin basically goes through a little auger and then it's kind of got this thing that spins around on the back and it

fires the fertilizer left and right out the back of the truck and depending on the settings there so we had a computer inside the cab that was recording the speed of the fan what product was being spread and it had differential gps on the truck so it knew where it was driving in the paddock with very high level like sub meter i think or sub half meter accuracy and it knew what product was going on and therefore based on the fan speed how far the product was going left and right of the vehicle and then we were dragging all this data back in and we had a company create a mapping software for us. So we could see exactly where it drove in the paddock.

And then sort of outside of that, you could see exactly where the product went. So at any point in time, if they were ever audited or I guess the farmer wanted to check up to make sure the spreading was actually done in an accurate way, they could go and see on that map and we had all those those public records well those records for the farmer against their farm which also then serves a historic record too if i guess as farms move on or change hands you can see exactly what went on when which is yeah a big part of the the legal requirements of running farm here in sprays is is um you know has very similar regulations i'm just not 100 sure of them yeah and one of the other things that's happened over the the time period in between our early experience in the current day is the proliferation of sensors around farms as well and so a lot of

the farms will have water flow sensors temperature sensors ground moisture sensors in all of the paddocks and in order to measure the conditions for growth because essentially if you're growing a cow you first have to grow grass and so even the agriculture is really a horticulture business and so all of the instrumentation for that has really taken off over the last few years with radio systems like LoRa or Sigfox allowing very low power sensor devices, potentially solar powered, to be sending a lot of information back. And so a single farm has definitely become the sort of sensor network and edge environment that we think of for a larger organization.

But of course, the single farm doesn't want to manage all of this. They want to have somebody else, and Ben's example, the fertilizer company, holding and running the platform for this. So in some ways, it's that each of these edge locations is a client to a more central, usually cloud location. And that seems to be a pattern we see quite often in Edge of this small repeatable unit that then does something locally but sends data back for further analysis. That, of course, assumes that we've got connectivity, as we've discussed, but it also means that

there's a need for automation of that deployment. And I think, Ben, one of the big things that we've seen change is that move towards platforms and automation alongside the improvements in the connectivity yeah totally I mean I was really excited at Edgefield Day early this year when we had people like Avasa talking about you know shipping well they obviously don't do the hardware side of things but being able to orchestrate these edges when they get deployed so you've got people say like scale computing be able to orchestrate these edges when they get deployed. So you've got people who say like scale computing, be able to ship hardware or stacks of hardware directly to site. So it's not having to come back to that central IT office.

We're not having to configure things there before it goes out. It can go out there, comes online, assuming it's got connectivity, then an automation or an orchestration platform can go, hang on, well, I know who you are. I know what persona you are. I know where you are in the world, whatever it it might be whatever you've tagged that device with and then it can push down that software stack that you've defined centrally and hold centrally which is great for deployment obviously um speeds things up we're not shipping things around the country it's obviously got an environmental benefit too depending on what you're shipping around but also for that ongoing

maintenance you know i look back to where we where we would have to send people out to site to upgrade these once a year or twice a year or whatever cadence these things were on. So having that connectivity in place and that automation in place, the platform to do so, means that all those updates, all that update our software packages centrally and have them push out, which means we can probably do updates more often, which is more beneficial to the organization rather than going, well, it takes us a week and $10,000 every time we update this edge, which probably means you're not going to do it every month, are you? So yeah, I think orchestration is key to this whole thing, being able to control these edges in an automated way. Certainly when you get scale, sure, if you've got one or two edges and they're not too far away from you, then, yeah, maybe it's not worth investing completely in orchestration or going the whole hog.

I definitely believe there's a level of orchestration that every organization should achieve. But, yeah, once you get to that scale or once you get that remoteness, so things are a helicopter flight away on an island or whatever it might be, or you've got thousands of them or hundreds of them, then orchestration really is a need, not something you can kind of just go, oh, well, we'll sort it out later, I believe. Yeah, and that ship things to site and have them auto-configure seems to be a very consistent theme through a bunch of vendors. I believe. Yeah and that ship things to site and have them auto configure seems

to be a very consistent theme through a bunch of vendors we saw it with NodeWeaver we see it with HiveCell and with Zadida as another presenter so yeah that really is a consistent element of deploying out to thousands of sites. Yes Zadida is a good one too especially I mean their device like obviously for each stack scale's really good for things like at offices or branches or stores or whatever that might be. But those Zededa devices, because they've got such an array of them, and I don't know how you felt about it, when they started presenting them,

I was like, oh, my God, these are the sorts of devices, these hardened devices we were trying to stick in trucks on the end of loaders, like you say um under the bench somewhere and or even in the fertilizer store um and i'm sure you come across this fertilizer is incredibly corrosive so just having a normal pc in there with a fan that's dragging through all the fertilizer dust they would literally corrode within a month if you hadn't had them formally coated so these hardened devices that can deal with these harsh conditions. And then you've got things like on planes and helicopters and trucks

and being shaken around everywhere. So, yeah, absolutely. Yeah, Zadida's devices and their range of devices that they're able to ship directly to site and have that orchestration platform kind of available for or to be accessible anyway by their APIs, I think is fantastic. Yeah, it is really interesting to kind of hit on this. Almost every episode we hit on this, when it comes to Edge, the differentiator is not

the technology, it's the use case, it's the scale. You know, Ben, what you just said about remoteness, about the number of nodes, about intermittent connectivity and unreliable bandwidth. These are the things that we've been hitting on all season long. And it's really amazing to think that there is much connection at all between, I don't know, a quick serve restaurant and an oil rig and a farm, but there is. And it's the same thing that we keep hitting, that you reach a point where these factors conspire against you and you simply cannot manage things on a one-off basis. Everything has to be completely integrated, automated, zero touch. It's just amazing. And that I think is the essential characteristic of the edge.

And it gets to this whole question of orchestration. So this is something I think that we could talk about for a long time, but tell us a little bit more. What is your definition of orchestration and how do you know it when you see it? Yeah, I mean, my definition of orchestration is really just automating in a repeatable way, like a deployment of some description or changing, modifying something at the other end in an automated repeatable way, which obviously has a number of upsides and benefits. We know the stack's the same. We know what version it's running. It's more secure. Someone can't accidentally forget to tick the enable TPM or whatever it is. So being able to orchestrate that um yeah i think that means that uh well

let's reverse that i think good deployments will show like good maturity within it departments a well-orchestrated environment will just mean that the it department actually has more time on their hands to actually deal with not firefighting in these little deployments and actually deal with the work and project these little deployments and actually deal with the work and project and enhancing things and moving other things forward in their organization if that makes sense i mean i'll start i don't know what do you what do you think around kind of orchestration like what would be a good example if you walked into a company right now and said show me your stack what would you know about them and how would you feel?

So for me, one of the key things is that stack maps back to business requirements and business value. This is where orchestration for me is about getting away from, to use AWS's term, the undifferentiated heavy lifting doing the hard thing right you make the hard thing easy to do and you can focus on something that's not just this this daily grind and so i think it's beyond simply saying we can automate a build we can deploy out an application but more that we can satisfy the business requirements so that we can get the agility the ability to innovate that's required for business. Some businesses are more innovative than others, but not being the department of no, the department that says, no, we can't do that, it's going to take us too long, being the people who become an enabler for the business. And that does require that we get away

from updating BIOS manually on every machine or updating operating systems, that we can treat our sites, our locations as a population and deal with them as a population and say, everything should be at this configuration. So declarative configurations and dealing with policy-based management as well, rather than having to look at every individual item and say, did this work? Did this not work? You look at a policy and say, did this work, did this not work? You look at a policy and say, are we compliant, are we non-compliant, whether it's a backup policy, a security policy, a policy that drives the version of application that's deployed

at which sites, a policy that defines whether a particular site needs to be compliant with maybe German data privacy regulations. Having the ability to see that as a set of policies and say, well, are all of our environments compliant with all of our local geographically relevant and globally relevant security policies? These are the kinds of things that, to me, indicate a good, well-orchestrated environment. Yeah, certainly makes it easy. Like, IT teams are already stretched, right? They're already trying to do more and more.

And like I say, with the proliferation of more tech, it only gets worse. And without having to scale those IT teams, then orchestration really takes that heavy lifting out of the organization, which benefits everyone. Like you say, you don't want to be the department of no, but we've all been there when someone's just going, hey, I need this thing next week.

You're like, well, I've got 300 laptops to roll out like when when am i going to find time to do this and there's a hard deadline on that so yeah i think you're right a well-orchestrated environment just makes it departments or organizations just more efficient it takes that that automated repeatable work out of uh sorry that that work that just needs to be repeated over and over over again out of the sorry, that work that just needs to be repeated over and over, over again, out of the organization, which lets them focus on more important things. Yeah, was my sort of opinion on it. What do you reckon, Stephen? Yeah, that's another interesting point, too. In terms of defining the edge,

another factor that has come up again and again is what you just said, which is unlike the data center where IT exists. There are people who care about this for its own sake. At the edge, there isn't. It's simply another tool. It's a utility, a resource that needs to be running in order to make the real work happen. And there aren't people who need to care about this stuff or want to care about this stuff. And I think, again, that's another factor that we need to keep in mind and another reason that we need to have good automation and orchestration.

It seems interesting, too, that a lot of the technologies that are enabling this type of orchestration come from the cloud. Because there again, you know, we have remote devices that we can't really be hands-on with. And so we need to figure out ways of deploying software in a repeatable and structured fashion, and we need to have automation. So, you know, we got to do it. Let's talk about Kubernetes on tractors. How does this, how does the cloud and cloud technology work here?

I'm not even, like, coming back to that Kubernetes thing, like, it doesn't even need to be Kubernetes, right? Like, I think it was Avasa who actually, I think, said they actually moved away from Kubernetes just because they actually couldn't get that cluster to do what they want. I mean, I'm all for Kubernetes, and I love the engine. I love the orchestration ability and, you know,

the scale that you can reach for these things, but it's certainly not the answer for everything. We've been automating and orchestrating things for a very long time. I think the tooling, like you say, has got better and they're now cloud delivered services and SaaS platforms, which I think has a benefit. It's yet another platform that organizations don't need to run and manage. Rewind 15, 20 years ago, these platforms didn't exist. So you would go and find a vendor to buy this software that maybe did this level of orchestration, and you would install it and run it on-premise and present it to the internet, and someone managed all the firewalls and the security and things around it.

But being able to buy something off the shelf now, if your organization will allow it, it has massive benefits. And it also has that resiliency because if it's in a cloud, hopefully that SaaS provider has got their services delivering in a high available fashion across multiple regions or for performance purposes. They might be at that global scale where you might have operations in Europe and the US and down here in little old New Zealand. And having even the software delivered out in CDNs at those locations and making sure that that platform's up means that you can rely on all those edge sites being orchestrated without having to worry about

a single point of failure, say, back at your head office or wherever your own data center, where this engine might be installed. So I think, yeah, the cloud has a big part to play in making sure that these edges are also resilient and can be orchestrated and monitored is a big part of it. But I think there is a huge differentiation between having a control plane in the cloud and using cloud technologies out at your edge location. That, as you alluded to, that Kubernetes is awesome,

but it may not be the solution for your edge problems because of the amount of infrastructure that's needed to run that Kubernetes cluster. And so although we use a lot of cloud-like technologies at the edge, there's also a huge amount of limitations at the edge that just aren't present in the cloud. You treat the cloud as a near infinite pool of resource and just draw out what you want,

or you have a very, very finite amount of resource at your edge location. And so although we're using a lot of the same tools and techniques, there is that difference in architecture. And I think we're seeing lots of vendors coming in with tools that help us manage that difference in architecture. And I think we're seeing lots of vendors coming in with tools that help us manage that difference in architecture and not have to get too caught up in the weeds of the details, let them manage the details of that limitation at site.

And all of the vendors we've talked to have had that idea of providing some level of abstraction from the underlying hardware. Yeah, that was one of the key things. I mean, I'm glad, Ben, that you brought that up about Avasa, for example, because we had that whole conversation with them. Yeah, I think the idea would be that Kubernetes is more of a tightly coupled control plane and that it wants to be able to continually contact the nodes, which is one reason that sometimes that technology isn't used at the

edge. And if it is, it's used differently. You know, as we talked with Brian Chambers about the way that they're using Kubernetes in their quick serve restaurants, it's more about specifying system resources and packaging and deploying applications. Not so much about the cloudy things that we do, like load balancing and scaling. And a lot of that dynamic stuff just isn't as relevant. Maybe we need, instead of a navigator metaphor, we need a tractor driver metaphor to come up with some alternative way

of deploying containerized applications and managing containerized applications instead of that. That's sort of the captain is in charge kind of attitude of Kubernetes instead of as opposed to more of a swarm approach. If only there was a company that had a product that managed containers in a swarm. I don't know if that existed. You know, the metaphor to use will be a cattle dog because it's under remote command from the shepherd. And it's marshalling these sheep that are a little unruly and that you want to deal with as a flock rather than as individuals so there we go what's greek for cattle dock i'm looking that up right now i'm looking that up i reckon we will i'm sure it probably already exists i bet you like john deere or some really big agricultural machinery provider has already

got kubernetes of some form in a tractor and even though it might not be presented that way i imagine the way that they can get that repeatability and the software running in the tractor or harvester or whatever it might be i wouldn't mind being there's already a yeah a big piece of machinery that's running kubernetes out there i'd love to know about it it's uh yeah pretty neat i mean even you know like i look at what we're even receiving in the data center these days around pure storage arrays and things all of their underlying software we don't have we can even receiving in the data center these days around pure storage arrays and things, all of their underlying software. We can't get to the Kubernetes cluster that's running in it, but there's a Kubernetes cluster running and it's running their stack, their monitoring, all their bits runs now on a Kubernetes cluster within the array itself. But we don't have to present a Kubernetes cluster to run our array, if that makes sense.

So I've no doubt that it's there um it's just not a it's not you know it's not the only option out there and i think i've also really had that on the head and and even some of the other organizations around just installing um like scale had a really good demo around yes they they deployed from template like that was cool like like what most people are probably doing today, deploying from some form of OBF-type build or mounting an ISO and then having a scripted build run out with some of the other orchestration tools,

Ansibles and other bits like that. So, yeah, I think you just need to work out what's fit for purpose. We don't need to kind of just put Kubernetes and all these really big advanced tool sets in just because we want a little bit of orchestration. we don't need to kind of just put Kubernetes in or all these really big advanced tool sets in just because we want a little bit of orchestration. If we only spin up one or two things and we don't need to have it on multiple nodes,

then what's the point in putting Kubernetes in? If you still want that container-like experience, you could just orchestrate even like a Docker Compose file or something if you want to abstract that hardware. And then if it can be installed on a computer, then why not just use something like Ansible to get that piece of software on there? And so I think, yeah,

having the ability to balance out what you need, but being able to centrally control that. So probably a good mark for choosing an orchestration tool or tools would be something that can drive multiple products rather than just, well, we only deploy to Kubernetes clusters at the edge. Probably not going to be a good fit unless all of your edges happen to look the same and you're running a three-node stack or a two-node stack or whatever it might be out

on that edge. So something with a bit of flexibility would be something to look out for in a platform. And increasingly, we shouldn't be caring what's inside that platform, whether it is Kubernetes that the platform uses. This is to the point of the tractor or whatever machinery with a Kubernetes cluster inside. We shouldn't care as the user of that platform and maybe care about the containers that are being shipped out, application code, but spend less time caring about the infrastructure that's used to deliver it. That's, I think, one of the really big things about this platform, is move in edge platforms.

Yeah, absolutely. And that gets back to that whole concept of it's not about NUCs, it's about DUCs, disposable units of compute. You know, basically, the computer isn't the important thing. The important thing is what you're doing with it and keeping that in mind too. It's kind of that pets versus cattle argument except taken to an extreme.

Definitely. I mean, even like the security thing that you look at the data, they would talk about security a lot, like to the point that you can configure every USB port and mount this out and change all of these things and the underlying encryption they would talk about security a lot, like to the point that you can configure every USB port and, you know, mount this out and change all of these things and the underlying encryption at the operating system layers, any data written to it, because we can't take it for granted that, A, this thing's not going to get stolen

or crushed by another loader or put between some hydraulic rams somewhere by accident or whatever. So the security of these devices are critical. So being able to configure that remotely, too, and make sure that those things are locked down and and compliant i think alistair you hit on that compliance standpoint certainly if your organization has any form of standard that they're trying to achieve quality or otherwise that may have some security or you know aspect to it then being able to prove to an auditor that you're compliant and the only way we deploy something down to these edges is with this piece of tool and it's got the steps in place to make sure that all of these security, you know, policies are applied in an

appropriate manner, I think has huge benefits because otherwise you're going to have to make sure that you've got manual processes in place for, IT rep or someone to log into these devices on regular basis and record that, yes, it is still off or on or whatever it might be. So I think that's definitely a huge one. certification here in New Zealand for our organization, that record keeping, that ability to orchestrate and prove that something is set or otherwise is a really big part of what forms the controls for our certification. So as we're getting to the end here, I think that it's been a fascinating discussion because we can see the parallels between or the surprising parallels between tractors and fertilizers and cows and factories and restaurants. Al, what's your prognosis here? How can the world of agriculture technology and the demands of that edge inform

the rest of the edge? Well, I think we've come to the conclusion that the world needs a sheepdog and that your edge location needs something that's going to control the running applications across the plethora of edge locations that you'll have. So pervasive connectivity, good orchestration, these things are absolutely vital for us. And we really want these platforms to disappear under our applications and to not be our problem, which is bring in some of that cloudiness. Of course, if we're talking about tractors right to repair, you've got to own it yourself and be able to control it, but you really don't want to have to. You want it to

operate for itself. Yeah, I mean mean i mirror all those those things that connectivity and the orchestrations are must um i think probably what the agricultural sector and probably some other very similarly aligned sectors would have to teach the rest is not all edges have to look the same and i think the agricultural industry is a really good example of that where we might have a branch store with some normal normal compute in it with you know windows or linux servers running in them but then we might have like you say a raspberry pi type powered device that's running whatever on it that's got a crazy sensor attached to the end of something or something in a plane or a helicopter in these harsh environments so being able to um yeah support

a number of types of devices depending on the use case rather than saying well our company's got these two edges we can deploy so if it doesn't fit in the loader or the helicopter then we can't do it and then on top of that making sure that your orchestration engine can support those different types of devices, I think, really kind of closes the loop on all of that. And then really the world's your oyster at that point, because all of a sudden we can deploy normal things and we can deploy really weird little cool things, which I think is where all the cool stuff is. It's the temperature sensor off the thing.

And then we can start collecting that data back and doing really neat kind of predictive analysis or maintenance tasks and things on them. And I think that's where we're going to see more sensors going on more devices over time. And, yeah, agriculture is high tech. As much as it looks like some farmers driving around a paddock, digging up things and putting things in the ground, there is a lot of technology that surrounds this industry. And they've got a lot to teach the rest of the world and a lot of other industries about how to run things, what to capture and what can be done.

Yeah, I think that's been very, very evident from all the different verticals that we've talked about, you know, from media and entertainment. Oh, it's just about the actors and the directors and stuff. No, there's a lot of technology and the demands that the technology puts on us. And also the things that are enabled by new sensors, batteries, solar, all of these things that we've got, cloud technology.

It really is fascinating. Well, thank you so much for this conversation. Before we go, Ben, where can we connect with you and continue this conversation? Yeah, you can find me on Twitter, X, Twitter, X, one of them, whatever. I think both work, benyoungnz, or my blog at benyoung.blog. So yeah, reach out anytime. Always happen to have a chat about anything, anything really. Mountain bikes, tech, you name it. Food, smoking meat, you name it. And you can find me, Alistair Cook, is at demitasnz. Again, demitas.co.nz is my local blog

site. And you'll find me out and about with the V Brown Bag crew and the occasional Tech Field Day event as well. And it should be easy to find me. You can find me on Google so long as you don't find that cricketer guy. So put something, my name and something technology related. And as for me, you'll find me here on Utilizing Tech, also on our weekly on-premise IT podcast and our weekly Gisht Alt IT rundown tech news show.

So thanks for joining us for Utilizing Edge, part of the Utilizing Tech podcast series. If you enjoyed the discussion, do give us a subscription. You'll find us in your favorite podcast applications. You can also find us on YouTube at YouTube slash Gestalt IT video. This podcast is brought to you by GestaltIT.com, your home for IT coverage from across the enterprise. For show notes and more episodes, though, head over to our dedicated website, utilizingtech.com, or find us on Twitter and Mastodon at Utilizing Tech. Thanks for joining us, and we will see you next week.