>> Okay. We're now going to go into the customer panel, and we'd like to welcome Angelo Fausti, who's a software engineer at the Vera C. Rubin Observatory, and Caleb Maclachlan who's senior spacecraft operations software engineer at Loft Orbital. Guys, thanks for joining us. You don't want to miss folks this interview. Caleb, let's start with you. You work for an extremely cool company, you're launching satellites into space. Of course doing that is highly complex and not a cheap endeavor. Tell us about Loft Orbital and what you guys do to attack that problem. >> Yeah, absolutely. And thanks for having me here by the way. So Loft Orbital is a company that's a series B startup now, who, and our mission basically is to provide rapid access to space for all kinds of customers. Historically, if you want to fly something in space, do something in space, it's extremely expensive. You need to book a launch, build a bus, hire a team to operate it, have a big software teams, and then eventually worry about, a bunch like, just a lot of very specialized engineering. And what we're trying to do is change that from a super specialized problem that has an extremely high barrier of access, to a infrastructure problem. So that it's almost as simple as deploying a VM in AWS or GCP is getting your programs, your mission deployed on orbit with access to different sensors, cameras, radios, stuff like that. So, that's kind of our mission and just to give a really brief example of the kind of customer that we can serve. There's a really cool company called Totum Labs, who is working on building IoT cons, an IoT constellation for, internet of things, basically being able to get telemetry from all over the world. They're the first company to demonstrate indoor IoT which means you have this little modem inside a container that container that you track from anywhere in the world as it's going across the ocean. So, and it's really little, and they've been able to stay a small startup that's focused on their product, which is the, that super crazy, complicated, cool radio, while we handle the whole space segment for them, which just, you know, before Loft was really impossible. So that's our mission is providing space infrastructure as a service. We are kind of groundbreaking in this area and we're serving a huge variety of customers with all kinds of different missions, and obviously generating a ton of data in space that we've got to handle. >> Yeah. So amazing Caleb, what you guys do. Now, I know you were lured to the skies very early in your career, but how did you kind of land in this business? >> Yeah, so, I guess just a little bit about me. For some people, they don't necessarily know what they want to do like earlier in their life. For me I was five years old and I knew I want to be in the space industry. So, I started in the Air Force, but have stayed in the space industry my whole career and been a part of, this is the fifth space startup that I've been a part of actually. So, I've kind of started out in satellites, spent some time in working in the launch industry on rockets, then, now I'm here back in satellites and honestly, this is the most exciting of the different space startups that I've been a part of. >> Super interesting. Okay. Angelo, let's talk about the Rubin Observatory. Vera C. Rubin, famous woman scientist, galaxy guru. Now you guys, the Observatory, you're up way up high, you get a good look at the Southern sky. And I know COVID slowed you guys down a bit, but no doubt you continued to code away on the software. I know you're getting close, you got to be super excited, give us the update on the Observatory and your role. >> All right. So, yeah. Rubin is a state of the art observatory that is in construction on a remote mountain in Chile. And, with Rubin we'll conduct the large survey of space and time. We're going to observe the sky with eight meter optical telescope and take 1000 pictures every night with 2.2 Gigapixel camera. And we are going to do that for 10 years, which is the duration of the survey. >> Yeah, amazing project. Now, you earned a doctor of philosophy so you probably spent some time thinking about what's out there, and then you went out to earn a PhD in astronomy and astrophysics. So, this is something that you've been working on for the better part of your career, isn't it? >> Yeah, that's right, about 15 years. I studied physics in college. Then I got a PhD in astronomy. And, I worked for about five years in another project, the Dark Energy Survey before joining Rubin in 2015. >> Yeah, impressive. So it seems like both your organizations are looking at space from two different angles. One thing you guys both have in common of course is software, and you both use InfluxDB as part of your data infrastructure. How did you discover InfluxDB, get into it? How do you use the platform? Maybe Caleb you could start. >> Yeah, absolutely. So, the first company that I extensively used InfluxDB in, was a launch startup called Astra. And we were in the process of designing our first generation rocket there, and testing the engines, pumps, everything that goes into a rocket. And, when I joined the company our data story was not very mature. We were collecting a bunch of data in LabVIEW and engineers were taking that over to MATLAB to process it. And at first, there, you know, that's the way that a lot of engineers and scientists are used to working. And at first that was, like people weren't entirely sure that that was, that needed to change. But, it's, something, the nice thing about InfluxDB is that, it's so easy to deploy. So as, our software engineering team was able to get it deployed and, up and running very quickly and then quickly also backport all of the data that we collected this far into Influx. And, what was amazing to see and is kind of the super cool moment with Influx is, when we hooked that up to Grafana, Grafana as the visualization platform we used with Influx, 'cause it works really well with it. There was like this aha moment of our engineers who are used to this post process kind of method for dealing with their data, where they could just almost instantly easily discover data that they hadn't been able to see before, and take the manual processes that they would run after a test and just throw those all in Influx and have live data as tests were coming, and, I saw them implementing like crazy rocket equation type stuff in Influx, and it just was totally game changing for how we tested. >> So Angelo, I was explaining in my open, that you could add a column in a traditional RDBMS and do time series, but with the volume of data that you're talking about in the example that Caleb just gave, you have to have a purpose built time series database. Where did you first learn about InfluxDB? >> Yeah, correct. So, I work with the data management team, and my first project was the record metrics that measured the performance of our software, the software that we used to process the data. So I started implementing that in our relational database. But then I realized that in fact I was dealing with time series data and I should really use a solution built for that. And then I started looking at time series databases and I found InfluxDB, and that was back in 2018. The, another use for InfluxDB that I'm also interested is the visits database. If you think about the observations, we are moving the telescope all the time and pointing to specific directions in the sky and taking pictures every 30 seconds. So that itself is a time series. And every point in that time series, we call a visit. So we want to record the metadata about those visits in InfluxDB. That time series is going to be 10 years long, with about 1000 points every night. It's actually not too much data compared to other problems. It's really just a different time scale. >> The telescope at the Rubin Observatory is like, pun intended, I guess the star of the show. And I believe I read that it's going to be the first of the next gen telescopes to come online. It's got this massive field of view, like three orders of magnitude times the Hubble's widest camera view, which is amazing. Like, that's like 40 moons in an image, amazingly fast as well. What else can you tell us about the telescope? >> This telescope it has to move really fast. And, it also has to carry the primary mirror which is an eight meter piece of glass. It's very heavy. And it has to carry a camera which has about the size of a small car. And this whole structure weighs about 300 tons. For that to work, the telescope needs to be very compact and stiff. And one thing that's amazing about it's design is that, the telescope, this 300 tons structure, it sits on a tiny film of oil, which has the diameter of human hair. And that makes an, almost zero friction interface. In fact, a few people can move this enormous structure with only their hands. As you said, another aspect that makes this telescope unique is the optical design. It's a wide field telescope. So, each image has, in diameter the size of about seven full moons. And, with that, we can map the entire sky in only three days. And of course, during operations everything's controlled by software and it is automatic. There's a very complex piece of software called the Scheduler, which is responsible for moving the telescope, and the camera, which is recording 15 terabytes of data every night. >> And Angelo, all this data lands in InfluxDB, correct? And what are you doing with all that data? >> Yeah, actually not. So we use InfluxDB to record engineering data and metadata about the observations. Like telemetry, events, and commands from the telescope. That's a much smaller data set compared to the images. But it is still challenging because you have some high frequency data that the system needs to keep up, and, we need to store this data and have it around for the lifetime of the project. >> Got it. Thank you. Okay, Caleb, let's bring you back in. Tell us more about the, you got these dishwasher size satellites, kind of using a multi-tenant model, I think it's genius. But tell us about the satellites themselves. >> Yeah, absolutely. So, we have in space some satellites already that as you said, are like dishwasher, mini fridge kind of size. And we're working on a bunch more that are a variety of sizes from shoebox to, I guess, a few times larger than what we have today. And it is, we do shoot to have effectively something like a multi-tenant model where we will buy a bus off the shelf. The bus is what you can kind of think of as the core piece of the satellite, almost like a motherboard or something where it's providing the power, it has the solar panels, it has some radios attached to it. It handles the attitude control, basically steers the spacecraft in orbit, and then we build also in-house, what we call our payload hub which is, has all, any customer payloads attached and our own kind of Edge processing sort of capabilities built into it. And, so we integrate that, we launch it, and those things because they're in lower Earth orbit, they're orbiting the earth every 90 minutes. That's, seven kilometers per second which is several times faster than a speeding bullet. So we have one of the unique challenges of operating spacecraft in lower Earth orbit is that generally you can't talk to them all the time. So, we're managing these things through very brief windows of time, where we get to talk to them through our ground sites, either in Antarctica or in the North pole region. >> Talk more about how you use InfluxDB to make sense of this data through all this tech that you're launching into space. >> We basically, previously we started off when I joined the company, storing all of that as Angelo did in a regular relational database. And we found that it was so slow and the size of our data would balloon over the course of a couple days to the point where we weren't able to even store all of the data that we were getting. So we migrated to InfluxDB to store our time series telemetry from the spacecraft. So, that's things like power level, voltage, currents, counts, whatever metadata we need to monitor about the spacecraft, we now store that in InfluxDB. And that has, now we can actually easily store the entire volume of data for the mission life so far without having to worry about the size bloating to an unmanageable amount, and we can also seamlessly query large chunks of data. Like if I need to see, you know, for example, as an operator, I might want to see how my battery state of charge is evolving over the course of the year, I can have, plot in an Influx that loads that in a fraction of a second for a year's worth of data because it does, intelligent, it can intelligently group the data by assigning time interval. So, it's been extremely powerful for us to access the data. And, as time has gone on, we've gradually migrated more and more of our operating data into Influx. >> Yeah. Let's talk a little bit about, we throw this term around a lot of, you know, data driven, a lot of companies say, "Oh yes, we're data driven." But you guys really are, I mean, you got data at the core. Caleb, what does that mean to you? >> Yeah, so, you know, I think the, and the clearest example of when I saw this be like totally game changing is what I mentioned before at Astra where our engineer's feedback loop went from a lot of kind of slow researching, digging into the data to like an instant, instantaneous almost, seeing the data, making decisions based on it immediately rather than having to wait for some processing. And that's something that I've also seen echoed in my current role. But to give another practical example, as I said, we have a huge amount of data that comes down every orbit and we need to be able to ingest all of that data almost instantaneously and provide it to the operator in near real time, about a second worth of latency is all that's acceptable for us to react to see what is coming down from the spacecraft. And building that pipeline is challenging from a software engineering standpoint. My primary language is Python which isn't necessarily that fast. So what we've done is started, and the goal of being data-driven is publish metrics on individual, how individual pieces of our data processing pipeline are performing into Influx as well. And we do that in production as well as in dev. So we have kind of a production monitoring flow. And what that has done is allow us to make intelligent decisions on our software development roadmap where it makes the most sense for us to focus our development efforts in terms of improving our software efficiency, just because we have that visibility into where the real problems are. And sometimes we've found ourselves before we started doing this, kind of chasing rabbits that weren't necessarily the real root cause of issues that we were seeing. But now that we're being a bit more data driven there, we are being much more effective in where we're spending our resources and our time, which is especially critical to us as we scale from supporting a couple of satellites to supporting many, many satellites at once. >> Yeah, of course is how you reduced those dead ends. Maybe Angelo you could talk about what sort of data-driven means to you and your teams. >> I would say that, having real time visibility to the telemetry data and metrics is crucial for us. We need to make sure that the images that we collect with the telescope have good quality, and, that they are within the specifications to meet our science goals. And so if they are not, we want to know that as soon as possible and then start fixing problems. >> Caleb, what are your sort of event, you know, intervals like? >> So I would say that, as of today on the spacecraft, the event, the level of timing that we deal with probably tops out at about 20 Hertz, 20 measurements per second on things like our gyroscopes. But, the, I think the core point here of the ability to have high precision data is extremely important for these kinds of scientific applications and I'll give an example from when I worked at, on the rockets at Astra. There, our baseline data rate that we would ingest data during a test is 500 Hertz. So 500 samples per second, and in some cases we would actually need to ingest much higher rate data, even up to like 1.5 kilohertz, so extremely, extremely high precision data there where timing really matters a lot. And, you know, I can, one of the really powerful things about Influx is the fact that it can handle this. That's one of the reasons we chose it, because, there's, times when we're looking at the results of a firing where you're zooming in, you know, I talked earlier about how on my current job we often zoom out to look at a year's worth of data. You're zooming in to where your screen is preoccupied by a tiny fraction of a second, and you need to see same thing as Angelo just said, not just the actual telemetry, which is coming in at a high rate, but the events that are coming out of our controllers, so that can be something like, "Hey, I opened this valve at exactly this time," and that goes, we want to have that at, micro, or even nanosecond precision so that we know, okay, we saw a spike in chamber pressure at this exact moment, was that before or after this valve opened? That kind of visibility is critical in these kind of scientific applications, and absolutely game changing to be able to see that in near real time, and with, a really easy way for engineers to be able to visualize this data themselves without having to wait for us software engineers to go build it for them. >> Can the scientists do self-serve or do you have to design and build all the analytics and queries for your scientists? >> Well, I think that's absolutely, from my perspective that's absolutely one of the best things about Influx and what I've seen be game changing is that, generally I'd say anyone can learn to use Influx. And honestly, most of our users might not even know they're using Influx, because, the interface that we expose to them is Grafana, which is a generic graphing, open source graphing library that is very similar to Influx zone Chronograf. >> Sure. >> And what it does is, it provides this almost, it's a very intuitive UI for building your queries. So, you choose a measurement and it shows a dropdown of available measurements. And then you choose the particular fields you want to look at, and again, that's a dropdown. So, it's really easy for our users to discover and there's kind of point and click options for doing math, aggregations. You can even do like perfect kind of predictions all within Grafana, the Grafana user interface, which is really just a wrapper around the APIs and functionality that Influx provides. >> Putting data in the hands of those who have the context, the domain experts is key. Angelo, is it the same situation for you, is it self-serve? >> Yeah, correct. As I mentioned before, we have the astronomers making their own dashboards because they know what exactly what they need to visualize. >> Yeah, I mean, it's all about using the right tool for the job. I think for us, when I joined the company we weren't using InfluxDB and we were dealing with serious issues of the database growing to an incredible size extremely quickly, and being unable to like even querying short periods of data was taking on the order of seconds, which is just not possible for operations. >> Guys, this has been really formative, it's pretty exciting to see how the edge, is mountaintops, lower Earth orbits, I mean space is the ultimate edge, isn't it? I wonder if you could answer two questions to wrap here. You know, what comes next for you guys? And is there something that you're really excited about that you're working on? Caleb maybe you could go first and then Angelo you can bring us home. >> Basically what's next for Loft Orbital is more satellites, a greater push towards infrastructure, and really making, our mission is to make space simple for our customers and for everyone. And we're scaling the company like crazy now, making that happen. It's extremely exciting, an extremely exciting time to be in this company and to be in this industry as a whole. Because there are so many interesting applications out there, so many cool ways of leveraging space that people are taking advantage of, and with companies like SpaceX and the, now rapidly lowering cost of launch it's just a really exciting place to be in. We're launching more satellites, we are scaling up for some constellations, and our ground system has to be improved to match. So, there's a lot of improvements that we're working on to really scale up our control software to be best in class and make it capable of handling such a large workload, so. >> Are you guys hiring? >> We are absolutely hiring, so I would, we have positions all over the company, so, we need software engineers, we need people who do more aerospace specific stuff. So absolutely, I'd encourage anyone to check out the Loft Orbital website, if this is at all interesting. >> All right, Angelo, bring us home. >> Yeah. So what's next for us is really getting this telescope working and collecting data. And when that's happened is going to be just a deluge of data coming out of this camera and handling all that data is going to be really challenging. Yeah, I want to be here for that, I'm looking forward. Like for next year we have like an important milestone, which is our commissioning camera, which is a simplified version of the full camera, it's going to be on sky, and so yeah, most of the system has to be working by then. >> Nice. All right guys, with that we're going to end it. Thank you so much, really fascinating, and thanks to InfluxDB for making this possible, really groundbreaking stuff, enabling value creation at the Edge, in the cloud, and of course, beyond at the space. So, really transformational work that you guys are doing, so congratulations and really appreciate the broader community. I can't wait to see what comes next from having this entire ecosystem. Now, in a moment, I'll be back to wrap up. This is Dave Vellante, and you're watching theCUBE, the leader in high tech enterprise coverage. >> Welcome. Telegraf is a popular open source data collection agent. Telegraf collects data from hundreds of systems like IoT sensors, cloud deployments, and enterprise applications. It's used by everyone from individual developers and hobbyists, to large corporate teams. The Telegraf project has a very welcoming and active Open Source community. Learn how to get involved by visiting the Telegraf GitHub page. Whether you want to contribute code, improve documentation, participate in testing, or just show what you're doing with Telegraf. We'd love to hear what you're building. >> Thanks for watching Moving the World with InfluxDB, made possible by Influx Data. I hope you learned some things and are inspired to look deeper into where time series databases might fit into your environment. If you're dealing with large and or fast data volumes, and you want to scale cost effectively with the highest performance, and you're analyzing metrics and data over time, times series databases just might be a great fit for you. Try InfluxDB out. You can start with a free cloud account by clicking on the link in the resources below. Remember, all these recordings are going to be available on demand of thecube.net and influxdata.com, so check those out. And poke around Influx Data. They are the folks behind InfluxDB, and one of the leaders in the space. We hope you enjoyed the program, this is Dave Vellante for theCUBE, we'll see you soon. (upbeat music)

(intense orchestral music) >> Hey welcome back everybody, Jeff Frick here with theCUBE We are taking a short break from the madness of the conference season to do some CUBE Conversations here in the Palo Alto studio, which we always like to do and meet new people, and hear new stories, learn about new companies. And today we've got a new company, we've never had 'em on theCUBE before, it's Evan Kaplan, he's the CEO of InluxData. Evan, great to see you. >> Yeah, hey thanks for having me. >> Absolutely. So for people that aren't familiar with the company, give 'em kind of the 101 on Influx. >> Yeah so, InfluxData is an opensource platform for collecting metrics and events at scale. The company is about almost four years old, has a large selection of tier one customers, is broadly accepted by developers as the number one time-series platform out there, so. >> So a lot of people talk about collecting data, so we've been doing Splunk since 2012, and, they really found something interesting on log files, and took it a whole 'nother level, so there's a lot of people that are capturing events. So what do you guys do that's a little bit different, how are you slicing and dicing this opportunity? >> Yeah, to put this is even in the broader context of what we're looking at is the 20 year break-up of the Oracle, DB2 and Formex franchise that dominated and relational databases were the answer to all problems and so if you look at a company like Splunk working on logs, they optimized a platform for those logs, for that data set, Elastic also, really interesting space. I think our innovation has been in saying "Hey, where the world's going, where all of these complex systems are going?" Particularly IoT, is to real-time view of the data and so, rather than collect verbose logs, historical views of the data and things like that, real system operators, real developers and builders want to instrument their applications, their infrastructure, so you can view 'em in real time. The place where the rubber hits the road is IoT. Sensors spit out metrics and events, period, full stop. And so if you want to be performant in how you handle, your instrumentation of the physical world, and how you do your machine learning, and how you want to manage these systems, you use a fundamentally time-series based database. As opposed to Splunk or Elastic or, which are primarily search-based databases. >> And are you primarily capturing and standardizing the data to feed other analytics tools, or do you have the whole suite, where you're doing some of the analytics as well? >> Yeah, such a great question. So, the fundamental platform is called the TICK Stack, and it stands for Telegraf which is a collector, which has about 200 different collectors that sit out there in the world and collect everything from SNMP data, to Oracle data, to application, to micro-service data, to Kubernetes, to that sort of stuff. There's Influx, which is the DB, which is highly optimized for millions and millions of writes a second, so collecting data points and samples. There's Chronograf which is the visualization engine and so, it allows you as soon as the data comes input you can see how it's graphed, see it on time-series oriented graphing, and then there's Kapacitor which takes action on the data. What we don't do is the super high sophisticated analytics. There are lots of companies in Silicon Valley who take our data, pump it up, and then we put it back on the platform to build a control loop for it. >> Right. So when the Kapacitor, does your application then take action on those things? >> Yes. Yeah, so, it'd do everything from alerting, to sending out another machine request, to spinning up a new Kubernetes pod, to basically scaling the application, self healing. >> Right. So does it fit in between a lot of those other types of applications that are sending off notifications, and those types of things? >> Yes, yeah. so you're in between? >> And usually, we're instrumented the way a standard developer, or an architect or CTO does is they look at a complex application, or a complex set of sensors, they instrument with Influx and Telegraf, and collect that data, they view it in real time, and then they build control loops, automation loops, to make that easier so when you see a problem, it's got a tolerance you can self adjust for. So it's the beginning of kind of the self-healing system. >> Okay, and I know that Telegraf is definitely opensource, are the other three? >> All four are open-source All four are open-source. >> Everything, in our world, everything for a developer is free, so, and a single note of Influx can handle a couple million writes a second, which is really really performant to run in production. Where our business model is, where we make money is, our closed source clustering, sharding, distributing the database, if you decide you want to run highly available in the production environment, you would buy our closed-source stuff. We have about 430 customers who run our closed source stuff on top of the opensource. >> So, it is kind of like a MapR to Hadoop if you will, where, you know, it's built on, built on the opensource, and then they've got their proprietary stuff kind of wrapped around it, almost like an open core? Or is that a? >> Yeah, it's a little It's a little different than the normal Hadoop stuff. One is, our stuff doesn't have any external dependencies. It can work with other third party projects, but just, it's a platform onto itself, there aren't 25 projects. There are four different projects, we own them all, they come across as a single binary, and it's not part of Apache. >> So they're integrated So the TICK is the full TICK >> Yes, and then you put the clustering on top. So there's some similarity, but not being part of Apache, we can control and keep clean what that experience is. And we're about, the thing that's been most successful for us is, well Paul our founder who is my partner, it's called time to awesome, the idea that a developer in 10 minutes can very quickly be up and instrumenting an application or a set of sensors, and see that data pouring in within 10 minutes from going to the site and downloading the opensource. >> So it's interesting, the giant opportunity is really around IoT, just in terms of the explosion of the sensor data, and we see that coming, and we were at AT&T show a couple weeks ago, talking about 5G which is, slowly, slowly coming down the road, (Evan laughs) they've got the standards fixed. But in terms of the, you said the shorter term, nobody has budget, I always like to joke, nobody has budget for a new platform, they do have budget for new applications, because they've got real problems. So you said you're seeing, your main success now, your go to market application, is around application monitoring? Would that be accurate, or what is kind of your? >> Yeah, there are two broad things, and they're both very similar technology as a service. One is the central monitoring stuff so, Tesla's Power Wall, Seimens' Windmills, a variety of solar companies build Telegraf into their platforms and then use InluxData to collect and store that information and analyze it. On the software side, people like IBM's Cloud Service running their network and their fabric, SAP with Ariba, Cisco with all their collaboration stuff, they instrument their software applications. And that's the idea is it's a general purpose platform for collecting and instrumenting instrumenting the applications or the sensors, either one, or both. >> Okay, and so what are you guys working on now, what's next, kind of raise the profile, get some new stuff >> Yeah, so we are-- before the whole IoT thing completely explodes, we're not quite there yet but it's coming down the pike. >> But we're starting to see it really happen, so that's really exciting for us. And this is just a really, really big market, it's certainly a super set of the log market, it should be. As you think about just the instrumentation of the physical world, how much instrumentation is going on, your clothes, your cars, your homes, your industrial devices, my watch, how much sensor data there is. We think this is a tremendously large market, so we're doing a couple of things. One is, we're about to introduce a new language for querying these kinds of time-series data that's going to be opensource, that a bunch of other people can use with their data stores. We're rolling out a new API-driven service, so that people can store these things directly in the could natively, so all they have to do is know our API. So we're really trying to push from the technology limit we're a product-driven company, and so, and an opensource-driven company, so we're trying to push that, that community is super important to us. >> It's so wild to me, the opportunity to have a closed feedback loop between someone's product back to the barn, you're barely starting to see it, Tesla obviously, is a good example, they're slowly seeing it in other places. But what a fundamental change in manufacturing, from building a product, making some assumptions about use, shipping that product to your distribution, and then, maybe you get some feedback now an then, versus actually monitoring the way that that thing is actually used by your end user, whether it's a product like a car, or even a software application, as you're rolling out all these different apps and features in the apps, how are people using it, are they using it? Where do you double down, where do you back off? And that loop has not really been >> That's pretty insightful. >> opened up very wide. Yeah, no it's just starting to open up, and that whole notion of product telemetry, my prediction is is that, as development teams grow and things like that, you're going to have telemetry experts, people are going to be specializing. How do you instrument these products so you get maximum engagement, and usage, and things like that? So I think that's pretty insightful on your part. If you think about it from a systems point of view, right? Instrumentation is first. You can't do anything 'til you instrument, whether it's telemetry from a product, it's the engagement or this. So instrumentation is first, visibility in real time is second. So observability is the big thought in systems application and building now, this notion of observing your system in real time, because you don't know, apriori, it's impossible to know a complex system, how it's going to behave, then it's automation, right? So like, okay now I can see these behaviors, how do I automate something that makes the experience for you, the user, better? But lastly, we can see this with self-driving cars, it's autonomy. It's the idea that the system becomes self-healing, and AI, and those sorts of things, but that's kind of the last step. There's a lot of learning in that process to get there. >> And it has to be automated because at scale there's no way for people to keep up with this stuff, and then how do you separate signal from noise and how do you know what to do? So you've got to automate a whole bunch of this. >> And you know if we had an aspiration it would be we're not going to write the applications that do these things but what we want to do is be that system of record so that people have a really efficient, effective metrics and events store so they can really track and keep track of all that engagement. Time-stamped data, for lack of a better way to say it. >> It sounds like you're in a pretty good space, Evan. >> Pretty excited (chuckles), thank you. Thanks for saying that, but yeah, we're pretty excited. >> Alright, well thanks for taking a few minutes out of your day and sharing the story, we look forward to watching the journey. >> Yeah. Thanks man. Alright, take care. >> Alright, thanks. He's Evan, I'm Jeff, you're watching theCUBE. We're having a CUBE Conversation in Palo Alto, we'll see you next time, thanks for watching. (intense orchestral music)