Hey there. This is another interview from Mark in our SpringOne Platform speaker series. It's a pretty good one. I hope you enjoy it. Why don't you check out the conference that this is pulled from, SpringOne Platform. It's over at springoneplatform.io. It's October 7th and 10th in my hometown of Austin, Texas. And if you want to get $200 off registration when you go to springoneplatform.io and register, use the code S1P200 underscore M Heckler. That's S1P200 underscore M-H-E-C-K-L-E-R. You can also check the show notes at pivotal.io slash podcast to get that spelled out to you. So with that, enjoy the episode. Today on our Women of SpringOne Platform series, I'm joined by Erin Schnabel. Erin, if you would, please tell our listeners a little bit about you. So I've been at IBM for a surprising to me 20 years. I've been working with Java for that amount of time, which is also kind of scary. I think we established there was one time I was talking with Adam Bean, who's a Java champion, and we figured out, I think I started with Java 1.1. I don't think I had 1.0, but I had 1.1. And so I spent all that time working with distributed computing. I started with Korba, all of that stuff, watched the rise and fall of the app server. And now at IBM, I'm working a lot with Spring within the context of Kubernetes and some new open source projects that have been coming out that try to make it easier to write Java apps of any kind and get them deployed in Kubernetes environments. And that's a really good summary, I guess, within the tech realm. But let's go back to maybe how you got into tech, because obviously, that's a good history with IBM. It's a good history of some things you've done. But what was life before IBM? So I landed an IBM right out of college. But the before before falling into tech was like, my dad brought home the first computer in whatever year that was, it was 8088, like zero RAM, five and quarter inch floppy drives, you know, the whole thing.
2:13And I learned early, and I learned early, how to format hard drives, how to foobar your machine by forgetting to do this last six at the end, did that one that was silly. But yeah, I was the one in the house that made sure all of the stuff worked all the time. I installed the modem by myself. I used to use bullet and board systems when those were a thing. And I would talk to my modem and make sounds because that's what you do. And you're a little nerd. And I remember the first programming classes in high school, we actually did Pascal. There was a girlfriend of mine, which is just a funny story, right, where we were going to be sophomores during this Pascal class. And she was like, Aaron, I don't really know if I'm going to be any good at this. She was amazing at math, like total brainiac. And I'm like, you're going to be fine. I don't understand. And so she, she relented. We did it together. She now works at the NSA. And now she does it. She's a closed mouth person too. So it just totally fits that she's at the NSA. But that was how I got started. It was all that long time ago. And then when I went into school, I was doing computer engineering, undergrad, computer science, master's degree. And my graduate advisor at the time, because that was when Korba was, was being born, basically. This is a million years ago. And so he was into Korba, which therefore meant I was into Korba. So right from the get-go, going from, actually at the time, I was also doing some C and C++ and that kind of stuff. So from Korba, I went into, into IBM to work actually on what was at the time component broker. And that grew into WebSphere, but on the mainframe. So my first couple of years at IBM was actually on, on the mainframe, which is a whole different environment to work in. I'm kind of going a little, maybe into the weeds here, but how did you make the transition from mainframe to Java to local development? Because Java at the time was mainly just desktop and browser based, right?
4:16Well, so, so in college we were doing Java and that's what I said, like the 1.1, I remember the first Java in a nutshell book. Do you remember those? And then I have like the first two huge volumes. They have these really big books because at the time, everything you could possibly want to know about Java fit in the two tones, but they were two inches thick. They're big, big books. And those were, that was in college, you know. So it was just when I went to IBM, I was actually back at C, C++ and Assembler for a little while. And then because of the way Webster evolved within IBM, right, we had Webster on ZOS or component broker on ZOS, mostly C and C++ at the time and some Assembler stuff. And then we had Webster that was on the distributed platform, both of which were trying to do Corva and ORM things and distributed computing. And so those ended up meeting and a lot of code ended up being shared, which brought, you know, the two code bases merged, if that makes sense. So that was years of fighting with JNI and memory management and blah, I'm really glad I don't have to do that anymore. But we learned a lot doing things at that low of a level. And I do think there's a lot of kids, I think, right now coming out of school that have only ever done Java. I feel a little on the fence about whether or not they've missed something, you know. Like, I feel like there's cards you earn if you double free or if you allocate memory incorrectly. It's an amount of care that I feel like, you know, you need to pay attention to at least at some point in your career. But you're, you know, you're understanding how things work under the covers. But maybe that's just because I had to do it. Maybe it's a hazing thing. I had to go through all that pain. So you should have to go through all that pain. I don't know.
6:16No, I think there's something to that, really. Because when I came from the C and C++ realm as well, I was immediately, well, maybe not immediately. It took me a bit to warm up to it. But as soon as I realized that I no longer had to worry about allocating and deallocating memory and, you know, worrying about leaks so badly, so much, I guess. I was immediately taken by that. I thought that was amazing. But by the same token, when you do come through that, you're a lot more aware of things, I think. And when you work in constrained environments, so to speak, I think it does make you better or more aware of things and potential pitfalls than you maybe would be otherwise. But, yeah, I'm not sure it's absolutely necessary, but I think it is useful. Does that make sense? Yeah. At some point, they started getting the Java out of the IO libraries that had native byte buffers in them, where they had a certain amount that could be shared with native memory. And I felt like when those came, having the previous experience about allocating and managing memory made a big difference, because those native byte buffers, like, you had to count those. You had to reference, count them, and make sure that they got cleaned up, because otherwise we were just leaking memory, leaking native memory. And I think it also impacted, at least on Z, or especially on Z, Z has a different resource, like, it has different resource consumption behavior for threads. And so when you would start, you know, like, you couldn't create threads willy-nilly, because they were much heavier, which made you much more conscious of, you know, algorithmic choices, because you couldn't just make threads whenever you wanted to. Because it had resources, it had performance implications. So it's like, you know, I don't know that that would be obvious to people who didn't have a background in native, like, low-level native programming.
8:20What I was going to say, I think it's weird. Maybe you can agree with me. But coming from the early days of Corva, through then all of the Java EE stuff, and now what's happening with Kubernetes, I'm, are you seeing the cycle that I'm seeing? It's just, it's cracking me up every day. We're, we're basically on the repeat cycle. We're at the stage where, instead of, you know, Corva managing transactions and connections and local remote transparency and all that stuff, well, Kubernetes did SEO or something. I'll handle this routing magic for you. You don't really have to worry about it. You're just going to go send, send your requests out, and we'll make sure they go to the right place and that the connection will be scary. It's like, you're seeing all the same, all the same behaviors where everything was in the app, but then they pushed it all into the infrastructure. And then everything's in the app, but now they pushed it down into the infrastructure. And I just think it's funny. I do think we spend a lot of time rediscovering problems and resolving problems and then changing our perspective on problems and solving them differently and then rinse, repeat. Oh yeah, I think it's, I think it's generational, right? It's like, I'm, I've been 20 years at IBM, right? So right now I'm the rebellious teenager yelling at my parents, my corporate parents, right? So all of my corporate parents are stupid. They don't know what they're doing anymore. I mean, I'm kidding. I love them. But it's like, it feels to me like you've got a generation, you've got a cohort of people who designed something one way. Then you have the next generational cohort, you get convinced, you didn't know what they were doing or, you know, technology, the environment changes enough. But they're like, that it becomes that they didn't know what they're doing. They're going to throw all that out and do it in a new way. And then that way, you know, progressives in the next cohort comes in. It's like, oh, they don't know what they're doing. And it's just the way the pendulum swings. I feel like it's because you get different generations learning and improving then and then a new thing happens. And then, I don't know.
10:20It's probably a little more, I don't mean it to sound that adversarial. It just feels to me like that's what happens. There's an old quote by Edmund Burke, I believe. Those who don't know history are doomed to repeat it. So here we are. It's like two generations later. Yeah, two generations later, or back when we started 20 years ago. There's a different spin on it now, right? Because the virtualization stuff that we have now was not present. But at the start of cloud native hype, right, you saw all the distributed computing mantras from 1984 coming up. There's a talk. I have it brewing in the back of my head, and I really need to put it down on paper and bring it to a conference. And it's everything we needed to know we learned on the main break. They had all these problems solved in 1982. Pick the mainframe stuff. All the distributed computing stuff, time coordination, and memory synchronization, and all that stuff. They had it done. And we've just been reinventing that over and over again. I do think, though, and I'll see what your thoughts are on this. I think that there are many times that we do fail to take into account the lessons of history, the hard wins that maybe have gone before us. But I do think sometimes that, for better and for worse, that when we come up with a new solution to a problem that had been previously solved under a different set of constraints, sometimes we have to do that, I think. And sometimes, frankly, we come out with a better solution overall. Yeah, no, we have to. I'm not blaming anybody who had cloud-native, like interpreted 12-factor apps, for example, and cloud-native stuff, and the way Netflix put all of the thought-tolerance behavior and the retry behavior and all that stuff and put it in the app. I'm not going to blame them for that. The infrastructure that they were running on was in the middle of just being hyper-virtualized, basically, and it couldn't do both things at once. You know what I mean? Like, the app had to do the compensation because the environment was just, people were just figuring out what to do with the environment.
12:23But now, with Kubernetes managing more of the environment and providing more of that same capability, and then you have things like ITO and service meshes coming in to smooth over even more of those bots. Well, now, this is what I'm saying. There's now this generational thing where it's like, okay, we learned in the past that it's hard to keep that stuff in all of the apps. It's too easy for developers to mess it up, for it not to be consistent and push it down into the infrastructure because they're ultimately an infrastructure concern. But it's like, you need to get to a consistent thing, essentially, at this point, which is Kubernetes, to be able to make that decision and push things down, right? It went back in the second day, right? That was Corva. Corva was handling local road transparency. Corva was determining subs and ties and retries and fragments and, like, you know, it was like all protocol-level stuff, which meant the app didn't have to deal with it. So, in short, we keep rebuilding the primitives and then rebuilding the abstractions and then rebuilding the supporting network of components around it. In fairness, though, in fairness, we did learn. Thankfully, with this new generation, we're just doing, like, JSON payloads. When you look at gRPC, that looks a hell of a lot, at least to me. And I fell on the floor laughing when I first read the WebSockets spec. I'm like, look, it's JRP packets for HTTP. I mean, I just thought it was so funny. But in doing that with just WebSockets or gRPC, they're still very basic types. They're not making the mistake that we did with Corva and Java use value-type marshalling, which used to make me cry. I was at the transport-level implementation details for all of that marshalling stuff, and ZOS was an EBSIDIC.
14:28So, not only did we have to convert these value types from big NBNs to little – well, yeah, Z was big NBN. All the distributed platforms were little NBNs, but we also had to translate from EBSIDIC to AFI or UTF-8 or whatever it was, which meant within the Corva test suites and the JavaE compliance test and all that stuff, there would be times when there would be a marshalling error, and we'd have to dig through the dumps to find the bite that didn't get – it was crazy. Like, we burned hours combing through binary dumps to figure out where the marshalling error was. Ridiculous. So, I'm really thankful now that when we're doing this, we're like, no, it's UTF-8. We're not doing code page, like, here, let me put in this service context, or, you know, let me put in the IOR that these are the code pages I support so that the client can figure out which code page it wants to use. Why did we do that? You know, like, we learned that lesson. This generation of things, we're not doing that, which is smart, because that was just miserable. So, progress. So, yeah, we are learning. We're not completely ignorant, but in some of the other cases, we're still, like, having to learn the lessons we learned before. Well, when we talk, I hear the love in your voice for the tech, all aspects, you know, the coding, but also just the archaeology, if you will, you know, kind of digging through things. But is there something in particular that drives you, that you love most about what you're doing, what you have done, kind of where the industry is heading, or anything? Oh, I'm still that nerd that just loves banging on something until it works. Just joy. It's like, oh, for no, we're going to laugh at swear words. Yes! That's my favorite. I love it. And some of the, like, these things that I'm passionate about is because I had those moments all the way through. Like I said, digging through the value type stuff to figure out which bite was wrong so we could fix it and, you know, do all that stuff.
16:32It was absolutely, ridiculously difficult. And over my career, I've been called the refactor queen a couple times. And, you know, so there's lessons that I've learned. Like, I go absolutely bananas when people are talking about 100% code coverage for Java. And the reason is because, again, I'm the refactor queen, right? It's the last minute before the release and there's a memory leak. And in order to fix it, we have to restructure the code to, you know, to be more conservative with memory or something. It's like, you go faster, right? But I have to go in with the last minute, refactor all this stuff. And Aaron's method of refactoring is I'm going to take all of these files. I'm going to put them over in a different directory. I'm going to create new files. And, you know, structure the, you know, in an object-oriented sense, right? Structure the pieces the way I know they have to go together to work better. And then I'll go rummage in the files I moved and, like, pull the code over that's still valid, right? And link it all together again, which is great. And from a getting the end result that you want, it's like being informed from what you did but not constrained by what you did. You get to, like, a better result. But let me tell you, if you have unit tests that are at the method level, the per-line level, you have completely hamstrung your ability to do that. I'm completely hamstrung it because, you know, at that point, if I want to make a code change and, like, every little section of code was tested, including a really ridiculous test that just basically ensure that if you pass a parameter in, you get it back out again. You can't then make those kinds of changes without changing the test, at which point you have no confidence that you didn't change behavior. That's important. That's important. I go bonkers with it because I spent more time trying to fix J-unit test weeks that had inherited, like, a whole inherited system of mocks. I get to the place where in order to get 100% code coverage, they were testing their mocks.
18:33They weren't testing their code anymore. And it's like, this is just, A, unsustainable, and, B, like, you could, you had no confidence. Yeah, the test run, and they gave you a green code coverage thing, but you had no guarantee that they actually tested anything meaningful. I want to talk about their passion right there. Good burn. It hurts. And I get really mad when people try to say 100% code coverage for Java. There's some other languages where that works better, but Java has so many weird boilerplates. Whatever. So that sometimes if you really want to get to 100% code coverage, you have to do really ridiculous things that provide no value and constrain your ability to fix the problem. Okay, you say that like that's a bad thing. I'm kidding. I'm kidding. Well, so for me, like, I take code coverage as advice, right? So it's like, I will go look at my code coverage report, and I'll look at what I've covered and what I haven't. And I'll be like, oh, you know, that path that's not tested, the end result of that actually matters. It's a behavior that something else in the system depends on, and I don't have anything that makes sure that that result comes out. So I'll test that. So if there's other things that aren't important, like aren't fundamentally important for the results, then I don't worry about it. Does that make sense? Absolutely, yeah. And the test coverage metrics are just like any other metric. They're subject to gaming. And I think sometimes when you just focus on the number of digits and I guess what the number is itself, then you kind of miss the whole point of the utility of it. So, yeah. Wow. Well, see, I had no idea you were also known as the refactoring queen. That does change a lot, actually, in a really cool way. So now I just want to go to SpringOne even more just so we can catch up and chat and, you know, kind of cover more ground on this. But to kind of bring things back to SpringOne, because obviously that's what we're building up to, right?
20:36This is kind of our favorite time of the year, at least mine. I hope it is yours, too. But a couple of years ago, you were on the main stage at SpringOne Platform presenting about distributed computing. And you covered a lot of ground there. Has your thinking evolved on that during the past couple of years? Or have you solidified your thinking or changed in any way? Well, what we were talking about during that particular talk was some algorithms in distributed computing. And those haven't really changed that much. Paxos is still Paxos. Like how you get distributed consensus, you know, all that stuff. They're pretty established patterns. And there's places where you use them. So that part hasn't changed. And that was an amazing experience that I really enjoyed. And Corina Lea-Bavis reached out to me for that. And I was both very flattered. And I'm really glad I did it. That was a really cool experience. And I tell people, I'm like, I did that. I stood up on the main page and I didn't die. Like, that was great. And all of the women that presented in that session, you know, it was just really great to meet them. And that was just a really great experience. But outside of that particular talk, which was more about consensus algorithms, we've already kind of touched on some of the other distributed computing things. And a lot of that has to do with the general move away from some of the original Netflix libraries, for example. And to some extent, even Netflix is moving away from those libraries. A whole bunch of the libraries that they have are tablized, essentially, because they're, even they are pushing a lot of these concerns down into the infrastructure and out of the library. And so how we, you know, isn't, isn't perfectly stable yet. The service mesh concept, I think everybody likes, and it's here to stay, but I think there's still a lot of behavior to stabilize, I guess, as people try to make it do all of the things that they needed to do. And I think it's sort of unfortunate how much still has to be exposed to the developer in some of these new distributed environments.
22:45In some cases, it's absolutely unavoidable. We're making the experience of writing the app and running the app or an application or a service or whatever, like, the developer is much more involved in that whole life cycle than they ever were before. And as far as I'm concerned, I think that's great, because when we were looking at some of the Java EU behaviors, which I know are still present in the industry in a lot of places, the, okay, I've written this app, I've coded it, I've tested it, now I'm going to throw it over the wall to the ops guys who are going to impose new roles, potentially change how it's deployed. And I think a lot of the 12-factor manifesto is all rebellion. I'm like, no, don't change all this stuff after I've tested it, please, because then if it introduces problems, I have no idea where they came from. And I think there's a lot of validity to that. And if you still look at the myth that if any kind of stability between a dev environment, a test environment, a staging environment, a pre-prod environment, and a prod environment, good luck. You know, if something breaks, you've got all those environments to maintain, and each of them is going to be differently non-stample. I'm not going to remember names right now, but there's a couple of really prominent people in the field who are like, in these distributed systems, the only place you're going to get a valid test is in production. Like, you're not going to be able to keep any of your other environments up to date and current and consistent. You may as well just put it in production and use routing magic to be very selective about how traffic reaches that new version. And I know that terrifies people, because the production system is often treated for regulatory or other reasons, and they're very protected. But I think when you look at large-scale systems, certainly, like, the ability to actually make a production-like pre-prod system or staging system, like, it just doesn't work.
24:49Within IBM, we have Kubernetes environment, we have a whole internal infrastructure, right, for all the services that we stand up, because we provide, you know, IaaS and PaaS and all that stuff, and we need to notice. So, when we're writing services that need to be surfaced to users, it's really difficult for us to test those on the internal staging system, because the infrastructure guys are also testing their things at the staging system, which means, as a service provider on top of the infrastructure, or if the infrastructure is unstable, then we can't tell if it's our app or if it's the infrastructure that's having a problem, which means we end up testing on the production system with routing tricks. So, I think that culture change is interesting. I think we move forward. I mean, we obviously always try to have those non-production systems, those pre-production systems mirror as closely as possible, but the fact that they are not the system means that there will always, always, always be some variation. And, I mean, what you're saying is absolutely the truth. You have to have, you have to limit risk, right? You have to accept that you're going to test the heck out of things, you're going to do everything you can to not deploy something that would break production, but realizing that at the same time, when you do deploy something to production, you have to limit your risk even there and do this kind of graduated rollout. And if there is damage, very much self-contained, small-scope damage. Yeah. Well, I mean, part of it is the shift in how things are deployed, period, right? The monolithic, let me deploy these six more files to my running forever application server, right? I mean, I come from a background of WebSphere ND, network deployment, right, where we would manage, here's the apps, here's how you want to deploy them,
26:49here's the nodes you want to deploy them to, here's how you're going to roll back, here's how you manage your versions. I mean, that was all there. So the servers were running all the time, and you were basically managing how the applications were deployed to those servers, which is similar, right? Because what you do now at the Kubernetes level, it's just, you're not deploying a work file, you're deploying a little isolated self-contained, but it can make people really uncomfortable because managing dependencies or relationships between services is fundamentally more complicated. And it's hard, like I'm just seeing a lot of people struggle with the transition from I need to deploy all of these things at the same time to incremental update of all of the pieces independently. I still feel like even people moving to Kubernetes, they're in a monolithic deployment mode. I've got these five services that are unrelated, I'm going to monolithically deploy all five. Rather than sticking to the point of cloud native, which is I should be able to update any one of those five alone. Such attention. People have a really hard time. It's ironic because I think you've identified the problem, which is people. The problem is always people. But I mean, it is true. We understand the concepts. We completely embrace the promise. And then we say, okay, to simplify things, I'm just going to make sure I roll out everything at once. Because that way it's consistent. So the whole reason to go to this cloud native microservices stuff is that we don't have to do these big bang releases. Except that I don't understand how to give you a little piece. So we're still going to do big bang releases. In which case, why did you break up your monolith to begin with? Why didn't you just leave it as an understood monolith? There's no reason to add the complexity. If you're going to keep it as a big ball, I mean, there's no reason. Along that same path, you are going to be speaking this year on metrics for the win, using micrometer to understand application behavior. And obviously, the more we need to be able to deal with individual applications, to deal with systems of applications,
28:50we need to understand what's happening at a particular point in time, to see what's happening as it unfolds, and to be able to address that, if need be, when it happens. So how did you get here? How did you decide to present on that particular topic? Why did you feel that was important? I mean, obviously, we know it is. But what brought you to the point of saying, hey, this is what I want to present on the SpringOne platform this year? Well, I'm a big fan of metrics. And it's hard in some cases to, like, as you get into distributed systems, people historically, like coming from monoliths, usually did log analysis. Right? They had their logs. They would go scan their logs. They would understand their behavior for logs. Like, everything was based on logs. When you get to a big distributed system with all the more moving, all the myriad of moving parts, dealing with centralized logs can get really expensive. There's a lot more data. I understand that Kibana dashboards are useful and stuff, but it's hard to query what you want. And the amount of data you're gathering is just huge. And so metrics, they're a much more concise way to represent behavior. And you can be a lot richer in terms of how you get, even though it's a more concise format, you can get a better understanding of what's going on in your system if you use metrics correctly. And if you look at some of the monitoring protocols, the Google SRE team has one. There's a few others that are not coming to mind right now. A lot of them go from, like, let me count errors. Let me count the kinds of errors because in terms of getting advanced warning or, you know, better alerting on behaviors that indicate something that actually bad is going to happen,
30:51you're much more likely to see that from numerical measurements than you are from log analysis. Both in terms of expense, frequency of gathering, you know, and just how you can analyze numbers versus words. But a lot of people don't understand, they still don't understand how to do that because they're coming from a background where most of what they did were looking at logs. I really like the way micrometer was created. The actuator is really simple to turn on. The way you can write to pick your output format without worrying about it, that's also really cool. There is a contrast that I think is going to have to, we're going to have to resolve, which is open census, is now combining with open tracing into open telemetry, I think it is. And open telemetry also has a metric library. So how we square that with the micrometer library, it's essentially a library, with the actuator, right, there might be some variation there or some resolution to do. But to me, it's like people need to understand metric better. They need to understand the kinds of things they should be measuring. And it's not just because it's a better alternative. It's a more compacted alternative to trying to analyze logs, which is what we usually do. I think that was like a long-winded, not very smart answer. But that's why I'm interested in the topic. I know it's hard for people to conceptualize or to figure out what they should be measuring. I wanted to give some examples. Here's what you should be measuring. Here's why it's important. Here's how you do analysis based on the stuff that you're collecting. And micrometers. I find it fascinating. And I want to help people understand what they should measure and be interested in adding those measurements to their application. Yeah, that makes perfect sense. And that was an absolutely brilliant answer because I think so many times when we arrive at a conclusion, when we say, oh, this is what we need to do and here's how we're going to do this, and then we share that with someone else, we overlook the why.
32:55Because we've gone through all that ourselves, right? We understand why we understand why this is important and what we're trying to accomplish with it, that we just kind of skip to the end. We jump to the last chapter in the book, and we say, here's the answer, and here's who did it, and here are all the wonderful things this is going to do for you. And if people don't understand why they would embrace that in the first place, why they would consider it, it's very easy for them to kind of like, well, you know, I'll look at that some other time. And they don't realize they're shortchanging themselves so badly by not understanding. Yeah, the measurement stuff, oh, it's cool, but, like, why would I use it directly is really the question, right? Exactly. Turning on metrics, turning on the actuator, you get a certain amount because the actuator, as with all things spring, right, it all automatically inserts itself in a bunch of places, so you get basic information about runtime behavior, and that part's great. It's easy, you don't have to think about it, but what I think people miss out on is some of the other nuance you can get if you add, if you use micrometers, interfaces to add additional measurements so you can understand the behavior of your system without having to go dig through log files. Like, I kind of feel like you need to use metrics to tell you when you need to go dig through the log files. Right. Well, I'm really glad you're going to be talking about this and presenting on this SpringOne platform. So, you know, yet another reason that people should come just for that, just for the one talk. If I could ask, since you are a veteran of SpringOne platform, what's your favorite thing? If you had to pick one or maybe just your top couple things? I know, obviously, just getting to chat with me has got to be one of the highlights, right? I'm kidding. I'm kidding. But no, actually, I mean, in all honesty, one of the things I like the most about attending SpringOne is all the people that you get to meet in a great community, right? Of people that are there to talk about Spring and to talk about other distributors. I mean, at this point, Spring is doing a lot in the distributed computing space, which is interesting to me.
34:57And I just find the engagement level with attendees, how interested they are in the technology, how interested they are in talking to each other and talking. Like, last year, I was there just as a vendor. I was there as a booth babe. But it's like, you know, the interest level you had, even just talking to people, which is great. It was fabulous. And that's one of the things I like best about SpringOne platform as a conference. Yeah, I think, again, I mean, you hit on some of my favorite things, too. The community, the chance to just exchange ideas and kind of, you know, percolate things that may have been tickling the back of your mind. And to be among other people who are just as committed and passionate about it is just awesome. So if someone is kind of on the fence, if they haven't been to SpringOne platform before, if they're kind of kicking around the idea, they're looking at Austin and thinking, wow, great barbecue. But maybe they're not into barbecue. I don't know. I mean, I can't understand that, but maybe they're not. What would you say to someone who's kind of giving it some thought, who's considering coming to SpringOne platform but just hasn't decided fully yet? I think, for me, it's how much you can learn. There's just, there's a lot of sessions. A lot of them are very, very deep. Some of them are still nice in general and broad. But between, I mean, we'll be there as a vendor again. IBM will be there with the booth. There's lots of other people that are there. So in addition to the technical talk where you learn all kinds of things about technology, you can also go to different companies and see how they're using Spring, which can give you a really good perspective on how this whole system is supposed to fit together. We're in an era right now where I feel like there's just so many options, there's so many pieces, there's so many choices about how, like, there's reactive, there's traditional web stuff, there's functions. And, like, we're just at a place where there's so many choices, being able to step back and see what, like, get the options into context can help you see it much bigger, if you get a better feel for the big picture.
37:03And for me, both the talks and then also the vendors, like, you can start to see how these pieces can fit. Maybe that's just me. Not at all. But you did leave out one really key, important reason that people should come to Springland Platform, and that's to meet Erin Schnabel. That's right. You should come see me. And I will be around. I mean, I have that one talk, but otherwise I will be around the IBM booth. Yeah, I'll be findable. And people should seek you out. I mean, I know you're too modest to say this, but we've been friends for a long time, and Erin is one of those folks who just really is an absolute joy to talk with, because every time I chat with you, I learn so much, as well as just having a great conversation. So if you haven't made your decision to go to Springland Platform yet, this is one of the arguably best reasons you can make that decision, is just to chat with Erin. Obviously, go to her talk, sit in on the Metrics for the Win talk, catch up with her, get a chance to pick her brain and to chat. That by itself ought to do it, right? The barbecue is just an extra. Yeah. But in the interim. Oh, and the bat. You can't forget about the bat. Oh, I wonder if it'll be the season for the bat. I don't know if it's the right season for the bat. There's a whole colony of bats that live under one of the bridges in Austin, and it's amazing when they take off at Dunk. It's absolutely, ridiculously amazing. It's so cool. So anyway, but I don't know if it's the right season. I forget if they're just over the summer. Well, I had no idea. Now I'm going to have to look that up. Oh, my gosh. Yeah. It's so cool. It is so cool. And they treat it as a, I mean, it is a kind of a protected habitat. But in a way, they do have some boats that go out on the river so that they can see all these bats coming out from under the bridge. It's a breeding area for the bats. It's just, it's so cool. Anyway. Wow. Had no idea. So that's just an extra, nice little extra, you know, in the evening when your brain is full and you need to go out and kind of get away and relax.
39:06Yeah. Awesome. Well, see, again, I learned so much from you. And it's not just in tech, but who knew? Erin, in the interim, between now and Springwind Platform, how can people get in touch with you? How can they follow you and keep up with what you're working on? I know Twitter is the best way, I think, because I'm partial to Twitter and because I love following your Twitter account. But if you would share with our listeners. I am Ebullient Works on Twitter. If anybody goes and looks up the word ebullient, all of those definitions apply to me. So, fair warning. All definitions of that word. That's me in a nutshell. Wonderful. Ebullient Works on Twitter is probably that. Okay, great. Well, between now and then, it just gives us so much more to look forward to. But thank you so much for your time, for taking time out of your busy day, and see you at Springwind Platform. Always great to talk to you, Mark. Likewise. Thanks. Well, I hope you enjoyed that interview. I sure did. Hey, and as a bonus for listening this far, if you want to register for Springwind Platform, the wonderful conference we have coming up October 7th to 10th in my hometown, Austin, Texas, when you go to springwind platform.io to register, you can use the code S1P200 underscore M Heckler. That's M-H-E-C-K-L-E-R. That's Mark's last name. You can find the discount code if you go to pivotal.io slash podcast as well, and that'll get you $200 off the registration fee, price, winning admission, however you want to think about it. Well, we've got several of these coming out, so if you enjoyed this one, you should check out the other ones. And otherwise, tune in to the regular Pivotal Conversations each week or so, and we'll see you next time. Bye-bye.