Cloud Infrastructure Leadership: What Changes When You Lead the Platform

Alexis:

Welcome to Le Podcast on Emerging Leadership. I'm your host, Alexis Monville. In this episode, we are excited to welcome Michael Galloway, a visionary leader in the tech industry with over two decades of experience. Currently shaping the future of cloud infrastructure at HashiCorp, Michael brings a wealth of knowledge from his dynamic roles at companies like Yahoo and Netflix. Today, he shares his journey, insights on platform engineering and the evolving landscape of technology leadership. Welcome to the podcast on Emerging Leadership. Michael, how do you typically introduce yourself to someone you just met?

Michael:

Yes. Thank you for inviting me, Alexis. The way I typically introduce myself is — I live in California, I've been working in the tech industry for about 20 years, father of two rambunctious girls and husband to a wife of almost 20 years now.

Alexis:

Wow, wow, wow. I would love to unpack all those things, but maybe we'll have time for some of it. Let's look at your journey in the tech industry — a fascinating journey. I've heard about your experiences both at Netflix and now at HashiCorp. Could you give us a snapshot of your trajectory and what drew you to the field of cloud infrastructure?

Michael:

Sure. Like I mentioned, I've been in the industry for more than 20 years. I was actually part of the early-2000s crew at Yahoo, just before the Google IPO. So that was an interesting experience to start off my career. Everything was possible, and some of the most brilliant minds I had the opportunity to work with many years later in my career started there. In fact, my current boss at HashiCorp was also part of that crew back at Yahoo. The Valley is ultimately very small.

From Yahoo I went through a number of different ranges of companies. I did a startup in the enterprise software space, which I was fortunate to sell — I would say it's more of an acqui-hire, but it was a great experience to go through what is startup life like in Silicon Valley. Eventually I landed at Netflix around 2016 and moved into the platform engineering organization. From there I led a bunch of teams in Delivery Engineering. The most famous part of Netflix that people may know of is the Spinnaker product that was developed for the most part between Netflix and Google. That's what we evolved and worked on. After that, that was really where I fell in love with platform engineering as a concept. The whole concept of full-cycle development and DevOps as we were pioneering it at Netflix was just fascinating, and working with some of the greatest minds I've had the opportunity to work with in that space.

I eventually moved to leading platform organizations at mid-tier companies, and now I'm over at HashiCorp running the infrastructure part of the organization personally. You asked about infrastructure — infrastructure specifically is a fascinating and evolving space. I actually have experience going in front of David Filo, one of the founders of Yahoo, and making physical hardware requests. I remember standing in line — a little anecdote there — we all queued up at these hardware request committee meetings, and David Filo was one of several members. I was right behind this gentleman. I had just started my job, maybe I was a month, two months in. The person in front of me was from Yahoo Photos, and he goes up to David Filo and he's making requests for several multi-million-dollar filer machines that we needed for the Yahoo Photos footprint. They discussed and OK, we will ultimately approve. Then my number's called, I get up and I said, I'm looking for $300 to buy a hard drive for one of our machines. And Filo had this look on his face of like, yeah, maybe we can do some efficiency improvements for this meeting — might not be the best use of everybody's time. I really appreciated that he saw it that way. So I think a lot of us have experience with the actual tin, but with the introduction of virtualization that came out many years later, we unlocked all kinds of capabilities like immutable deployment patterns, and real ephemeral infrastructure started to become a thing. What we're seeing is the outcome of those innovations and this idea that you can allocate virtual global infrastructure in minutes. But I truly think that that's actually just the beginning of where we're headed as an industry. So it's an exciting space to be in.

Alexis:

Whoa, whoa. That's very interesting because with the introduction of virtualization, basically a lot of people thought, oh yeah, you don't need to care really about cloud infrastructure anymore — anyway, everything will be fine with infrastructure as code, and let's do everything. But that's not really what happened. Even if I don't remember — DevOps, it's what, 2009? Something like that. We are still not there yet completely. In your talk at Plato Elevate you mentioned that cloud infra was not about hiding complexities, but setting the right defaults. I would like you to discuss that a little bit more, because that will maybe tell us what is coming, what the future looks like.

Michael:

Yeah, this is a very fascinating conversation. It's something that we can quickly get into modern applications and lose a sense of principles. So I like to come at this more from a principles-first approach than the common conversation that I hear in many platform organizations or many companies, which is, how do we present a Heroku environment? I think that's missing some grounding. You're talking about how to use it, as opposed to the philosophies of behavior that you want to encourage or support in an organization. Like everything else in software development, the answer is nuanced.

Let me give you an early story that really grounded my thinking on this. It goes back to my Yahoo days. I was a software engineer there and I worked on the Konfabulator product — a desktop widgets product that worked on both Mac and Windows. Actually, the modern Apple widgets experience on iPhones, as well as Netflix's video capabilities on TV, and all the modern TV widgets, are actually born from some of the same humans that worked on Konfabulator. So all things are connected. I was working on this and I was around much smarter minds than mine. One of the lead engineers in the group emphasized to me: don't just use the interfaces to these libraries that are available to us from the TVs or from the OS systems we're trying to operate on. Don't just use the interfaces — you need to understand what they do underneath. You need to understand those in order for you to be able to solve the real problems, the hard problems.

And he was right. How often we end up grabbing a library and just using it without thought of how it's actually performing these actions. We've seen this in software development all the time, where you have higher and higher level frameworks, and the understanding of the magic underneath is ultimately limited to the few that actually care to introspect. Some of those frameworks actively try to encapsulate and block the ability for you to really understand what's under the covers. Why does that matter? Because if it fails to do the thing I need it to do, if my application calls into an interface and for whatever reason that interface has an unexpected side effect, I now have no ability other than to abandon that interface to solve that problem. That becomes really a limiting factor.

If you take it from that perspective and you view software platforms, infrastructure platforms or platform engineering platforms — they're all the same concept: encapsulation, abstraction, the same software principles. You start to get to the point where you realize, where do you want to put the responsibility for resolving and solving problems? In a true DevOps world, you ideally want to enable application teams to ultimately have the ability to understand and operate their products in production. If you don't enable them to be able to see below the details for how something is being done, they have no ability to perform that task. They have to rely on a central team to do it.

So when I think about the right experience, what I look at is not about hiding the complexity per se. I think you can follow abstraction or present an interface façade if you want to simplify the zero-to-one problem — that's most of the time what they're talking about. I just want to get my application out, I just want to get a database. That's a zero-to-one problem. Provide a simple façade. That's where the abstraction actually can have value. But it should be an abstraction that you can drill further down if you want to. You can see what actually was done — how does this machine perform the actual instantiation of that database? What is the instance size, if it was, say, Amazon, of that database that was set up? I should be able to introspect these things because those can lead to me understanding why a failure occurred in my production system or how better to architect.

A good example of this is a situation we just recently encountered in my current universe at HashiCorp, where one of our products has a stateful — it wants to perform in a very stateful way. Stateful is a particularly tricky monster from an infrastructure standpoint. We very much on the infrastructure side want to see the world as cattle, not pets — that's a common euphemism. The idea that I can truly lose or blow away my infrastructure if I needed to, and that the resiliency is supported both at the application tier as well as other parts of the infrastructure to support the idea that any virtual thing can fail. The truth is, virtual things fail because physical things fail. A stateful application doesn't like to operate that way — it likes to believe there is permanence with the thing it's in. This is a really tricky problem with infrastructure systems to date. If we have a full abstraction of what is actually happening on the infrastructure tier, especially when we need to version the infrastructure underneath the covers, it can be a real problem for the application team because they don't understand why systems are periodically being disconnected or broken. As a result, they have to offload all of the operation problems to the central infrastructure team. That is the anti-pattern we all want to avoid — the whole point of DevOps was to move out of a central team operating applications in production as much as possible. So that was a long-winded answer. The short nugget here I would say is: predictability is more valuable than velocity.

Alexis:

Mm. Yeah. I guess that summary helps really to understand the whole thing. Could you tell us about a particular challenge you faced working on that realm of cloud, of platform at HashiCorp, and how you approached it?

Michael:

Yeah, I'll give you a different challenge — life's full of those. When I joined HashiCorp — December of 2022, so almost at my one-year anniversary — about a month and a half in, sometime in January, all these alarms started going off. It was not my fault — I had just started. That's OK. I don't mind if it is. But alarms are going off, all these 3 a.m. things blown up.

The issue was: a big portion of our system relies on a workflow engine that a lot of our use cases require to be operating effectively. The engine's Cadence — pioneered by Uber. Temporal is maybe a more well-known modern name, the next iteration of that workflow engine. Anyway, this thing started to blow up, and the reason was that it was backed by a single, very hard, very large database instance. That database instance was struggling to keep up with an unanticipated load. This was not necessarily a new issue — Cadence is a perfectly fine workflow engine, but the design was just not well-designed to be very scalable. As a result over the last several years, people had kind of wanted to avoid this system because it was known to be problematic and it had burned people out trying to support it. But it had finally tipped over — by tipped over, I meant it actually stopped keeping up with all of the workflows coming in. So it started building a history list — something on the order of maybe a million runs behind, and continuing to fall behind. When you see that, it's a downward spiral.

We brought in AWS people and we performed a quick crew to set up basically like a war room situation, to try to triage and stop the internal bleeding. What's the first thing you do? OK, well, if we can't horizontally scale because we hadn't sharded this system, let's scale up. Whenever I hear scale up, all of us — especially in the infrastructure space — kind of cringe, because there is a finite limit to scaling up, and scaling up doesn't actually solve the underlying problem. Ultimately it just delays the problem. So we did — our first focus was stop the bleeding. We scaled up. It helped. Still some things were not quite as stable as we wanted.

This is where the more interesting part of the story comes in. All these kinds of technical problems — in my whole 20-year experience, I've very rarely been on what I would consider a Mars-landing kind of problem, where you're maybe doing something fairly novel. Most problems are not insurmountable technical problems where there just is no answer. Generally, I've found that 99% of problems I've had to deal with are more about organizational problems — even leadership problems, in the sense of how do you think about approaching this kind of crisis? What are the right things to do when a crisis like this happens?

The steps we took. The very first thing is recognize that upper leadership, partners, customers who are relying on this thing all want somebody to raise their hand and say, I'll take ownership of this problem. That's the very first thing everybody needs — they need to hear you. And so we did. I basically said, OK, we recognize this as a problem. I'm not going to make up stories about this — it's a problem and it needs to be resolved, so we're going to take ownership of it. What we did was form a permanent team around this. That sent a very clear signal: we're going to own this problem, we're going to move it to a place where you can trust it. That was actually a really important thing — not just for the ownership aspect, but there was real lack of trust in building these workflows by teams because of the instability history. As a result, teams started to look for alternative approaches, and that would have led to a much more complicated universe to manage. So it was very important that they knew somebody was going to own solving it.

Once we did that, we defined some specific outcomes towards stability and scalability that we needed to be able to achieve. It needs to be horizontally scalable, not vertically. That was one of the most important things we emphasized — that the thing we did today to band-aid this is not a solution, it's a band-aid. What we need is not to try to put all our cargo on one ship — we need multiple ships. Once some of the fundamentals — these are not complicated concepts, but they are complicated to execute on, because having multiple ships means a whole lot of additional complexity and logistics up front for figuring out what goes on those ships. Establishing this is our success criteria, this is our strategy, was critical to get out early. What are the outcomes, not the physical deliverables.

The next thing we had to do: deliver short-term wins. By that I mean, what anybody ever cared about was stability in the short term, as well as enabling products to launch. So the products that were afraid to right on this — we immediately engaged them, prioritized making sure that they were stable, that they had the resources within the system to be reliable, and we enabled those product launches. Then we pumped out every week what the reliability status was, were there any issues, and any updates or communication on progress towards those outcomes. This was critical. Those two things were vital for us to establish credibility and for people to actually feel like the wind had changed and that this ship was actually going to turn. That built confidence and trust, and gave us momentum.

As we continued to execute, this team has completely revamped the architecture. They've migrated a bunch of the critical systems to having better resource isolation, which are fundamental things in an infrastructure universe — to be able to isolate workloads and manage resource consumption by each. We didn't have some of these fundamental abilities before. Now we're in a state where we've moved away from RDS and we're bringing in a scalable backend — a Cassandra backend — which will allow us to horizontally scale. To the point where a leader about a week ago said to me: not only do I no longer worry about Cadence, I've basically entirely forgotten that it was ever a problem. Which is great, except I said, just make sure that we don't think we can remove people from this team right now. I'm glad you are confident.

Alexis:

Yeah, exactly. I believe that's very interesting, what you offer as a solution. If I put aside the technical solution, we could apply that to a lot of different problems that we have. Having a team that is able to say, OK, we are owners of that thing, and now we own that problem and we will solve it. Being really clear about what are the outcomes, where we are today, how we measure ourselves compared to those outcomes — that's very, very critical. And knowing that you will not win the trust of people by announcing a 24-month plan. You will win the trust of people because you are delivering something now. Getting into that mindset is critical. So I love what you're saying about all that. Have I missed anything in what you propose?

Michael:

No, you summarized it exceptionally well. I will say generally — I fully agree with you — this is not a unique situation. This is a pattern and a strategy for approaching what comes up fairly often. In every job I've taken, there is always a crisis. I'm going to misquote the person, but the famous saying is, never let a good crisis go to waste. These are hugely valuable opportunities to actually have a tangible impact on the business. Where others may be afraid to tread, these are the opportunities that really enable you to shine as a leader.

Alexis:

I really like that. Are there other pivotal moments in your career when you really learned something significant about change and leadership?

Michael:

Oh my gosh, yes. First, if anything I'm saying here sounds at all polished, please understand it comes from the many battle scars I have over my history of making mistakes and reading and learning from the wisdom of others, and then having the opportunity again to apply them.

At Netflix, in Delivery Engineering, we embarked on this initiative called Managed Delivery. It was a very ambitious project that is still very near and dear to my heart. Fundamentally, delivery in Spinnaker is done by articulating pipelines. What we found was that every team was defining their own pipelines. In Spinnaker, we had about 16,000 pipelines across about 4,000 applications, about 400 teams was about the size we were at. Platform Engineering has some challenges. One specific challenge was: as we were still very VM-based, when we would release new base OS AMIs that might include security improvements, patches, other things — we had an adoption rate where it took on the order of months to years for certain patches or updates to be rolled out. That was really problematic for us. Sure, if you did a security sev-one incident, they could broadcast across the company and people might take action, but that's a pretty disruptive thing to do. What you want is a design that helps enable the bottom tier to be as evergreen as possible.

But we had a problem. All the teams owned their own pipelines. Spinnaker had no intelligence about those pipelines — it just knew, run this step, if that step gives me a green light, go to this next step, and maybe some conditional logic. But what do those steps represent? What is the confidence after step two as to whether this new update is safe to roll out? All of that was opaque to the engineering system. So what we needed was a way that we could evolve our infrastructure and we could evolve our AMIs, evolve our strategies under the covers, and do so without having to get all the teams involved.

Another motivation was we thought it would make it easier for teams to also not need to articulate or come up with strategies in their pipelines for safe delivery. Teams would deliver applications to multiple regions. What's the right sequence of steps that would enable you to catch a problem and roll back the change if a failure happened in, say, the second region you rolled out to? First region successful, second region fails, most of the time pipelines would just die, and now you have this very confusing universe where you have different versions of your stuff running and problems can surface. So we thought, hey, let's take that problem away from teams too. Let's create a declarative form of delivery that enables people to define the criteria for success that would enable promotion from one lower environment to higher environments. That was essentially the goal of managed delivery — move them towards the description of what needed to happen as opposed to defining how it should happen.

Very ambitious on the size I was mentioning, especially because Netflix culture very much operated with a freedom-and-responsibility concept, which meant that teams were never really obligated to use a service or a new system. So imagine operating in an environment where you have lots of very smart and talented people from all around the world that are working on their problems, their projects, and you ask them to engage on something that they honestly would prefer to not really have to think about. The water company doesn't reach out to me to talk about repiping pipes to my house — I have no interest in that conversation. If you need to do it, sure, go ahead. It's the same way in delivery engineering and reaching out to these teams — I don't, my software always continues to deliver, it's fine, why do I need to care about this? This is a very common problem in platform engineering, but also for library producers, API producers, anybody producing something that others are consuming — you almost always have more interest in making that happen than they do, especially when the value proposition may be more on one side than the other.

That was the key mistake I made. At that time, we very much wanted to take the approach: if we built something really valuable and very interesting for folks, they would adopt it. There was merit to that. We spent a lot of time thinking about the early adopters. We got some early successes, we got some people to enjoy it. But then we hit that classic crossing-the-chasm problem where we couldn't get past the early innovators to the early adopters. We struggled on that. What was it? Was it some combination of features, capabilities? What I miscalculated personally was the actual value to the business was the platform engineering side of the equation — platform engineering needed to see this adopted across the fleet for there to be real value. Given that, the strategy may not necessarily be one of slow adoption — it may be more important to take a little bit stronger of an approach.

John Kotter talks about this. He has an article in HBR called Leading Change, and a book called Why Transformations Fail. I read that book during that time and I failed in probably at least the top three even after I read it. I learned how big the gap is between knowledge and wisdom — and that gap being how wide experience needs that gap. Long story short, managed delivery's value proposition very much is alive, it is moving forward. But that was an experience where I realized: because our adoption was very slow, we did not take an aggressive enough approach. By aggressive I mean, we didn't establish a sense of urgency. Teams were necessarily complacent in the adoption — and it's not their fault, that's the way the culture was designed to operate. As a result, getting that change to actually happen was much harder. They are doing amazing stuff now. In fact, years later I landed at HashiCorp. My peer came from Samsung SmartThings. He recognized me and said, oh, managed delivery — apparently larger footprint than Netflix, much higher traffic than Netflix, all the IoT devices call into theirs. They overnight basically — maybe not quite overnight — fully adopted it and saw some of the benefits as a result. So it was comforting to hear. But yes, it was a good experience in the challenges of change.

Alexis:

Yeah, it's very interesting that we're going back to that idea of a team owning a problem and trying to solve it. Unfortunately it's really a problem for the business, but it's not necessarily a problem for the other teams that are consuming something from that team. So how do you create a sense of urgency for the other team when they are not even aware that it's really a problem for the business, and you cannot count on them to investigate that part?

Michael:

Well, I have a story about creating the urgency, because that's one of the things I learned. There are actually two pieces to that, and I applied them at the next job after I left Netflix. It was a mid-tier company. The entire fleet was on Heroku. We were hitting problems with that platform — going back to the ability to introspect and understand how things work, Heroku was too abstract, too high-level for us to operate it effectively for the things we wanted to do. It got us the zero-to-one, but that hard abstraction made it impossible for us to get past that one. Long story short, we needed to migrate. The business decided we needed to migrate off. But even with that, like all things that happen in a business, they are good goals, they're set, like the 24-month goal — oh yes, we should be — but how important is that? How urgent is that?

From my experience with managed delivery, this is what I learned. Two things. One, you need a sense of urgency. So how do we create that urgency? You need to get a date set, and that date needs to have consequences. We talked specifically about setting a nine-month target from the point that I had started that job. The reason for nine months: nine months feels close enough that it will happen, but far enough away that virtually no engineering team says no. I mean this very much affectionately — we all believe that the world is possible in nine months, not three months, but nine months, yes, for sure we'll have time. So we got alignment that in nine months we would hit this target. We made sure that the other aspect of this was: we were going to shut off Heroku, actually disable and tear up the contract. That was the cliff date.

There's a lot to unpack on the importance of setting dates, but the other bit that was vital was we needed to get executive alignment with that — that needed to be something that the executives would back. By that I mean, the term leadership or executives is nebulous; just someone in a position of authority at the right level that can basically say, once you get to three months away from landing this, this is a date that will not move. We were able to get that. Those two things ensured that this very ambitious project — we moved the entire fleet out and over to Azure with zero service disruption. It was a remarkable feat. The team did an amazing job, but I truly believe having both of those factors enabled us to do that Herculean task. The last three months were brutal, stressful — we bought lots of DoorDash for people and supported them as they were executing on all of this stuff. But once we landed it, the entire crew could look back and said this was an amazing thing we were able to accomplish, and there was real pride with being able to do it. Very good lessons learned.

Alexis:

I love it. That's really interesting to unpack the learnings about that. You need a date, and when people hear that, they can hear, yeah, that's a date, but maybe we can be late — and no, that's really a cliff, there's nothing behind. You need that support, that alignment. So nobody will dare to change the date. There's no option around that, and that's absolutely clear for everybody. So now they can make plans, they have the time. Nine months is a good one — we were thinking, yeah, it's feasible. I realized when you were saying it that if you would have said three months, I would have said, oh no, I would have started to think why it was not possible. But nine months I was comfortable to say, yeah, OK. And I know nothing about the challenge, the reality of the challenge. Funny. So yeah, you can start making plans.

Michael:

That's right.

Alexis:

What would be your advice to emerging leaders or who want to make a meaningful impact?

Michael:

The first thing I would say is you need to understand your stakeholders. I have learned the enormous value in developing those relationships and deeply understanding who your customers are, who your peers are, and what leadership is expecting of your organization. A lot of people, I think, focus — especially emerging leaders — they focus on their team and down. I have a lot of experience in doing that and failing beautifully because I misunderstood what was expected, what was not spoken, but expected by my peers and by upper leadership. You really need to understand not just the surface statements of, here's our goals, here's our outcomes. What you want to ask is: what keeps you up at night? You want to ask where things have failed in the past. You want to hear the reactions more than you want to hear the thoughtful process of desires. It's those emotional reactions, those small perceptions of your team and of what is expected of your organization, that actually will influence whether or not you are successful — those are the micro-perceptions that determine whether they're going to think of your team as a team to rely upon for those next strategic steps. So understand them very well, and that takes a lot of time. There are great books on this. This is where it truly is around the psychological approach far more than it is the technical execution or delivery.

The next one is: you need to deliver wins within the first 90 days of starting a new job. There is a great book, The First 90 Days. I think it's a fantastic book on this topic. I've applied it successfully a few times now. It very much is correct. Get that win. You have to have credibility when you go into a room. You have to be able to be believed when you say we should do X or Y. Otherwise, you're going to stay in the tactical level always because you haven't established that you can actually solve bigger problems. The key thing with getting that credibility in the first 90 days is you don't need a big win — you just need something meaningful, something that addresses a concern. Peers of mine had mentioned this to me years before too: don't try to run after the biggest thing you can run after, especially when you first start. Start with something you can own and influence — something within your control. Don't do something that's going to require a bunch of other folks to be aligned, especially when you first start. Second, it's got to be something that matters to other people. It doesn't really matter what it is. It doesn't have to be a technical solution — it could be an organizational solution, an information solution, a communication solution. It needs to be something that actually addresses a fear or concern. A great example of this is just starting a monthly newsletter for your organization and ensuring the rest of the business understands even what your team does. That's surprisingly a big problem in many places — just the awareness factor — and doing that suddenly puts you on the radar of a lot of people. That's not a technical problem at all, but it is a problem and it can establish you.

The third thing emerging leaders need to be taking a look at to have real meaningful impact: define the purpose for your team. By that I mean you need to bring your team into that. Defining a purpose is one of the most fundamentally powerful actions that I have ever learned to take with my team. Purpose is different from mission and vision. A purpose lives the lifetime of that team or that group that you are managing. A purpose — sometimes it's referred to as a North Star. I don't think it's quite that. A purpose establishes a philosophy that everything stems from. One of my favorite examples — gosh, the name is going to slip out of my mind, but he was a French designer that helped establish the purpose for Disneyland. That purpose was to create happiness in the visitors. Now, if you think about that, that sounds very simple, but it's a very powerful fulcrum. At that point, when you have that, everything from how you name the parking lots — you name them after Mickey and Goofy, not A and B and C — the design of the trash cans, the uniforms, the decision to have very pleasing flower beds that are millions and millions of dollars of investment for each. Why do you do that? Because each of these pieces maybe makes somebody smile a little bit more. Establishing a purpose for your organization enables you to prioritize. It gives your teams freedom to execute and to think more broadly, and it enables you to align with what your next strategic steps need to be. It really is the guiding principle. I've written articles on this, but there are much better, smarter minds than mine that have spoken on this.

Alexis:

Ah, I will link to that and we will let people decide. So what's next for you? Any exciting projects or initiatives you want to share?

Michael:

Yeah, so with HashiCorp, one of the exciting things we have coming up next from the platform engineering organization is really trying to crack this self-service nut. HashiCorp is an organization that builds tools for infrastructure management — we build tools for platform engineering. How do we leverage all of the tools that we have and the patterns and behaviors we want to encourage to enable self-service within our organization? A team being able to go from zero to one. I know this is a nut that a lot of people have cracked in the sense that they've created IDPs — internal developer platforms. But I think that's more of a how, and I want to get back to the principles. What are we caring about? Enabling the actual day-one problem of, give me a service, is not a hard problem to solve — it's been solved a lot. The day-two problem of, now I want to add a database to my service, that's a harder problem. That's one of the ones I'm excited to see get moved forward.

Alexis:

That's very cool. So let's talk again. Thank you very much, Michael, for joining. Have fun solving that.

Michael:

Thank you, Alexis.