Voices in DevOps – Episode 19: A Conversation with Portworx

Guests

Lisa-Marie Namphy, Director of Marketing at Portworx, has built her knowledge of DevOps and tech as a open-source contributor and advocate of the SF Bay Cloud Native Containers User Group. She has led global developer community efforts on open source across HPE. Eric Han, the VP of Product Management at Portworx is also a founding member of Google Kubernetes.

Transcript

Jon Collins: Hello and welcome to this episode of Voices in DevOps, where I’m here to speak to a double bill of speakers. I’ve got Lisa-Marie Namphy and Eric Han, both from Portworx. I’m in the UK; you’re over in the Bay Area, so as usual, we’ve got this long-distance thing going. Let’s kick this off straightaway, Lisa, with yourself and maybe what brought you into both tech and into the offices of Portworx. How did you get here sitting on a microphone talking to me?

Lisa-Marie Namphy: Thank you. Thanks for having us, first of all, it’s great to be here. I love technology. I grew up here in the San Francisco Bay Area so I think I came to it through osmosis, just drinking the water! I was the daughter of an English professor at Stanford and I was an English major myself. For me, coming into technology is because I have such a passion for it and because everybody that I went to high school with was building the new, new thing and creating technology companies, and this was in the early days so I was fortunate to be at companies like Oracle in their early days, Hyperion and Arbor [Networks] in their early days.

I really loved working with developers and all my friends were developing really cool software that then they were just putting out there – open source – for everybody to use. I just thought, ‘This is really neat’ and watching how communities came together to build this software. People from across different companies who just had a passion for the same thing. That spark that I’ve heard some of your other guests talk about in your early days of DevOps, you feel that spark, particularly here in the Bay Area, with the new technology.

I run a really large user group and I always try to focus on whatever the new cutting edge technology is. I try to run the first meet-up of ‘you name it,’ and I keep it broad, whether it’s cloud native, automation, containers came in, so we always have the opportunity to bring to the community and to work with developers who are working on the cool new thing. That’s what gives me energy. To answer your question about how I got to Portworx, the hottest new thing in cognitive storage, I couldn’t resist. Once I met wonderful people like Eric Han, I was like, “okay, smartest people in the industry are here, this is where I need to be.”

You do run a lot of user groups, don’t you, and you spend a lot of your time doing that.

Lisa-Marie: Yeah. I try to combine them all into one big one that I can run cool technology out of because that’s what the community here wants. You don’t have to all be in our own little silos. I love bringing solutions together and seeing how ecosystems work together and whether it’s open source or not, bringing different technologies together and bringing solutions to our customers. It’s my passion.

Eric, you’ve got an interesting background as well, I think.

Eric Han: Yeah. It’s great to be here, Jon. I consider myself very fortunate to work with people like Lisa. It’s just an exciting time and in this space there’s so much change. My personal background is actually more that I started off in enterprise tech. Just was really interested in core networking in college and grad school and that evolved through Microsoft then. I spent quite a bit of time there doing enterprise work. Then I did have a great time at Google, where I was part of the original Kubernetes team. Since that time, I’ve been at Portworx from early, early days when we were in a small little office, now to where we’re growing all the time. We’re very lucky to be having people like this with us.

From my perspective, the thing I would answer for you, Jon, is also “Why is tech still interesting?” It’s really that it’s constantly... there’s a lot of things that we relearn, a lot of things that we do again but they’re different every time. There’s so much imagination and so much practical benefit that, in some ways, how could you not be excited about what’s going on?

We’re not here to talk about Portworx but we are here to at least reference Portworx. Storage is – to anyone that doesn’t work with storage, it’s not, let’s say – I actually once, many years ago, gave a presentation called Making Storage Sexy.

Eric: How did that go?

It went extremely well, funnily enough because there’s so much going on, and I think that people forget just how everything relies on – you think about the processor and the networking side of the infrastructure, but everything absolutely relies on where you actually put the stuff. In database terms, the persistence layer as I like to see it, it’s where you stuff your money under the mattress, under the bed, so that at least you know where to find it again! Anyway, storage is interesting. Storage is fun. Storage is great.

Eric: Let me just jump in there. I would say it this way: I couldn’t agree more in the sense that, not just one company, this is the way things are evolving to where everyone will do it this way. Rather than talk about this vendor, any vendor in specifics, I think it is an industry change that is more important to me.

What keeps us excited, what keeps things going is that even as things evolve, we start with DevOps, we start with automation, and maybe we automated some simple applications but every application (in some ways I want to hear more about your talk, but) every application has data. Whether we can make that automated in a way that – I do believe that we have to appreciate automation, it’s value and where it’s useful.

The point is that the industry, regardless of one vendor, will be automating every piece of data, especially when it comes to production. It doesn’t have to be at scale and it doesn’t have to be for every use case, but there is a change of making it easier, more predictable. That’s what I think is valuable, regardless of one company or another.

Lisa-Marie: Yeah, and I’ll just add onto that. We can make any technology sexy. I used to work for a POSIT certification company and then I worked for an OLAP company. If I can make OLAP service sexy, CEP, POSIT –

You got me; I’m already there!

Lisa-Marie: I can talk about complex event processing in a way that would just bring tears to your eyes.

I just got the shivers!

Lisa-Marie: Because what’s sexy about it is the technology, the cutting edge-ness of the technology. As Eric was saying, everyone is going to do it this way. Containers are a thing. It’s not going to be like, “oh should I?” so this technology is being adopted. Now, we’re solving the problems – the rest of the ecosystem problems, like okay, well how do we secure this? What’s happening with the networking? Storage is a huge piece of that because the data it turns out is very important to people, don’t want to lose that. This to me is super interesting and how we’re solving these problems and people rally around it.

You said something I think earlier when we were talking about how this is still early adoption and not everybody is doing it. We actually just did a container adoption survey and found out that 87% of enterprises are running containers right now, and at least half of them are running some sort of application in production. This really is a reality today. I don’t know what part of DevOps you want to plug that stat into, for adoption... it’s not if, it’s not when, it’s now, I guess, is what I’m trying to say.

I think at the risk of digressing and not even getting past the introduction to the podcast, we’re always on dangerous ground, you said a really interesting thing as well, Eric, which is, essentially that – well, it’s one of those things that I think is interesting because it plays into some things I’ve been thinking about; therefore it’s interesting. It’s one of those self-reinforcing loops, isn’t it? It’s the fact that we’re actually going into a phase where things are starting to standardize a bit and that’s fascinating.

Rather than this big fan out that we’ve had – there’s several different ways you can do just about everything and you end up Xn possibilities and massively fragmented pipelines and massively fragmented target architectures and so on. We’re coming around to certain views about what the target should look like, what the pipeline should look like, about how to deal with certain patterns in the storage layer and so on, which just makes life so much easier for everybody. Thank goodness for that.

The other thing I wanted to mention was the fact that when we do look at those enterprises, a lot of these challenges they already had. When we talk about legacy systems for example, to me a legacy system situation is just one where you’ve already got the experience of all the things that could go wrong. When we’re starting to have these conversations with people about… never say to an enterprise guy, “it’s all about the data” because they’re going, “yeah, I know!” It’s really good that we’re having these epiphanies and we’re starting to standardize a bit more because it does [make] us more able to actually have conversations with people that have been around the block a few times and they’re trying to address the challenges already.

There you go! That was almost a soapbox rant. What have you got to say to that stuff, so what’s the challenge?

Eric: I feel like, Jon, there is so much we could say. I think, not to be contrarian, let’s just use an analogy from a different industry. Standardization in automobiles is a fun one. A long time ago, things would be hand-assembled etc., and then you could say, things got standardized in terms of how they’re manufactured or roads or tires. I just back from visiting London but we drive on different sides of the roads. There is standardization but there is also still differentiation and I think things in this ecosystem people can point out to that are standards-based.

I do think that the infrastructure, how it gets substantiated, how it gets consumed is becoming more standardized in a productive way because what we don’t want – and I don’t want to throw another buzzword is – people talk about ‘lock in.’ You caught me. My point here is that I think from a lock-in perspective, which sometimes talks about standards is: I think people are willing to be soft locked-in based on the value, but not be hard locked-in based on some non-standard based approach. What I’m bringing out is that there’s always going to be changes. My car ten years ago is not the car I have now. It’s not the car that I would have ten years from now. My point is we start to compete and differentiate at the higher levels. Those sometimes get noisy and hard to swap in and out, but I do think that there is a productivity benefit. We’re getting the toil standardized so that the toil starts to become easier and easier. That’s the part I value.

As much as we talk about the complexity, I’d rather focus on solving some of the core basics. To your point, data has always been around. Enterprises have always had – the problems are consistent, but they’re changing, in terms of what the actual day in and day out can be. In our own careers, we’ve seen that. The thing that enthuses me is that there are enterprises who are saying, “This is not how I did it three years ago,” but DevOps automation containers – it’s becoming the pattern that I think about today. That pattern is to get to a different plateau tomorrow. Otherwise, we’re just circling, and no one’s trying to circle here. We don’t have enough time. I think standards are there. I think the standards will enforce the bottom layers. I don’t know yet about the top. That’s the contrarian point, if I had one.

Lisa-Marie: These standards need to be global. This is another challenge we have with software. It’s getting more and more global. It’s easier to have developer communities on the other side of the planet. You used to sell companies all over the world if we can get past a few regulations. One of my favorite slides I’ve ever seen Eric present – we just did DevOps Days [in] Amsterdam, and Eric was giving the keynote. He put up this slide of – he literally unpacked his bag and put all of his adapters, the plugs that go into the wall, on his desk. He showed a picture of it. He had at least seven, eight because he was traveling through different countries of Europe, and everybody has a different type of adapter. His point was: “can we get a standard here for electricity?” Clearly, we can’t. He builds off on the history of electricity and why. If we can simplify this, and to the degree that we can simplify this, I think, is going to make us all a lot more successful.

Maybe that’s the key word: simplification. I love the notion of a soft lock-in. I think that there’s a lot of mileage in that. Lisa, I’m interested to know what you think about – if you’re wearing the new, new thing hat today, how does the notion of getting everyone onto the same hymn sheet play out when everyone wants to do whatever’s next around the corner and the new exciting stuff? Is there an alignment, or is there a misalignment there?

Lisa-Marie: It’s very difficult at times for larger organizations especially. If you don’t have a mandate from the top down – “We are going to do this, we’re going to get on board with this technology, we’re going to do it this way” – it’s not going to happen. When I was a developer advocate at HPE, one of my jobs was to roll out an enterprise-wide GitHub license for HP software for developers.

You would think that would be an easy thing. It’s like, okay, this is a company mandate. Everybody’s going to be on GitHub. This is how we’re going to do social coding, have this whole social coding movement. You buy companies that come in with their own technology. Half the people are on Proforce. People are on all kinds of different stuff. Trying to get everybody on the same page, not just from a skills standpoint but from an emotional and mentality standpoint, it was really hard to shift a culture and to get a large company 100 percent on the same page.

It has to be a mandate, and it’s going to be painful for some people here and there. If you don’t, we see the price of not adopting the new, new thing. It turns out, the way we develop software now is completely different than the way we developed software five years ago, ten years ago. Every year it’s changing. Every week it’s changing. Companies need to think a lot about that, especially companies that aren’t tech companies and when tech isn’t your core business. Mercedes – you have to all of a sudden be a software company. GE – all of a sudden you have to be a software company in order to really keep up with all these trends. It’s hard.

Eric: I think that’s the most harmonious way. I love that perspective. I think there’s always that little rebel group out there that’s in some ways trying to buck the trend. They’re experimenting. I think there’s a lot of hope that I personally feel that these little experiments – sometimes, they help educate us in terms of how to

then later standardize. I totally agree with Lisa. I also appreciate those little groups out there, not that you don’t. There’s always those little groups out there that you wish would go away. Some days, they come back, and they bring you something that’s pretty amazing.

Lisa-Marie: I think you have to push the envelope, or we won’t innovate.

I’m just reminded of a large government place that I used to work at, which will remain nameless. It was very good at doing things right, so on and so forth. Then there was the library. There in the library was a librarian. There in the librarian’s office was a desktop. There he had installed Linux. It was just a tiny example of the boring place, the boring guy, and the boring little setup. That’s where a little spark of innovation happened. I think it’s not always the big flames of the exciting front-end stuff that need to be fanned. It’s just watching those little ground swells and nurturing those little roots.

Eric: Yeah, and I think sometimes the expectations – it just helps to fly under the radar for a little while.

I’m delighted to talk about the standardization as a thing because actually, one of the big challenges I see when I speak to organizations out there is almost the sorcerer’s apprentice challenge, which is where they’ve got so much fragmentation. They’ve been trying all these new things, lots of different teams. To your point, Lisa, shouldn’t be silos, but operating in a very siloed way.

You’ve got little groups everywhere trying out this new stuff, and trying it out in slightly different ways, with different pipelines, with different tool chains, and ending up with literally thousands of different ways of doing things, different tools, different targets, and so on and so forth. Fragmentation is clearly a big issue. We can carry on talking about that stuff, or is there, from your storage perspective, something that you can see? Actually, do you know what? What we’re seeing most of all that really is preventing progress right now, is ‘stateful vs stateless’ – making the infrastructure linkages. What are you seeing out there?

Lisa-Marie: That’s a really big one: stateful versus stateless. When Kubernetes first started taking everybody by storm, there was this notion that you could not run stateful applications on Kubernetes. That’s absolutely not true. You do need a little help from companies in the cloud native storage ecosystem and other parts of our community.

We have to figure out a way to solve these problems because it’s just too important not to. People are going to want to run the applications in containers. We solved this problem. I think that’s a really big one. It’s referred to often as day two problems, day two issues. Day one is pretty easy, but what will you do on day two, three, four, five, six – that’s where we chose to focus, and I think we’re solving a really crucial problem.

Eric: I just want to jump in. I think I’m probably going to contradict my earlier comments, but I feel the right to do so. Starting small, experimenting – I think the thing here is – the thing that, in some ways, touches a nerve is, we travel and we talk to people. Sometimes I’m on stage, and sometimes there’s somebody sitting next to me that I disagree with who says, “Let’s just start simple.” I think there is such a thing as starting way too simple. My point being I think we have to have some strong beliefs. We can talk about strong beliefs we held.

My point here is this. I think the containers, Kubernetes storage – the thing that I believe in personally is the automation, what you can do in terms of having a platform. That platform, in some ways, what Lisa’s also pointing out, has to be useful. We start way too simple, and we start using little examples of how I can do HelloWorld apps. That’s not really going to move the needle or benefit anyone after the library, as we go bigger in the campus.

What I want to contradict myself in saying is that we have to pick a problem that is tractable and solvable but also represents the end goal. If the end goal is to say “How does my team get trained up on this new technology?” it better be a use case that matters to the business. What I would say looking more at our customer base is: it's oftentimes a lot of analytics workloads. It's like "Hey, I want to process this set of logs. I want to be able to explain to my business what's going on." If that's end-meaningful, those are incredibly rich. If it's not that, that's fine.

My point is, let's not start with the technology to answer what we should be doing. Let's start with what the problems are [we are] solving. Oftentimes, it's: how do I move into production faster with these workloads? Regardless of what we pick, I think there is such a thing as too simple. I want a T-shirt that says that.

You can start too simple. For some reason I actually had a T-shirt that said, "Pobody's Nerfect." When someone said to me on Twitter, "Pobody's Nerfect," I then said, "Oh, I have that T-shirt." Then I was able to find the photo of me, when I was aged about 19, wearing that T-shirt. There you go. Nothing to do with anything at all.

Eric: I had a hat that said, "Blah, blah, blah." I'll go look for a photo, but it's got to be – (laughter)

I just wanted to wrap up a little bit quickly because almost we went straight to the – right the way through, and right to the answer, and then all the way back again.

The first thing we talked about was stateful vs. stateless and the switch. In my ignorant lay person's understanding of that, it's that a lot of these new technologies enable you to do really clever things at the application level, and manipulate data. Then if you switched it all off and on again, you wouldn't have any record. You'd need the system of record behind the scenes somewhere to hold that information. You've got to make a translation between the run-time, everything's just happening because it should, and actually being able to store something in the back. It's that management of the state of the application, the state of the process, the state of the date where it's all represented by what you store. That's my understanding of it. You can correct me on that.

Lisa-Marie: I think you just made the point that we make a lot, which is that there's really no stateless application. I think one of our customers told me once, "The only stateless application out there is HelloWorld." Almost everything has some state involved. Really, what we're talking about – we're solving a problem that everybody has. I think that's partially the point that you're trying to make.

Thank you for not saying, "No, you've got it completely wrong." With that, this does fit into the whole conversation around standardization, fragmentation around soft lock-in and all those things because essentially, to your point, Eric, a lot of this needs to happen already, so that you can get on and build things. You can't just be the librarian. You can't just be learning from scratch about what the patterns should be because it will take you too long. You won't innovate.

It's a bit like someone said to me... it was actually someone from a travel technology company, or an online travel agent, OTA, who said, "We did not come in to step on this planet in order to be the best network engineers in the world. That's not our job. Our job is to become the best OTA in the world." Therefore, a lot of this stuff needs to be already available both in terms of technology, but then also in terms of the expertise that's inherent in the patents. The whole stateful stateless patent, for example, or set of things that you need to do around that, should be part of the platform.

Eric: I like that we didn't step on the planet to be the best in the sense that that person is representing that they have a day job. Let's not go reinvent things that others are already solving. We also have to be careful of where we go seek our answers from. Our perspective, or my perspective, is that there are certain companies or groups out there solving this. We happen to be one of them. There are places you're going to go to who don't have that view because they're the status quo.

If you're looking for a new answer – you should have certain expectations and demand a lot. Demonstrate that this value's there. Guide me, partner with me because that's another fun part of just bringing it back to the top of the conversation. Our very first question is “What's so exciting about technology?” It’s that we're doing it together. In this ecosystem, there's such a democratization that there is a sense that the customers, the vendors, they all learn together. It's not a repeated 20-year-old version. It's something that's getting changed in a meaningful way.

My point is that that partnership, that is what's exciting as well in this technology landscape. That team that's looking for a better answer, they should find it and have high expectations, and in some ways make sure that they're picking the right partners to go on that journey with. It is supposed to be different. There are things that should be demonstrable and help them be the ones that are best at their OTA job. Let the toil go towards whatever you pick as the best choice of that stack.

Lisa, given your user group community hat for a moment – if we're wanting people to be – we're demanding that people are more demanding, if you like, or set higher expectations on what the providers provide so that a lot of these problems are solved, at least in principle, out of the box, how does that play into the nature of the people that are at the front line of innovation, if you like, the part of your user groups? Are they that demanding? Are they setting up these high levels of expectations, or are they being the best network engineers in the world rather than the best OTAs in the world?

Lisa-Marie: No, if you try to do that you will crash and burn spectacularly. We always have these sayings, “don't try to boil the ocean.” To your point, my user group is incredibly demanding. Maybe it's because we're here in the San Francisco Bay area. Maybe it's because there's so much amazing technology. Maybe it's because everybody wants sushi and champagne instead of beer and pizza. It's just a very demanding user group.

I think that this is where automation comes in, and it's very helpful. We can save people from themselves. Don't try to do everything. Let's take a lot of the human stuff out of this. Let's let you get back to your day job, and what your expertise is, and the business that you're trying to run. We will automate as much as we can. We'll just make this stuff work for you as much as we can.

What Eric just said about partnering is massively important. Choose the right partner. Make sure you get in bed with the right technology and the right people, I guess. Those type of decisions – and if you make those early on, you'll go down the right path instead of going down the wrong path. That's just an analogy for life. How you set these things up, how you architect your environment, same thing with your life. Make good decisions early on, and their full effect from that later will pay off big for you.

To play that back, I hear a lot of people say “the platform economy” for example. It's about building on top of the platform. This is a different take on it, which is to set very high expectations of the platform. I just want to be the best travel agent in the world. Sort me out. Fix these problems. Make it so that I can just focus on that, which is a very interesting place to be – but it's not an unrealistic one, if you don't actually know what the technology can do.

If I don't know what the technology can do, part of me says I should first learn what the technology can do. What this is actually saying is: I shouldn't have to learn that. I should just have to expect more from the providers.

Eric: I think they'll still be learning. It should be, in some ways, visible. It shouldn't be everything has to go to first principles. It should be: ‘this is what we're trying to achieve.’ You're trying to build that travel platform or build that travel experience. The platform can service that travel because the main thing – let's just play with this example, is that I need to have real-time results more quickly. In a real-time system, there's going to be a data pipeline. That data pipeline is going to ingest from thousands of signals. Those thousands of signals need to ensure that any node loss, or any failure, doesn't cause a brown out.

What I mean to say is: we can walk back and say our goal is to build a real-time travel platform. That real-time travel platform interconnects. It has to be resilient. It has to be automated in its recovery. It has to demonstrate faster results, and it has to – all I mean to say is: it will be grounded. I'm using your example because it helps to go all the way through. The thing is we don't have to think about it as "Oh, we're going to go learn every single piece of this stack in order to answer one piece of the question." That's the expectation that I'm trying to say can be guided.

Lisa-Marie: Exactly, you can learn what's possible as a solution without learning how to code. You don't have to get that granular. I'm not saying your Fortran background won't come in handy for you, Jon.

Eric: You went there.

Lisa-Marie: I went there. You don't have to be an expert in all the things. You do have to be focused on solutions. The big question is: focus on the platform and make the right decisions around the big questions.

My very first job interview was actually with Hewlett Packard. They said, "What do you think of COBOL?" I said, "It's a dinosaur. It's never going to last. No one needs that." They said, "That's great. We're a COBOL shop. We program COBOL." I was like, "Oh, bye." It was a very short interview. Then 30 years later, people still rank on it.

Overall, then, where we are is that there's things that organizations need to do, they need to understand. If you were to summarize the things that this particular travel agent needed to know in-house versus the stuff that they should be expecting other people to just provide you. They have technical architects. Even if they're not doing the network engineering, should they have the network engineers? At what level should they be in-housing versus outsourcing from a skills perspective, would you say?

Eric: I would say the parts that are closer to the business experience, they need in-house. If their travel agent is running in multiple locations, multiple sites, they'll have a technical architect. They'll have someone who's doing application architecture. They'll have someone who does the IT or platform architecture. Whether they get to specialize is probably more a question of the size of the company. Sometimes, smaller companies get to wear multiple hats.

[In] this industry and this space, there is still a heavy emphasis on the architect having that deeper education. Then there will be teams that do the operations that are incredibly critical to all this. The part that they may not choose to – or the part that let's separate out what we're not saying, is that they won't have someone who's only focused on just one resource doing one networking skill set or one storage skill set.

In some ways, from our perspective, this is about making Kubernetes the centralized platform that can run anything. Kubernetes becomes the expertise that we standardize on and allows you to run all these workloads regardless of where.

Lisa, does that fit with the people you're speaking to?

Lisa-Marie: Yeah, I think so because it's how reality will force that. Especially if you're a smaller – you're a small travel agency. How on earth are you going to have expertise in all of those areas? You just can't. I think that reality is forcing you to understand how to make these decisions, and how to be smarter with the resources that you have.

I guess the flip side of the thing is that for larger enterprises that have all of these skills, which bits of it should they be letting go? They have teams and teams of enterprise and technical architects.

Eric: I think they'll have teams and teams, and then they'll also still have additional things that we haven't talked about. I think you made one comment that hearken to this is things like compliance. I was out visiting enterprise architects around your area. Their perspective is we have ones that only focus on different public clouds. We have ones that focus on the compliance question. Their world is incredibly complicated for other reasons.

There's not much that they will give up or give away, but it starts to become [a question of] “How do we make this a repeatable – or how do we make this the bet that makes us competitive with the other big company down the street?” Their pressures become different. I don't know how to solve making their org structure simpler. In some ways, that's beyond my visibility.

Lisa-Marie: Now you're touching on our other favorite topic to talk about these days, which is multi-cloud. We've been talking about this a lot. We feel like Kubernetes is finally making things like DevOps, and things like multi-cloud a reality. The technology is catching up to be able to solve these problems for companies and figure out what's the best way to give you a solution. Where do you want to run those workloads? How are you going to secure and protect that data? Multi-cloud is one of those solutions. You should probably evolve your Voices of DevOps to Voices of Multi-cloud for the next wave of these trends.

Or Voices in Cloud Native because that's your user group.

Lisa-Marie: Exactly.

It's interesting. Some of these things are causes and some of these things are symptoms. My belief on multi-cloud is that it's something that is now possible. It's something that if you go back to Yourdon and Constantine's paper on structure design in 1975, which was all about modularity and systems. Then distributed systems happened and everything broke because you just didn't have the network bandwidth to run between systems and then between clouds.

What you've got with multi-cloud is now the ability to build systems how you wanted to 40 years ago. The reason I say that is because actually it gives us hooks into how we can speak to enterprise players. We don't say, "You've got to throw it all away and start again." We say, "You know those things you learned back at college? Now, we can get on with it, and we can actually deliver on those things." It's really quite a low friction and quite attractive approach.

Eric: Yeah, I think that's a great example. One thing that's also happening now, if I had to forecast, is that going forward, people are going to start running legacy workloads in Kubernetes. I don't have to re-architect, and lift, and re-platform my application. I can bring it wholesale. That's not necessarily true at this moment, but I think in a short amount of time that will be true. That will be yet another sea change.

It was the goal of web services, and it was the goal of SOA, and it was the goal of component-based development. It goes all the way back as well.

Eric: It does.

As someone that was involved in screen scraping projects in order to get data from one place to another, I whole-heartedly agree. We've got onto where things are going, which is probably a good point to wrap up and think about what we've discussed. We've discussed the issues around standardization, particularly at the lower levels, as you say, the toil areas, just the painful stuff. Let's automate the pain, so we can focus on the great gain, which has to be where things want to be. We've looked at state from stateless as a manifestation of the challenges that people face. We've looked at the things that smaller organizations can do, that bigger organizations can do.

We've started to talk about what things are happening in the future, which does come down to this increased tendency towards models that are more usable across the board. I'm trying to avoid using the word standardization. Standards are horrible – I used to be an X400 trainer. That didn't go so well. No one's using X400 these days. We don't want these big standards, as you point out, Eric. We want low pressure, low threshold platforms that allow people to do what they want to do without having to think about the horrid stuff. So Lisa, maybe [I’ll] put this to you then. If you were to leave people with, "If that's the way the world's going, here's what I would do about it," thoughts, what would be your top one, two, three suggestions in terms of getting organized for that?

Lisa-Marie: I think there's still some of the hard stuff, as you call it, that you do have to think about. Security is a big one. If I run a Meetup called Security in Kubernetes, the room is packed, completely packed. The networking stuff is hugely important. That's problems that we're still trying to solve.

You see awesome technologies like Istio coming out. You see a lot of CICD stuff coming out too, just to try to automate and make all of this stuff a lot easier. I think you do have to still focus on some of these areas and make the right bets going in. That partnership is huge, finding the right partners, finding who's going to help you on this journey, and help bring you there.

The platform that you choose is also going to be pretty important. I think Kubernetes makes a lot of things possible. We can all agree on that, I believe. You're seeing everybody get in line there, all of the big companies. Now we're just solving the problems around the edges of that.

Eric?

Eric: I think in a one-two-three, the one would be: find that library or that rebel team. I'll contradict a third time. Find that rebel team and give them the tools to go experiment. Part two is: think about it from a platform – or platform's my version, but a business need to drive change. Three would be in some ways find the right partners, wherever they [may] be. Let's not go relearn the painful toil parts. Let's go solve the real problem. Obviously, we have a perspective. Whatever that is for your industry, there is a change. That change is going to be impacting the way all applications run. Have that library team. Have a bigger vision. Then find friends to go work on that.

Lisa-Marie: Your three took my one.

I think to your point, Lisa, that there's stuff happening. You say there's stuff happening around the edges of Kubernetes. I think this is still a work in progress. I don't think anyone would say we're done in terms of the technology stack around that. Your very existence at Portworx is an example of that. There's a general consensus that this is the right way to do things. That's certainly something to hook onto.

Lisa-Marie: That's what the community here has decided. That's what the evidence that I'm seeing is. You know me. I'm going to follow that new trend, but that is absolutely where we are right now.

Cool, well we look forward to – I'm going to have such a cheesy wrap up after you said that. We look forward to seeing where that's going to go. I need to throw in some words about journeys, and destinations, and how wonderful it's going to be. It just remains for me to say, thank you so much, Lisa-Marie, and thank you so much, Eric, for being such good sports on this podcast. Thank you for all the advice and expertise that you've brought.

Lisa-Marie: Thank you, Jon. Thank you for having us, a lot of fun.

Eric: Thank you.