Beyond stateless - DevOps & Databases, Robert Reeves of Datical (Ep. 95)

Episode 80 · 45:38 · SRT · archive.org · all Tanzu Talk

All right, well, why don't you introduce yourself, guest? Well, I am Robert Reeves. I'm the CTO and one of the co-founders of Datacool. And what we do is bring DevOps to the database. This is good. You know, I think, what is this, 20? I was looking up the 451 research articles written about you because I wanted to get updated. And I think the last one written was by me in 2013. So five years later, I finally know how to pronounce the name. I always say Datacool, but Datacool, that sounds better. Exactly. Rhymes with radical. Oh, yes. Radical. Now I got it. I'll have to remember that. We should have put a pronunciation guide in that report that I wrote. I don't know how to do declensions and hats over O's and stuff, so I wouldn't be able to do that anyways, but like radical. So speaking of radical, that was a pretty nice sweater you had before we turned the video off. What would you call that type of situation? Well, it's just, you know, it's just a, you know, wool shawl collared sweater, you know. You ever turn that collar up? Nah, not really. I'm not cool enough for that. I'm, you know, moving very comfortably into my 40s, so it's sweaters and slippers. Oh, slippers. You know, elastic band pants. I'm really enjoying that. Yeah. Sansa belt. That's what you should look into. Yeah. You know, I actually have a pair of old Sansa belt that has one of those, like, black, it's not tartan, but, you know, it's sort of like graph papery kind of look from long ago. Man, those are nice pants, but I need to lose a little bit of weight. I unfortunately got them altered, I think you would say, when I was at my minimum healthy weight, and now they're a little too small. Our listeners have a lot of mental images right now from the two of you, so this is great. I'll have to go take a picture of those pants. Yeah, exactly. They're good pants. Good pants. Well, we brought you on to talk about DevOps and data or radical things and things,

stuff like that, and also, y'all have some interesting things you've done with Concourse and stuff like that, all sorts of things relative to listeners' interests. But first, as always, we have some news to go over. So, I was just catching up on things, Richard. We have the big Pivotal Container Services GA announcement. I think that still stands for general availability, if I remember my acronyms. But that was made GA today, right? What's in there? It was GA today. And for those who feel like they keep having a sense of deja vu, this is the real one. So, we kind of did the, hey, it's coming back in August at VMworld, and then December, talked about it as part of the SpringOne platform. But this is the real one, we promise. So, this is really GA. So, you can download today from the Pivotal network at network.pivotal.io. And so, what's in the box is the current version of Kubernetes managed with VMware NSX for the networking components. You've got Harbor, the registry. You've got the multi-cloud for both GCP and VMware to start with. And, yeah, it's exciting. It's been fun to watch this go through the paces with early customers. And it's ready to go. So, we're excited to see how people start using it and how our customers start seeing the types of workloads that also belong in an environment like this, which may come up in our chat today as we think of kind of where do data workloads go as you think of continuous delivery and you think of more agile databases. Something like Kubernetes can be a great home for a lot of that. At least that's the assumption. Indeed. And then, well, you know, I always like to provide pointers to further homework and to interleave our stuff. I'll throw in one here. I'm not done reading. I think I might have mentioned this book already, but I'm not done reading it. But you've got Mark Schwartz's A Seat at the Table. Now, you may remember him from his previous book. It was something like The Art of Business Value, which all sorts of fun subtitles you could have for that. Sort of like a mystical look at being a CIO. I think I forget the full acronymization, but he used to be the CIO of the, as they would joke, the immigration service that welcomes people for the U.S. government.

And now I just notice he's at AWS, you know, traipsing around, telling them about enterprise things. But it's a nice book. Look, I excerpted a part earlier in Twitter last week about questions managers would ask their teams when they're planning things out to avoid the, I don't know, big upfront waterfall planning that is very inflexible. But it's definitely worth looking into. It's a nice book. Now, also, another thing that GA'd, we have Spring Cloud on Google Cloud Platform. What's the story with that, Richard? Yeah, they announced the kind of alpha release of some of the Spring Cloud components that work with GCP. So basically, if you're a Spring Boot developer and you want to consume Google Cloud services like Google Cloud SQL, or you've got things like their PubSub messaging bus or cloud storage, which is their object storage, any of those things, you can use the Spring Boot starters and the like to immediately make them accessible as, you know, easy first class objects in your Spring Boot app. So we saw this happen with Azure. You know, we continue to see ways to make it easier to talk to these different clouds without having to know each individual API. You just get to use these nice typed objects that work in Spring Boot and play nicely. So it was really cool to see that get released. I'm sure they'll keep evolving it, but you could use that today. Tasty. Now, also, as another thing, you know, I think it's been a while since we talked about like industrial IoT stuff, but there's a – I don't always look at this, but I probably will more now that I've refreshed myself. But also fellow Austinite, I believe, Stacey Higginbotham, if I can be so bold as to try to say her full name, she used to be at GigaOM and wrote somewhere else, but now she covers like IoT stuff, and she's got a pretty good roundup newsletter. But she had something that I think was fun. I think maybe it was all quoted from vendors, and you know how trustworthy vendors are. Am I right? But like it was still a good point about if you're trying to start up IoT things and you're worried about the ROI or the business case, it's good to, as always, start small with things.

And it's a good sort of brief overview that you can find a link to in the show notes if you go to pivotal.io slash podcast. And it's nice to know that just like in the normal software world, if you start like a big gigantic thing, that's probably a terrible idea. I'm not sure why that's nice to know, but you can apply the same tactics of starting out slow and experimenting, which I think is a good tip for anyone who's trying to improve their computering. But I think that's all the news we have for this week. So, Guest, why don't you give us an overview of what it is Radical Datical does? Well, sure. I mean, look, at the end of the day, we are releasing software faster and faster. We certainly saw that in, you know, 2002, right? Agile Manifesto comes out, and we're going to change the way we build software. And since then, we've gotten better and better at it. And I think it's reached a point, you know, certainly with customers that use PCF, that they're able to focus on the application itself. They don't have to worry about the infrastructure. They don't have to worry about how am I going to get there from here. The problem is, is that all of those things that have happened, Agile, DevOps, the cloud, containerization, none of that has helped the database. We are still updating the database the same way we've done for the past 25 years, which is what? We create a ticket, send it to some external data services team. They manually review and execute the script, and then somebody closes the ticket. That's the problem we try to solve. And at the end of the day, we're just trying to align database changes with your application code changes so that all the benefits you've gotten from platform as a service, containers, the cloud, can be applied to the database as well.

And so what's the deal with that? Why is the database world so, like, isolated from change? I mean, to some extent, so isolated from change that a whole other set of databases were created over the past 10 years to sort of, like, work around relational databases. It's sort of like – I always like to think – I always think, like, on the diagram, the thing that's still a silo is always the database. Like, it's always that, like, cylinder of isolation. And I don't know. I mean, why do you think it's been, like – it hasn't been invaded by all the agile and DevOps hordes of people? How have they so successfully defended themselves? Well, it is – they have a huge billy club, the data folks. They can use that – what they can say is, we're not going to change because we put the data at risk. And you tell that to a CEO, a CIO, CSO, they're going to listen, maintain the status quo, don't change anything. That's not working anymore. Right now, you have got customers that are going so fast with updating their application that it is really killing that external data services team. And they can no longer use that billy club of you put the data at risk. That's why it's been that way for so long. It's also a hard problem. It's not sexy. You can't look at a web browser and say, oh, wow, look at how they updated that database. That was phenomenal. That's right. No, no, it's not – it's not cool. But when you get a new app updated and say, oh, look what we did here, that's exciting. But you've got to fix it because a herd is only as fast as its slowest member.

And right now, it's that data tier. It is slowing down these large corporations that are trying to put out software like the small startups are doing. So let's talk specifics then. So you all messed around a little bit with Concourse and Daticle and things like that. So can you tell me – we'll drill into then some of the more esoteric topics about data and teams and legacies and things like that. But what have you done specifically around Concourse, especially for folks who are thinking about how do you drag the data tier into the 21st century? Well, let me start out by saying that at Daticle, we don't come up with anything. All right. So the way we're – what we focus on as a company is the challenges that customers are having. So we were working with a PCF customer that was updating their applications. And they were using Concourse. They were using Concourse to push those applications out. But what was happening is that they were waiting 7 to 12 business days is what they told us to update the database. So, for example, you add a new attribute to an object. Okay. Well, typically, you've got to add a new column to a table. And they would have to wait 7 to 12 days. And since they were using Concourse, we looked at the problem and we said, well, hey, we can integrate Daticle with Concourse so that when you go prior to pushing your application out, prior to saying build and release that to dev, test, prod, whatever, let's go ahead and do a forecast of changes and review those changes and then let's go ahead and actually make them, oh, that was successful. Well, great. Now we know that our application push is going to be successful. And so what we were able to do by integrating Daticle with Concourse is have a single place where you can push the entire application, not just the compiled bits, not just the microservices, but also the changes to the database.

Because one will not work without the other. So it has to go out together. So then how, like, you were saying it's like 7 to 10 days to make a change? Like, what's the result that they have after that? Well, that's the thing that's really killing me. I mean, because I hear from customers that are saying, oh, we're waiting 3 days, 7 days, 2 weeks. Some are longer than that. And I ask why. And they say, well, we have to get approval. We have to send this out to a DBA to review this stuff. And then I ask, well, why? You know, doing the Toyota 5Ys, right? Why, why, why? Eventually, we get down to the root cause. And it turns out that what they wanted was the world's best computer, the human brain, to review these SQL scripts, these proposed changes for correctness, for adherence to corporate standards, like, you know, table names must start with T underscore, stuff like that. And then we were looking at it, and we were like, well, that's what Daticle does. Daticle has a rules engine that can enforce these standards. And whether it's naming conventions or things like, hey, don't add too many indexes to a table, the stuff that DBAs look for all the time, we can automate that. And so there was really no reason to take time away from our DBAs who are focused on scalability, performance, high availability, security. Why have them focused on this tsunami of application changes that are coming? Let's get them focused on the things that they do really well, and let's automate this task. Let's not automate the role. Let's automate the task so that we can decentralize data management and push it to the app team so that, you know, you build it, you run it. And do these, do DBAs respond well to that? Like, how do you, well, let me ask a question and then make a bunch of statements.

Like, there's, like, I encounter a similar thing with audit people and, like, enterprise architects who, I don't know, you're sort of, like, stealing their point of existence. And so there's different answers you give to people, you know, it's always good to assure people you're not going to fire them because you've just automated their job. So that's a nice step. Hopefully it's true. But then, you know, it also, it seems like a lot of the times, like with compliance people, what you sort of get to is the idea of, like, you already work too much, so maybe you could work less if you automate this stuff. Because, you know, it's one thing to have the, you can do higher value activities. I guess a good response by an employee would be, like, then you should pay me more since they're higher value. But, you know, like, how do you win over the sort of, like, the hearts, let alone the minds of the DBAs who feel like they really like checking if the table begins with T underscore? Well, I got to tell you, I have never run across a DBA who really likes reviewing SQL scripts. Right, right. It's just not something that they're excited about. What they do get excited about is things like, hey, how do I move off this Oracle RAC server, this physical server I have that I can touch in my data center, to the cloud? How can I make certain that we're providing valid test data to all our teams in a self-service fashion? So, that gets them really excited. Basically, being, in essence, a release janitor for these things, cleaning up after the dev team, does not get them excited. So, there are some folks that certainly a large majority of DBAs will say, oh, thank God you're here. Get this off my plate. I'm so sick of those guys and having an argument every single time we have a change. And then they get to focus on the things that they really like to do.

But there are some folks that you get into a who moved my cheese kind of moment. And it is threatening. It is disruptive. One of a very large customer of ours, a real big consumer bank, there was a DBA that was not on board with Daticle. He had a real challenge with it and wanted to see it work. And then once it started, they started using it to push to production for changes. His tune changed. All right. He was really pushing back because he knew how scary and fraught with risk it was. But once he saw it working, he was totally on board. And now he's in charge of the enterprise rollout at this bank. So not only did he move away from his job of handling scripts, but now he's in a management role tasked with improving the rest of the company by rolling the stuff out. So, yes, roles are going to change. Tasks are going to change. And to some folks, that's scary. But we can't put this toothpaste back in the tube. It's out. So we need to fix this problem now or else you're not going to have a company to work at if you don't resolve this. Yeah, that's a good point of like, you know, no one wants to be the – well, I assume most people don't want to be the release janitor cleaning up the developer's throw up, right? Like it's a much better job to be a little more constructive rather than just like mopping the floor all the time. Can you imagine putting that on a job description, you know, post that to LinkedIn? Hey, can you clean up developers' throw up? Well, we've got a job for you. Exactly. Sign me up. So I was interested. I mean you listed a few things there as people kind of get started with this and especially as DBAs start to adjust to this new world. What do you see as – are there things, sometimes things people forget with this?

They think, okay, we're going to automate just the release cycle, but are there aspects around, you know, on-demand provisioning of data environments or, to your point, even data migration and things? Are there things that when you get excited about automating the data tier that might not be top of mind but should be? Well, absolutely. I would argue that it is the expand, migrate, contract model, all right? So a lot of our mutual customers have monolithic applications that they are trying to piece apart into microservices. And that model of expand, migrate, contract is exactly what they need for the database, all right? So, for example, let's say you are trying to – you're building a microservice that's going to handle user registration now. Previously, it was in your monolithic application, but the first microservice you're doing or series of microservices is to pull that out. So first you build it, okay? And then you start updating the monolithic app to call those – the new microservice, you know, driven application. All right, great. And then when that's all done, we take out the old busted code and we're done. So expand, migrate, contract. We can do the same thing with the database. So, for example – now, this is a bad example, but just for, you know, sake of, you know, because people are listening, I can't whiteboard this. So let's say you've got a column with first and last name, all right? And that's bad. We need to separate that into two different columns. So part of that model is we need to create two new columns and then we need to populate the data. But then we've got bits of code that is using the old column and now the two new columns. So we need a trigger that's going to keep those two – now three columns in sync. You can, with Datacle, enforce expansion, migration, and contraction.

You could say, all right, this release is where we expand. So we're only going to create new objects. And then at some later date, we're going to have a contraction where we're actually dropping things. And so at that point, you can have reporting that says, hey, we're dropping this. This is what's going to happen. And to alert the right people. So if you are able to automate your release process with the database along with the application, you're able to tackle these problems of how do we go from A to B. We have a real challenge with data, keeping data in sync. Well, let's go ahead and tackle that problem because now we have all this free time. Because we've automated a lot of this drudgery, we can now tackle this other stuff. And that's what companies are looking for. They're not looking to say, all right, great, let's go to the cloud and let's double our dev team. No, they want to enable that dev team that they have to move to the cloud. And so it's imperative on companies like Pivotal and Datacle to just really take a lot of that heavy lifting off their shoulders. Makes sense. What do you do with the legacy data stores? You know, the ones that maybe don't have APIs that make automation simple that you can't just, you know, programmatically update tables or add store procedures or do, you know, do extra monitoring from the outside in because maybe it's a vendor proprietary interface. So do you start to wall those off and suffocate those to move to platforms that are more friendly or sometimes you can't have that freedom to do that? How do you approach the legacy data store? Well, I think, good question. All right. And I think a good example of that is a lot of airlines use platforms like Siebel to keep track of their frequent flyer programs.

And they don't actually make queries to the database to get information, all right, which is probably one of the reasons why it takes like a day after you fly to see your updated, you know, statement to see the miles that you earned. And they don't actually, you know, they don't actually change the data structure. So for those sorts of things, we, you know, Datacle doesn't work with that stuff. So for those sorts of things, what we work with is custom applications that they've built where they do have to update the database. So if it's things like Siebel or Salesforce.com, you know, that kind of stuff, we, you know, we have our customers use the APIs to get the data. And we focus on managing those database schema changes when you update the application itself. So we really focus on the custom stuff. Got it. So one thing that comes up a lot is, you know, especially in our realm of cloud native awesomeness is how easy it is to release things. And, you know, one of the secrets of that is like everything's easy if you're stateless. Like all sorts of things are nice. And one thing in particular that I think people get excited about is the idea of if we're doing weekly or daily releases or whatever it is we're doing, it's a good idea to basically do sort of like blue-green deploys or incremental deploys or whatever fancy word the kids are using nowadays. But at the data level, the data layer, like if I, if I want to like incrementally do a release, right, I want to release to like 5% of the user population and 30% and 100% or whatever, like, you know, I can't like go change the database once. Like I almost need to have two databases running or something.

But like, I mean, what, what are people doing in that area to help out with sort of more incremental releases or do you just not do that with data? What are you seeing people do? Oh, you, you absolutely have to do that. You have to support that. You know, one of, one of the things that there's kind of two layers here to your question, I think. One is everything that you've said is true if you are making direct calls to the database. All right. So if you say this data here, the only way that you can access it and change it is through a microservice. That problem goes away because then it's, you're only changing the database that that microservice uses. And typically it's going to be a lot smaller. It's going to be a single team managing it. So you don't have to worry about changing a table name or something like that or splitting a table into two. However, if you are on that path from monolithic to microservices, you are going to have to make some pretty significant changes. And they typically come from, the biggest problem that you're going to have is drops or a rename. Another issue is changing data types. And so sometimes that makes sense. But a lot of the time, it does cause challenges with your deployment strategy, blue, green, or you have different zones or what have you. And so you can enforce standards with Datacle that just says, we don't drop. As part of this automated release process, we're not dropping, we're not renaming, we're not changing data types. Now, if you want to do that, well, then that's the time you need to engage the external data services team.

That's the time where you need to work with them and say, okay, guys, how are we going to do this? Will our, you know, maybe we've got three data centers or that we're using GoldenGate to replicate data around. How is this going to impact that? And, yes, you're going to have to engage with that team. But I would argue that it's far better level of engagement than, hey, I added this column, go run this script. There will be times you have to engage those folks. And that's what, you know, Martin Fowler has always been preaching, that cross-functional team. So I would like to see in an ideal world, we bring a lot of those DBAs from operations into the product team. You know, we're not calling them development anymore because they build it and run it. Let's bring those DBAs in so that they can answer those questions on day one of design as opposed to waiting until our maintenance window for a production push. Yeah, that's interesting. You raise up an interesting, well, for me, always interesting question is sort of like, I don't know, what are the design standards that apply here? And like, as you were saying, there's a standard that you might have or policy or whatever fancy word you want to use of, well, if changing a column name breaks things, how about don't do that? Yeah. And I think it's easy to get caught up in, like, all the, I don't know, rapid delivery of stuff where you're just like, you know, a bunch of keystone cops changing things around. But it does seem like, you know, to show my age, I always think back to that book Effective Java, maybe there was one of these in the .NET and other worlds. But like, Effective Java was basically a bunch of like, rules you would follow in Java to avoid doing dumb stuff, right? Like, you know, you should not remove methods once you've made them, things like that. And so I wonder, like, like, are people collecting what these, like, rules of DevOps database are somewhere? Or do these kind of style things exist?

Because a lot of them seem obvious, but probably are not until you type them down, as it were. Oh, yeah, that's the real, that's a real challenge, because a lot of these rules, okay, these concepts are stuck in between a DBA's ears. And just like, you know, these best practices, don't remove a method. That is stuck between a developer's ears, okay? And so what we have to do is tease that out. And that's what we've done at Datical, that we've got hundreds and hundreds of rules that are standard. You could certainly write your own. It's based on rules, so it's a very Java-esque looking way of programming. But, you know, we sometimes have to just sit down with a customer and say, look, what are you trying to do here? Can you show me the last three sternly worded emails your DBAs have sent out? Have you, you know, put this on Confluence or Word doc? Have you written this in stone on some tablets perhaps we could look at? And let's, you know, bring these rules into code and apply it across the entire enterprise. Well, they've got them written up in their ITIL runbooks, right? So you basically just have to copy that. It's no problem. Yeah, sure. Just cut and paste, man. Super easy. No problem. So with that said, do you think that, I mean, the DBA plays a part in, I mean, I'm trying to think of the future role of the DBA. And you kind of touched on this earlier. If they're not going to be release janitors, they're not going to just do, you know, low-level running scripts and things like that. So, you know, walk me through. What's the job posting for a modern DBA? Are they helping write some of those policies? Are they building automation? What are those things that I would be hiring for today with a sort of DevOps, cloud-native data DBA sort of type person? Well, look, I love affording people, individuals, the opportunity to grow the career, grow, reach new heights of self-actualization, make more money.

And because that's exactly what you're talking about. The days of being pigeonholed by the technology that you have mastered is over. You're expected to learn more and more as you continue in your career in tech. And we, you know, I also look for analogs. And I see a lot of similarities between what happened to system administrators with the advent of the cloud and Puppet and Chef to what we're seeing with DBAs right now. Remember, SQL is still the number one language used. All right. It's in all the job posting. SQL is number one. Okay. And that is still going to be needed. Certainly, people that understand the difference between outer and inner joins, very valuable. But we need our DBAs to stop being focused on this system of record and being an Oracle DBA or a DB2 DBA or MySQL or whatever. And we need them to focus on what data means to the company. And I would argue it is the most important thing. At the end of the day, that system of engagement, the application is supposed to change. But the data should always be there. And we're collecting more and more. So as far as job description, I would argue for a solid foundation with databases, exposure to NoSQL and big data, but also to be gifted generalists. They should know how to write code that's not SQL. They need to be able to automate their jobs because that's where we're going, and that should be the expectation. Yeah, that's interesting. That's like a – maybe it's biased from programmers, but a reoccurring theme for every role in this process is like you should know how to program more better, which makes sense.

I guess it is to some extent part of what being a generalist would be. Like if you can do some programming, you can manipulate a wide range of things rather than just the specialist thing you have. Well, I had like two more things I wanted to ask about. One of them just occurred to me. You know, I'm always curious about, you know, what goes on in the industries. And since you just like easily rattled off that the airline industry uses Siebel a lot, which as they say in that movie, that's a name I haven't heard in a long time. But anyways, like when, you know – What is it from Star Wars? It's an older code, but it checks out. Exactly. There you go. But – exactly. But like so in other industries, you know, what would be your generalization about the databases they use in other industries? Well, banks use a lot of DB2 on ZOS. Yeah. Makes sense. They are using – everybody's using Oracle. Yeah. Now, one thing that I have seen is a move away from it. I've seen a rise of certainly at Fortune 500 financial services, whether it's insurance or banking investments. I've certainly seen a appetite to move away from Oracle to either Postgres or MySQL. And I think that's shown in – you know, Gartner puts out that annual software marketplace revenue share. And I think a couple years ago, they started putting Amazon on the relational database and semi-structured component or bucket of revenue. And so we're starting to see people are adopting open source relational databases. They are adopting them very quickly in the cloud. And they are not adopting semi-structured, so no SQ on big data, as fast as we predicted five years ago.

That's one thing that we're certainly seeing. Now, there's a place for it, and it's important. There's a lot of value in those NoSQL document stores. But the idea that they are going to totally replace the transactional nature of the relational database, nah, nah, it's not there. So you're saying there's a more SQL afoot, not just less SQL, as they used to say. Yeah, look, it's – when all you have is a hammer, everything looks like a nail, right? So we put everything in Oracle. We put it all in SQL Server. But now there's certainly a place for those document stores. Like Cassandra for fraud detection is phenomenal. So I've seen a big uptick in that usage. But it is – the idea that there is a zero-sum game, that if one data platform wins, the others lose, that's not happening. In fact, everything is going up. Everything is increasing in usage, including DB2 for Z. No, I mean that's what we definitely see in the perch that we're in is people will use anything that works and not get – not force the hammer to work on everything, to use the old metaphor. Well, that goes back to the gifted generalist. You need somebody that is not – all they know is Oracle. So they're going to try and use Oracle to solve every problem. We need technologists. Fortune 500 needs technologists that can look at a business problem and apply the best technology to solve that problem regardless of what it is. Well, so the last thing I wanted to ask about, I remember a long time ago when I was talking with you all. We're both in Austin. So, of course, we would run into each other. I forget what you all are based on, but like what's the stack of software that you all use? I mean what's it composed of nowadays?

Well, we're certainly – we're based on Liquibase. All right. So Liquibase is an open source project for database migration. So that is our core, you know, what we do. Use that to update the database. But then we go a little bit further. So to add certainly the forecast functionality and the rules engine, that's based on drools. Daticle 4, which is currently released, is based on Eclipse. And we are re-platforming to microservices using Docker containers for Daticle 5. And that comes out on the 20th of February. And so what that's going to allow customers to do is, one, you don't have to install Daticle as a desktop app, all right? It is now a long-running server process that you integrate or interact with using either a browser or web services. So we have moved over this past year, 2017, from Eclipse to Docker containers, and it has been phenomenal. It is just the best move we ever made. Back in the day when we started, it made sense for our customers to have Daticle installed on their desktop and their servers. But now, as they move to the cloud, they move to virtualized servers, they're really jumping both feet into this. It's imperative that we're skating to where the puck is going to be. And for our large customers, that's the cloud. That's microservices. And so that's the stack that we're based on now. So does that mean, like, if you're moving from Eclipse, like you move from, like, OSGI Eclipse-y bundle things to container services that you wrap a UI around? Or, like, what does that mean? Because, I mean, you're essentially a tool with sort of like a, I don't know, headless running process that can hook into your pipeline, right, to do all this enforcement and everything.

And so it's interesting to think about, like, how microservices applies to a non-production thing, if that makes sense. Well, it was certainly a challenge. You know, there is workflow enforcement in the Eclipse UI, and they're certainly using those OSGI bundles, how we put the software together. But it turns out that we were able to take those bundles and wrap them instead of in the Eclipse UI in microservices. Right. You know, use a lot of spring, of course. And so, you know, that's, it was actually, it made a lot more sense than we thought it would. Yeah, yeah. You know, it's, it's, it's like Fowler, you know, he's certainly talked about microservices, that there is value in creating a monolithic app first, because at least you get your domain model down. Right. And that's what we were able to do with the Eclipse stuff. But now, a new day has dawned, and it's time for, if we're going to take advantage of scalability with the cloud, this is a direction we had to go in, and we have. Yeah, that's interesting, because I guess, in theory, you could scale up from a laptop, just running all this stuff to basically doing like, I'm going to embarrass myself, but you could horizontalize like running everything to get more, more horsepower behind it. When you're doing all your analysis and stuff by sticking it up, not only on a server, but into a whole cluster of servers or a cloud, as people would want to call it, and centralize that a lot more. So that's, that's interesting. Well, we certainly could have done that. But the time was right. I mean, look, companies want to purchase solutions that mirror the direction that they're going. And if we're pushing, you know, five-year-old technology, it just doesn't make sense to them.

And so we also wanted to personally, you know, if we're going to help our customers move to the cloud, move to microservices, cloud-native applications, if we're going to solve this persistence problem for them, we need to do it in a way that they themselves want to do it. Yeah, and then I guess, I guess to cite the obvious thing, well, do y'all run it as a service or is it like you run it, a user runs it on its own? Because once, once you can containerize it and stick it in a cloud somewhere, you could potentially run it for someone. Well, absolutely. And that's the direction that we're going. First, what we want to do is we want this installed inside our company's data centers. Now they're virtualized. A lot of our large customers have not moved to the cloud. They're certainly going there, but today they're not. So what we wanted to do was put this behind the firewall and we wanted to make certain that they were satisfied with it. Once you've made these, you know, Fortune 25 companies happy, it's then very easy to release this as a service. One of our challenges is going to be releasing it to every single cloud that our customers want to go to. And so that's, you know, one of the things that we're working on this year. How do we make a change to a microservice and then hit a button and then it goes out to all the different locations that we have it installed and also using a shared data store? I hear that there's some companies out there that are really good at managing that. Do you guys know of any? That's right. I'll have to go check my notes. Exactly. You know, some people. Yeah. Yeah. No, that's interesting. It's always fun to see the, I don't know, across, let's see, what year is this? 2018, across the last 10 years or so, the two steps forward, one step back move of getting like IDEs somehow running in the cloud.

And there's been a lot of two steps forward and everything, but everything gets closer and closer to that. So we'll see how all that pans out. Maybe one day we'll all be running on, well, I'm not a developer anymore, but developers will all be running on Chromebooks and we'll say, what happened to the sun rays? It'll be very sad. I remember those. Those were sexy. Yeah, yeah. I still have an old one that they gave me up on the shelf behind me that I don't know why I keep it. Maybe one day my kids will inherit it and they'll be, what is this piece of crap? But stick it on whatever eBay, eBay of the space future. Anyhow, well, on that note, as we contemplate the space future, thanks for being on. It was fun to talk about. It's always good to go over data stuff. If people want to follow up with you, maybe follow you around the internet in a non-creepy way, like what would you point them at? Well, certainly there's the Datical Twitter account, D-A-T-I-C-A-L. There's certainly at Robert Reeves, which is my Twitter handle. If Pivotal customers want to learn more about Datical for Concourse, they can go to our website, datical.com slash partners slash Pivotal. Or you can just put Datical, Pivotal, and Google, and it'll be the first link. Yeah, no doubt. Pretty unique combination of words there, probably, unless there's something I don't know about. That's right. Well, as always, thanks for listening. This has been another exciting episode of Pivotal Conversations. If you want to easily peruse the back catalog and find the RSS feed to subscribe to and all of that kind of stuff, see some highlights of other episodes we've had and end users we've talked to and other partners, you can go to soundcloud.com slash Pivotal Conversations. I think, as you may recall, if you haven't listened to last week's, relevant to us having PKS released this week, we talked with our buddy Paul here on the same team I am about Kubernetes and what it is and why you might be interested in. So check that episode out if you haven't seen it.

And every Thursday, we post the full show notes, which will have links to the things we talked about and other related stuff over at Pivotal.io slash podcast. And with that, we'll see everyone next time. Bye-bye.

Tanzu Talk · 🍕 Get more pizza.