Welcome to the Episode 351, part of the continuing series called “Behind the Scenes of the NetApp Tech ONTAP Podcast.”
This week on the podcast, Andrew Sjoquist (https://www.linkedin.com/in/andrewsjoquist/) joins us to talk about how Fluid – a software defined infrastructure platform which allows for the simplified and automated rollout of cloud-like environments anywhere. Find out how Fluid integrates into NetApp BlueXP and how it can help you deploy your own cloud-like infrastructure on-premises or at the edge!
For more information:
Tech ONTAP Community
We also now have a presence on the NetApp Communities page. You can subscribe there to get emails when we have new episodes.
Finding the Podcast
You can find this week’s episode here:
I’ve also resurrected the YouTube playlist. You can find this week’s episode here:
You can also find the Tech ONTAP Podcast on:
I also recently got asked how to leverage RSS for the podcast. You can do that here:
The following transcript was generated using Descript’s speech to text service and then further edited. As it is AI generated, YMMV.
Episode 351: Fluid and NetApp BlueXP
Episode 351 – Fluid
Justin Parisi: This week on the Tech ONTAP podcast, Andrew Sjoquist of Fluid joins us to talk to us all about the integration with NetApp BlueXP.
Podcast intro: [Podcast intro music]
Justin Parisi: Hello and welcome to the Tech ONTAP podcast.
My name is Justin Parisi. I’m here in the basement of my house, and with me today I have a special guest all the way from, I guess Australia, right? Is that, is that right, Andrew?
Andrew Sjoquist: That’s right.
Justin Parisi: All right, excellent.
Andrew Sjoquist: Indeed.
Justin Parisi: Andrew Sjoquist is here. So Andrew, what do you do down there in Australia and how do we reach you?
Andrew Sjoquist: Thanks Justin. Hopefully you can understand me with my really southern accent. So I’m the founder of a company called Fluid, and Fluid has a great relationship with NetApp. It goes back a couple of years and you can reach us via our website at Fluidhq.io. We’re also on all the other socials like LinkedIn as well.
So reach out to us and you can also find us inside of the BlueXP console as well, which is what we’re gonna talk about later today.
Justin Parisi: All right, excellent. Now, I’m not gonna make any Australian accent jokes or anything like that, but I will ask you, what’s your number one least favorite Australian accent joke?
I have, I have my theory of what it is, but let’s, let’s hear it.
Andrew Sjoquist: There’s a couple we probably can’t use on the podcast here. But you know, "g’day mate"or "Throw another shrimp on the barbee" or
Justin Parisi: That’s the one! That’s the one I was thinking of.. A shrimp on the barbee. Like, I’m not Australian. And I knew that if I were Australian, I would hate that.
Andrew Sjoquist: Yeah. Well that’s not a knife, that’s a knife.
Justin Parisi: Yes. I can’t believe you’re still getting Crocodile Dundee jokes. It’s been 30 years now.
Andrew Sjoquist: Indeed, indeed.
Justin Parisi: Paul Hogan. Marvelous guy. All right. So let’s talk about what we’re here to talk about and that’s Fluid and BlueXP of course.
So let’s start off with Fluid. What is Fluid, what do they do? And tell me a little bit about the products.
Andrew Sjoquist: Yeah. Great. Thanks Justin. So Fluid is a software defined infrastructure platform which allows for the simplified and automated rollout of cloud-like environments anywhere. So our goal was really to be able to give a cloud-like experience like you would get in a public cloud hyperscaler, but more on-prem or at the edge or in a colo.
So we’ve seen obviously the rise of the hyperscalers and the public clouds and some fantastic services that are offered there. But also the simplicity with which those services can be consumed. So we set out about three years ago to build Fluid and Fluid enables that to happen.
Justin Parisi: So it sounds like you’re integrating pretty tightly with a lot of NetApp products and most specifically BlueXP. So I’m a little bit familiar with BlueXP but I would imagine that you’re much more familiar with it.
So tell me what BlueXP is and try to tell us from the perspective of a partner integrating with it.
Andrew Sjoquist: So BlueXP, as we see it, is the next evolution of Cloud Manager. So that whole concept to that, a single pane of glass can manage your data state, whether it’s on-prem or in the cloud really now has been reimagined to enhance and drive deeper into those data services from NetApp, but now also with third parties such as Fluid.
So what we bring to the BlueXP experience is the ability to now not only manage your data services from NetApp in that single console, but now also manage the network and compute elements of your solutions regardless of wherever they may be deployed.
Justin Parisi: So basically you’re taking the concept of storage and you’re kind of lumping it in with the virtual machine aspect of the cloud with compute instances, so you’re able to manage all those in a single location. Is that kind of what I’m understanding there?
Andrew Sjoquist: That’s right. So Fluid allows you to run compute workloads in the form of either virtual machines or also Kubernetes enabled containers. So in a really simple deployment methodology in a matter of minutes, you can turn those bare metal resources that you may have in your colo or at your edge locations into fully fledged VM capable platforms or Kubernetes capable platforms as well. And then of course, tie that back into the Kubernetes enabled services that NetApp offer, like Astra Control Service, and Astra Trident just to name, but a few.
Justin Parisi: I know BlueXP can manage instances either in the cloud or on-prem.
Does Fluid also tie into both of those locations, or is it strictly a cloud based management system?
Andrew Sjoquist: So Fluid is truly a hybrid cloud offering, and this really kind of makes that hybrid cloud story ring true. So regardless of wherever you wanna run your workloads, whether that is on-prem or at the edge or in a public cloud, using the bare metal resources that you can get from those providers, we can have a seamless homogeneous experience to enable us to deploy those workloads regardless of the form factor, whether that be VMs or containers.
Justin Parisi: So with the containers and Kubernetes aspect, is it strictly like a Kubernetes deployment that you’ve stood up yourself? Is it GKE? Is it AKS? Is it all the above? And can you also integrate things like straight up Docker into this.
Andrew Sjoquist: Yeah, great question. So we basically provide a Kubernetes instance that’s deployed from upstream Kubernetes. We orchestrate the full turn up, so we deploy the operating system, we deploy Kube, then we also deploy some Fluid magic around the networking as well. So it’s not necessarily a flavor of like GKE or EKS or AKS.
It’s not a distribution, but it’s a method of basically deploying Kube in a simple way. Cause for those out there who have ever tried to deploy Kube outside of a public cloud provider, there’s a lot of complexity that goes into that, particularly with relation to networking.
You’ve gotta get your load balancers set up. You’ve gotta get your subnetting sorted. You’ve gotta get your networking underlays and overlays sorted. All that’s managed completely automatically and orchestrated from within Fluid, the platform, and visible and controllable therefore within BlueXP.
So it really simplifies that process. It also means that from a customer’s perspective, you have that single pane of glass approach regardless of the infrastructure that you choose to deploy your resources onto. So it’s not necessarily the case now where you have to build something for a particular cloud vendor or another particular cloud vendor.
We take this homogeneous approach. So we basically say you can scale your workloads now, globally rather than having to silo your workloads into particular cloud vendors or into particular locations or regions.
Justin Parisi: So, is Fluid kind of acting like its own Kubernetes engine then? Is that what I’m hearing?
Andrew Sjoquist: Yeah, so we manage the Kube turn up and then we also manage the deployment of both master nodes and worker nodes in those clusters. Then we also add some extra capabilities, which is great for departments and service providers, like departments of large enterprises.
So, for example, we have a nested Kubernetes capability, so the ability to run Kube and VMs at the same time on the same hardware clusters, but then run multiple clusters of Kube within that without using any virtualization. So very similar to the approach, I guess that’s taken with an SVM in say an ONTAP cluster where we’re able to basically keep deploying those Kube services really rapidly.
Additional services stand up in about a minute and then hand that off to a department or a developer to be able to make use of Kube without having to worry about all the complexity that’s happening downstream or under the hood, down to the bare metal, for example.
So again, that’s where we talk about having a cloud-like experience where all the infrastructure is orchestrated and turned up and stood up by itself. And you can jump really quickly then into actually getting down to deploying workloads and adding value at that upper stack layer.
Justin Parisi: So what if I already have an existing Kubernetes deployment?
Can this work alongside that, or am I gonna have to migrate over to what Fluid uses?
Andrew Sjoquist: Yeah, so it can work alongside that. We basically say though in some scenarios that we can join an existing environment. Brownfields of course, is a little bit of a challenge in some cases not just from a Fluid perspective, but across a lot of technologies.
So yeah, there is a capability to do a seamless migration and integration with existing services on a case by case basis. I guess from our perspective is because we can turn up Kubernetes instances and that platform completely and literally five or six minutes from the time that you boot the first machine there’s really a good value proposition there to switch to Fluid.
The other thing I’ll say too about Fluid from a security perspective, which is kind of interesting, is that we’ve built Fluid to be immutable and ephemeral. So what we mean by that is that the operating system that is pulled down from the cloud service that runs alongside BlueXP is hardened and secured and built out of a series of industry best practice security standards.
And so when you boot the operating system that is going onto your bare metal hardware, effectively you have comfort in the fact that environment is free from critical vulnerabilities and exports and other security issues that may be lurking in your underlying infrastructure. Now, the beauty here, of course, too, because of the ephemeral nature, whereby we can add and remove nodes literally as quickly as we can boot them or shut them down, it means that our upgrade on our environments to either patch a CVE or to scale because more resources are required is as simple as rebooting a node. And in a scenario where your workload’s deployed and Kube inherently is resilient to failure. It means that a rolling upgrade on a cluster basically leaves you at the end of that upgrade process with a freshly patched and upgraded environment without having any downtime to your workloads.
Justin Parisi: I would’ve guess that you have some logic built in there to automatically migrate container workloads from node to node as you do these reboots, right?
Andrew Sjoquist: Exactly right. And we all subscribe to the view that, which I know NetApp’s pushed for a while, that Kubernetes is the operating system of the internet.
So from our perspective there’s no better from an orchestration perspective built by the guys and girls and team at Google, and what we say about that is that, we leverage Kube extensively, particularly for the scaling elements and for the orchestration elements.
And so a lot of that failover and resiliency pieces come inherently with Kube. But of course we have some additional magic that happens to make sure that those workloads migrate around either failures or upgrade processes that are in play.
Justin Parisi: So, failovers and resiliency and upgrades, that’s just one aspect of keeping a Kubernetes cluster online. The other aspect is data protection. So how are you approaching that? Are you integrating with stuff like Astra Control with NetApp or are you doing something else there?
Andrew Sjoquist: This is where the NetApp relationship with Fluid really comes to the fore.
So because we’ve built Fluid on open standards and so what we say about open standards, in a networking stack, for example, we leverage BGP extensively in the Kube world. We leverage CNIs and support full suite of CSIs – container storage interfaces. It means that when it comes to bringing integration with the likes of Astra Control Service, Astra Trident, and other products that are also Kube natively integrated. It means we can do that very quickly and it means that we’re not maintaining a proprietary or closed ecosystem that may exist in other providers.
So there’s a really nice pairing there that happens that when you, for example, turn up a Fluid cluster, whether that’s a single node cluster or a cluster with dozens or hundreds of nodes in it. The handoff point that we provide back to third parties, such as Astra Control Service is the Kube API. And so from within BlueXP console, what you can do is you can log in there, you can actually download directly the Kube config file straight outta BlueXP, import that straight into your Astra Control Service, for example. And literally in a matter of minutes, the clusters been built by Fluid, the data in the clusters now being protected by Astra Control Service, and we haven’t had to do any special networking. We haven’t had to turn up private networks or VPNs or anything like that. It’s all happened with the magic of Fluid under the hood. And the connectivity then between say Astra Control Service and the workload running in that Fluid cluster is completely secure as well. We use mutual TLS between endpoints, even though we relay traffic through the Fluid cloud service that sits alongside BlueXP. We have absolutely no visibility of the traffic that’s going in there. So it’s a completely secure, completely cloud-like infrastructure. It just so happens that the actual Kube workload can run literally anywhere that you have a piece of hardware to run it on.
Justin Parisi: So with the upgrade process for the cluster nodes, does that also extend into the Astra Control and Astra Trident pieces? Do you upgrade the plugins along with that, or is that something you have to do manually yourself?
Andrew Sjoquist: So at the moment that’s a manual process. We are working through on a roadmap, a series of add-ons and enhancements in that regard.
So that should be next quarter. We bring through some capabilities to automatically do those upgrades. But again, because we expose the Kube API component, we can literally plug the Fluid endpoint straight onto the end of any existing CI/CD pipeline or other configuration management tool that customers might be using.
We’re just building out, like I said, more and more integration with NetApp. The focus has been today to get the integration with BlueXP. And that’s been a huge effort from both our teams and also the. NetApp teams based in Israel. And what it’s meant is that from a user experience they’re able to log into BlueXP, use the authentication there, use the workspace separation and account separation.
We also log all our information directly back onto the audit timeline that’s in BlueXP as well. So from a user experience perspective, you really do have that seamless visibility and capability to do the deployment. Now our next phase here is to continue to enhance that experience with more integration from an automated upgrade perspective, like you mentioned.
Justin Parisi: You mentioned configuration management tools. Do you tie in, I guess to like Puppet and Chef and Ansible and all the standard things or do you have recipes already pre-canned that people can download? How do you approach that aspect of it?
Andrew Sjoquist: We use some of those technologies under the hood as well.
In terms of what’s exposed at the moment. We obviously expose the Kube API. We also have a fully documented Fluid API as well. So basically everything that we’ve built has been API first. So when you look at BlueXP, you know what’s happening under the hood. Effectively, it’s calling our api, so there is capability there to plug on those automation tools.
Like Ansible, as you’ve mentioned, your Terraform in terms of a standup capability. Have we written plugins yet? Not yet is the answer. But we are keen to hear feedback from customers and users as to what’s a priority for them. And we can certainly prioritize that. We’ve got a ever growing roadmap.
We have all the, the tech there, we have the, the endpoints there. Like I said it’s just a matter of prioritizing. Do we build an Ansible plugin? Do we build a Terraform provider? You know, again, which led by requirements there. And we can move extremely quickly in that regard as we’ve demonstrated.
So if there’s a customer demand that’s needed for one of those tools we’ll make it happen in a really short space of time.
Justin Parisi: What about like a presence with GitHub? Do you have stuff laying around on there that people can access with open source, or is that something that’s in the works as well?
Andrew Sjoquist: So we do have some documentation that is there inside of GitHub. So some of our source from a Fluid perspective is closed. We obviously leverage open source technologies quite extensively. We have a read the docs which goes through and talks from a documentation perspective about how to get started with Fluid.
But really, I, I guess we’d encourage people who are interested in giving Fluid a go or wanted to talk to us more if they go into BlueXP, you should be able to see the Fluid icons that’s currently listed under operations on the left hand side there. And that’ll basically guide you to how to start with the the sign up so you can start deploying workloads almost straight away.
And then obviously access to the documentation, the Git repositories and things like that that were built and is there for reference. We also have a Slack channel that end users can subscribe to that gives full and fast access to some of our development team and engineering team.
So always keen to engage with more and more customers in any way that we can.
Justin Parisi: You mentioned there’s a way to access Fluid through the BlueXP interface. When I do that, is that like a trial thing that I get to start up? Is it something I have to pay for right away and if I do, what does that payment structure look like?
How are you guys making money on this?
Andrew Sjoquist: No, great question. An important one. So no, it’s a trial. So in terms of coming into the environment, there’s a trial capability that you can spin up your environments without any commitment on day one. When it does come time to license Fluid, the licensing model’s pretty simple. We license on a cost per node per month basis. So we wanted to keep the license model super simple. Basically count up how many physical servers you have or metal instances and cloud providers, multiply it by the cost per month and away you go. So really simple.
We don’t subscribe to a model where you have to have RAM usage counters and different sizing. Just key from a Fluid perspective like everything else that we do to keep the licensing super simple. So it’s literally about counting them on your hands and then licensing the number of nodes that you need in that particular month.
Justin Parisi: So you’re not charging licenses per CPU on a VM?
Andrew Sjoquist: Not per CPU, not per RAM. No. We just wanna keep things simple. There’s enough complexity in this vast world. So, from our perspective, we find that model works well, whether you’re a service provider or an enterprise. It doesn’t need a doctorate in licensing to be able to work out how much you need to pay from a licensing perspective. It’s a really simple model that’s working well for us.
Justin Parisi: I feel like with that model, the concern is not so much simplicity and more so the feeling that you’re being completely taken advantage of. Like, it’s like, Hey, I’m gonna grab every last cent out of you
So I think that’s really what the benefit of having a more global licensing structure is. You might still be making roughly the same amount of money, but it doesn’t feel like you’re being squeezed.
Andrew Sjoquist: Yeah. Are you referring to the usage? Yeah.
Justin Parisi: Like if I’m charging per CPU and per RAM megabyte, you know, really as a customer, you’re like, man, you guys are really squeezing me. They might all come out to be the same exact amount, but feeling that squeeze, feeling that granular, yeah. Every grain of sand squeeze is, I think it’s a relief when you only have this one thing to worry about.
Andrew Sjoquist: Well, that’s it.
Yeah, that’s the way that people have purchased infrastructure for decades, right? You buy infrastructure, you capitalize it, and you get a good run out of it. And it’s pretty simple. When you r provider starts now wanting to come in and take a bit of tax out of your operating model it hurts a bit and like you said, what do you necessarily get for that? So from us it was all about being simple and on that point it’s gonna be interesting to see what happens when the likes of the process of manufacturers, cause there’s talk now about being able to buy your processes in your systems, and then not necessarily have all the features enabled and then have to have software licensing on the features. So it’s gonna be interesting to see what the response in the market is to things like that as well. Where now more and more your hardware providers are kind of limiting things that happening.
You’re seeing it in the automotive industry, for example. You buy a car and then, oh, you wanted the heated steering wheel, well, you can turn that on and it’ll cost you $10 a month in the app. You know that the element’s in the steering wheel, right? And someone’s just gotta write a piece of software, and there’s a line there, I guess, where I think people need to be careful that you don’t overstep your welcome, so to speak in terms of interfering too much with your customer’s workloads or what they’re doing.
We certainly wanna provide value, but it doesn’t mean that we necessarily have to clip the ticket every time we do.
Justin Parisi: Yeah. And the automotive industry piece is a good parallel there cuz it is happening in like, you know, BMWs offering heated seats and that sort of thing, but you have to pay for it.
I get why maybe they did that, but I don’t think that they’re factoring in that lost customer that happens with that. Cuz with anything, if you start to feel like there’s friction with things that you should be getting with the product that you’ve already paid for… and you can extend this out to video games and the microtransactions like, oh, you need to buy all these different things to get these cool outfits or these new weapons. Right. You just start to lose interest in it. Cause it’s like, man, this is a lot.
Andrew Sjoquist: Yeah. It probably started back maybe with cable television. Used to get cable and cable was cable and, then, oh, you want this channel?
Justin Parisi: I think people wanted the choice. People wanted to choose what they wanted to watch. The problem is, is they gave that to you. It’s like, a deal with the devil, right? It’s like, oh, you want that ? Guess what you get with this fool?
Your soul is mine!
Right? But yeah, it’s really the same concept with licensing and anything cuz wherever you can make money, people are gonna try to do that.
Andrew Sjoquist: That’s right. And look, you know, from our perspective, our next challenge and that licensing piece as well, putting the customer’s question out there, which is what happens on really small devices because that’s great that you can license per node and I can build a really beefy quad processor system with a couple of terabytes of RAM and run a ton of VM and container workloads on there. But what about the other end of the scale when you go down to micro devices and another thing in the new year for us, at the moment we’re running on X86 hardware across the board. We don’t care which vendor, by the way, whether that’s Dell, SuperMicro, HP…
We don’t really care as long as it’s X86. But in the new year, we’re adding support for ARM and so that obviously then opens up a whole new world of smaller and smaller footprints. And because Fluid has a really small footprint in terms of where it can run, it’s 200 megs or so in size from a deployment perspective.
The question then becomes, alright, well I wanna run it on we always joke internally in the office about you know, running it in the back of a taxi that’s not too far fledged right? Like a Kubernetes cluster that’s running on some Raspberry Pis or whatever it might be. But then, yeah, how do you license that?
So that is a question that we’re rolling with at the moment. Cause obviously, it does need to come at some form of discount, but we also don’t wanna end up in a situation where we shard our licensing so much that we end up in this, here’s, 50 different flavors of the same thing that, again, you need that doctorate in licensing to understand. So we’re super keen to make that as simple as possible.
Justin Parisi: Yeah, and that also extends into mobile and IoT and that sort of thing, so you’re really looking at a wide swath of things that you could do that you really need to account for when you’re doing the licensing model.
Andrew Sjoquist: That’s right. Yeah. And again, look, from our perspective, it’s about enablement, right? So, we saw the value in Kube we see the amazing capabilities it has to run workloads. And I guess we’ve just enhance and extend that so that we can really deploy the platform, connect the platform into CI/CD pipelines and other dev pipelines.
And then really make that edge part of a software defined infrastructure. So when you’ve done your updates, they’ve been through your tests in your development team and you want to get ’em out to the edge where they’re gonna be used and provide real world value. You pump that into Fluid and Kube running along on top of Fluid and your updates are out there in the field.
So yeah, that’s where we’re headed, I guess in the new year, pushing more and more out to the edge. But it means that from our perspective, that software defined capability and, you know, IDCs done some interesting commentary and synopsis of that market as well, if you look at software defined infrastructure, and then you break that down into software defined network, software defined compute, and software defined storage controllers is the three categories there, and NetApp fits that storage and data part really well. Fluid deals with the network and the compute really well. So that’s what makes this a really interesting stack together, is that we have this full software defined infrastructure stack that you can deploy and manage and upgrade and secure all from inside of NetApp BlueXP.
Justin Parisi: So does this basically work anywhere BlueXP works like any of the cloud providers, or do you have limitations on which cloud you currently support?
Andrew Sjoquist: It’ll go on any bare metal hardware. So today that’s obviously hardware that you have yourself wherever you wanna buy and deploy that. We have an integration specifically with Equinix Metal, and I know NetApp has a long relationship with Equinix as well. So we can deploy straight onto Equinix Metal, which is the packet company that was acquired by Equinix two years ago. And then we can run also then in any of the three major hyperscalers, so AWS, Azure, Google, on their bare metal instances.
We obviously can’t deploy on their virtualized services. So we do need access to the bare metal. But the bare metal instances, like EC2 bare metal for example, is perfectly fine at a great place for running Fluid. And bear in mind too is that it can be any and all of those.
So we have some fantastic scenarios and interesting use cases from customers where they might have nodes running in their colo and nodes running on Equinix Metal all at the same time, all on the same stretch cluster. And so basically that whole promise of hybrid and multi-cloud becomes true because we can move workloads around simply by relabeling, retagging pods that exist inside a Kube.
Whether those pods are single binaries or whether the pods are VMs running inside of a pod, we have the capabilities to shift that all around. And then of course, under the hood we’ve got NetApp’s Data Fabric technology. So what we’re seeing there are some really interesting use cases, whereby they may have Fluid nodes running on AWS bare metal instances, Fluid nodes running in Equinix Metal and bare metal instances of Fluid running on a bare metal hardware in a colo. And what we’re seeing is that whole hybrid and multi-cloud story becomes true because those resources are able to be seen in that single homogeneous pane of glass inside of BlueXP.
And when we deploy a workload, we deploy the workload into that stretched cluster if you like. And therefore, the ability to move them between clouds is as simple as labeling and tagging pods, whether they’re single binaries or a VM running as a pod, we can shift those around between locations, and then Fluid’s magic is handling the networking elements. And then we lean upon, of course, the NetApp Data Fabric technology to make sure that the data gets to the right place at the right time. So again, it’s another example where Fluid and NetApp working together to make that hybrid multi-cloud story come to life.
Justin Parisi: As far as your integration with NetApp goes do you have hooks into things like SnapMirror and replication outside of Astra Control? Is it just basically something that you have to cook up with REST API on your own, or does Fluid kind of handle that for you?
Andrew Sjoquist: Something where we ‘ve tossed around a lot internally is, how deep do we go from an integration perspective? Because a lot of that functionality and tooling is already available in BlueXP through the other services that are exposed. And certainly as that continues to evolve and System Manager features end up in BlueXP and a lot of that will already be exposed within BlueXP. So, we make use of the open integration standards that exist from the NetApp tool sets that are out there. So a good example of that is Astra Trident, and, great CSI that is evolving, huge leaps and bounds every time it’s released which is pretty regular.
And so a lot of that functionality around controlling the snaps and sending instructions to the NetApp Data Fabric and the cloud services we leverage through the CSI interface. So what it means, from our perspective is we don’t have to necessarily do a lot of deep integration with understanding how NetApp does its thing.
We can rely upon Kube and CSI and Trident integration to basically handle those things for us. So a lot of that is inherently supported out of the box, the ability to turn up a Fluid platform literally in a matter of five, six minutes and then connect it back to Astra Control Service. That’s what real integration, true partnership’s about is being able to leverage those around you that are good at what they do. And we see NetApp as being the best of breed in terms of data management. And so rather than reinvent those components, we’ve integrated and the perfect I guess melting point or melting pot for those things is to, to have the meat inside of BlueXP.
And that’s exactly what we do.
Justin Parisi: Sounds like you’ve got a lot going on there with Fluid and BlueXP integration, and I think it’s worthwhile for people to go check it out. Is there a place where we can find more information, other than going to the BlueXP interface and clicking on that particular icon?
Or do you have independent places for people to go in case they don’t have access to BlueXP?
Andrew Sjoquist: Yeah, sure. So you can go to our website, Fluidhq.io, and there’s a bit of a background there, some case studies overview of how the platform works. And of course, anytime you can find us also on Slack. FluidHQIO.Slack is our workspace.
So feel free to reach out, or of course on LinkedIn. You can find me there, Andrew Sjoquist, spelled S-J-O-Q-U-I-S-T or my other co-founder is also there as well, Alex Turner. Feel free to reach out to either of us and we can put you in touch with the right people and really enjoy hearing about different solutions and scenarios and challenges and working with customers to see where the Fluid can help resolve some of those in real world environments.
Justin Parisi: Yeah, and we’ll include those links to those pages as well as the email addresses in our blog, so you don’t have to worry about writing those down as you’re driving.
Andrew Sjoquist: Thank you Justin.
Justin Parisi: Safety first.
Andrew Sjoquist: That’s it always.
Justin Parisi: All right, that music tells me it’s time to go. If you’d like to get in touch with us, send us an email to firstname.lastname@example.org, or send us a tweet @NetApp. As always, if you’d like to subscribe, find us on iTunes, Spotify, Google Play. iHeartRadio, SoundCloud, Stitcher, or via TechONTAPpodcast.com. If you like to show today, leave us a review.
On behalf of the entire Tech ONTAP podcast team, I’d like to thank Andrew Sjoquist for joining us today. As always, thanks for listening.
[Podcast outro music]