 Hello and welcome to this special CUBE conversation. I'm John Furrier here in Palo Alto, California. You're host of the CUBE. We're here with Sean Knapp, who's the CEO and founder of Ascend.io, heavily venture backed, working on some really cool challenges and solving some big problems around scale, data, and creating value in a very easy way and companies are struggling to continue to evolve and refactor their business now that they've been replatformed with the cloud. You're seeing a lot of new things happening. So Sean, great to have you on and thanks for coming on. Thanks for having me, John. So one of the things I've been interesting with your company, not only do you have great pedigree in terms of investors and tech staff, is that you guys are going after this kind of new scaling challenge, which is not your classic kind of talking points around cloud scaling and more servers, more data, more phone. It's a little bit different. Can you describe what you guys mean around this new scaling challenge? Absolutely, the classic sense of scaling, particularly when it comes to the data industry, whether it's big data, data science, data engineering, has always focused on bits and bytes, how many servers, how big your clusters are, and we've watched over the last five to 10 years and those kinds of scaling problems while not entirely solved, for most companies are largely solved problems now and the new challenge that is emerging is not how do you store more data or how do you process more data, but it's how do you create more data products? How do you derive more value from data? And the challenge that we see many companies today really struggling to tackle is that data productivity, that data velocity challenge and that's more big people problem. It is a how do you get more people able to build more products faster and safely that propel the business forward? You know, that's an interesting topic. We talk about DevOps and how DevOps is evolving and you're seeing SREs has become a standard position now in companies, site reliability engineers that Google pioneered, which is essentially the DevOps person, but now that you don't need to have a full DevOps team as you get more automation. That's a big, big part of it. I want to get into that with you because you're touching on some scale issues around people, there's relationships to the machines and the data. So it's an interesting conversation. But before we do that, can you just take a minute to explain what you guys do? What is Ascend IO? I know you're in Palo Alto, it's where I live and our office is here. What's Ascend IO all about? Absolutely. So what Ascend IO really focuses on is building the software stack on top of modern day big data infrastructure for data engineers, data scientists, data analysts to self-serve and create active data pipelines that fuel the rest of their business. And we provide this as a service to a variety of different companies from Australia to Italy, finance to IoT startups to large enterprises and really help elevate their teams. As Bezo said a long time ago out of the underlined infrastructure, we help them do the same thing out of the muck of classic data engineering work. That's awesome. Andy Jassy, now the CEO of Amazon who was the CEO of it, I've been doing it many times over the years and he always has a line, undifferentiated heavy lifting. Well, I mean data is actually differentiated and it's also heavy lifting too but you got, you have differentiation with data but it's super important. It's really, you got to, but there's a lot of it now. So there's a lot of heavy lifting. This is where people are struggling. I want to get your thoughts on this because you have an opinion on this around how teams are formed, how teams can scale because we know scales coming on the data side and there's different solutions. You've got data bricks, you've got Snowflake, you've got Redshift, there's a zillion other opportunities for companies to deploy data tooling and platforms. What's your thoughts on the changes in data? Well, I think in the data ecosystem is we're changing very, very quickly which makes it for a very exciting industry. And I do think that we are in this great cycle of continuing to reinvest higher and higher up the stack if you will, right? And in many ways we want to keep elevating our teams or partners or customers or companies out of the non-differentiated elements. And this is one of those areas where we see tremendous innovation happening from Amazon, from Databricks, from Snowflake who are solving many of these underlying infrastructure storage, processing and even some application layer challenges for teams. And what we find oftentimes is that teams after having adopted some of these stacks and some of these solutions then have to start solving the problem of how do we build faster? How do we build better? And how do we produce more on top of these incredibly valuable investments that we've made? And they're looking for acceleration. They're looking for, in many ways, the autopilot self-driving level of capabilities and intelligence to sit on top and help them actually get the most out of these underlying systems. And that's really where we need the big challenges. Yeah, I mean, self-driving data. You got to have the products first. I think you mentioned earlier, a data product, data being products. And but there's a trend with this idea of data products, data apps. What is a data product? That's a new concept. I mean, most people really can't get their arms around that because it's kind of new. Data is data. But how does it become productized? And why is it growing so fast? Yeah, this is a great question. I think to quickly talk through a lot of the evolution of the industry, oftentimes we started with the, well, let's just get the data inside of a lake. And it was a very bottoms up notion of what we just collected, then we'll go do something with it. The very field of dreams-esque approach, right? And oftentimes they didn't come in and your data just sat there and became a swamp, right? And when we think about it, a data product oriented model of building, it is less focused on the, how do we just collect and store and process data? And it's much more on the business value side of how do we create a new dataset? In architectural models, how do we launch a new microservice or a new feature out to a customer? But the data product is a new refined, valuable, curated, live set of data that can be used by the business, whether it's for data analysts or data scientists or all the way out to end consumers is very heavily oriented towards that piece because that's really where we get to deliver value for our end users or customers, et cetera. Yeah, and getting that data fast is key. Again, I love this idea of data becoming programmable or kind of a data ops kind of vibe where you're seeing data products that can be nurtured and also scaled up too with people. As this continues, the next kind of logical question I have for you is, okay, I get the data products. Now I have teams of people, how do I deploy them? How do the teams change? Because now you have low code and no code capabilities and you have some front end tools that make it easy to create new apps and products. And where data can feed into someone discovers a cool new value metric in a company, they can say, here, boss is a new metric that we've identified that drives our business. Now they got to productize that in the app. They use low code, no code. Where do you guys see this going? Because you can almost see a whole nother persona of a developer emerging or engineering team emerging. Absolutely, and I think this is one of the challenges is when we look at the data ecosystem, we even ran a survey a couple of months ago across hundreds of different developers asking data scientists, data engineers, data analysts about the overall productivity of their teams. And what we found was 96% of teams are at or over capacity, meaning only 4% of teams even have the capacity to start to invest in better tools or better skill sets, and most are really under the gup. And what that means is teams and companies are looking for more people with different skill sets and frankly, how they get more leverage out of the folks where they have. So they spend less on maintaining more than building. And so what ends up starting to happen is this introduction of low code and no code solutions to help broaden the pool of people who can contribute to this. And what we find oftentimes is there's a bit of a standoff happening between engineering teams and analyst teams and data science teams where some people want low code, some people want no code, some people just want super high code all day, all the time. And what we're finding is, and even actually as part of one of the surveys that we ran, most users, very small percentage, less than 10% of users actually were amenable to no code solutions. But more than 70% were amenable to solutions that leaned towards lower no code, but allowed them to still program in a language of their choice and give them more leverage. And so what we see end up happening is really this new era of what we describe as flex code where it doesn't have to be just low code or just no code, but teams can actually plug in at different layers of the staff in different abstract layers and contribute side by side with each other all towards the creation of this data product with a pluggable model of flex code. So let's unpack flex code for a second, if you don't mind. To first define what you mean by flex code and then talk about the implications to the teams because it sounds like it's integrated but yet decoupled with that layer. So can you take me through what it is and then let's unpack a little bit. Absolutely, flex code is really a methodology that of course companies like ours will go and productize but it is the belief structure that you should be able to peel back layers and contribute to an architecture, in this case a data architecture, whether it's through building in a no code interface or by writing some low code, say in SQL or down and actually running lower level systems and languages and it's become so critical and key in the data ecosystem as what's classically happened has been the, well, if we need to go deeper into the stack we need to customize more of how we run this one particular data job you end up then throwing away most of the benefits and the adoption of any of these other code and tools ends up shutting off a lot of the rest of the company group contributing and you then have to be, for example, a really advanced scholar developer who understands how to extend Docker runtime environments to contribute and the reality is you probably want a few of those folks on your team and you do want them contributing but you still want the data analysts and the data scientists and the software engineers able to contribute at higher levels of the stack all building that solution together and so it becomes this hybrid architecture. And I love, I mean this is really good exploration here because what you're saying is it's not that low code and no code's inadequate it's just that the evolution of the market is such that as people start writing more code things kind of break downstream you got to pull the expert in to kind of fix the plumbing and lower levels of the stack, so to speak the more higher end systems oriented kind of components. So that's just an evolution of the market. So you're saying flex code is the next level of innovation around productizing that in an architecture so you don't waste someone's time to get yanked in to solve a problem just to fix something that's working or broke at this point. So if it works, it breaks. So it's working that people are coding with no code and low code it just breaks something else downstream. You're fixing that. Yeah, absolutely. And that's the idea being here is it's one of these old outages when you're selling out to customers. We see this and I remember this head of engineering one time told me look, you may make 95% of my team's job easier but if you make the last 5% impossible it is a non-starter. And so a lot of this comes down to the how do we make that 95% of a team's job bar easier? But when you really have to go do that one ultra advanced customized thing how do we make sure you still get all that benefit oftentimes through a low code or a no code interface but you can still go back down and really tune and optimize that one piece. Yeah, that's really kind of I mean this is really an architectural decision because that's the classic you don't want to foreclose the future options, right? So as a developer you need to think and this is really where you have to make an architecture decision that's really requires you guys to lean into that architectural team. How do you guys do that? What those conversations look like? Is it work with a send and we got you covered or how does those conversations go? Because if someone's slinging low code, no code they might not even know that they're foreclosing that 5%. Yeah, oftentimes for them they're the ones that are given the hardest radius, gnarliest problems to solve for and may not even have the visibility that there's a team of 30 analysts who can go write incredible data pipelines if they are still afforded a low code or no code interface on top. And so for us we really partner heavily with our customers and our users. We do a ton of joint architecture design decisions not just for their products but we actually bring them in to all of our architecture and design and road mapping sessions as well. And we do a lot of collaborative building very much how we treat the developer community around the company. It's all, so we spent a lot of time on that. You're a partner strategy. You're building the bridge to the future with the customer. Yeah, absolutely. We work in fact almost all of our communications with our customers happen in shared Slack channels. We are treated like extensions of our customers team and we treat them as our internal customers as well. And that's the way it should be. You're doing some great work. This is really cutting edge and really setting the table for a decade of innovation with the customer if they get it right. So I got to ask you with this architecture you got to be factoring in automation because orchestration, automation, these are the principles of DevOps that kind of go on the next level. I love this conversation. DevOps 2.0, 4.0, whatever you want to call it. It's the next level DevOps. It's data automation. You're taking it to a whole nother level within your sphere. Talk about automation and how that factors in. Obviously this benefits the automation, autonomous data, pipeline would be cool. No coding, I can see maintenance is an issue. How do you offload developers so that it's not only an easy button but it's a maintenance button. Yeah, absolutely. What we find in the evolution of most technical domains is this ship happens at some point usually towards or from an imperative developer model to a declarative developer model. For example, we see this in databases with the introduction of SQL. We see it in infrastructure definition with tools like Terraform and now Kubernetes. And what we do from an automation perspective for data pipelines is very similar to what Kubernetes does for containers. We do for data pipelines. We introduce a declarative model and put in this incredible intelligence that tracks everything around how data moves. For us, metadata alone is a big data problem because we track so much information all that goes into this central brain that is dynamically adapting to code and data for our users and dynamically generating work. And so for us, when we look at the biggest potential to automate is to help alleviate maintenance and optimization burdens for users so they get to spend more time building and less time maintaining. And that really goes into the how do you have this central brain that tracks everything that builds this really deep understanding of how data moves through an organization? Yeah, that's an awesome vision. I got to ask my brain's firing off. I'm like, okay, so what about runtime assembly? As you orchestrate data in real time, you have to kind of pull the assembly to all and link and load all this data together. I can only imagine how hard that is, right? So can you share your vision because you mentioned Docker containers, the benefits of containers is they can manage state and stateless data. So as you get into this notion of state and stateless data, how do you assemble it all in real time? How does that work? How does that brain figure it out? What's the secret sauce? Yeah, that's a really great question. For us, and this is one of the most exciting parts for our customers and our users is we help with this paradigm shift where the classic model has been the, your writing code, you compile it, you shift it, you push it out, and then you cross your fingers, you're like, gosh, I really hope that that works. And it's a very slow iteration cycle. And one of the things that we've been able to do because of this intelligence layer is actually help hybridize that for users. You still have pipelines and they still run and they're still optimizing, but we make it an interactive experience at the same time, very similar to how notebooks for data science help make that such an interactive experience. We make the process of building data pipelines and doing data engineering work iterative and interactive. So you're getting instantaneous feedback and evolving very quickly. So the things that used to take weeks or months due to slow iteration cycles really now can be done in hours or days because you get such fast feedback loops as you build. Well, we definitely need your product. We have so much data on the media side all these events and they're all like little, it's like little data, but it's big data. It's a lot of little data that makes it a big data problem. And I do feel like I'm jumping out of the airplane with the parachute and I'm, will it open? You know, one of the work is that you just, we don't, you know, we don't know, right? So a lot of the fear is, you know, splat. We don't want to, you know, crater and build data products that are, you know, praying, right? This is really kind of what everyone's doing right now. It's kind of state of the industry. How do you guys make it easy? That's the question, right? Cause you brought up the human aspect which I love the human scale, how do you scale teams? Nobody wants another project if they are already burnt out for the COVID and they don't have enough resources. You know, it's almost like there's a little bit of psychology going on in the human mind now saying, enough or burnout or, you know, the relationship to humans training data. Data has now got this human interaction. All of it is around, you know, ease of use, future of work, and simplicity and self-service. What's your thoughts on those? Oh, I wholeheartedly agree. I think the, we need to continue to be pushing those boundaries around self-service and around developer and frankly just outright data productivity. You know, and for us, I think it's become a really fascinating time in the industry as, you know, I would say in 2019, 2020, much of the industry and users and builders in the industry had just embraced the fact that frankly the building data pipeline sucked. And it was a badge of honor because it was such a hard and painful thing. What we're finding is now, as the industry is evolving, is an expectation that it should be easier. And people are challenging that conventional wisdom and expecting building data pipelines to be much easier. And that's really where we come in is both with a flexible model and with high levels of automation to keep people squarely focused on rapid building versus maintaining and tinkering too deep in the staff. You know, I really think you're onto something with the one, the scaling challenge of people and teams, huge issue. To match that at the pace of, you know, cloud and data scales, a huge, huge focus. And I'm glad you're focusing on that. That's a human issue. And then on the data architecture, I mean, we saw with Hadoop how to do a failed project. You require the customer to create all this, you know, undifferentiated support and heavy lifting and time lag. It's just to get to value, right? There's no value, right? Into cloud. So this is, you're on the right track. How do you talk to customers? Take a minute to share at the folks who are watching or if it's a customer, an enterprise or potential customer, what's in it for them? Why ascend? Why should they work with you? How do they engage with you guys? What's in it for them? Yeah, absolutely. What's in it for customers is time to value. Truncated dramatically. You get projects live and you get them faster, far faster than ever if not possible. You know, the way that we engage with our customers is we help partner them with them. We launch them on the application. They can buy us from the marketplace. We will actually help even architect their first project with them and ensure that they have full-fledged live data, data products live within the first four weeks. And that really, I think becomes the most key thing. Frankly, it doesn't, features and functions and so on really don't matter. Ultimately, at the end of the day, what really matters is can you get your data products live? Can you deliver business value? And is your team happy as they get to go build? Do they smile more throughout the day as they're enjoying that developer experience? So you're providing the services to get them going. It's the old classic expression teaching them how to fish and then they can fish on their own, is that right? Yep, absolutely. And then doing whatever next gen thing. Yeah, and then we are excited to watch quarter after quarter, year after year, our customers build more and more data products and their teams are growing faster than most of the other teams in their companies because they're delivering so much value and that's what's so exciting for them. They're successful. I think the cliche every company is a data company. I know that's kind of cliche, but it's true, right? Everyone has to have a core DNA, but they shouldn't have to hire hardcore data engineering. They have a data team for sure. That team has to create a service model for practitioners inside the company. Well, hard to be agreed. Sean, great conversation. Great to unpack the flex code. I love that approach. Take it to the next level. Take it low code to the next level with data. Great stuff and Send.io Palo Alto based company. Congratulations on your success. Thank you so much, Sean. Okay, this is the CUBE Conversation here in Palo Alto. I'm Sean Furrier, host of theCUBE. Thanks for watching.