Machine Learning Made Simple

Fantastic. It was great to see Woz talking about AI earlier, wasn't it? I wasn't really expecting him to start talking about self-driving cars. Definitely not in the way he was. I think it's also been a really common theme we've been talking about today around the kind of cloud value proposition and what we've been doing.

I think what's been really interesting is like the conversations around proprietary tooling, the different types of technology that's been going on and what's been happening alongside that. I think one of the things that really seemed quite concurrent across the discussions that we were having there is machine learning and artificial intelligence is complicated, and actually one of the reasons we're really struggling to adopt it is actually it's hard for us to try and embrace, understand, and get a hold of, and that causes a large degree of failure that becomes intimidating and has reasons why people can't quite grasp the concepts.

One of the things I'm trying to get across today is actually the reasons why that is. Start to help share some of the expertise that I have behind it for what it is, and then hopefully give you guys some of the positioning Civo has to try and break this down a lot further. That's perfect for the AV guy trying his hardest. That's fantastic. Thank you very much. There we go.

I've recently joined Civo. I've joined as Chief Innovation Officer and actually I've got a long background with machine learning. I just recently moved over from AstraZeneca where I took responsibility for leading their machine learning platform strategy. The goal there, trying to make sure that we could consistently engineer products in the same way in a supportable framework, but then also help scientists and doctors start to jump into that machine learning space outside that traditional software engineering skill set.

I've launched 300 machine learning projects over the last 2.5 years, and I spent an awful lot of that time trying to make sure that I can try and get to an easy to maintain landscape where the value was really clearly defined. Alongside that, I've made contributions back to the machine learning space through AWS's machine learning certification, and actually I wrote their first exam, their course material, and some of the machine learning positioning frameworks for their use cases on their platform.

I think one of the things I'm most proud of in my career is actually being able to implement some of the machine learning into the Covid vaccine trial. I was lucky enough to win a clinical award even though I'm not a clinician in that space, and really show people that machine learning can be useful, and partnering with domain expertise is a really powerful way to achieve that.

I think the most important part is I've spent eight years battling with machine learning tools, and I've done that across all the major hyperscalers, and I think that there's learnings across all of them, and everyone does it slightly differently. What we were trying to do today is actually try and look at how we can do it yet again in a different way that brings alignment across what we're doing as an industry.

So, quick show of hands. Put your hands up if you agree with the statement that 74% of executives anticipate machine learning will deliver more efficient business processes. Okay. I think that's the majority of the room. I think we'd probably all agree that machine learning is creating new projects alongside that.

I think keep your hands up if you agree. If you can for a second, and I think I put your hands up again, if you didn't know that 85% of machine learning projects fail. 85%

Now I think everyone sees it as a complex area. Everyone sees it as difficult to jump into. I think what most people don't understand is the majority of people doing it are unsuccessful, and that's a factor that changes the way that we think about a problem. It actually makes it quite esoteric. You put it on the far side of expertise, you start to think about can you be done by the super hyper intelligent people that have been positioned inside that space? Start to think you need a PhD to be able to grapple with the problem.

Alongside that, over 50% of machine learning never makes it to production. Ends up being an experiment, a development activity, something you kind of do on the side of the desk.

Now, failing to deliver can mean a lot of different things. It can mean you never really got the outcome you were looking for. You wasted all your budget. You annoyed your project manager enough that they gave up on the project and folded it all back. But I think the main thing to take away is that machine learning has a lot of common pitfalls, a lot of places where you can take one step and fall off the cliff.

Some of that is esoteric knowledge, things that you really need to understand to be successful. I think a lot of that is complex skills, but actually I think the piece that I'm trying to address today is actually how diverse those ranges of skills are.

Now, who's seen this diagram before? Okay. I think this gets presented to death. I think you can't have a conversation about machine learning effort estimation without referencing Google's Scully diagram. And that little tiny box in the middle of the diagram that we're all looking at is the part that most people would stereotypically refer to as machine learning engineering.

There's this common misconception that in every machine learning project, a machine learning engineer just grapples with their problem in a perfectly engineered situation. All their data in a database, perfectly wrangled. They don't have to install any drivers for their GPU. All their features are perfectly aligned to exactly the outcome they've got.

And I think the reality of the situation, we know that's not, and that's the reason why people aren't being successful in their efforts to do so. I did some math. I broke this down. I scaled up the problem. And actually, if you start to look at where you're spending your time in machine learning engineering, 60% of that is actually in infrastructure engineering.

You're spinning up a server, you're making sure your Docker container runs. You're trying to position the networking alongside what's happening. You're spending 20% of that doing data engineering. I have spent countless hours of my life writing SQL. I think the truth behind that is it's a necessary evil.

You have to be able to put your data into perspective, and it's a very different type of skillset to setting up your infrastructure. Some of that forms very closely to the skill set of feature engineering, where you've got some data and you take some domain expert's impression on that, and you start to wrangle that data so you can infer some more accuracy about what's going on.

That's only 5% of what you're doing is machine learning engineering. 5% of that is the really difficult skill set everyone's sought after that says it's one of the rarest, most sought after talent gaps in the market right now. People think about this in lots of different paradigms, but what it basically means is that if you're a solopreneur in the machine learning space, you're a T shaped individual.

You're not someone who's a traditional data science PhD, machine learning PhD. These overlaps exist, and I think that as computer science professionals, we love overlapping skill sets. Everyone knows multiple programming languages, different types of technology. You'll see people thinking about a problem from multiple perspectives.

I think the interesting part about that is the mindset the machine learning engineers take is normally actually a mix of mindsets that they've learned about what's effective across disciplines. Breaking it down again, and I'm going to keep throwing infographics at you if you haven't quite realized, is that if you look at what the sub-domains of these types of skill sets end up being is very complex, typically non-overlapping.

You'll see people spend time doing things like data visualization using html css. Just spend time looking at how business analysis is working, trying to measure different aspects of the problem inside the company. I think there's the obvious piece about domain knowledge, right? If you start to think about it, big data management, spinning up your OOP cluster, managing your S3 buckets, spinning up databases, sharding those databases, writing those queries, turning those queries into rest calls.

It pushes you even further out of the traditional mathematics machine learning skill set. The part that a lot of people really think is not needed is the mathematical domain to understand bay's theorem. Why does the machine learning model work in that way? And whilst that's really critical towards the end of scaling your problem, actually it's consistent throughout that you dip in and out of these types of expertise.

And it can't just be something you assign as a single task to a single person in a project. It's something that you need expertise across everything to make sure that you can all lead in the right direction. Zoom in yet again. The challenge we're facing as an industry is that these expertise in an enterprise are common.

You can go find lots of these. You've got 60,000 people workforces. You've got really wide degrees of disciplines across domains. But actually, and that was not an enterprise game anymore. The majority of people adopting machine learning right now are startups. The reason why they're doing that is probably the top right hand corner, which is that 73 machine learning startups last year got a billion dollar valuation.

That's worth chasing after, right? Yeah, yeah. I see some nods. Some people, obviously I don't want a billion dollars. And the adoption for that needs democratization, right? I think some of the points that actually Matt brought up in a really clear way is that you need to be able to make sure that you are.

Building in a way that's scalable and how you work around these different types of skill sets that you don't have as a startup. That combined with the current state of where we are economically, means that everyone's being challenged to do more with less. You don't have the spare budget to hire these three nursing skill sets inside your company.

And what we at Civo think is particularly interesting here is actually all the economies of scale, the part where the cloud promises you, machine learning gets cheap. That's all at scale, right? Starting out, renting a graphics car is an expensive thing for a startup to pick up and start to run with. This huge amount of complexity combined with this scale fast mentality, the skill shortage, people siloing skill sets and saying, I'm just an ML engineer.

People want and demand to work in different ways. And then that itself is made even more difficult by the tools provided. When you start to look at the tools that you are being provided with, they're all doing different things in different ways. Now, the common misconception, and I have strong and long arguments with this for people, is that machine learning doesn't end up in the cloud.

Machine learning ends up on premise, ends up in a co-located center, and the reason for that is because cloud's elastic type of workload that's useful is great for serverless modeling. But if you are gonna scale your machine learning to the point where you've got a hundred thousand people hitting it an hour, you're probably never gonna spin down that server.

You're probably always gonna run it hot. If you are always running it hot, you probably want the ROI behind how you manage that workload. Now the problem here is actually the scaling steps and the entry point towards that scaling. Where it gets difficult to justify is when you start to measure the ROI.

ROI on premise makes a lot of sense. You own it longitudinally. But then is your machine learning model gonna be here for two years? Are you gonna own that server for two years? Are you actually gonna re-engineer your machine learning and think about a different paradigm? GPU accelerates it. I'm gonna buy 64 GPUs, run that, and then suddenly realize that my workload might become more efficient on a CPU tomorrow.

And while it's unlikely, those use cases do happen, and that's a lot of money you've thrown away. The common example I use to put this in a really simple way is kind of big investment banks that spend a billion dollars building a quantified algorithm trading system that unfortunately doesn't have a very successful outcome.

And, and your returns a hundred dollars a month and you're sat there trying to justify it's your hedge fund manager while your ROI is gonna be a hundred pounds a month, you might never pay back some of this investment you've made, extreme but it still is the case.

The really worrying part here is there's actually a good chunk, almost a quartile of people who don't ever deploy to production. Now, if you are concerned about ROI and returning value over a long amount of time, you wanna make sure that value is consistently returned, that you can easily justify it back to what people are doing.

Now, if you don't have a framework around the quality of that, if you're not locking down the environment, your machine learning's running, you're kind of doing what you want. You're probably not gonna guarantee that type of framework. You won't have a standard around it as software engineers will all appreciate that standards make better software.

The last part I think is quite interesting, which is, I don't know, I don't know what I'm doing in production. I don't know what I'm doing with my machine learning, and this isn't these people's fault, right? These tools have abstracted the concept of running in production away from them. And they've just got a run button that says Push to live.

And that's effectively how they're running their machine learning. It's separated away from the traditional software development and software engineering skill set. Two separate pathways. We think of that as quite a ridiculous concept as a cloud native company. Trying to make sure that we can bring consistency behind that.

And when you start to kind of push into the reasons why people aren't making it to production, it's actually pretty simple, right? People are worried about security. Machine learning always is a high value, high investment type of environment. If you have a security breach, and that could be, I lose my data, I lose my customer's data, I breach GDPR, that can cause one of the reasons why your model will fail. It doesn't have to stop producing accurate results. You could actually lose your competitive advantage, your data being opened on the internet.

I think connecting, wrangling, gaining value from your data seems quite consistent across these trends as well. And what really seems to happen here is that people are challenged to be able to get their data both month by month, through their pipelines into their machine learning model consistently. You point back to the couple of slides back, you're looking about 30% your effort being building these pipelines to consistently deliver your machine learning.

The part I'm most passionate about is huge barriers to interoperability. You'll spend your time building your model in R. Your platform supports Python. Very particular type of python you end up spending forever re-engineering how you could approach that. You're spending a lot of time looking at how you migrate your code productionize. A phrase that machine learning engineers use a lot to be able to get into the next stage. Assigning your compute resources, buying, installing, setting up, I mentioned installing the video drivers. That's a barrier of adoption. Actually, if you do that in an incorrect way, huge performance hits can ruin your return on investment.

Also break your machine learning production environment. And I think some of the interesting parts as you go towards the bottom is actually there's a huge chunk of people who are worried about moving to the cloud, right? The reason they're not going to production is because they don't want to go to the cloud.

And if you think about it, from a cloud native point of view, there shouldn't be a difference to be how you deploy on premise to how you deploy in the cloud. And I think the one that's worthwhile calling out here just for the point of longitudinally is model decay and data drift, which is how do I keep my model returning the same results accurately, consistently across what's happening.

People have probably seen a machine learning pathway before. The important bit to take away from here, and everyone would do this differently. This is probably my viewpoint and quite a generic process, but as you notice, every step has an opportunity to fail and step you back 1, 2, 3 steps. You can identify your problem, get all the data you need to analyze it, and find a perfect machine learning model that you think will suit and fit your data really well.

You've run lots of different types of experimentation, different environments, different model paradigms, weights in your neural nets, and then you tune your hyper parameters at any point. You can fail either, absolutely to the point where you have to take it back to the drawing board and reapproach a problem completely.

But then also you can go one step back and have to redesign your algorithm, bring more data into the problem, look differently about what that data's doing, and this kind of think fast, fail fast experimentation and machine learning is critical, right? I think failure in machine learning is just another word for experience.

There's a phrase I hear thrown around quite a lot. And I think that what's really important here is that you have to accept that failure. And 85% of machine learning problems failing is what you want to do. You want to fail a lot. You want to learn a lot. The truth being told is you want to fail until you can't fail anymore with machine learning.

This gets even more difficult when you look at the kind of different ecosystems you have to build in the stupidly wide range of tools that you have to implement within. All of those, probably doing it a different way. Maybe different modalities, different types of lock-in and different attributes.

And I think actually the abstraction layers that they put around these types of ecosystems don't help. Right? A single abstraction layer to wrap all of this is complex. And actually the thing people really want is autonomy, right? They wanna be able to bring their own tools, bring their own types of technology.

Part of that is, I think that it's a difficult canvas to paint on for machine learning, but you've also got a creative part of this art, right, which is how you really want to think differently. Your competitive advantage doesn't come from taking this loop the same way as your competitor. It comes from doing it differently.

Now, this isn't all the tools. These are the most popular ones. I've probably missed out some here that some people use at home, but what I really wanna show you is the diverse opinion. Some of these tools are heavily in use. Some of these tools are heavily sought after. Some of these tools are heavily declined in what they're doing.

The truth being told is nothing on this list solves the whole life cycle end to end. You're probably, if you're looking at these, picking one or two, you're probably looking at what you can do to make them mesh together. You're probably writing code to make them work together. And the challenge here is that actually we're not moving away from that problem. We're investing in it to a state where actually we're putting more and more tools in the landscape, spending more time trying to look at a new tool to solve the same problem we've been trying to solve with the old tools.

At the end of it, when machine learning engineers say they've got a tool kit or a tool set, it kind of ends up being a bit of a pick and mix sweet shop where they've got a very heavily preferred type of tools.

The reason I think a lot of ML engineers spend a lot of time arguing about tools is because that tool preference is very different to the colleague next to them. If you look at the majority of fully managed toolkits and fully managed tool sets, you're probably spending a lot of time there being locked in.

And actually what fully managed means is build this way. I think with the types of considerations you get around ROI, driving the outcome of if your machine learning is gonna keep running or not. Buying more tools is in itself hypocritical towards trying to bring a better value for money at the outcome.

The lower the cost of operation, the faster you can iterate, the more likely you are to be able to put that model into production and gain value from it.

Now, there's lots of really interesting paradigms here. This particular survey is aimed at the open source community. And there is a little bit of an overfit here, so to speak, but actually I think it still speaks really strongly across enterprise adoption and what we're doing in lots of different spaces, which is that the most sought after piece in machine learning is more innovative open source tools.

People don't want more vendor specific tools. Right. And the reason why for that is actually open source tools allows them to interoperate to a much finer degree. Second is that it is actually a preference around avoiding lock-in. Again, to the point of autonomy, and I think one of the things that makes it really interesting around how these things come together is the economical focus combined with people's choice on speed.

Being able to iterate through that machine learning life cycle as quickly as possible, gives people a lot of different options. Get your result faster. Understand if you're gonna be successful, or if you're gonna fail as early in that life cycle as possible. And you can see this being adopted within large companies, picking up a tool set with AWS one year, picking up a Databricks implementation the year after.

We're still jostling around exactly the perfect end-to-end golden path.

The two circles in the bottom right, I think form some kind of irony, which is that if you ask the majority of companies, if they've got the investment necessary in high quality machine learning tools, 65% of them say they'll lack those tools. 87% of people who answered that same question are already invested in open source.

So these companies that have open source adoption are complaining about not having machine learning tools, probably writing code, using open source tools, using libraries like TensorFlow, PyTorch, which are open source on platforms, which most likely are closed or proprietary.

Now Civo has always tried to position its cloud services differently. I think some of the points that Mark mentioned earlier actually about how we try to step away from the hyperscaler mentality and try to look towards different ways of solving problems, I think is really important. And what I particularly believe in is this single path that can include everyone.

If you wanna bring tools from across your landscape, which have very small adoption, but you think have huge potential. We don't wanna block that. If you have a lot of different types of interoperability with existing systems, even other cloud providers, we again, don't wanna stop that. A lot of people try to get around this by using data as an interoperability.

The reason for that ends up being actually the majority of their infrastructure is really difficult to hook up to other infrastructure. As a cloud native company, we love the concept of Kubernetes to overcome that. We've looked a lot at the different ways we've been trying to solve the problem, and we think that actually backing open source instead of fighting against it and building a closed source, proprietary tooling ecosystem is the solution.

Expanding cloud native is one of the goals of the company and just where we primarily see a lot of our focus and what we do with our engineering, and actually one of the things you can probably see as a recurrent theme in what I'm saying here is actually. Breaking down these barriers of adoption, a low barrier of adoption lets you pick up these tools quickly, evaluate them quickly, try to understand if they fit well for you, and an autonomous pathway where you can change those tools out to what you do prefer.

Remove the things in your stack that you don't think are effective suits the machine learning ecosystem so well. When we look at different ways of how we can position these different jigsaw pieces to solve the problem. The typical machine learning problem normally has about 18 different types of implementation throughout its lifecycle.

They all look drastically different. If we landed the right tool configuration, the right data configuration, the right feature, engineering first time, it's gonna be something that would even be easy for everyone to do. The truth being told is that the tools we need to be successful in machine learning long term haven't been built yet.

And actually we're spending a lot of time focusing on GitHub projects that have really awesome technologies. And the majority of platforms for machine learning spend six to eight months getting those projects into their ecosystem to be supported. You don't wanna look at technology you're using, being like, can I run that? You want to be like, I'm going to run that.

We're really excited to announce the first managed machine learning product from Civo KubeFlow as a service. KubeFlow is an existing platform and technology that we've spent a lot of investment as a company in already. It comes from the Google ecosystem as an in-house project that was being opened and currently is sitting as a submission to be incubated by the CNCF.

KubeFlow has a wide variety of tools that suit an extremely wide preference of users. It doesn't matter if you only code in an I D E or a Visual Studio Code if you're an R programmer who likes RStudio and RShining, or if you're a Jupyter Notebook junkie and you like to do your work that way.

The outcome here is actually if you wanted a fourth option. This is possible with the technologies that we have here. We are not interested in fighting against people who wanna build tools and open source. We wanna give you a home where they can be effective and be used. We understand the wide range of frameworks are set alongside that, and actually we wanna say bring your own.

We don't want to go vendor preferring around what's being happening with MXNet. We don't wanna force you into PyTorch types of training operators. We actually wanna encourage you to use the ones that we provide and then challenge us to be able to bring even more to that. Our goal is to provide a zero configuration platform so that you can jump into these types of workloads effectively.

I've seen people set up infrastructure for machine learning for six months. We're hoping to give that to you in minutes.

The cloud native adoption pathway for machine learning is complex. It's got speed bumps. It's really difficult to do, and normally any company will have about five to 10 engineers helping move their workload into a cloud native paradigm. Well, they'll probably be building their own cloud native framework around that to help her get implemented.

Actually, that's a really big scaling issue, right? You're building your own proprietary in-house wrappers around open source technology. So what we think is really important is to try to provide that as a managed service that can help you scale from startup to enterprise. And we don't wanna put any blockers in the way of you being able to take that back to your laptop.

Say, for example, you need to scale down and work on a project in a small capacity. A local KubeFlow instance will feel very at home being exported and imported into these types of outcomes. We also don't wanna stop you using our Kubernetes clusters to run your own bespoke KubeFlow, if that's what you'd like to do.

We've thought a lot about the security considerations that sit behind machine learning. We've worked really tightly with defense.com, one of our partners, for a solid security and peace of mind, and actually think that we want to take that ownership of concern around, is my machine learning safe off your hands?

We have full support for the KubeFlow ecosystem and actually further support for the other tools within the Civo ecosystem. You've probably seen from a couple of the announcements today that we're really focusing on managed services that give back to open source things like OpenCP, and we wanna keep building in that direction where we're not building proprietary platforms that lock you into our cloud native ecosystem.

KubeFlow has been tested wide and far with enterprise adoptions in over a hundred million dollars in some settings. We've already been spending a lot of time building KubeFlow, so since 2001, my colleague Saiyam's been working on how you can do a single click deployment into KubeFlow, into an unmanaged cluster, and that won't change.

We'll keep investing in and directing that into a more outcome. A more outcome driven platform that hopefully lifts up everyone who's leveraging it. Our goal is to build alongside companies like Arikto, AWS, Google, who already have large investments, and the commitment we have is that our meaningful contributions will go directly back into open source.

We are great at delivering this type of open training documentation. And being able to help really smoothen that adoption curve, particularly with things we've done around KubeQuest, a way that people can start to learn Kubernetes clusters from a zero point perspective all the way through to experts. I think the most important part about here is you wanna make sure that it doesn't block beginners, it doesn't block hobbyists. It allows people to rapidly ideate and scale to the stage. We're doing it from a large perspective.

As I mentioned with the Civo ecosystem, we're focused on freedom of interoperability and this Build Without Barriers concept is something we really believe in. We think it's the strongest part of how Kubernetes adds value to a large scale operation. So you'll see here that actually we're working on how you can remove the data engineering concerns with things like Civo volumes, Civo object store Civo databases.

All of which sit within the volume api, s3 API, standard my SQL databases, Postgres databases. We wanna make sure that you can still work and connect to these different types of outcomes. If you want to run a Kubernetes cluster alongside the Interoperates, whether that be on Civo or elsewhere, you're very free to.

We are working around how you can make sure that you can connect with some of the lower barriers of entries that are easier to use than managing a whole Kubernetes cluster. Things like compute instances, on-premise instances, a docker container running on your laptop, and actually what we're really excited about is the Civo platform as a service, which gives you just a one-click option to drop a container.

What I think is really powerful about this is you can put your data in a Civo database. You can wrangle that data inside KubeFlow. You can produce that in a web app and call that model from KubeFlow with the platform as a service. And actually you're managing zero infrastructure. And you can take any of that and deploy it anywhere.

You can use any of the existing providers that use those standards. You can choose to run all of that yourself inside your own cluster. And this freedom of interoperability is what is gonna make you iterate faster than people not doing this. Some of the other tools want you to adopt their wider ecosystem with preferred ways of working. We will let you access these standards and let you define your own ways of working as an outcome.

And outside the managed space, because some people want to build and brew their own. We're really excited to start to look at really disruptive types of technologies that allow you to do that. And what we really wanna do is step apart from hyperscalers, offer lower scaling points with huge ROI potentials, and actually, I think, disrupt some of the initial propositions and cloud value propositions that exist with machine learning.

The first one we're really excited about is actually a GPU Edge box. Our Edge Box product has been really successfully adopted across different types of enterprises who are trying to claw back ROI, run large scale compute operations in house. To the point I was discussing earlier about on-premise solutions, what we are doing differently here is a box that you can very simply implement into your enterprise.

Take on the ROI benefit of owning and running your own GPU If you know your workload gonna run hot, but actually give you a way that you can instantly deploy a model that you probably wouldn't be able to put in the cloud. Having worked in pharmaceuticals, you know that you've got regulatory authorities that are gonna demand a lot of compliance around what you're doing.

Some people wanna make sure that you can have a full set of control. There are machine learning models guarded under gunpoint in the world, and for those types of requirements that live outside of the technical expectations, we can enable that. We're still positioning pricing, but our goal here is to be incredibly disruptive with our return on investment offering that we can give.

And if that's that upfront capital investment isn't something that you are looking for right now, we're looking at what we can do to enable GPU instances. The first type of GPU instances is obviously the traditional, but what we're trying to do here is offer a much lower price point Civo's normal pricing transparency.

Looking at what you can do to align alongside that where you don't have data transfer and ingress and egress. That in itself is a huge cost saving for a machine learning ecosystem where data ends up being the majority of your concurrency and super fast launch times let you scale up and down that in a much more graceful way.

DDoS protection and bandwidth pooling actually makes a lot of sense when you start to think about machine learning, lots of different nodes, ecosystems working together and connected. The bit I'm really excited about is actually fractional GPU instances. Now, it's hard to find a hard, hard number for me to put on this slide, but when you look at the average GPU utilization, it's about 24%.

People aren't running a full GPU to do workloads. Your training speeds up, loads up, you vectorize, you run, ramps Down. In a traditional hyperscaler cloud setting, you are paying for 100% of that GPU and using 24% of it. The reason why machine learning is failing is that gap in the middle that you're not using, you are paying for.

We're looking at what we can do to create a much lower pricing point of entry appropriate for startups, small businesses. And actually, I think what I'm really excited about is hobbyists starting to democratize machine learning for people who aren't experts, but don't wanna pay 2000, 3000 pounds a month for a GPU.

This combined with Civo's fast launch times and scalability that we offer behind Kubernetes means that you can get a really low cost machine learning implementation that actually starts to open up possibilities for GPU inference at a much lower cost, GPU training cycles at a much lower cost.

Particularly with automated regular retraining, you can start to look at where you can be positioned in a much more competitive way. In the current economy where you see SaaS products running on like a 40% margin, US lowering your costs 20% is probably the likely piece that's gonna help you make more money than your competitor.

We're also continually looking at bringing down that barrier of entry and machine learning, and I think it was amazing to see our panels start to talk about how machine learning is complicated. Machine learning takes a long time to load, long time to learn, and having spent a lot of time with doctors, clinicians, scientists, and helping them go from kind of like PhD experts to machine learning hybrid experts, we think one of the things that is really important is actually bringing down that barrier for the beginners.

Then also enabling rapid experimentation and rapid prototyping for the experts. We are partnering with some great companies like DataChimp, around how we can start to enable this rapid ideation, rapid movement. And we're looking for other partners who can help us bring more people to machine learning. Open up this use case and start to get out of some of the misconceptions we had at the beginning of this presentation.

So we're announcing this now. We're launching this soon. Timelines are yet to be declared. However, what we're really excited for is to grow and scale with our customers. And actually, we are looking for people who want to be a part of our alpha launch, who can come together and start to look at how they can grow with us, scale with us, feedback to what this platform's doing, because there isn't anything else like this currently being round in the way that we'd like to.

And I think particularly with the ROI that's promised behind it is it opens it to a whole new audience of people that are gonna think about machine learning differently and the tooling behind it very differently. If you've got machine learning use case and you're interested in helping grow with us, at that url, you'll find a registration form where you can submit your interest and we'll be onboarding people into that ecosystem in a white glove service partnership, most likely similar to our Slack Connect service that we offer through our existing Civo partnership.

Civo is great at listening. Civo is great at running infrastructure at scale. I think it's great at operational excellence, and what we're trying to do here is expand that to include people to start to lower economical price points behind it, and hopefully come to outcomes where people can be more productive with machine learning and we get away from this ridiculous failing mechanism.

I just wanna say thank you so much for being here.