Holly Cummins | Innovation Leader | In the Open with Luke and Joe

Luke: Thank you for joining us for another installment of In the Open with Luke and Joe. Today, I'm excited to bring you a conversation with Dr. Holly Cummins. She is an innovation leader at IBM, and our conversation is going to cover a variety of topics ranging from sustainability and Cloud Native development, to the IBM Garage method. Before we welcome our guest, let's say hello to my co- host Joe Sepi.

Joe Sepi: Hey Luke, how are you my friend?

Luke: Hey Joe, how are you? I'm well, thank you.

Joe Sepi: Good, good. The weather is lovely today. It really is quite nice. I can actually see our pool guy is out there freshening up the pool. We're almost like really nice pool weather. It's beautiful.

Luke: I think we are in the same microclimate this week. As some of you may remember, in past weeks, Joe and I are very close to each other, but the weather will be drastically different. I was in my garden this morning and it was beautiful. Gorgeous.

Joe Sepi: Nice. Yeah, yeah, I'm up in the woods, up in the corner and you're down close to the water. It's very different, interestingly.

Luke: Which, something I wanted to mention regarding this is, we've been talking about microclimate, but I learned something new this week. There's actually nano climate, getting down to meter scale and this is really important in agriculture, because where the frost happens could really vary depending on where there's tree cover, where there's not. I had a conversation last week with some folks from UC Davis, and they were talking about this and how they're studying it. I wanted to mention before we bring in Holly, there's a new Linux Foundation project that just launched this week called AgStack for Agriculture Stack. It's going to be all about open source models and data and code for the agriculture industry.

Joe Sepi: Yeah, that's fascinating. Nano.

Luke: Nano climates.

Joe Sepi: They can even predict the weather very well already, but nano, good luck. I'm very curious about that. I'll look into the AgStack. Pretty cool.

Luke: Without further ado, let's welcome Dr. Holly Cummins.

Holly Cummins: Hey.

Joe Sepi: Hey, Holly.

Holly Cummins: I got all excited before we do anything. Have you seen the streams from Sebastian Blanc?

Joe Sepi: No.

Holly Cummins: Red Hat. He has this house in France that seems to have this magnificent pool with these magnificent views, and so he now has started doing all his streams from inside the swimming pool. Come out and have the microphone and the keyboard, he'll be half underwater. Really, must try harder frankly.

Joe Sepi: Yeah, that's a grand idea. Like we said, Luke's not far. We're both vaccinated, they say we don't even need masks now, which I'm a little hesitant on, but we could go out to the pool and do this and do it in style. Let's see next week.

Holly Cummins: Yeah, we could do an open pool party.

Luke: Out of the gate innovation. Thank you. Thank you, Holly.

Holly Cummins: That's what I'm here for.

Joe Sepi: That's great. Why don't we start off, if you don't mind, doing a little introduction, and let people know more about you.

Holly Cummins: Yeah. I'm Holly Cummins, and my job title is an innovation leader. What that means is, I work across IBM, and if we've got a client that has this need to innovate and then we've got a client team that has a really cool solution and they just need a little bit of an extra push to make it happen, or they just need a few more ideas adding, or maybe they don't have any ideas and they just need, " Please, we don't even know where to begin with this. Let's get some ideas together," then that's my job, is to try and make it happen and try and come up with the cool ideas, and then to try and get them actually out and happening.

Joe Sepi: Yeah. Sometimes it's a few less ideas even that they may need.

Holly Cummins: Yeah, that's one of the things about innovation actually is, never underestimate the power of a good idea in a different context, and reusing these ideas and moving them from context to context and saying, " In this area, this is incredibly boring, but actually if we take it here, it's incredibly interesting." I think that actually is some of what's going on with the agriculture, is taking the techniques that we would've applied to something else as business as usual, and realizing that in agriculture they're new and they solve problems.

Joe Sepi: Yeah.

Luke: That's so true. There's another Linux Foundation project called Open Horizon, and that's exactly what's going on. They use it in factories, they use it in retail and now it's being adapted and being used for agriculture.

Holly Cummins: Cool.

Luke: I would also like to let our audience know a little of your CV, because you have this very interesting CV. You've been involved in Java, you've been involved in all kinds of development and product, and now you're in this innovation role, but you have a PhD in Quantum information Studies, is that right?

Holly Cummins: It is, yeah. I've got a PhD in quantum computing, which is actually why I joined IBM, because IBM has a huge history of doing quantum computation work. When I was doing my PhD, I met researchers from IBM and I said, " Oh, that's cool. I want to work where you work." Then, as it happens, I joined IBM, didn't end up doing quantum computing, I decided that actually I'd rather just program all day, so I joined IBM as a developer. Then, I started out working on Java performance. That was really rewarding, because the JVM is so widely used, that if you can make a half a percent difference to it, then that's going to have a huge impact. Then, when we're going to talk about sustainability in a bit, and when you think about in terms of sustainability, those improvements again can have a huge impact, even though they're small. Then, from there, I went and started working on Webster Liberty, which then became Open Liberty. Then, I wanted to see the outside world and I wanted to see clients and I wanted to see people who were using the things that I was building, so I switched and I joined the IBM Garage, which is services organization. We helped clients take advantage of the Cloud and become Cloud Native, because there's a lot of ways to think you're becoming Cloud Native and actually not become Cloud Native. We try and teach the best practices and share what we think works, and co- create.

Joe Sepi: Yeah, that's fascinating. I remember not long ago, a year or so ago, maybe a little bit longer, wanting to dive more into quantum and learn more about what we're doing at IBM and Qiskit, and all the things. I kept coming across your name and I'm like, " But wait, she doesn't work in quantum." Yeah, it's a fascinating trajectory. That's one of the things I love about IBM too. You meet people and they started here and then they've done this and then now they're doing this over here, and it's a long arc.

Holly Cummins: We talk about diversity in teams being a good thing, but I think diversity in individuals is a really good thing as well. Again, we talk about the certified idea of being a T- shaped person, that it's our breath that gives us our superpowers, and that if we know something from another domain, we can pull it in and solve a problem. Or, if we have a weird little skill that doesn't come in handy very often, then one day it's going to come in handy and we're going to be able to raise our hand and say, " Ah, I know how to fix this."

Joe Sepi: Yeah, that's fascinating.

Luke: I can imagine having this solid foundation in quantum, but then having all this experience in real production systems and working with clients... The time we're in now, the last few years and this next few years, are such a pivotal moment where quantum is becoming real. It's obvious to me you're so poised to be able to just come out of the gate and really help people use this technology effectively.

Holly Cummins: Yeah. When I did my PhD, the conversation that we had when we were getting tea and stuff was, will there ever be a quantum computer? It was an if, not a when, and for really good reasons because there's really fundamental physical reasons why a quantum computer is hard to build, because you have to have it perfectly isolated from the outside environment and yet you have to be able to interact with it. Those two are opposites, you can't do both, but actually, now they've vanished to do both. We really were back at the physics level and the theoretical physics level, and it's jumped forward so much in the past 20 years. Now, you can go and you can play with a quantum computer on the Cloud for free, which still slightly blows my mind. The conversation that we're having now is not, will we build this thing, because we've built it, but how is this going to be useful? What problems should we use it for? What problems have we not even thought of yet because we assumed they were impossible? Now, with a quantum computer, they moved from intractable to tractable, and we need to change how we do business to take advantage of that.

Joe Sepi: Yeah, and it's interesting, I think we talked about this in one of the prep calls. When you were doing your PhD in quantum computing and you joined IBM, quantum computers were in theory at the time, and then they became real. Now, not only that, they're on the Cloud and people can take advantage of them. Is that accurate?

Holly Cummins: Yeah. Most of my thesis I did in that lab because that was the only way that I could do it, and it was, " I think if we did this on a quantum computer, if we had a quantum computer, it might work out well."

Joe Sepi: Yeah, that's amazing. I'm curious too, you have all that background, and then now you're doing innovation with the Garage. Is it coming, I don't know if full circle is the right word, but do you see quantum on the horizon in terms of your innovative work at the Garage or how is that lining up at all now or in the future?

Holly Cummins: Yeah. IBM is starting to work with businesses to... We talk about this idea of phases of quantum. We had a theoretical phase, and where we want to get to is quantum advantage, which is when you can solve something on a quantum computer that you couldn't have solved otherwise, at least not in any reasonable amount of time. It's genuinely useful. It's not the theoretical. We couldn't solve this problem before and nobody would ever want to solve this problem, but we could solve it. It's when it's going to make a difference to your business. Where we are now, we talk about quantum readiness, which is, " Oh, we're so close to that quantum advantage." We need to make sure that we've got everything in place that we, as an organization, that we figure out what problems we want to be tackling, that we've got the skills in place, that we've got those connections, because there's going to be an advantage for the first movers to take advantage of quantum advantage, which is more advantages than that sentence.

Joe Sepi: Oh, you're on mute Luke.

Luke: I love to do that at least once every broadcast.

Holly Cummins: Keep us on our toes.

Luke: Yeah, keep us on our toes. I added the link to this blog post about the quantum development roadmap and I think, we don't have to get too into the nitty gritty of it here, but it's fascinating. Sometimes I feel like we're working at NASA in the 1960s. The amount of change that is happening that were right in the middle of. As you mentioned, right before the pandemic lockdown, I went to a financial conference, and it was so interesting to hear from all of these industry players, exactly like you're saying. While it maybe is not in production today, they need to get ready now, they need to start investigating, they need to learn these things, because it takes... Especially with mission critical systems, say financial industry or materials and pharmaceuticals, you can't just turn it on a dime, you need to really prepare and figure out how to integrate these things. Such a fascinating...

Holly Cummins: Yeah, it definitely does have this feeling of a frontier or a horizon. You have an idea what's over the other side, but you don't totally know, and we can guess what impact it's going to have, but we have to see it really to see it.

Joe Sepi: Yeah.

Luke: Well, and very much like open source. I think this is such a time for opportunity. What it is, get involved. Like you were saying, if you're a subject domain expert in say financial space... I was talking to a video game developer the other day, lifelong video game developer, very successful, so passionate about quantum. Spends his nights and weekends doing it. I just saw he posted he won a big hackathon. When you combine those things, now all of a sudden he's going to be able to bring that to domains that maybe wouldn't have... Someone who is maybe that physicist isn't necessarily going to know the things that he knows and then you find that common ground. It's amazing.

Holly Cummins: Yeah. There's a couple of cool things going on. One is, unlike NASA in the'60s, it's all being done as open source, because we know that's the most effective way to do things. Anybody can just rock up, make a contribution to Qiskit, make a poll request to Qiskit, move things forward. Then, as you say as well, the thing that we really need, is the problems, and the applications, and exactly as you say, physicists. They're not going to know every problem in the domain of banking. They're not going to know every problem in the domain of gaming, of maybe even agriculture. When people are using these systems, we're going on the trajectory that we went with classical computing, but much faster, so we have the equivalent of Moore's Law where we can see we're getting more computational power. Then, in terms of the programming models as well, they're advancing really quickly. A lot of times when we're teaching quantum computing, we start at the gate level of, " You could do this and that to the gate." Nobody, I don't think except for to learn it, really wants to be programming at the gate level. You want to be programming in your domain. You want to say, " I want to do this financial regression model. I want to do this four year transform, whatever it is." We need people to be developing those libraries that make sense to people in a domain, that then take advantage of the quantum computing. I think we're not there yet. At some point quantum computing's going to become almost like a sticker. So it's, " Well, there's a quantum computer inside, but it doesn't make any difference to my user experience as someone who's taking advantage of the system, I just know it can solve my problem, and before I couldn't solve that."

Joe Sepi: Yeah, that's fascinating. I encourage folks to take a look. You can engage with the quantum computer on the Cloud today, please go check it out. It's pretty exciting stuff. I know there are lots of other exciting things that you want to talk about, like sustainability, so maybe we can dive into that?

Holly Cummins: Yeah. I've been interested in sustainability for a long time. Like I mentioned, when I was doing the Java performance work, one of the things that made me feel really good about was what I was doing was, I could see there was this potential sustainability impact. I think it's becoming more and more pressing as a conversation, and more people are talking about it, which is really good. We're just, I think, on the cusp of... When we talk about the non- functional requirements of assisting for a while, we've been talking about resiliency and scalability, and now we're starting to talk about observability and that kind of thing. I think sustainability is going to be one of those ilities that we just should be including in the conversation by default. If you look at the IT industry, getting an accurate measurement of its carbon footprint is hard, which is one of the problems that we need to fix. If you look even just at data centers, they use around 1% or 2% of the world's energy, which is comparable to aviation. Aviation's around 2. 5%. When we think about aviation, we just automatically think, " Oh look at that, it's so environmentally irresponsible," but actually we're comparable. We, for pretty sound sustainability reasons, I think need to be doing what we can to try and bring that footprint down. The thing is, a lot of it's not hair shirts and making these really great sacrifices, it's things that we should be doing anyway. Maybe I don't need to have these servers that I'm not actually using that's hanging around burning cycles. That's going to reduce costs and it's going to reduce carbon so why wouldn't we do it?

Joe Sepi: Yeah. When you talk about sustainability and trying to do your part for climate change, there's small things, there's big things, you can get overwhelmed by the big things, but there are a lot of small things. I'm reminded of, we as develop advocates and engineers, have access to our IBM Cloud and we have unlimited stuff, but once a month or so somebody comes knocking and says, " Hey, make sure you spin down your containers and your clusters, and all this stuff." I think, like you're saying, simple things like that and being mindful of what you are using and what you're not using, can really go a long way in the small term, but it all adds up, right?

Holly Cummins: I'm fascinated by this problem actually, because it's one of those problems that seems like it should be really easy, and it is incredibly hard, because that experience that you describe, I've had the exact same experience in the Garage. I think every software developer in every organization has it. We want to learn a technology or we're playing or we're trying something out, and we spin up something and then we've done it, so then we get excited by the next shiny thing and we forget to turn it off. Then, someone somewhere in manager land looks and goes, " My bill is how much?" There's this steam coming out of their ears. Then they try and figure out how much of this is needed, how much of it can be turned off. It's really hard. Every system we come up with doesn't seem to work. There's depleting emails, is the first line of defense. We've all been, " I'm a bit horrified by my Cloud bill, could you please try and sort it out?" Then there's, I think we try tagging and that seems like it should work, because tags solve a lot of problems. Then, we have to come up with a naming scheme for our tag. How do I know what tags I can delete and what tags I can't delete? How do I actually make people remember to do the tag, because this is actually still a manual process? Then, how do I write my automation to go through and find the things with the tags and delete it? It just still ends up pretty clunky. Yeah. Then, the worst one I think, is meetings. We say, " My emails didn't work, so I'm going to bring you all into a meeting and we're going to sit here until our Cloud bill is halved." Everybody in the room's like, " Okay, I'll turn off my workload, just let me out of the room." We're seeing innovations in this area, but they're slow. Stuff like FinOps and GitOps I think can help, but it's still emerging for what is such a big, expensive, annoying, and apparently simple problem, except that clearly it's not or we would've solved it already.

Joe Sepi: It's funny that having a meeting to bring everybody in to bring down your costs is innovation.

Luke: I actually have a personal experience that really relates to this, and I'm both sides of this story. I'm the one who's perpetrating and the one who's cracking the whip. It's just my home electric bill. I have this studio, I have all these LED lights, and I'll have other rooms and I'll be running around and then maybe I'll just go to sleep and then I'll wake up the next day and I'll come down and I'll be like, " What was I doing?" I know, we see it in our own home electric bill. I'm like, " Yeah."

Joe Sepi: I don't know if this is a dad thing or whatever,'cause I know other dads have joked about it, but my superpower is going around turning off all the lights. I walk around, " Why is that light on? Turn that light off." When we moved into this house a couple years ago, one of the first things I wanted to do was get solar on it. Now I have a battery and I have an app that tells me how much I'm using and how much is from the grid and whatever. Now I'm pinpointing things like, " Oh, that pool filter is not very efficient. I need to look at upgrading that." Yeah, it's funny how sustainability comes into all this.

Holly Cummins: Yeah, the data is so important, because I think without actual numbers we go on our intuition, and I think we all trust our intuition a lot because, " I'm a smart person, I must know." We end up really fixating on something that actually doesn't contribute a lot. Then, it's something like the kettle, and overfilling the kettle, actually can be a huge drain, the biggest thing, but we don't think about it. We think about, "Oh, that device, I don't trust that device." As well, I think, I'm a developer, I love automating things. I've never seen something I didn't want to automate. It feels like we shouldn't be at the manual stage on this problem still. You shouldn't be wandering around turning off things after your kids. We should be detecting that no one's in the room and dimming the lights, and we should be doing that in our houses, and we should be doing it in our infrastructure as well. If this server hasn't had traffic for 30 days, maybe don't shut it off, 'cause that was the thing that was running the computation that was going to in 60 days solve all of the world's problems. Maybe send an email saying, " By the way, do you still want that? Looks pretty boring to me."

Joe Sepi: Yeah, yeah.

Luke: That reminds me, this past week I did a think session and the topic was code engine. I feel like this is a tool or a solution that actually gets to some of these problems, because it lets you do Cloud Native without having to worry about any of the Cloud Native infrastructure management, but you can also use it to run batch jobs. It's basically functions as a service as well so you can get to that place of, it automatically only runs things when it needs to run and you don't have to worry about all the tags and rules. I come from a soft layer infrastructure as a service, and I see why they created Kubernetes and why we got to this place, but it's still not that easy, and now we're finally getting to a place where we've got some mature tools like this.

Holly Cummins: Yeah. I think managed infrastructure, and multi- tenancy, and that responding to demand rather than being always on, those three things are really important, and code engine manages to combine them, which is so cool. Sometimes in the past I've heard people talk about just plain K Native as a solution because that allows you to scale your workload down to zero. The pattern I was seeing, which just made me go, "No don't do that," is we'd have K Native, but in order to run K Native we'd need to spin up a cluster. We'd have this whole huge cluster, and then the one little application in the cluster would spin down to zero when it wasn't being used, but the rest of the cluster was still there not doing anything because we hadn't sorted at our multi- tenancy. With the managed and the multi- tenancy that fixes that, and then you really do get the good...

Joe Sepi: This is a perfect segue to the next topic, but I wanted to make sure that we shared your blog post here,'cause I think this is really important. Do you want to touch on this before we move over to the Cloud Native topic?

Holly Cummins: Yeah, I think a lot of what I write in that blog post we've just talked about, but I've got a bit more detail on some of the factors that can make Kubernetes be inefficient. I think Conway's law, we talk about it for architecture, but I'm sure it applies to your network topology and your cluster topology as well, and these human factors that can then end up having that environmental impact. And, it's got pictures. The biggest recommendation for it.

Joe Sepi: That's great.

Luke: Yeah.

Joe Sepi: I would love to hear more about, you were saying patterns you're seeing in the space. Let's talk about Cloud Native. I know it's a hot topic. What does Cloud Native mean to you?

Holly Cummins: Cloud Native means so many different things, and I think when we were talking about sustainability just now, every time you said something I said, " We can automate that. There's a technology solution for that." I think that, as techies, that's what we do. I think we've done that a little bit with Cloud Native, and we've tended to focus on the technology aspects of Cloud Native. Sometimes we even say Cloud Native and Kubernetes as if they're synonyms. What I've been seeing is that, a lot of organizations want to be Cloud Native and so they try and buy Cloud Native and they try and install Cloud Native, but the why of Cloud Native is being missed, because the cultural aspects and the process aspects and some of those DevOps aspects aren't there. Then it means we've got all the kit, but we're not actually getting the benefit.

Joe Sepi: Yeah, it's hard to just plug in Cloud Native.

Holly Cummins: I think when we're trying to define Cloud- Native, for me I think we want to go back to the why and then frame it in terms of the why. If we are getting that why we're Cloud Native and if we're not... The why really is about having ability, getting to market fast really and being able to get something from a developer's laptop to a user in a really short time. Then, when you realized that maybe that time was too short and the developer has made a horrible error, that you can then get the fix from the developer's laptop to the user fast enough that actually it didn't matter because your quality's higher than it would've been if you'd done it the slow way.

Joe Sepi: I'm curious in terms of app modernization and perhaps migration, what are you seeing people doing wrong and what do you think is perhaps the right approach when you have more of a legacy application that you want to be Cloud Native? Native being the tricky part.

Holly Cummins: Yeah, I'm going to sound like a broken record, but for me, you have to figure out what problem you're trying to solve. I think sometimes again, this is something that all of us do is, we see things being done by others and we want to be better, we want to be as good as we can, and so we copy those but without stepping back to what problem that are we trying to solve. For example, I heard a story and it was a bank and they're quite well- established, long established bank, and then they were starting to suffer with competition from these newer, nimble competitors. They said, " What's going on? How can we fix this?" They looked, and they had this huge COBOL estate. They said, " Our competitors are not using COBOL, they're using microservices. We can fix this." They were hoping to modernize everything, rewrite it all in a more modern language, have it all be microservices. We thought, " Great. Yeah, this sounds like really good. Exciting project, we can help you with this." Then they added, " Our release board meets twice a year every six months." The point of microservices, the value of microservices, is that you can release them independently and the cost you pay for that is more overhead in terms of just the automation that you have to have and the testing that you have to do, and that kind of thing. If you're planning to release these things in a huge chunk every six months, you may as well actually just have them running in one process and then you're going to save a whole bunch of complexity, which is going to give you more time to actually write a better application that's better for your users. Or, if you're not going to do that, then you need to rewind and you need to not start with, " Let me make my application distributed," you need to start with, " Let me figure out how I can build enough trust internally to release this thing without going through this really slow, heavy, infrequent release board." That's what's going to actually make the difference to my customer.

Joe Sepi: Yeah, that's really interesting. When I worked at Adobe, I was on the Behance team, and they were acquired by Adobe. We had already had Behance, a pretty modern approach to CICD, and we're even building out our own tools to further facilitate that. Adobe recognized how we were doing things in a modern way, and they elevated that team within Adobe. " Okay, help modernize the rest of our groups." The first thing that we got, was a three page a checklist for a Java deployment that took two days and had multiple people sign off, and we're like, " Oh my god, this is insane." Yeah, those challenges are real.

Holly Cummins: Yeah, I worked on one of my first Garage projects. We'd been brought in by a client who really... It was a similar thing. They could see that how they were doing things wasn't quite ideal and wasn't fast enough, and they wanted us to coach them and help them. That change is hard, because these processes are there because people think they're reducing risk, and in fact they're increasing risk. Making that mental flip is tricky. We were doing full CICD, and full automated testing, and test driven development, and everything. Then, when we went to release we had a similar... I think it was 86 tabs in the spreadsheet. One of the things was about how many of our tests were passing, and we were like, " Of course it's 100%, because if it wasn't 100% that were passing, the build would've broken and we wouldn't have got to this stage." There's no such thing as tests that aren't passing in the CICD world. Again, it's just changing and updating those processes.

Joe Sepi: Yeah. I work on Node. js, and so that 100% isn't always... We have a column for flaky tests. Yes, I agree. That mental switch is really hard for people I think, especially who have been doing it that way for a long time. In that previous situation I was describing, we were sometimes deploying 80 times a day, and people were like, " How do you not break everything?" When you have a process and you have tests, that's what you do. Then, sometimes you do break things but you also have a process to scroll back a step and then inaudible.

Holly Cummins: Yeah. If you deploy that many times a day, you're so good at it that you can make changes really quickly. Whereas, I think what we sometimes see in the other way of doing it is, it goes out and it's not good, and then there's a real panic and either we have to do something really horrible... Open a shell on the production system and I'm going to patch by hand on the production system. No, just don't do this. Or, we end up with, it's going to take us two weeks of people working overtime and nights to try and get this thing out, whereas it should be just a boring thing where we go, "Oh yeah, whatever."

Joe Sepi: Yeah. Yeah, and so good at it is, typically tools that enforce the processes. Yeah.

Luke: I wanted to mention quickly, that we actually have a whole podcast series on app modernization. If folks are interested, this would be a great place to get started thinking about what techniques to apply. When we had our prep call last week, right after the prep call, I went and produced another think session and it was on Open Liberty, which we had just talked about. I was like, " This is so funny." They said the exact same thing that you just said, which was, there's this backlash sometimes you see on blogs and forums now where, " Oh we're going back to the monolith from microservices." That's not the answer. I think it comes back to, if we want to chase that new and shiny thing, but if it's not actually the right solution for that problem and you apply it, of course it's not going to work.

Holly Cummins: There's not going to be one answer for your whole estate, which is really annoying, because when you talk to an architect and you say, " What should I do?" They say, " It depends." You're like, " That's not what I'm paying you for, just tell me the answer." It does depend, because some things in your estate, you only change them when you can't possibly avoid it and it's running in the server under the stairs, and the right thing to do with that is to leave it alone and to not touch it. Whereas other things, either you're changing them all the time and every time you change them really hard, or you're not changing them but you can see you need to be and your customers are going, " Look, this is so annoying, why haven't you fixed this?" It's like, " Because it's too hard to change." Those are the ones you want to put in the microservices, put to the head of the modernization queue.

Joe Sepi: Yeah, it's interesting that you call it an estate a couple of times here. We're talking about owning houses and whatnot. If so much of my house and property needed updating modernization, I wouldn't take the whole thing at once. I would be like, " Okay, what's going to be the most impactful and what should I approach first?" I'm curious... Oh sorry, did you have something Luke?

Luke: I was going to say, if anybody has any questions, I forgot to mention this earlier, please feel free to drop them in the chat. We definitely have a lot of chatter going on in the chat, no direct questions. They're actually very funny. We have a very funny audience today. They have lots of silly things to say, which I'm not going to repeat, but feel free if you have any questions, we'll surface those here.

Joe Sepi: Nothing inappropriate.

Luke: No, nothing inappropriate, just silly stuff.

Joe Sepi: I'm curious, the conversation we're here we're having here around modernization... It's funny, I've worked at IBM for five years now, which I know is a small amount in the IBM world. A lot of people work here for decades.

Holly Cummins: You're a baby.

Joe Sepi: Exactly. Multigenerational sometimes, which is fascinating in and of itself. I don't know a lot about the Garage. Maybe you could tell me more about the Garage, what you do there, and how it applies to some of this work that we've been talking about?

Holly Cummins: Yeah. The Garage, so many things that when we talk about IBM, I've started by saying I love it. I love Open Liberty, I'm so proud of what we did there, and I love the Garage, and I'm so proud of the Garage. It really started when we are looking at the startup world, and we were looking at how startups were doing business. We said, " We have a Cloud that's going to be really, really great for these startups," but they weren't our traditional customer base in IBM. We said, " We need to change how we work in order to fit with these businesses." We adopted a lot of best of breed technologies and practices, so things like Extreme Programming, things like Lean Startup, things like Design Thinking, and we combined them together, which was quite novel at the time. We said, " We're going to work in startup spaces." We were in Galvanize in San Francisco, and we were going to work like a startup. What was interesting was, startups went, " That's cool. Wow, look, Watson could really help. Let me work with you." Then a lot of the really large companies looked and said, " Wow, that's amazing. We've been struggling to work in a modern way, and we're getting bogged down by this old way of working. We thought because we were a big company we couldn't change, but IBM, we can see you're working in that way now. Can you please tell us how you did it with your scale so that we can do it?" We started working with a mix of startups and large companies. With all of it, we were really working on web apps or the traditional domain of the Cloud. Then, what we defined was, we called it the Garage method. It was gaining that set of practices. Then, we realized that's not just for Greenfield, that's not just for a web application, it works really well for data and AI, because a lot of it is the things that I've been talking about. Start by trying to figure out what problem you're going to solve and what problem you need to solve before jumping to the technology. You need to do that in data and AI as well. Again, people, I think especially in data and AI, people forget because it's so exciting. You think, " Oh, I could make a data model." We don't step back to say, " But, is that data model that anybody needs?" Then we realized it's the same thing for apps modernization, it's the opposite of those Greenfield web apps, but the principles were the same of, let's figure out whose life we're making better and figure out how to make their life better. Let's be really radically incremental and iterative, and not do this big bang thing because that's probably going to fail. Let's do these small steps that are going to succeed. Let's do DevOps, ICD. All of these things, we just kept expanding and realizing that it worked in various domains. Now, Garage and IBM, we do a whole bunch of different things. We work with people who maybe haven't even bought anything yet and we say, " Let us show you how this can solve your problem. We have a services organization," and then we can do these big transformations as well to say, " I've got a big company and I need to change a lot of things." This is a different scale than just one team, but Garage can help with that.

Luke: I was going to say, that's so interesting and it makes sense, because the whole history of lean and that methodology, if you trace it back, it's like the Toyota method, and Deming, and all this. It came from the big organization, got really popular, adopted in for the small, and then comes full circle. The other thing I was going to say, I come from startup background as well, and I think what's so cool about IBM Garage method to me is, it's like a full stack. We think about full stacking code, but this is full stack all the way through design. I think that's so important, because my own startup failed, but almost every startup I've ever met that failed didn't fail because their product didn't work. It did work, it was a product market fit. It was the team, it was other factors. When you approach it from the IBM methodology, you're getting all of these factors, everything. That's why I was like, "I'm so smitten with it."

Holly Cummins: I think one of the things that we've adopted from Lean Startup, is this idea of, let's try and figure out what our biggest risk is and let's do that first. Whereas, I think we have a natural tendency to put the riskiest thing off for the last and we'll say, " I've got a really great idea. This is really great technology, let me do all this first, and then by the end I'll go try and figure out if anybody wants it." It was like, " Well no, let's try and figure out if people want it and if this is the right thing to do first." I think we do it in terms of our architectures as well. There's this really natural tendency to say, " I'm going to do all my plumbing work first. I'm going to do all my infrastructure work first, because I know I can do that. It's going to make me feel really good to have this solid infrastructure." It's like, well, there's no point having a solid infrastructure if there's nothing on top of it.

Luke: Which, that's actually what you just said, perfectly relates to this question we have from Facebook is, " How do you deal with and anticipate things out of the developer's control? For example, server, OS, Kernel updates, that affect the developer?"

Holly Cummins: I think with that, you probably want to divide them into two buckets, and you need different coping strategies for the two buckets. One, is the known unknowns where you say, " I can probably anticipate that this might happen. I don't know when it's going to happen, but because I can anticipate this, let me try and front load that risk, and either put in place a system to handle it as an early thing, or try and do something to make sure it doesn't happen," or that kind of thing. Then, on the other side, there's going to be things that you just didn't anticipate. Maybe you made a mistake, maybe you couldn't have anticipated, but either way they're just going to come out of the blue. Then, there's where you really need the resiliency. You can do resiliency in a few ways, and I think they're all really important. One, is like what we were talking about with the bad release. You need that CICD DevOps resiliency where, if something goes wrong, you can get a fix out without even breaking the sweat. Then, you need your team resiliency as well. One of the things that we do, is pair programming. We do that partly because it's for built in code review, and it catches problems and improves code quality. The main thing that we do is, there's this idea of staff liquidity, which is, if we have just Bob and he's the only one who can handle it, if a Kernel update happens and Bob goes on holiday, then the rest of us are in trouble, so we need to make sure that Bob is pairing and sharing his knowledge. Maybe the rest of us aren't going to be as good as Bob handling the updates, but we can do enough so that we don't have a catastrophe. There's the people resiliency, which comes through doing multidisciplinary teams, full stack development, peer programming, the technical resiliency which comes from optimizing for tight feedback loops, and then as well, front loading the riff.

Joe Sepi: Yeah, that makes a lot of sense. I've worked at places with a Bob.

Holly Cummins: Yeah, everybody's heading where it's, " Don't touch that code, he's the only one." Anytime any of the rest of us touch it, it's broken for six weeks.

Joe Sepi: Yeah, but I've seen it too in terms of the CICD stuff, and just containerizing applications and being able to repeat your deployment steps, staging QA testing, and all those things. Then, if you do have to update one thing, whatever it is, whether it's the deep down or just in your application, you have a process and it's repeatable, and then you also can roll back if it doesn't work. All these things fit into that, I think.

Holly Cummins: Yeah, one of the things that we always say is, " Never do anything manually. It's got to be automated. Never do a fix until you have a failing test that reproduces the problem." Otherwise, you can get into these fishtail, like a car fishtailing, where you veer from catastrophe to catastrophe. You fix the one problem, but you don't write a test for it. Then, the next problem comes along that was created by your first fix, and so you fix that but then that regresses the first thing because you didn't have a test for it, and so then you just yo- yo between bad situations, which doesn't make anybody happy.

Joe Sepi: Yeah, absolutely. I don't know if I've thought about it in the same way, but always, if something's broken, write the test for it and then fix it, and then you're covered for sure. I'm curious too, do you see the Garage within IBM growing and the usefulness of it? Obviously it's very useful, but I don't know if influence is the right word, but do you see it expanding and growing?

Holly Cummins: Yeah, it's growing both in terms of size and in terms of influence, which is really nice to see. They are hiring loads and loads at the moment, should anybody want to go look that up. As well, not just in terms of the numbers, but in terms of how so many organizations are looking at what we're doing and seeing how well it works and then adopting, either turning into a garage themselves so now there's lots of different garage organizations across IBM, or independent of the name, just picking up bits of the method and saying, " Yeah, that really does work."

Joe Sepi: Pop that up there for folks who want to check it out. Is the concept expanding? Correct me if I'm wrong, but technology garages, or is that related in the same sphere? What's going on there?

Holly Cummins: Yeah, so technology garages, that's a pre- sales facet of the Garage. Again, because we were doing really good stuff but people had to pay for it, and then we said, " Wouldn't it be cool if we could have a bigger reach by doing this without necessarily having to have that services contract in place, because people are going to get a lot out of this."

Joe Sepi: That makes sense. I know we've talked about Open Liberty a few times, and it's something that we wanted to make sure we touched on and I'm looking at the clock and realizing we should switch gears, and chat about Open Liberty. Tell me about what you've done there, and what's what's happening.

Holly Cummins: Open Liberty is probably a really good modernization story actually. I hadn't thought about it in that way until just now. What open liberty was, WebSphere Liberty was hugely successful for IBM, and was used by lots and lots of our customers, but it was large. For an ops, the ops experience was really great. The developer experience was large, which is not necessarily what you want on your laptop, but we couldn't modernize it, because so many people used WebSphere that we couldn't just say, " Hey, I've got a better, newer WebSphere." People would be like, " But I was using the old one, I can't cope with that change," and they shouldn't have to. Then we had this challenge to try and figure out, " Well, how do we completely change it and make it miles better, changing it all, and without breaking anything?" We worked out that what we could do, the things that people were actually depending on, was the the programming models and the APIs, and those external libraries. We kept all those the same, and we had them in little OSGI modules, and then we changed the inner core to be much more dynamic. We saw things like, it would start in three seconds, which certainly traditionally no application server had ever started in anything like that time before. We could run it on a raspberry pie, and again at the time, it was inconceivable and no matter who you were that you could run an application server on a raspberry pie. It was so small and it was so fast. The problem that we were solving, was developer experience. This is actually one as well where I'm going to contradict myself, because I say, " You've got to know what problem you're trying to solve," but sometimes you solve a problem that you weren't trying to solve, because it turns out that we'd optimized it for laptops and developers. It was just started instantly, and it was tiny footprint and that was great for developers. At the time, the Cloud was just starting to emerge and it turns out that's exactly what you need in the Cloud as well. It's so sensitive to footprint in a way that it's not if it's on- prem in a data center. It turns out that Liberty was the version of WebSphere that was really appropriate for the Cloud. As everything moved into the Cloud, it ended up being Liberty arena really took over there. Then, reflecting the success of Liberty as well, it was open sourced which was really nice. Again, this is too good. We don't just want us to be using it and developing it, and we want community contributions, and we also want it to be that friction free access where developers should just be able to use it without having to worry about contracts and stuff, you should just be able to use it.

Joe Sepi: That's interesting. I'm not as familiar, correct me if I'm wrong. It's now a little bit more componentized and probably a little bit easier for developers to get involved into different areas of how it's structured now?

Holly Cummins: Yeah, so the the big change, there was two changes. One, was that we componentized it, and that made that as a performance statement and it made it more dynamic, and it reduced the footprint. Then, it carried on that for a while as WebSphere Liberty, and then we made another big change and it went from WebSphere Liberty to Open Liberty, and it was open sourced.

Joe Sepi: Yeah, when I say, " Developers," I'm thinking about open source folks who want to get involved and help to improve and such.

Holly Cummins: Yeah.

Joe Sepi: Interesting, okay. Sorry, I'm looking at the website.

Luke: I also wanted to mention, I just asked Jan if you answered a question and she said, " Yes, you answered a question that the two bucket explanation really helps." She said, " Thank you." I wanted to ask too about, when you were working on Liberty, it was closed and then now it's been open, so now you've gone probably back and you can probably still have contributions in there. What was that? I heard a story from Brad Tobel about the Eclipse folks, when they worked on it, they were real upset when it became open because they thought they were making this proprietary thing. What was that experience for you working on something proprietary that then became open?

Holly Cummins: I was so happy when it became open source. There's a little bit of a scary thing once things become open source that weren't intended to be open source, because all of a sudden your code is visible to way more people. I think every product, all the stories isn't there of the comment that was never intended for more than a small audience and now all of a sudden people are going, " Why does this line say this never works and should never be released?" It's out there. I didn't have any of that in my code, but it was really nice, because so much is open now and there's so much vitality about the open source community, and being able to see my stuff out there and see my stuff being used on the community, is really cool.

Joe Sepi: That's cool. Do you see anything on the horizon, the future of Open Liberty that's exciting?

Holly Cummins: It's really gone now with microprofile, so there's so much activity around microprofile and bringing in a lot of things that you need and a modern server, a lot of the observability and that kind of thing. It's coming in via the microprofile standard rather than by the JAE standard. There's lots and lots of vitality in that community, which is nice.

Joe Sepi: Yeah, very cool.

Luke: If there's any other questions, but we are getting close to the top of the hour, we probably could fit in other question in if we get one through, but no pressure, folks. I will add the link to my micro profile in case anybody wants it. Since we are getting close to the end of our time, Holly, do you have anything we didn't discuss that we should have or anything that we didn't ask that we should have?

Joe Sepi: Do you have a movie coming out or anything?

Holly Cummins: No, we were talking beforehand, because I do have a book but it was written before I started working on WebSphere Liberty, and it's about the power of OSGI. OSGI is the technology that made Liberty so fast, and it made it so dynamic. I think it's a fairly niche subject, and the book was a while ago so I think we probably won't be beating down the doors of our local bookstore.

Joe Sepi: I will share the link.

Holly Cummins: You can share the link.

Joe Sepi: Yeah, let me pop that up there.

Luke: Well, thank you for adding it,'cause I had actually had it there and then I deleted it.

Joe Sepi: That's funny. Cool. Anything we want to wrap up on?

Holly Cummins: Oh, actually I've got one other thing. Unfortunately, I don't know if we have the link, because next Tuesday I've got a webinar on a IBM Cloud TV. I don't know when it is.

Luke: Expert TV?

Holly Cummins: Yes, thank you.

Luke: Let's see if we can find it.

Holly Cummins: Yeah, it's with Dana Price and Dwight Fortice. It's about the why of modernization. We're going to be doing a lot more of sharing some of those stories of, here's good reasons to do it, and here's reasons why you really shouldn't and you should have just done something else a while ago.

Joe Sepi: I found the link, but it's maybe not an easy one for folks. We might have tweet that one out. Hang on, actually I have IBM biz expert TV. Let me just pop that up. Oh, dang it, now the page went the other way.

Holly Cummins: It's okay, I only remembered it when we started talking about modernization.

Joe Sepi: Yeah.

Luke: At least I'll put the title up so it people can have a reference there. It's funny, that was the think session that I produced was Dana's session, so that's where they were talking about microservices and the misapplication of them sometime.

Holly Cummins: I've got a new party game though, which is, I can come up with lots of really obscure things to reference and watch you two scramble to try and find the link to put it in.

Joe Sepi: No, it's fun.

Luke: You're welcome back anytime. You could come up with some obscure things. Yeah, we're here for you.

Holly Cummins: Yeah. Super. This is fun, thank you.

Joe Sepi: Yeah, thank you for joining us. It's been really great talking, and I feel like we could dive deeper on any of these topics, which would be fun, but we'll save them for another time.