#150 Unlocking the Power of Data Science in the Cloud (with John Knieriemen & Solongo Guzman)

Open up your thinking in your mind. Right. Because now that you're in this new world, the barriers, in my experience, become lower. Right. So if you have a barrier, you've got a roadblock. If you're not meeting the price that you need, the performance that you need, don't stop with, it's okay, good enough is good enough. I'd say open up your mind and say, there's a better way.

Hi there, John and Solomon. Great to have you on the show.

Hi, Richie. Thanks for having us.

Thanks for having us.

Brilliant. So I'd like to kick off with a little bit of motivation. So can you just tell me why you might want to move your analytics to the cloud? What's the pitch?

Yeah. So again, thank you for having us, Richie. This is a really exciting discussion for me and really looking forward to our time together here. You move your Anzulitics to the cloud primarily for the flexibility the cloud allows. And in the prior model and the on prem model, a lot of times you don't have the flexibility you need from a data analyst perspective, from a data science perspective, you're subject to creating an on prem infrastructure that requires regular updates. Internally, there's process. You don't get the flexibility that you need. And sometimes the cost is not what you need as well. Some organizations have decided that they want to get out of the business of managing a platform. They want to be more strategic in the way they interact with technology and choose technology. So at a high level, that's really the high level pitch for moving analytics to the cloud.

And since there's a lot of bits of analytics stacked, there's a lot of things you might want to move to the cloud. So can you just talk us through about what are all the different parts that you might want to move to the cloud?

Absolutely. So in terms of layers, you can think about your analytics layer as the storage layer starting out, and then there's the integration ingestion layer, there's the processing layer, and your analysis layer. So the easiest way to approach this is starting with your storage layer. So Cold Object Store is relatively cheap in the cloud. So that can be your Amazon S3, that can be your Azure Blob or Google Cloud storage.

So.

So that would be a great place to start. And then you connect that with your enterprise data analytics warehouse or database, and then you have the composable services that you can start playing around with.

Okay, so you're suggesting you just start like just you got a load of files lying about, shift them to the cloud first and Then sort of worry about the analytics later. That's kind of interesting. Okay, so I guess before we decide that moving everything to the cloud is a brilliant idea, what are the alternatives to this?

Yeah, so there's basically an alternative to have either a full on prem infrastructure, a hybrid infrastructure, part on prem, part in the cloud, and then all in cloud. So those are really the three different scenarios. The benefit of all in cloud, as you look at what I said earlier around the flexibility and the ability to design your architecture in the way you want to design it, it's really optimal. I sat down with a chief data officer a few months ago and she basically told me, she said, I want my architecture to be like a Lego set. I said, what does that mean? She said, I basically want it to have those nice holes and fittings that fit together nice, that then I can design it the way I want to design it. So that's really what a lot of organizations are looking for. So that cloud really enables quite a bit of that. Some organizations, if you go to the other side, have a need to be fully on prem, whether it's regulatory concerns around security or having the ability to control their whole destiny end to end. Some organizations are doing that today. And then I actually see a growing number of organizations in the middle with a hype, right? Some part on prem, part in the cloud, and they're making decisions for those environments, deployments based on what they're trying to achieve.

And so if you are going to push things into the cloud, it seems like maybe the reason you talk about to keep things on premises is going to be worries about privacy and security and things like that. So how do you address those if you're going to move to the cloud?

So at a high level, when you move into particularly a public cloud provider, their whole business is centered around security, right? Particularly the three major cloud providers. If they don't have tight security for both public and private sector, they really won't have a business. So those organizations have really excruciatingly tight security that they follow. And then all of the technologies that fit within that environment are naturally as secure. So from a security perspective, when you're kind of all in cloud, you're doing the analysis on the public cloud provider side and then fully on prem. You have to do all that yourself, right? You do all that vetting yourself and work with either a software provider and or your security team within your organization to figure that out.

Okay, so it sounds like a lot of this is about how much do you want to do yourself versus how much do you want to outsource to other platforms and tools?

Correct.

Okay, so are there any economic factors that drive this sort of migration of analytics to the cloud?

Cost savings? I think it boils down to how much upfront expenditures you're willing to kind of forego. The process of provisioning a physical infrastructure, where we've seen it's a very. It can be a very long process in a large enterprise. It starts with infrastructure planning, architecture design that can take anywhere between, you know, three to four months. There's an internal certification process. Typically we see this in financial services. So there's the infrared design pattern documentation, and that can take anywhere between five to six months. And then there's the actual physical hardware delivery and the installation of the different environments, DevTest, ProD and the data centers. So by the time the business has access to the environment, it can take as long as 12 months. So with the cloud, you're foregoing that. And with the pay as you go model, you pay for only the resources you consume. So that eliminates the need for you to provision the resources up front. And it's also increasing scalability and agility. So what that means is you're able to respond effectively to fluctuations of workload, so you're able to reduce the need for over provisioning and you're able to scale much faster. There's increased operational efficiency, so there's overall reduced maintenance and downtime. The economics are incredibly attractive for going to the cloud.

Okay. I think saving money and doing things faster, that's a pretty strong argument for making the move. So what's the initial trigger in general? So what's the point where companies realize, okay, we need to start doing this migration?

Yeah, I would say there's several triggers. First and foremost, it's, are you able to meet your business needs and objectives in the way that you've designed what you've designed? Right. So you think about the data scientists and the data analysts. Are they able to be the most efficient in their role? To be able to succeed fast, fail fast, to be able to get the performance they need, to be able to access the data they need across the organization? If that is a concern, that would be a trigger, Right. To look at what type of. Is it a deployment model issue? Is it a process issue? Right. It's not always where the data sits or how you deploy it. Sometimes it's just a matter of process and how the organization is structured by who has access to data and how they access. I would also say that to Salambo's, point, costs could be a driver, right? When you look at the cost and look at sometimes on prem, you have to design for worst case scenario. So you're designing this, this kind of a unilateral architecture that is worst case scenario versus being able to, to her point, be able to use in a consumption based model just exactly what you need. The third one is probably the most obvious. Sometimes there's a mandate from a C level executive that says we shall go to the cloud and that, that gets everybody kind of rallied that direction.

I certainly think those economic drivers are kind of pretty relevant at the moment. There's a lot of companies trying to cut some costs. But on that last point, I have a feeling a lot of our listeners might be the people who are like having to implement this sort of stuff. Suppose your CTO comes to you and says, okay, we need to move all our analytics to the cloud. Like where do you start?

Where we see this is, and I'll just chime in, maybe John can add is really use case oriented. So you know, the market has changed quite a bit. Generally we saw a decade ago the CTO CIO driven top down decision making, but now you see this mass consumerization of data and analytics. So what that means is the business and the users are really creating these use cases. It's really use case oriented. So if they have a need to go to the cloud, they need to do it quickly. You know, they want to modernize their solution as opposed to doing a more lift and shift. Because if you have silos, if you have issues on premise, why would you want to migrate that onto the cloud? So you want to take a much more holistic approach and you know, starting out with maybe the highest pain points and say what is the use case that needs to go to the cloud and start with that and then maybe adapting a proof of concept and starting there because the cultural aspect might be one of the biggest barriers of this migration.

That's really interesting, the idea that I guess it's true in every company where they're like, oh, I hate the structure of our data. We've got data silos everywhere and it's probably like one magic company where they have that problem. But the idea of just changing your infrastructure gives you the opportunity to, to just rebuild things from scratch and maybe do things better. Okay, cool. All right, so you mentioned starting with high impact projects. So I'm wondering what the trade off is here between like starting with high impact projects versus starting with low risk projects. Like what's the sort of Thinking behind how you decide what, what to move first.

Yeah, I would say organization is different. When you look at, I mentioned earlier around the projects that are creating the most pain, I think those are probably the most obvious, right. So the pro, the situations where you're physically hindered in your role as an analyst or a data scientist, those would be the potential ones to Solongo's point, that you may move like right now because there's not a lot to lose in that. The risk is very low on that one. There's probably only upside to that situation. There's maybe other ones that if you can use the analogy, it isn't broken, don't fix it. Maybe those you would look at and put those further on the roadmap. So being able to look at the ones that are creating the most pain, the ones that are running okay, and then systematically migrate and when you get to the ones that are running okay, you might even make the decision to do those as well. Because there's an economic advantage to having everything in a cohesive environment.

I think hopefully people are sort of sold with the idea that this is a good idea to move things. Who needs to be involved in this process?

It's everybody. So especially you know, now when you. Gartner has done phenomenal job, you know, with their data analytics maturity model and the frameworks. So the simple answer is the business and tech teams both need to be involved as, as well as the executive decisioning. And a cloud migration is a strategic decision. So you need to have obviously the executive buy in. But in order to move the organization up the maturity model, you need the entire organization on board. That means the business teams, the tech teams and the leadership.

Okay, so that's a lot of people. So by the time you got the users and anyone who's involved in data and anyone who's involved in IT and leadership. How do you manage all these different teams working together? Because I imagine they're going to have different viewpoints on what to do.

The way you kind of manage IT is really bringing the teams closer together. So, you know, in the, in the traditional model there is, you know, an IT perspective on the types of technologies that would solve a business challenge. So there was already that should have been that natural relationship with the business and it. But at the end of the day, the IT group would normally say I can or can't do this depending on the technology in the stack that, that I'm aware of. In this other model, it actually with, with more flexibility comes more responsibility for the data analysts and Data scientists, because now they're in a position where the, the operational side is mostly covered. Right. Because you're in an environment that, as we talked about earlier, is secure and works well together and is a marketplace of tools and solutions. So at that point the data analysts and the data scientists become more powerful to be able to make those types of decisions. But the IT group still being informed is extremely key. Right. So any organization where there's decisions happening in silos, and I've seen both, where IT is designing and building, they will come. And I've seen the business side making unilateral decisions. If the business side is making unilateral decisions, the risk is that there's a lack of governance and potentially a high cost. Right. Because they're deploying at will and siping their credit card and things can get out of control in all different areas. So there's still a requirement to have to sloanless point, people very tightly engaged across the organization and then from an executive perspective that they're aware of the opportunities and the risks and they have full support for the organization as well.

And do you have any sort of tips on, it seems like communication sort of the big key here. So do you have any tips on like how to like communicate across teams or how to sort of manage these, these big processes?

So center of excellence have worked really well, especially in big complex organizations, bringing a committee together and having various members from the stakeholder group work well. But also we're seeing it happen at a grassroots level, for example, at a big customer. We have advanced analytical capability now in the cloud. And now the users have never had this kind of access before. So now the question has turned into who has this data and when can I use it? And, and by default that process has allowed closer collaboration of the different teams.

That sounds pretty cool. And so maybe I'd like to hear a bit more about some of these success stories than you've had with your customers. So can you tell me an example of when the customer's been through this migration process and then they've had a big win from it.

We had a large healthcare company that we work with, us based healthcare company who made the decision to move to the cloud. Their decision was based on the fact that they wanted more flexibility, they wanted more agility and they had a theory that there was cost savings. So they ended up taking their current on prem data, moving it into Object Store and the cloud provider that they were using and that created a layer by which they can then make the decisions to the Lego analogy, how they plug the Legos in the engines in to optimize that stack. And it's, I'd say it's still a journey. What I applaud them for is they haven't, they've been flexible along the journey. And that's one thing I'll stress is that the journey, the first step of the journey is critical to get the foundation built. But then you need to be flexible as you move through the journey and the cloud allows that flexibility. So they've taken a constant look at what engine's best for what job, what types of AI and ML tools are best for the teams. And it's been a very collaborative group and we've been honored to be able to work with them too, around some things around performance and some of the things that we provide. But it's just been a very to applaud them again, they've been very flexible along the way and along the path. And back to your question about organizational. They've created a structure by which they have a center of excellence. They have regular meetings and interactions across the business and the IT groups, but then also with executives and they run very cohesive unit.

Okay, so it sounds like the big win for them has just been sort of increased access to data and maybe are there any productivity benefits that go along with that?

Yeah. So when they started this journey, the data analysts and data scientists were complaining because sometimes they could only run three or four questions of their data in a day. Right. So one or two hour queries, things are just getting out of control. They'd go grab a cup of coffee and by the time they came back, the query may be still running. So. So they were ineffective, inefficient because they couldn't succeed or fail fast enough to be productive within their organization. So when they moved into this cloud environment, they were able to select the right tools to be able to optimize. And now the data analysts and data scientists are far more efficient in being able to ask far more questions of the data for a lower cost to be able to leverage those tools in a consumption based approach.

And oh, so you mentioned this was like a healthcare provider and I have to say like data camp, because we're sort of tech startup. Like we're of course like you do everything in the cloud, but I guess it sounds like a lot of the sort of benefit from this migration. It's going to be older companies and perhaps larger organizations. And would you say that's an accurate description of your customer base? Like who cares about this?

The Most, No, I would say it's actually particularly interesting for mid tier companies because mid tier companies don't necessarily have the massive amount of operational resources to support in the way that they need to support. This particular healthcare company was a large one that decided, we don't want to be in the business of doing this, even though we could. We don't want to be in the business of managing an operational platform. But for mid tier organizations, we met with one last week where we had one guy who was basically running the whole shop and he was a solo guy running the whole shop. And so in that situation, cloud makes a ton of sense because you're able to leverage all of the operational support and the whole marketplace of tools and solutions you get when you can't necessarily afford to hire a whole team, a.

Lot of Fortune 100 companies and the power going back to the business users. So instead of relying on it, we have teams, know, and two of the large telcos, they run their own infrastructure. So they own it, they run it. And, you know, a lot of the overhead, operational overhead is outsourced so they can be freed up to do more strategic work.

With a large cost project like this, for migration to cloud, you're going to want to see some kind of returns and you want to know how to measure those. So can you just talk about, like, what's the measurement for the success of this?

Absolutely. I think the first and foremost is why did you set out to do the project from the get go? Was it cost savings, was it scalability, was it access for compute resources? So I think that's the initial uat, if you will. But the ultimate success is what we're seeing with our customers is data availability and accessibility. So when you have a single source of truth and improved governance, improved security, there is sort of a data flywheel happening where more users having access to the right data that they need at the time that they need it. Now the business is able to effectively harness more value out of their data. So it's going back to climbing up the maturity model and using data as a strategic driver for the business.

Okay, so you really have to define some goals then upfront before you actually embark on this. If you want to be able to sort of accurately measure how well you're doing at the end of it, that makes a lot of sense. Okay. On the flip side, are there any things that can go wrong? Like, what do you see are the most common problems?

Yeah, I'd say that what can go wrong is maybe the first. What we said could Go right. It's when you don't go in eyes wide open, when you haven't done your due diligence to map out what you believe the business opportunities are, where the gaps are, how you can optimize for cost, how you can optimize for performance. And some people go in sort of with blinders on to think that there's a utopia and they come to find out that they'll lack of planning means that they're in a worse place than when they started. Right. So I would stress that doing proper planning, making sure that you understand what the gaps are, what the trade offs are and make the right decision for your business. And every business will be different. Some will be full all in cloud, some will be full on prem, some will be a hybrid depending on your model and the market you're in and all that. So I would say that planning is extremely important. And being realistic about when you're going to have those quick wins and where you're going to build the foundation is also important.

It always disappoints me when like planning is a thing that you really need to do to be important. They want to dive right in. I've got to be patient. So yeah. All right. So planning seems to be a very important thing. Having some goals seems to be an important thing. Are there any other tips you have for making sure that a migration project is a success?

Yeah, I think it's arming yourself with as much knowledge. I think now that the responsibility shifts back to the users. You really have to know a lot about your cloud platform of choice. You got to know how the tools and the interoperability works. Because going back to the risks, you can never eliminate the human error. Cloud might be one of the safest places because of the robustness in security features, the data encryption at rest in transit. But you know, there are incidences of not provisioning things properly. So, you know, just knowing as much of this incredibly powerful capability will make sure that it'll be the best way to mitigate any risks.

Yeah. I would also add that it's important to design that center of excellence we talked about earlier. That is educational center of excellence. And where I see some organizations struggling as well is fitting a square peg into a round hole from a tool perspective. Because some tools are designed for performance, some are designed for ultra flexibility, some are designed for just low cost. Right. So if you use the tools in the way that they're not designed, you know, you could escalate your costs and then hurt your ability to get the Performance and the data that you need, need and then being able to design that data in a foundational way to be able to access the data you need across the organization, not for the silos. Not locking the data down for users is important in creating that center of excellence and having kind of a shared network where people can share, hey, I used this tool for this and it worked well. And be able to share among the company and organization is best practice.

So you mentioned this term center of excellence a few times. So I mean, curious as to what this involves. Is this like a dedicated team from who had just dedicated this one project or what's the deal here?

It's all of it. So it's a team, it's a process, it's a mechanism in place where it allows you to make this incredibly otherwise complex project happen. So we're seeing cloud center of excellences. We have the, our own database center of excellence in certain customer sites where it allows people from other parts of the business and department to come together and share knowledge on an ongoing basis. So there's transparency. So which when there's transparency there's better control.

Okay, that sounds like a useful thing, just having everything together in one place just so you can make sure that I presume it makes communication easier if everyone's not sort of spread out around the globe and in different teams with different needs. Okay. All right. So we talked a lot about the sort of general migration process. Maybe let's focus on databases since of course Exasol, you're primarily a database company. I think that's a fair characterization. So I guess the big names in cloud databases is things like BigQuery and Redshift and Snowflake. So how does Exosol compare to those companies or those platforms?

Yeah, so I'll kind of start with the business challenge again we discussed earlier. So there's kind of three different balancing acts, if you can think of it that way, is the ability to have choice within the databases you select, the ability to optimize for cost and the ability to optimize for. So those are sort of the three balancing metrics. You see with databases. We call ourselves a no compromise solution. So we're able to properly balance that. We've got a very strong foundation around an MPP based architecture that can scale concurrent users and scale data seamlessly. But then we have the in memory technology that helps it operate very efficiently and very rapid, particularly at the, the BI layer. Right. When you need to have second sub, second type response times within queries. And then we have Some things that virtualize. So we have in our database the ability to reach into different data sources, natively structured and unstructured, to be able to pull that data in so that the data analysts and data scientists don't have to worry about different systems and bringing systems together and moving data around. You can natively pull that in. And then we have things that are just native within our solution that make it easy to operationally manage. It automatically creates the primary index and those sorts of things. So we're excited to be able to offer the market. It's a no compromise solution when you look at those balancing metrics.

So it sounds like high performance was a big part of your pitch there. You sort of mentioned like the sub second query times and things. Is it just about chasing faster query execution or are there other parts to. To improving the performance of people working with data?

At the mechanical level, it's two things, Richie. It's faster ingestion and faster query times. But going back to what we said, we really focused on use cases and outcomes. So faster queries and faster ingestion mean a lot of things for our customers. So typically when we're working with large enterprises, they're coming to us with specific purpose and specific outcome they want to achieve. So they want to increase revenue through strategic pricing and customer acquisition, or they want to reduce costs through reducing operational expenses or reducing risk and meeting compliance. So we are really focused on delivering what that use case requires. So it's much, much more encompassed and wrapped around faster ingestion and faster query times.

So I quite like this idea of focusing on the use case and just sort of getting beyond like just, well, you know, can you crunch SQL really quickly? Can you maybe give me an example of one of these use cases where you've had to sort of tailor what the database is doing to meet that need?

Yeah, absolutely. We have a telco customer that has a really useful use case. They're doing network optimization. So what they do is they have different data analysts and modeling teams. They generate models that make recommendations to improve 5G configuration plans and designs. And that also includes infrastructure acquisitions, which can be really expensive for telco. So they're able to predict using models, you know, what type of investments would yield the highest ROI and what type of specific configurations, cell tower configurations. And they're able to track the progress of that using third party external crowdsourced data. So it's a full circle of not just providing the recommendations, but also seeing the progress and tracking the progress so that they can improve their models. And continue being that vital part of business decision making.

Okay, that's actually a really interesting use case because it sounds like if they're using external data sources, you've got like a data engineering component for like bringing everything into the database. And then it sound like some kind of optimization or maybe machine learning on the other end of it as well, like some fairly sophisticated analytics. So how does the database fit into that kind of broader like technology pipeline?

Then when you look at the pipeline, right, so you have the ingesting of data, the database is really the horsepower, the processing part of it. Right. So. So whether you're running an AI and ML model, whether you're running a report in a, in a BI tool or solution, the horsepower usually comes from the database itself. Right. So database really offers, it's a make or break in a lot of cases to be able to offer the performance that you need across the. Now I won't minimize other things like being able to properly prepare your data. And sometimes the ingest process is broken. So it's not just the database is the magic silver bullet. It never is. Right. It's the end to end process. But the database is sometimes a key bottleneck for organizations if it's not utilized correctly and you're utilizing the right technology again for the right job.

That's a really good answer, John. So we typically see three deployment patterns. So there are three main use cases that a data consumer can get to the database. So you have the traditional Data engineers and DBAs using SQL and accessing the database like XSL. Or you have the data analysts going through a BI reporting tool like Tableau or Power BI. And then you have the data scientists go through going through a Data Robot or SageMaker to access the database. But nonetheless it is the compute engine. It's sort of the heart of the operation. So when you have BI users complain how slow the dashboard is, it's actually the underlying database. So a lot of the kind of credit goes to the front end. But what's actually happening is what's underneath the hood.

Okay, yeah, certainly I've seen that where you've got a really clunky dashboard. Well, sure. What's going on there? Maybe it's like it's the processing upstream from the dashboard that's actually the problem. All right, so. Oh, John, you mentioned bottlenecks. And I'm kind of curious to hear about. Are there any more examples of like analytic problems where it really benefits from that more powerful database engine in the middle?

Yeah. So pretty much any industry that needs to make decisions in a quick enough period of time to actually affect, make or save money are critical. And I'll use a couple examples. One's from retail, right? So you have a call center, you got people that are taking calls. And a lot of call centers are selling centers in some cases, right, where they're able to not just support the customer, but also to sell or upsell the customer. So in those types of situations, we work with a retailer around being able to do that in near real time so that as the person is sitting there with the individual on the other side of the line, they're, they're running not just analytics, they're running predictive analytics. So to Sloan's point, they've gone up the maturity curve where they're saying this person's calling. This is what we. Based on all of the people and crunching in real time and the market and the day and whether it's a holiday or not, they're able to make a predictive theory about what you should be discussing and presenting to that customer. So that's ultra critical that you've got an engine, a database that's able to, to do that. Another example is we're working with a high tech company around sustainability, right? So basically for all of their physical locations, they're attaching Exosol to be able to monitor energy consumption and usage in near real time, to be able to make those adjustments. And again, it's not just descriptive, it's predictive analytics. To be able to predict based on these types of energy consumption behaviors. We're going to go and adjust and, and optimized for sustainability.

That's actually pretty cool because I guess when I think of databases, I'm thinking of just doing really sort of a simple business analysis, crunching numbers. And once you start getting to doing predictions, a bit of machine learning, then that's where you break out Python or R. But actually the database part of that, from what you're saying, sounds like this is still really important because you got to get the numbers processed in the first place before you even start trying to do any of that. Okay, cool. All right. Are there any, I guess for people getting started with this, there's gonna be a lot of organizations who are just trying to figure out cloud migration now. And so you mentioned having greater access to data was, was one of the big benefits, I think, for your healthcare example in general, how do you think about data governance more generally at Exosol?

I think by process of migrating your analytics to the cloud, you have better metadata Management, better cataloging, you're improving governance. We have seen that with a large customer where it's been traditionally on premise and they had siloed data sets in their own business units, so there was a dispute on who had the source of truth. So by effectively having they have a data lake now on Exasol in aws, so there it's a single source of truth. The governance has just improved and the business has access to already cleansed, wrangled data that the data scientists and modelers just can run with it. So it's. They've seen improved governance, they've seen improved security by having a central repository.

So I'd like to talk a little bit about skills and does moving your analytics stack, like if you put it in the cloud, does that change the skills that your data analyst and your data scientists need?

I'd say absolutely. The point made earlier, with much flexibility comes responsibility, particularly for the analyst, data scientists, the business user as we call them, to be able to be more in tune with not the depths of a technology, but how a technology functions and how it should be used. Because essentially now that it's on their shoulders in a lot of cases to make that selection to pick the right tool for the right job, to not fit that square pattern into that round hole. So they need to be more in tune with the types of technologies. Again, not full architecture understanding, but enough to know when to deploy, which again, Lego on top of that LEGO set for the particular thing that they're trying to achieve.

I kind of like that. It's like I don't need to understand the architecture, I just want to play with Lego all day.

I have three young boys at home, so it resonates with me. I step on them on a daily basis, unfortunately, but it resonates.

Nice. Okay. And so if you're working on problems where you do need high performance. So you mentioned some examples of like working in retail, you need to get the answer in almost real time. So if you do have that sort of need for like really fast analytics, what sort of skills do you need to get there?

Again, it boils down to the database Richie, because the front end tool is only as powerful as the underlying database. So we see very common in the market. A Tableau is, for example, a popular dashboarding analytics BI tool and you're able to do only subsets and extracts, versus with Exasol, you're running analytics on a live data set with through a live connection. So that really empowers the data scientists and analysts to do more analytics. Richer analytics on bigger data sets and fresher data sets. So really, when you're playing around with powerful engine, powerful tools, especially in the cloud, when you have plethora of microservices, you have to know how these tools work together and really understand the power of this. Because the flip side of going with the pay as you go model is if you don't know how to properly use it, the cost overrun can really be a surprise. And you don't want to get that surprise bill at the end of the month. So you have to know how to provision them, you have to know how the tools work together.

I was chatting to a data engineer recently and he was just like, oh no, I left this database Running for 10 days, I didn't really remember it. And he said, yeah, you just got.

The bill for that.

So certainly remember to turn off services you aren't using. Very good cloud advice. But so I think to summarize your point there, you were basically saying that like, if you want high performance stuff, you just need to buy the right tools first that are going to deliver that performance and then learn how to use those tools properly. And that seems to be the order rather than think about skills first and then figuring out tools after you've got those skills. Does that make sense? Is that what you're saying?

It does. And I would also add that having the ability to work with it is important as well. So having that sort of people interactions to be able to work well together with the team is important because is again, not the tool doesn't solve everything, it's the whole process, end to end. And for those data scientists, data analysts that have regularly scheduled interactions with it and view them as a business partner, those are the ones that are most successful.

And I think one thing that's sort of come a few times here is that you need to know a little bit about like what the database is doing, what all the other tools are doing. Even as a data analyst or data scientist, like we're actually kind of using these things. So are there any particular things that you think people need to know about, like the underlying tools and infrastructure?

Yeah, I would say that, you know, some technologies, as a data analyst, data scientist, you can hit select star and it's not going to crash the database. Others it will basically totally crash and you'll be in a bad state. And so I think understanding enough about the types of ways that you would interact with the tool, the things that are okay, the things that are not okay, and understanding those boundaries, some tools have some databases have good workload management capabilities to be able to have one data analyst and a prioritization because they're running something critical for the CFO and the others are going to take in lower priority that some tools have that some don't. And so being able to understand that well enough to be able to go back to the IT group again and say, hey, I really need priority this week because I'm running this particular thing, that's really important.

And just to wrap up, do either of you have any final advice for organizations sort of wanting to migrate their analytics stack to the cloud?

I'd say start with a POC and really look at what is highest pain point, what's the most critical and start small and take a graduated approach and start with just the storage layer and play around with the microservices and you know, see where it goes. And it's also important to focus on the quick, quick wins while building up that long term strategy.

Oh yeah, proof of concept and getting a quick win seems very useful. Especially you've got impatient managers wanting to see results. And John, how about yourself? Any last advice?

I agree. Everything Solango said, I would also say open up your thinking in your mind, right? Because now that you're in this new world, the barriers in my experience become lower. Right. So if you have a barrier, you've got a roadblock. If you're not meeting the price that you need, the performance that you need, don't stop with it's okay, good enough is good enough. I'd say open up your mind and say there's a better way. There's a lot of tools out there, there's a lot of things we can do. And it's really exciting when organizations kind of open up their thinking and say we can achieve what we need to achieve.

Fantastic. And with that. Thank you, Salongo. Thank you, John. It's been great having you on the show.

Thank you, Richie. Thanks for having us.

Great. Thanks so much.