Orchestrate all the Things - Streamlit wants to revolutionize building machine learning and data science applications, scores $21 million Series A funding. Featuring Streamlit CEO/ Founder Adrien Treuille

Episode Date: June 16, 2020

Streamlit is an open source framework that wants to revolutionize building machine learning and data science applications, and just secured a $21 million Series A funding to try and do this. Streamlit wants to be for data science what business intelligence tools have been for databases: a quick way to get results, without bothering much with the details. In today's episode, we welcome Streamlit CEO and Founder, Adrien Treuille. We discuss what makes Streamlit special, how it works, and where data-driven applications at large are going next. Article published on ZDNet in June 2020.

Welcome to the Orchestrate All the Things podcast. I'm George Amadiotis and we'll be connecting the dots together. In today's episode, we welcome Streamlit CEO and founder, Adrienne Trey. Streamlit is an open source framework that wants to revolutionize building machine learning and data science applications and just secured the 21 million Series A funding to try and do this. Streamlit wants to be for data science what business intelligence tools have been for databases. A quick way of getting results without bothering too much with the details. Adrian and myself

discussed what makes Streamlit special, how it works, and where data-driven applications at large are going next. I hope you will enjoy the podcast. If you like my work, you can follow Link Data Orchestration on Twitter, LinkedIn, and Facebook. So I think we're ready to go, right? Mm-hmm. Okay, great. So yeah, thanks for making the time. And, well, a typical way to start this kind of conversation is, you know, by asking the people with whom I have the conversation to say a little bit about themselves and their background and what they're working on and all of that. The floor is yours. So I came to being an entrepreneur via academia,

actually. I was a professor at Carnegie Mellon and I was doing machine learning and big data before it even quite had those names and certainly before they were cool. And I then went to Google X and I started working on AI projects there. And then I went to Zoox and I worked on self-driving cars there. And I saw basically a similar thing happening in all these places, which is that the promise of machine learning and artificial intelligence, which can really, you know, it's sort of the key to these next generation businesses, really, in decision making, was often sequestered in those groups and not influencing the organization as well or easily as they could. And so I started building basically a project for myself to solve this for myself personally. And that started getting used by a bunch of different engineers and quickly grew into investment float in and had a big open source launch. And that sort of flowed into what Streamlit is today. Okay. So just to get an idea, you know, of the timeframe, how long was it that since you started, since you came up with the idea, since you noticed the problem and then, you know, you came up

with the idea and started working on that initially on your own. And then if you could also mention a few words on on your team basically the people you have built because I guess you know what you just referred to is basically the origins of streaming so if you would like to say a few words like you know who joined you and when and at some point and you know what what your team's like yeah so we did something a little bit unusual for a startup, which is that we waited a long time to launch. But during that time, what we did do is we had great, first of all, great co-founders coming very early and then great users coming in very early. So really, the story was I built something that I thought was cool for myself. It was not meant to be a

business. In fact, my mom was like, if you're going to spend so much time on this, you should make it into a business. And I was like, oh, that's not possible. There's no business model. It's just for me. But what I started doing was showing it to friends. And in particular, one of my friends, Tiago Teixeira, who worked with me at Google X, I was like, this is cool. You should check it out. He started immediately. He was like, I want to help you build this.

So we started building it together. Then we started showing it to some friends. You know, we're old AI guys. So we knew a bunch of all of our friends from academia are now at Uber, Lyft, Google, Stitch Fix, Twitter, doing AI. And so we showed it to them, and they thought it was cool. And next thing we know, it's taking up all of my time, and a bunch of people are using it at some really great companies. And so fast forward a couple of months, and we're really, actually, we're like six to nine months. We have, it's really my full-time job at this point. And pretty much investors are saying to me, why aren't you getting paid for this? We'd love to put money in.

And I remember actually an investor gave me some really good advice. He said, it wasn't what you have to lose. Let me see. You know what, I'm gonna have to remember that one and I'll, and I'll, and I'll, um, um, but, uh, but, but, but the, but the essence of the advice was basically, um, you know, sometimes in life, when people start companies, a lot of the focus is on, uh, it could not work or it could fail in all these ways um and he was basically like you should also just bear in mind that it can succeed um that that can happen too um and and maybe you should just go for it because you know it can succeed too um and and in a sense so far that's what's happened to us and uh i'm so glad i i'm so glad i took that perspective actually

okay and since you spoke about investors um yeah it's probably useful to uh to clarify for the people who may be listening to uh to the conversation that you know the opportunity for having the conversation is precisely the fact that you're announcing your series A. So I was wondering again, if you'd like to say, well, a few words about who your investors are. I think you already kind of touched upon,

you know, what the main idea is, but if you don't, you know, since I'm pretty sure that this is something you've practiced, if you can do like the elevator pitch. So, you know,

one liner of, you know, what it is that you do with Streamlit and what makes it so great and a little bit of the business, let's say, background of how this Series A came to be. Yeah. Basically, companies across the country, not just big tech companies, but really mainstays of American industry, Caterpillar, 7-Eleven, are building machine learning and data science groups and are increasingly making decisions based on those groups. It turns out that to actually extract value from machine learning and data science

often requires taking this data and exporting it into the rest of the company in a way that can be useful. And that's very expensive to do. I'm not just talking about, let's do some SQL queries and let's just graph our sales for the past three quarters. I'm talking about rich you know, let's do some SQL queries and let's just graph our sales for the past three quarters. I'm talking about rich mixing data models into an experience that can be used throughout

the company, sort of part of the operating system of the company. It's very, very expensive to do. And at its core, what we do is Streamlit allows the data scientists and the machine learning engineers to build those apps themselves, cheaply, easily, as a byproduct of their existing workflow. And that is a real need. A lot of times, people don't even appreciate it, especially at the CIO level, CEO level. But on the ground, it's a real need. And so we created what we thought was a great way of doing that. You know, it was basically

literally a personal project that evolved into a company. And so it was sort of grounded in the experience of my experience, the experience of a developer, software engineer. And I think people loved it and they recognized, wow, this is fun, this is cool, this is fast, and this is doing this amazingly difficult thing that it was scoped for three months to build an app around this and we had to hire a team of five.

And lo and behold, I just did a very good first approximation over the weekend myself. And that's the cool factor. Okay. That was also my impression, you know, by just browsing through the information publicly available, basically. And, well, as someone who does have a certain background in application development, so in a way I

come at least from a different angle than the one you approached. I totally see why for someone with a data background that's classified in a very crude way. So yes, I totally get why people like data scientists, for example, are not necessarily familiar with how to build and set up and deploy an application. And yes, having something like this totally makes sense for them and makes their life easier and easy to show what they do

and so on and so forth. That said, however, and I think you have a very good description of that in uh this blog post you wrote to you know to basically kind of outline the whole idea behind what you do and you know where you want to go in which you talked about what you said the maintainability what you call the maintainability trap so So, yes, I mean, the data people do what they have to do and they get to a certain point. And then, of course, you have to go back and revisit your data sets and possibly revisit your models and add features and so on.

And you get into this kind of vicious circle where you always have to redo things. And as you also said, on the other hand, if you call in the application team, you know, they have all the right frameworks and, you know, they do a great job in this whole application development circle. But the problem is, as you said,

that, you know, at some point they go away and you're stuck as a data person, you're stuck on your own and, you know, you're not self-sufficient. You have to call them again back if you want to make changes and so on. And so you kind of try to bridge this gap. And I get it and I see the value in that. Where I would raise an objection to the way you're doing that is that, well, it's great

to have something quick and dirt, let's say, but for an internal project, it's fine. But if it's something that you want to share with the world, then I think what you're doing will end up getting out of hand. For example, relying on a single Python script to do things. Or you end up maybe reinventing things that web frameworks, which have been around for a long, long time, have already worked on. So how do you approach it?

Yeah, that's a great question. So I would say that we don't see that trade-off. And in fact, or rather, we do see the trade-off, but we do think we have a solution. So Streamlit apps are now used in companies by dozens, if not hundreds of people simultaneously. So we have an existence proof that you can take these sort of quick and dirty apps that you're describing all the way to production

and certainly not externally to the company, but internally for large teams. And that's really part of the dream. And I think that it's absolutely possible given the architecture that we have and the proof is in the pudding. Now, the other aspect of this that you brought up was, well, are we going to have to reinvent the entire web framework world and ultimately compete with this giant and beautiful ecosystem, which is how you build modern web apps? And for that matter, they include mobile apps.

And the answer there is actually, we don't try to compete in that sense. Instead, we view ourselves as a translation layer between the Python world and the web framework world. work world um so uh for example um everything in streamlet is actually written in react which is you know when you've discovered the joy of react it's like a programming nirvana and um and so uh and so we can actually take really almost anything in the React ecosystem, which is Uber's new mapping library or Facebook's new graphing library, and translate that into Streamlit almost effortlessly. And so our core technology is really that translation layer. And I would add to that

that we are releasing a feature called Custom Components in a couple of months, or actually one or two months, which is going to allow any developer in the world to basically translate any bit of web tech into a single Python function call as part of Streamlit. So we're really trying to take the best of these two worlds and simply marry them to one another while allowing each the python the incredible

python data ecosystem and the insanely rich interactive ecosystem of the web and mobile development allow those two ecosystems to flourish independently of one another okay Okay. So what you're saying is that you're basically leveraging React at the moment and just offering some kind of wrapper that enables Python programmers to leverage React components without having to learn React or JavaScript or any of that? Yeah, I would say I think there are two key ideas here.

First of all, while we use React, the component system is actually completely multi-paradigm. So we have examples of components written in React, in Vue, in ClosureScript, in Elm, in just raw HTML and JavaScript. So first of all, we don't have an opinion on the website, although we ourselves internally use React. Then as far as whether we offer, yes. So we do offer, the core tech is both a translation between the two so that you can call one from the other really easily. And it's also a theory of how event should be handled in Python, so that basically you can take an existing Python script and turn it into an app with almost no changes. So you basically just say, these constants, turn them into basically sliders or other types of widgets.

And then the entire app is sort of translated automatically by Streamlit. So, yeah, the core goal is we understand the lived experience of the data scientist, the machine learning engineer, well, at least we try to, we aspire to. and we want to make it so that app building is actually a byproduct of their work rather than an additional step. Okay, that does make sense. However, not, I would argue, you know, the counter argument that would be that, sure, data scientists are mainly preoccupied with very specific data science-y tasks. So, you know, fine, do a prediction based on that data set

or, you know, identify the patterns in the other data set and so on and so forth. While an application, on the other hand, is not all about that. So, you know, in the broader scheme of things, yes, you know, maybe even the heart of your application is, yeah, find recommendations, I would argue, is a good example for that. So, you know, all web shops today have them, and, you know, they're a useful feature to have.

They're not necessarily, you know, the heart of your application. So what the heart of your application is, I don't know, rent, make people watch movies, right? And you may add recommendations as a feature to make them add more movies. And fine, yes, to do recommendations, you apply a number of data science algorithm techniques on your data set, but your user has to log in, you have to keep track of what they watch,

their payments, and so on and so forth. So how do you marry those two worlds, basically? Yeah, yeah. That's a great question. And I think we don't aspire to be the front end to your entire company. If Netflix came to us and said, hey, we want to write the Netflix app website in Streamlit, we'd say we don't think that's a good idea. But underneath the hood is this sort of internal operating system of the company. And that app framework has very different properties, actually.

And that's where we think Streamlit really shines. And actually, your example of a recommendation system is very interesting. We've been talking with a very, very big tech company that has a huge product list and SKU list, and they sell these products to their customers. And the salespeople, they'd like to basically do a machine learning recommendation system for the product. So if this customer bought products A and B, then they might be interested in product C or J or whatever. And so this is something that was given to the machine learning team. And they came up with very beautiful models for how to do this uh that seemed to work well and now uh it's time to put this model in the hands of a hundred thousand sales people literally

and uh the uh and and the problem is now the core which is uh this machine learning model has to be wrapped into an app and then inevitably there have to be a million changes. This or that small thing has to change and then you have to add an additional field for this or that. And to have the data science team disintermediated from the end customer by the app layer is a huge source of pain, actually. And so to have them be able to more or less thinly wrap their models um it's not a perfect app for every application but it is a it's a thin and but yet beautiful and production worthy wrapping of their models in such a way that it can be directly exported to the sales team without disintermediation is something that stream, we think it's the best software in the world for.

And that's really the sort of what a core use case that we're really aiming for. It's an example of a core use case. I can give you others. Okay. Yeah, I would say that, you know, in a way it sounds like, yes, you know, it's not a generic, let's say, web development framework, but something I would liken most to something like what BI solutions did at some point. They would give you an out-of-the-box framework. If you used it, you would be able to build dashboards and present your pie charts and whatnot.

So if you were to build it manually, it would take a lot of work. They just gave you the framework, you filled in the data, maybe tweaked some parameters or queries and whatnot, and you had a functioning application for a very specific purpose with very little effort. And it sounds like what you're doing is something similar, except you're not doing it for data and pie charts and so on. You're doing it for machine learning models, basically. That's exactly right. That's a perfect analogy. Okay.

So one thing that piqued my interest in the information you shared previously was, yeah, how, and, you know, it kind of ties into how you're doing it in an open source way. And, you know, there's a whole discussion around open source sustainability and how that would work. And, you know, obviously you managed to convince some people that your business model is sustainable. So I was wondering if you were able to share a few words on where does the open source for free line, where is that line drawn in? What do people have to pay for and in what way? Yeah. So, well, we're very fortunate that we created this open source library and there was really sort of a global excitement built around it. Almost instantly, it was like what we thought was going to be

three years of marketing and blog posts explaining to the world why Streamlit is so cool. It seemed like it almost happened overnight. And people were just saying to another, oh, and you can use it for this. Oh, and you can use it for that. And it was truly amazing. It was truly breathtaking. And so now we're in a position where we see Streamlit used all over the world, including all over in giant companies know, giant companies. You know, we get inbound from Fortune 500 companies about how can we use it for this side of the other thing. And the problem which all these people are having is, okay, great, we can build these apps super fast and easily in Streamlit. Just like you said, it's not just graphing the past,

it's the models are in there. The whole Python data ecosystem is available to us. How do we deploy it? And can we pay you to solve this problem for us? And that's the business model, which is we let people, the app building is completely open source, it's completely free. It's actually community driven. So we have a lot of community involvement in that. And then the second half of the story is how do you deploy? And we encourage people to use GCP or Heroku or whatever other technologies they want, but we also have a first-party solution called Streamlit for Teams. And so we are able to take our customers from the app building all the way to the deployment with that same sort of Streamlit ease of use,

simplicity, fun, cool. That's the hallmark of the open source product. Okay. Okay. So just to make sure I got it right. So you're saying that's fine. You can develop all you want. And then if you want to deploy that, you're offering users the chance to do that on your own cloud? That's right.

So we're offering the users the chance to do that on our own clouds. And then we're developing a set of unique features which exist in the cloud version, which makes sense only for sort of collaboration teams and deployment. So, for example, better security features, secrets management, authentication, scalability guarantees. So we actually believe there's a lot of interesting things to do in the cloud version. And the cool thing about this approach is twofold. First of all, it means the customer gets the value for free, completely for free. And in fact, if they want to pay nothing, if they really want to do everything

themselves, they can even deploy it for free. And we're really happy for them to do that. The more people using Streamlit from our perspective, the better. So that means fast time to value, and you're not making this big bet. You get to know. Secondly, it's a very clean separation between the open source and the Teams version. One of them is about building the apps. The other one's about deploying the apps.

So we don't get caught in this trap that some open source projects get caught into, which is, oh, do we charge for this feature or not for that feature? You know, is the community going to be mad if they want a feature and we don't give it to them without charging them? We don't have that problem. It's a very clean separation.

And we basically give away app building for free and we charge for deployment. And on top of that, we feel like the, you know, the business model is quite de-risked because people want we charge for deployment. And on top of that, we feel like the business model is quite de-risked because people want to pay for deployment. So we feel pretty comfortable that there's a sustainable business model really staring us in the face. I was going to ask, so yeah, I mean, what happens if, you know, for whatever reason, performance, compliance, you know,

the usual reasons for which people want to stay on-prem instead of going to the cloud. Some users want to deploy on-prem. Can they do that? And if yes, how? So the answer is yes, but they have to do it on their own right now. So we actually have published some guides on how to do this.

And to a certain extent, we are available to help. So we actually have published some guides on how to do this. And we, you know, to a certain extent, we are available to help. We don't have a paid, you know, support plan or anything. But we try to be helpful when we can. And we're considering whether there's another interesting on-prem business to build as well. Certainly, it makes a lot of sense. And one of the cool things about Streamlit is that, you is that you can download it and run it on your laptop, and you can run it on an airplane, in airplane mode, and it doesn't require the internet at all. So using that property as a

benefit for customers who want on-prem deployment is something that we're considering. But we are launching with the SaaS model because we think it makes a lot of sense and it plays to our community strength, which is people on the ground who use Streamlit really love it. And we want to build on that strength too. We don't want to just turn around and now try to sell the CIO or CTO on some kind of giant deal. We want the people on the ground saying, look, I just did this cool thing. How can we support this company? How can we deploy this?

Okay. You mentioned something when you said that, which touched upon something I wanted to ask anyway. So you said people can use it on their own laptops. And to me, that implies a number of things. So obviously, you know, if you want to do that, you need to either have all your data there already, if it's the first time you're running it, because, you know, you need to run the algorithms and so on and so forth. So that is the case, I guess, right?

I mean, there's no other way. If your data is on some server elsewhere or in the cloud or whatever, you can't access it. So it has to be accessible. Well, I would take issue with that description. I would simply say that Streamlit is a Python package, literally. It's installed with pip, which is the Python package installer. And then it runs in bare metal Python, which means that...

So what that means is that it has exactly the same properties that any Python script would have running on your laptop or in the cloud. So what does that mean? You can use any other library with it, and you can connect any data sources you want with it. So if you have a Snowflake data instance, you have TensorFlow models and an S3 bucket, whatever, those are accessible to you both in the cloud and on your laptop if you have access to those things from your laptop. Sure, sure.

I'm not arguing that. I was specifically referring to use your laptop in the airplane mode. Oh, yeah, yeah, yeah. Yeah, yeah. So certainly once you turn on airplane mode, you need to have the data on your laptop. Okay. So yeah, that's a great point. And I think the point there that I was trying to make,

or really the thing I was trying to emphasize is that many pieces of software these days require that you connect to something online you know google docs you'll just watch this actually they have yeah um asana or something uh and so we uh we have a sort of more flexible model in that um you know you can uh you you can install it on your laptop if you wanted to and and it's perfectly workable but yes you do need to have the connection to get to the data okay so the second part of what i wanted to ask has to do with caching actually because this is something that you uh you mentioned in your description and it kind of caught my eye

because well basically because caching is uh you know as some people have said, one of the really hard things in computer science, how do you cache your policies and all of that stuff. So how do you cache, actually? I guess the first time you run another thing, you're not caching. You're actually executing. And then you specifically make a point of how you don't have to do it all the time. Of course, if your data doesn't change, you don't have to do it all the time you know of course if your your data doesn't change you don't have to do it all the time and we just you know use the results you have already so how do you do that where where do you cast and do people

do users have some kind of access some kind of control to how this happens uh yeah that's a that's a really cool question actually um so uh I'll maybe just take a step back and say that one of the things that makes, one of the basic assumptions of app development is that you sort of take these widgets and you put them on the screen and then you have to wire them back together in the back end using callbacks and so on. And so you're sort of starting at the screen and you're moving back into the data. And then you, by definition of, by that definition of an app, you know, you're always really controlling where the computation happens. And so that's how you make things efficient. Streamlit actually starts in the opposite direction, which is that we assume that you have some kind of underlying data script that's crunching on some data and not designed to be an app at all.

And, you know, this is like load some data, load some other data, maybe load a model, combine them in these ways, run these, slice them in various ways, etc. That's our fundamental assumption. And then what we let you do is take that script and add UI elements to it at various points. And that becomes the app. So it's literally sort of the reverse direction. And it's because we have this reverse direction, it's why I think people look, when they figure it out, they're like, oh, wow, this is so fast. This is exactly, you know, I did this thing that would have taken me such a long time. And you don't have to think like an app developer. Okay. So given that we're

going in this reverse direction, and we're assuming that you just have a data script, we want to make sure that you don't always do everything every time there's an interaction. That would be too slow. So we have a way of allowing the user to annotate their code and say, don't do this every time. And that's caching. So we're not just caching data. We're literally caching computation itself in some cases. Like, don't redo this computation. It's already cached. um, you know, when we, to your point, when we launched this feature, uh, it was very simple and we just, you know, did the simplest thing possible over the past year. Uh, it's grown more and more and more complex as people say, I want the cash to expire and I want the cash to, um, handle GPU TensorFlow objects in a special way.

And I want to, uh, you know, anyway, the list of things that people want and the little tweaks in the corner cases and stuff is growing and growing and growing to the point that my co-founder Tiago was like, we need to rethink this whole caching thing. And so we actually have been working on some really neat ideas

and we'll release them over the next year that will hopefully re-simplify caching. So I think that's probably the most complex aspect of building in Streamlit today. And for all of those Streamlit developers out there listening to this, we are working on it and we want to hear your thoughts on how we can do this uh make this easier and uh more obvious because the the key of upstream is really just super super easy to use super fast to use and we want to make sure that that extends to every part of the product okay okay that makes sense i would actually be um extremely worried if you said anything else other than, you know, caching is super hard and complicated. That's funny.

Okay, so another thing that you mentioned was, well, how you make use of CPUs and, you know, the CPUs computing and so on. So I was wondering if there are some cool Python frameworks around that could do that, like Dask and Ray. Is there a way for people to use them while also using Streamlit? Yeah, totally. And, well, you know, so one answer is that we are a very unopinionated framework. We don't, we're not a platform.

We don't control the Python ecosystem. We don't say your code has to be structured like this or that. We are just a package. It's very modest in some ways, very small. And therefore, we sit alongside whatever the whole Python data ecosystem. And that to us is really exciting because, you know, the bigger story here, which is way, way bigger than Streamlit, is that the data world, which was at one time big databases, and then it was Excel, and then it was Tableau, and more recently Looker. That world is being, this tsunami is coming, which is open source and machine learning and Python and Pandas, scikit-learn. And this basically 20 years of academic research

into machine learning is crashing into the data world and completely transforming it. And we are, I view ourselves as just, you know, a little surfboard in that wave, just riding it or trying to ride it as best we can. Because the bigger picture is the way that the Python ecosystem and the community of open source developers and academic developers and corporations,

you know, TensorFlow is built by Google, PyTorch by Facebook, how all of these different forces have come together to create this incredibly powerful data ecosystem that uh that that you know truly can revolutionize decision making that truly has different properties than just a simple excel spreadsheet and a list of your sales over the past year okay so that's a perfect opportunity for me then to wrap up with what I also see as the bigger picture. And some people call it software 2.0.

So basically, developing applications that are data-driven, that have machine learning algorithms at their core. And everything else is kind of the transactional or UI, UX layer around it. And the problem with that, it's great in theory, and it's a kind of new paradigm in a way, which you also described previously.

The problem with that is that I think most organizations haven't even gotten to the point where they've gotten software 1.0 right, because there's a whole range of complexity around it. So development process, version control, release management, and DevOps and product management and all of those things, they're not entirely obvious. They're quite complex. So if you take that and you add to that another layer of complexity and i would argue

maybe even more complexity because you also have to manage your data sets and you know your provenance and how these things change from release to relation you also have your models and their parameters of the models and they also change from release to release and then you combine those two you get combinatorial explosion, basically. So I'm not sure. I don't think there's a solution to that at this point. I think people are still kind of trying to find their way of how do you develop this thing, this monster. And I was wondering if you have an opinion on that. Yeah, I think that's a very well-observed point. And in a sense, that question is really part of the zeitgeist

over the past couple of years. People have started writing these blog posts saying, you know, I am a machine learning engineer at Tesla or at Uber or whatever. And this is how we built our machine learning stack. And I think what's happening now is there's a wave of new startups, including Streamlit and there's Tekton and there's Weights and Biases, which are essentially productionizing every layer of that stack. And I feel very excited. I think that the people who are working on this are very talented. It is murky, but it's coming into view how to do this.

And the world is changing incredibly fast. And not just in Silicon Valley. I mean, it's astonishing to me the extent to which we are really seeing machine learning happening in every industry segment. And big, recognizable non-tech companies are investing in it and building groups around it and asking, I would say, surprisingly sophisticated questions. I mean, we've had, well, I won't mention any companies, but we've had very sophisticated data conversations with companies that I would not associate with that. So that would be my answer. And if you are a company asking yourself how to get into this world, I would say, what is even the first step? I would say, go to Insight Data Science, hire one of their machine learning engineers or data scientists

at the finishing school for data scientists, and then give them Streamlit. And I think really great things to know. Okay. Okay, well, great. Thanks. I think we went a little bit over time, but we had a slow start.

So, yeah, it's okay. Thanks. It's been really interesting having this conversation with you. I hope you enjoyed the podcast. If you like my work, you can follow Link Data Orchestration on Twitter, LinkedIn, and Facebook.