PurePerformance - Preparing for a future microservices journey (with Wardley Maps) with Susanne Kaiser

Episode Date: August 5, 2019

Susanne Kaiser (@suksr) has transformed her company from monolith on-premise into a SaaS solution running on a microservice architecture: Successfully! Nowadays she consults companies that need to find their “core domain”, break up and re-fit their architectures and organizational structure in order to truly get the benefit of microservices.In this podcast you learn which questions you need to ask before starting a microservice project, how to find your true “core domain”, how to restructure not only your code but also organization and you get exposed to the concept of Wardley Maps which help you decide what to build vs what to outsource in order to deliver value to your end users the most efficient way.Links:Susannne on Twitter - https://twitter.com/suksrDevOne Conference Page - https://devexperience.ro/speakers/susanne-kaiser/Wardley Maps Microservices presentation - https://www.slideshare.net/SusanneKaiser3/preparing-for-a-future-microservices-journey-with-wardley-maps

It's time for Pure Performance! Get your stopwatches ready, it's time for Pure Performance with Andy Grabner and Brian Wilson. Hello everybody and welcome to another episode of Pure Performance. My name is Brian Wilson and as always with me is my co-host Andy Grabner. Hello Andy. Ooh, I'm here. How are you? Good, you know, I just flew back from vacation last night and boy are my arms tired.

Why? From flying? It's a bad joke. It's a bad joke it's a bad joke it is a bad joke exactly no i was at uh you know i was thinking from a performance point of view right so we went to universal studios in orlando and we went on this roller coaster called the rocket and two things i was thinking of of testing and performance on the rocket at one point you know it rains a lot in Florida in July or June. So I'm getting ahead of the summer already. It rains a lot in June. And they had shut the roller coaster down.

And when they started it back up, they ran about, I'd say, 12 to 15 test cars doing all the little different telemetries. And I guess they had all these different sensors everywhere collecting all the feedback. And all I kept on thinking was like, there's all these feedback loops loops and they're collecting the telemetry to see what's going on this is just like a really well monitored system uh but then the other cool thing they do is on this and i and i i implore anybody who likes roller coasters if you're ever down there go on the rocket uh you get to pick which music you want so you have like speakers right by your head. And the other thing I was thinking from a testing point of view is like almost every song they had, I think works really well with the rollercoaster because you go up flat up on

your back. Like you go up horizontal up the hill and then you crest over and go down this really big hill. And the first time I went on, I picked, I will survive by Gloria Gaynor because I was thinking I'm going to die. So I thought that was perfect because at first I was afraid i was petrified i'm like this is perfect and then the second one was some motley crew with like some fast heavy guitars i'm like this is

rocking yeah so i was thinking somebody probably had to go test the songs they're using to make sure that they fit with the roller coaster user acceptance right so anyway i just had to tie that in to be able to justify all the business expenses i did on my family vacation well it still it still doesn't explain why your arms hurt but maybe we get to this later because i flew you know like a bird anyway yeah yeah correct so i guess people i mean as much as they're interested in hearing about your vacation and being jealous that you were in universal studios uh today is actually so you had you had like little cars like little little components on your roller coaster it's like kind of like small little

microservices that work in perfect orchestration to give a perfect user experience right isn't that kind of what it is exactly and do you know what? I think we invited the perfect guests for the show today to actually talk about microservices, lessons learned, and a lot of other things. And I think it's really... Who would that be? Who would that be? I don't know. Let's see.

I think we already hear her giggling in the background. So without further ado, Susanne, do you want to introduce yourself? Thank you. Welcome, everyone. Thank you for having me. Yes, I'm Susanne, do you want to introduce yourself? Thank you. Welcome, everyone. Thank you for having me. Yes, I'm Susanne. I'm from Hamburg, Germany. And I also have a little story about a roller coaster at Universal Studios a long time ago.

And I was driving the roller coaster with a sunburn at my back and it was such a pain. So that's the reason why I really, really can remember this. But unfortunately, it was not such nice memories. Yeah, sunburn was everything. I do hope that you also have positive memories about the university. I also had positive memories, yes. All right. So, Susanne, I know you just said you are from Hamburg, Germany,

and I'm pretty sure you get a lot of jokes about Hamburg and hamburger. Well, I'm not even sure. Are there jokes about Hamburg and hamburgers or not? Not from Germans, to be honest. But yeah, usually from people from the US especially. You can say stupid Americans. That's okay. No, no, no. I'm not going to say that. I will. But yeah, sometimes like you are a hamburger.

And then yes, you are right. I am a hamburger. Like you can't eat me. Here's a joke for people familiar with the old McDonald's characters. And I'm just making this up now so i can't tell you if it's going to be good but uh preamble my jokes are really terrible so i don't way back in the old days mcdonald's had characters ronald mcdonald and mayor mccheese so my joke is what do you call a thief in hamburg the hamburglar because that was one of the

characters that was yeah awesome right stupid stupid Americans all right go on all right so Susanne we actually didn't meet in your hometown neither in my hometown but we actually met in Iasi a city on the eastern border or the eastern side of Romania we both spoke at a conference, Deaf Experience. And you spoke, I think your talk was titled Microservices Lessons Learned. I found it fascinating. So I actually reached out to you and said, hey, let's do a podcast because it's really interesting the way you explain how you approach microservices projects.

And there's a lot of cool lessons learned. And then just, I think, a week or two ago, as we got kind of closer to the recording, you said, well, there is maybe another presentation. And it's about worldly maps. And it's about, you know, again, microservice journeys. And I said, well, let's have a look at this. And I thought, wow, this is even cooler stuff. So I think there's a lot of

stuff we can talk about i i do want to get started though with a question to you and then we'll see where the conversation goes but i i see i see a lot of especially enterprise companies being very excited about breaking the monoliths moving to microservice architectures because they all feel the promise of microservices is so great of delivering faster with better quality, delivering value to the end users, just in a more modern way, a sustainable way to beat the competition. Now, I want to start though with asking you, is there any advice from your end before starting a project when people try to figure out, are microservices the right thing for us to do?

Is there any advice on key, let's say, things to look at to figure out, is it actually a good and smart idea either for the particular software project, the application, the service, or maybe for the organization to say, yes, we should go down the microservice lane, or no, it doesn't make sense for us? Yes, so usually there are some criteria that I would like to tell everyone when they try to consider going the path from monoliths to microservices. And the thing is, one of the criteria is, are you really benefiting from microservices after we have extracted those? And so to split your monoliths just for the sake of having smaller pieces, I guess it's not the

right angle or the right perspective to have. So at the very beginning, you should ask yourself, what am I expecting from having a microservices architecture style in terms of can I, for example, after I've extracted some services, can I deliver features faster? And do I have some service candidates that require a lot of changes, for example, that require a lot of new features to be delivered? Or another criteria could also be, after I've extracted a service, does it allow me to scale more efficiently than before?

Or another aspect could be, criteria could be, does it allow me to shift ownerships within my team so that the impact across the teams is smaller than before, that the teams can work independently from each other and can develop and deploy their services independently from each other and with minimal impact across the team so that in the end they can deploy their services and deliver new features faster to the customers. So at the end, the core question is, can I deliver features that matter to my customers faster with microservices? And sometimes people are are mostly like kind of like have a blind spot. They just want to cut it into pieces and just for the sake of, okay, microservices now, that's something that we have to do right now.

But if you are a small team and you always deploy your product, for example, on-premise as one artifact, because that's one requirement or that's one user need, then probably it makes not such a good sense or it's not that big of advantage that usually microservices will give you. So if you always, for example, have one big web archive that you have to deliver on services, then, well, why have you split it up beforehand just only to deal with all the infrastructure and operational complexities that come with microservices? Then you could have kept it, if you would have kept it in one piece

because you're always deploying it in one piece to your customers, then I would recommend that probably a monolith would be better. It depends on different aspects. So it's not only the deployment artifact that you deliver, but also does it allow to scale your organization? So if you're only two people working on one product, probably it's not that beneficial for you to go the microservices way. So there are different aspects that you might consider in but the core principle is does it allow you to deliver features fast so features that matter to your customers. That's what I would usually answer to that question yeah i i especially i think

i'm not sure if ever if i ever heard people name one of the benefits it just means which means shifting the ownership if you have large teams and then you have a big code block and you have you have a large team responsible for it i think breaking breaking it up to just free, quote unquote, free people from the ownership of something they shouldn't own, I think is an interesting aspect. But you're right. You should always ask yourself the question, does it really make sense? And what's the real benefit from microservice to your organization? Now, obviously, you're not just talking about this because you want to. You like to talk about this topic with them.

Sure you do, but you actually have a lot of experience on this too. If I look at your bio and if I remember some of the discussions we had, you were actually going yourself through one of these transformations, correct? Where you migrated from a monolith to a SaaS solution where you needed microservices. Can you kind of reflect back then from your own story on what drove you to breaking up the monolith and kind of what you did and how you got started? Yes. So, in fact, we were growing in every aspect. So, in the very beginning, we had a monolith in every aspect. So in the very beginning, we had a model in every aspect.

We had one team working on one collaboration product that was shipped as one archive or one artifact to the customers. And so everything was growing after a while. So the team was growing. We added more and more features to our product, and the source code got bigger and bigger. But after a while, we were confronted with some downsides of it. So for example, one thing was also the ownership that you were mentioning before, is that no one really felt responsible for something, so for a specific part of the

software. So that as a consequence was that, for example, when a bug arise, it took a little longer than it's supposed to take because no one felt really responsible for the specific bug or that discussions, meetings, decisions took longer than before. So our processes were slowing down and also because we were constantly adding new features, we were increasingly confusing our customers because sometimes you had buttons to upload documents, for example.

It's a collaboration app where you also can manage or share documents between your team members. And the customer themselves got a little confused after a while. So there was a kind of like desire to split things. One, from the organizational perspective, that we can create clear ownerships to the teams, but also from the usability and user experience perspective, that we split our product into separate collaboration apps,

and each of them is solving a specific use case. For example, sharing documents, so we have a document management or to communicate in real time, a kind of chat client, but also like task management between your team members and so on. So we're splitting on the one side the product itself and then also assigned to each collaboration app that we extracted. We were assigning those apps to specific teams so that we could establish clear ownerships to the teams.

And then as a consequence, so it was not a technical or technology-driven decision that we made. What it was, was driven by product and organizational circumstances that we then followed to also to transform our modelers into microservices so that we can have this clear ownership, this well-assigned responsibilities within the entire system, only not from organizational or product perspective, but also from the software architecture as well. So that was the motivation that we have.

So the motivation was to have well-defined teams, autonomous teams with well-defined responsibilities that can work on collaboration apps, on their collaboration apps independently with minimal impact across the teams and develop and deploy their collaboration apps and deliver the features independently. And to deliver then the features faster to the customer.

That was the motivation going from monoliths to microservices. That's pretty cool. I think I got the ownership question wrong earlier. I thought there were too many people that thought they are owning this and therefore there's too much fight over who is doing it. But in your case, you actually explained that the reality in your case was that nobody really felt responsible therefore it took too long to actually find the responsible person and uh we just understand worse in real life it happens also so if you have i don't know a specific set of tasks and uh you

have not clear ownerships like you have a lot lot of people that are assigned to a set of tasks. It could be the case of it bears the risk that no one really takes a task or is responsible to taking the responsibility. That's kind of like very human reaction to that one. And so if the responsibilities or the ownerships are clearly defined, I would say it makes it easier, not only from the maintenance or to understand what this, for example, this microservice is doing, not only from the understanding perspective, but also from, okay, this is my, I own the services. So I am responsible from, um, from concepting it, but also from, um, yeah,

developing and deploying and delivering it to the customer. Hey, uh, is there, um, is there a metric? I mean, I know we, we, we love metrics here. Uh, when we talk about performance, is there a metric that you were tracking that actually showed you that there's too much time wasted in pushing ownership and responsibility around? Meaning too much time wasted in discussions on who should take it? Is there a metric that you can track? Is there something tangible? Maybe, I don't know, the time it takes to finally assign a ticket to a team or is there

anything you were tracking and then a metric that you could see afterwards after the the migration being improved well that's a good question so we um not really um we're we're not tracking every uh single person because uh we trust each other but the thing is that example, the reaction times in terms of, like, not only assigning a ticket to yourself, but also the first reaction to the customer, like, that's something that I would say that decreased after we had clearly defined the ownerships, that the people now felt responsible. Okay, these are the tickets that are related to to our team and

we are taking care of it and immediately so that the customer gets responses earlier than before that's pretty cool um so susanna in your so i believe if i read the bio correctly and if i remember the correctly so you are you are a CTO of a company that migrated from monolith to a microservice architecture, also moving the business to a SaaS business, correct? Yeah, it's a SaaS solution. And it was originally a monolith and then transformed to microservices. But I would say that it has two challenges. One, the transformation from monolith to microservices,

but the other one is that the SaaS solution is not only available on cloud, but also on-premise. And this is something that i would highly recommend to reconsider the next time when when you start this journey like if you have to deploy your product on premises on on the customer's infrastructure it's really um slowing you down because it's not you're not only because you have to to find the how do you call it the least denominator is that correct correct word okay so because you have to to find the least denominator to to find out like uh what interest infrastructure you can support to

establish um uh automated uh delivery processes like your pipeline that you set up. And it's not only one challenge is that the infrastructure and operational complexity that come with microservice itself, but on addition, having a solution that runs in the cloud, but also on premises, that's a real challenge. And I would highly recommend to reconsider if either you would like to follow it because that's something where you make the most profit from, that's something that you're really reluctant to change it. That's one problem.

But if you're going microservices path, I would recommend to consider what kind of complexities you have to deliver your software. And if you can rely on cloud-native infrastructure, that is the best, from my perspective, the best infrastructure and works pretty well. But as soon as you still have to deliver it on-premises, because there you have to deploy it in one artifact and you still have to negotiate with the customers down times or something because they don't have the infrastructure that's usually available on your side. So it could be very challenging to go this path.

So the next time I would have more focus on that, okay, where do you have to deploy your services and to figure out if you could shift the strategy? Okay, we are now a cloud SaaS solution only. Yeah, I understand that if it's possible, but I think if your customers demand otherwise, like in our case, Dynatrace, we actually deploy both, right? We deploy SaaS and on-premise. And we see it, well, first of all, you're right. I mean, it's obviously a little more challenging to provide both deployment models, but we also see it as A, fulfilling a customer demand because we have a lot of enterprise customers that want, that needs to run our software on-premise.

And in our case, we also see it as a competitive advantage. But I definitely agree with you. It's more challenging, right? If you can really just go SaaS only, it's the easier route. Yeah. So if it's a user need which generates a competitive advantage, then it could be something that could belong to your core domain because that's something that differentiating you from your competitors. And then that's something that you have to strategically invest into.

That means that operations, DevOps, has to be something that you have to focus on as well. Because to automate all the delivery pipeline is then very crucial. And, for example, another client that I was working with, he has the same requirements to deliver their SaaS solution on top of Kubernetes clusters that are running on different cloud providers such as Microsoft Azure or Amazon EKS. And so they also have a microservices architecture,

but they are running on top of a Kubernetes cluster, so they are extracting away the cloud infrastructure beneath. So that's also possible. You still can run with microservices, but you have to invest more to automate the infrastructure, to automate the delivery pipeline. Yeah. So let me ask you, this is actually an interesting topic because we are currently developing

an open source project. It's called Captain to actually support exactly automated and continuous deployment and operations for Kubernetes environments, hybrid cloud environments, meaning wherever Kubernetes basically runs. Now, what we have learned, and I would be interested in your experience with your clients, while Kubernetes in theory is Kubernetes the same everywhere, in practical life, Kubernetes on one cloud vendor might not feel and taste the same everywhere, in practical life, Kubernetes on one cloud vendor might not feel and taste the same as Kubernetes on another cloud vendor or Kubernetes deployed on-premise.

And I'm not sure if you have seen this in your kind of quote-unquote hybrid cloud Kubernetes environments, that there are subtle differences. Some of these differences are not as subtle. Some of them are actually bigger. But have you found that challenge as well? While Kubernetes sells us, it's just the same thing everywhere. It's actually not, and you have to account for that.

Yes, definitely. So it's also like how they provision the worker and the masternodes, for example, and it master nodes, for example, and it's all about the configuration, how you set up the nodes themselves. So sometimes in one cloud infrastructure, we were running smoothly, and with the same setup on another cloud infrastructure, we were running out of resources. And the question is like, okay, it's still, even though they say it's abstracting infrastructure away, that's true. But it comes

with totally new primitives. And you can mess up with configuration. It could be totally, even though it's running on top of Kubernetes and taking care of orchestrating our containers, still has different impact on different cloud infrastructures. trying to make it visible what comes with microservices in terms of infrastructure and operational complexities. And also, like, for example, if you're small teams with little DevOps practices in place, how can you still handle these infrastructure complexities that come with microservices and still deliver user and business value in one option.

So I was mapping out different options going from, for example, let you say infrastructure complexities are handled by mostly open source software, for example, Netflix, OSS, or Prometheus, Grafana, and so on. But then going to container orchestration such as Kubernetes and from there to service mesh and then to serverless. So there was a kind of evolution of the value chain going through these different options. And when I was talking about Kubernetes, it's abstracting a lot of infrastructure components away like service discovery, load balancing, centralized configuration management, scaling,

recovery, and so on. But the other side is that it comes with new primitives. So it starts with that you have to configure pods, deployments, services, volumes, ingress, and then a lot more like stateful sets, secrets, config maps, front-off. So there are new primitives that come along and that you have to deal with. So while as a developer, for example, you don't have to deal with the infrastructure components that I've mentioned before, like self-discovery and so on. But now you have to deal with new primitives and configuring them that come with Kubernetes, for example.

And it makes it then. So there's kind of a trade-off between them. They get infrastructure components handled by the container orchestration, which is great, but it comes with new primitives that you have to configure now. And this has to be considered from the very beginning and what does it mean then to your team? And so, yeah, it could be different in every cloud infrastructure. Do you think this is the reason why we see, at least I think they're popular, if I talk with people, services like AWS offers Fargate, Google offers Cloud Run, and I'm pretty sure Azure, they also have their own version of,

you just give me your container and I basically run it for you. And you don't need to worry about anything underneath. Basically, providing a managed service on top of Kubernetes and everything else. So just really allowing developers to focus on what they should really do, which is just providing containers. And then they take care of all the complexity underneath. I guess that's the thing exactly that all the primitives that come with container orchestration is then becoming invisible to us developers and that we don't have to deal with anymore. And otherwise, I guess, it takes a lot of time to take care of these infrastructure components, which is shifting our focus away from building our core domain,

because our core domain, that's the one that gives us competitive advantage, that's differentiating us from our competitors. That's where we are generating or fulfilling user needs, which leads then to higher customer satisfaction. And if we have to deal with all these infrastructure complexities, it could be the risk that we are focusing not on the elements or on the features that matters to our customers, but to parts of our software,

which is invisible to our customers. And if you're a small team and with little DevOps practices in place and you have to meet sharp timelines, you might end up with compromise, something that you should not compromise, and it could be a product that is not fulfilling your user needs and leading to unsatisfied customers in the worst case.

So it's really important, it's very crucial that the infrastructure components are handled by someone else. And for example, but also, yeah, that's if you can, for example, if you can go this way, like if you still use the work of unit, the container as a work of unit, but if you go the next step, the next step is um that you then can also that the can use the function find a grain short-lived function um based on several technologies for example so because this one's been uh um gives you the opportunity that your infrastructure is fully managed by someone else. You're offloading the infrastructure components to someone else.

You're not taking care of them anymore. And instead, you only have your fine-grained functions that are triggered by a variety of events. And your code itself is then within the function that you implement, but also the building block that you're wiring together with the functions, for example, and DynamoDB. When I talk about, for example, AWS, it was AWS Lambda serverless technologies, then it allows you to focus on your core domain because you don't have to handle the infrastructure components anymore. But it also comes with constraints. So there's also the problem.

It feels like if you, I think Brian and I have made that reference in the past, but if we're extracting everything back to the core, you know, basically business value that it provides. So building a function and then, you know, interacting maybe with the database, and then we are only, somebody takes care of running it and we get charged by the invocation, which in the classical serverless Lambda model it is,

it feels like we are back to the mainframe days where we have never been a mainframe developer, but you write your functions and then it runs on somebody else's hardware that they manage, and then it just gets charged by the MIPS, by the millions of instructions per second. It feels like we're moving,

it feels at least, right? We're moving back into that model that has worked in the past, but now it just runs somewhere in the cloud and not on a big mainframe computer that you buy and that you basically rent and run in your own data center. Yeah, so it releases the time. It frees time that you can use now more on building the functionality,

the feature that matters to your customers, because you don't have to take care of the infrastructure components anymore. And also what it allows you that it's, you only have to pay for execution. So when the function gets idle, it shuts down and costs nothing. So, but there's also downsides. So it could also be, it shuts down and costs nothing. But there's also downsides to this. So it could also be, it's not always applicable to every case.

But if you have, for example, a constant high load, it could be even more expensive than running on a Kubernetes cluster, for example. But I guess you also have to consider the total cost of ownership like um um it's even though it could be more expensive on aws uh it's it's still have to you still have to configure or consider uh what uh cost uh could be caused by maintaining provisioning it when you don't go serverless i think this is also one of the, you mentioned it earlier, the term, your core domain, right?

This is the, I think, I like this a lot. And I looked through your slides, which by the way are excellent. So for, we'll put a link into the proceedings of the recording. The deck is called Preparing for a Future Microservices Journey with Wordly Maps.

And I think also in this deck, you talk a lot about focusing on the core domain and then figuring out what you can kind of outsource. And can you give us maybe a little insights on how you would start kind of figuring out with a company what is their core domain versus what is not their core domain so that they can figure out what to outsource and what to focus on. What's your typical approach here?

I guess it's a learning curve. So you don't, when you start, it could be still, it's an iterative process so at first you start with identifying for example you start with a value chain so a value chain is something

behind every user need there is a value chain it starts with a question who are your users first for example I gave the example of a conference solution. The users of a conference solution could be the attendees, could be the speakers, but also conference organizers. And I was focusing on the attendees. They have the user need, for example, of are fulfilling these user needs either directly. So when they are fulfilling them directly, these are the components that the user are touching directly.

And for example, you could have a scheduled speaker management, a session rating, or a survey and ticketing platform that the user is going to interact directly with. And then the next part of your value chain could be those components that are fulfilling, not the user directly, but that are facilitating other components in this value chain. So at first you identify all the components that are relevant to fulfilling the user needs, but could be fulfilling the user needs directly or indirectly by facilitating other components. For example, other components could be the data storage

to store the states of the domain models of speaker management or schedule management, session writing, and so on. And it has less visibility to the user, so you place it a little bit further down in the value chain. It goes from top visible to low and visible to the user. And then you go from top to down what components are relevant. And then also you might need a search engine that facilitates schedule and speaker management.

You, for example, would like to search for speakers by name. Also, you could also, since you would like to communicate event-driven, you might need a message broker where you can, or services can publish and subscribe messages to. And then it goes further down. Then you need an environment in which the software is executed, your compute platform, and this runs on top of a virtual machine. So you start first with the value chain from user to user needs to and plot it along the x-axis. That's called the Wadley maps.

So, Wadley maps is consisting of a y-axis, the value chain, and the X-axis is the evolution stages. And the evolution stages are going from left to right, from Genesis custom-built product and rental and commodities, going from left, the very new things that have never existed before, to custom-built and product and rental, for example, off-the-shelf products and open-source software and commodity and utility on the far right. And you take this value chain and plot it along these axes and that allows you to figure out which component to build and how.

So what components could be, what are the components that the user needs that belong to your core domain? So, for example, in this conference solution, I would say that survey and ticketing does not belong to your core domain. So these are very good candidates that you use where you can use off-the-shelf products. So that's, and then you do this with every component along your value chain, which belong, could belong to the evolution stage of genesis of custom build, which would you like to build in-house or what to, where to use or buy off-the-shelf products or integrate open source software that goes to the product and rental evolution stage or where to outsource to commodities or to utility supplies that are those components that belong to the commodity evolution stage.

And this allows you to identify where to strategically invest most. That's custom built and genesis components or where to outsource it to either using or buying off-the-shelf products or outsourcing it to utility suppliers. And I tried to not only taking this value chain from this conference solution and plotted along the evolution axis, I was also trying to integrate the infrastructure complexities that come with microservices in terms of service discovery, load balancing,

scaling, and so on, and centralized configuration management that come along with microservices. I tried to plot them along the evolution access, trying to go through different stages from, okay, at first, the first draft could be, let, for example, Netflix OSS and Spring Cloud that

provides service discovery, load balancing, circuit breaker, and centralized configuration management. And then you can use Prometheus, Grafana, Zipkin, and the Elk Stack that helps us to provide observability with metrics gathering, monitoring, distributed tracing, and log aggregation, and so on.

And then you look at those and think, oh, that's a lot to handle. It's still we as developers have to integrate it, we have to implement it, we have to configure it. So it's a lot to handle. And how can we optimize it? And then, for example, you can identify those components that can be extracted away, for example, components that can be extracted away by integrating a content orchestration platform, for example. And then the next evolution stage could be, okay,

now what happens when we use, for example, Kubernetes? What happens to these components? So they are becoming less visible to us as developers in the value chain itself because they are moving a little bit further down. But as I mentioned before, for the Kubernetes cluster, we have to deal with new primitives like pods, services, deployments, secrets, config maps, and so on. We have to configure those.

And so that's a trade-off. Like, okay, we get the infrastructure components handled, but we'll trade off to that new parameters come along. And so it goes further and further. It's a very iterative process, and it's like a continuous discussion between your team members, how you can evolve the technology stack of your components and with a focus that you still can focus on your core domain and that is differentiating you from your competitors and offload those undifferentiating components

by outsourcing it to utility suppliers. And at the end, I was then going from open source to Kubernetes to service mesh and then to serverless and to see how the components evolve along the value chain and within the world limits, how this could help you to visualize and to understand the benefits and the constraints introducing the one or the other. Hey, Susanne, I'm actually just, as you're talking, I have your presentation open here. And again,

I can just encourage everyone, if you listen to this, you know, re-listen again, re-listen again, check out the slides. They're all on SlideShare. and now just so that i understand and i think i understand it correctly but all of these iterations this is still all part of the worldly maps uh process so i'm not sure what what it's called but it's all the the planning process so you start and then you basically in iterations uh in planning mode, you're basically figuring out what is it really that you need to build? What type of technology do you really use? And which of the things are you, let's say, offloading to a third party? It's all in the planning phase still.

Exactly. I really, I've never, to be honest with you, right? I mean, I've never heard about Wordly Maps before, but I look at your your slide deck makes a lot of sense i did some you know i googled uh found the worldly maps there's also some extremely good examples out there but i i really love yours because you have one consistent example that really explains the whole process by the way did you is there any recording of your presentation available, meaning a video recording, that we should also point people to? Yes, there are a few up already. So I gave the talk as a lightning talk, but it's a very short version

that was at MicroCPH in Copenhagen, the Microsoft Serverless Conference in Copenhagen. That was in May. And mid of May, then also two weeks in June, I did a talk at MuCon London. This video is already up. You only have to, I guess, register with Twitter or Facebook or whatever. But it's behind a login I wanted.

But it's accessible for everyone, but behind a login. And the next one was the ThinkAbout conference in Cologne. This video has also been recorded there. And soon I'm going to a conference in Paris, Death Break, and I guess they are recording their session as well. So there are a lot of recordings hopefully available when the podcast is online. Perfect, yeah. Awesome. Now, Susanne, I think I kind of have

my questions pretty much answered, the ones that I had in mind, because I think we started off with, you know, what are the right questions to ask, why you want to move to microservices, some good and some bad examples you gave them as well. I really like the whole concept of building stuff in-house versus outsourced. The Wordly Maps is a great utility to use. We also talked about, which is a topic I had in mind for the end, but the responsibilities of microservices teams. I think you, and correct me if I'm wrong, but basically you say try to abstract away the infrastructure, don't focus on the infrastructure, but try to focus on creating value, which is coding and leverage the new cloud services that we have that take away the complexity.

But I guess it also depends, as you said, on the size of the company, because if you are a decent size, if you have services that are used heavily, then maybe it becomes more efficient, cost efficient to run parts of your infrastructure, let's say parts of your applications on your own infrastructure because it becomes more cost efficient. Is there any, did I get this right? I know I summarized it a little bit, but does this make sense what I'm saying? Yes. Yeah. summarized it a little bit but uh does this make sense what i'm saying yes yeah yeah and uh i guess

uh don't yeah i guess the main thing is because we because i am i have a yeah computer science background and i always love shiny new technology but uh we always have to focus is it really fulfilling the user needs of our customers? Is this really something that matters to our customers? I guess that's something, sometimes the question that we tend to forget to answer instead of like going for the next shiny new thing. So I guess it always makes sense to reconsider it.

And that's also where Wadley Maps helped a lot. Like how can I evolve my technology stack, but still with a focus if it's fulfilling, if this technology stack is still fulfilling the user needs. Hey, Brian, are you still with us? Actually, I see that. I mean, it seems we've been talking the whole time. What about you?

Yes, I'm still here. I'm still here. This ended up being one more that I listened to or try to listen to. You know, I think a lot of this was really, really informative. And I had a quick chance to look at the presentation beforehand, but it was a little too much to try to consume or wrap my head around in the 15 minutes that I had. So I've just been listening and trying to absorb as much of this as I can, because it's really, really fascinating stuff.

And I love the idea of calling some of the components utilities, because it is starting to mature into that realm. So I think that's really... Exactly. So every component is... That's what WaterMath says. Simon Water, that's a researcher from the UK who has created this technique. And he says that every component is evolving from left to right. And there's no choice over evolution. So you continuously have to adapt. Otherwise, you get overtaken by your competitors, for example. And I really like this idea that I also like that the efficiency enables innovation. That means that the industrialization of one component enables you to innovate others in terms of, for example, that new features of an existing product can appear

or that another component can co-evolve or, for example, that new components can emerge and it's the genesis of new component that then enables new user needs that have not existed before. So it frees new ideas, new innovations. So the industrialization of one component or the evolution of one component or the evolution of one component enables the innovation of others.

And it's kind of like ecosystem where everything is moving and evolving and nothing stands still and you continuously have to adapt. It's really challenging on the one side, but also very exciting on the other side. And also, I'm sorry for for being so big you're both so that's the reason why i uh when i give a presentation um i always scribble my slides i don't know if you if you see if you look at my slides those are hand-drawn they are all hand-drawn that's awesome i love that and the with linux by the way with my clumsy mouse i don't have an ivory i tried to to download it all manually.

And usually when I talk about something, I love to present it with my slides because they are piling up from, so they are only little icons with labels attached to it so that everyone could follow because I'm doing this because I picture myself sitting in the audience and I guess I have the shortest attention span on the Northern Hemisphere,

I would say, because usually when I'm sitting in a conference talk, I have to apologize, but it's, what is he or she talking about again? So it's really, okay okay you have to to stay focused i am uh trying to cheat myself in terms of like okay um slide by slide only one icon and uh it piles up with only icons and labels and not not so much text on it so i'm sorry i i would love to give the podcast with slides uh aside that you can watch while I'm talking. Yeah, it would be cool. But then I guess it wouldn't be a podcast.

That's true. Yeah, the only other thing I wanted to say was, and I think you said this, but if not, I'm going to put the words in your mouth about how all of these decisions that you make really are to the point of allowing the business to most efficiently and effectively serve the user, right? And that's what it really comes back to. And you mentioned early on in the beginning of the podcast, how, you know, if you could go back again, you probably wouldn't do the on-prem thing. Whereas as Andy mentioned, we kind of have to have the on-prem thing, but that's because of our users, right? Our users, we have some financial users, some government users and all that, where there has to be that on-prem thing. So just even using that as an example, it's really about knowing what your customers are, who your customers are and who you're going after,

finding out what it is they're going to need. Because if you're servicing an area where they're not going to need an on-prem version, then as you said, don't bog yourself down with it. That's just as you go, like technical debt or business debt that you're going to be adding into this to have a feature that might not be to the business's advantage and more so not to the user advantage. But if it is, that's where, you know, then definitely put it in and and the the challenge we see with so many um customers and just organizations out there is hey there's all these shiny new technologies and we want to jump on them well okay well what's your justification right and what's it look like and how much is it going to cost you and if you do a roll your own version where you're going to have to own and maintain it how much does that cost versus a product that you might have a little less control over um but then how much does it

cost to maintain the payment there's a lot a lot of uh moving levers in terms of cost efficiency and everything that really have to be thought out really well before you really commit or, you know, you can experiment and modify as you go, but it's not just, Hey, let's just, we're going to go ahead and do this. Andy, I think if you remember way back when we had, I forget his name, but the guy from Fender with the app, the Fender apps, and they, they, they did it and it worked for them, but their whole thing was like, we want to build a serverless app. Right. So it was a phone app that would go back in the entire, everything that the phone interacted with was serverless. But it worked in that case.

They thought it out. They made it work. Right. So it just goes to show you really have to think about these things. Yeah. Yeah. For example, for one client, I was developing a solution solely based on serverless technologies, and it worked out pretty well. It was a backend API.

And I totally understand going this path, and because it was meeting the user values, we have to be online very quickly. And it helped me because I was there at that point. It was just a prototype at that point. But it helped me a lot because I didn't have to take care of the infrastructure. I don't have to set up a Kubernetes cluster. I don't have to. It's just my functions. And the thing is, even though if you go serverless,

what still applies is a domain. So I am from the domain-driven design field or from that area. And you can apply it based on microservices, but also based on serverless technologies. And it still applies there as well. And it helps you not to lose sight of your functions, which functions belong to which bounded context where your domain model is. And it's really helpful that some things are remaining the same,

even though that's another technology that you're using underneath. Excellent. Hey, Andy, you you sort of summarize before, but was that your summer summer rated summarizing or do you have another? Let's, let's you know, let's wrap it up. And I think I have a couple of things I want to add to what I said earlier. Come on, do it. All right.

So first of all, Susanne, thank you so much for being on the show. I think you are covering a problem or you have a lot of expertise by solving a problem that a lot of enterprise customers or a lot of enterprise companies, but also startups are facing. Trying to figure out are microservices the right thing? What type of granularity and how do we approach it? I have to say one of the biggest takeaways is the stuff with the ownership that I mentioned earlier. So whenever you think about going microservices, think about, first of all, does it benefit us? Does it solve the ownership problem? So do we have better and clearer ownerships later on, which allows me to scale also

better from an organizational perspective? I think that's a key thing. I would really like to see a metric that we can look at to say we actually currently have an ownership problem because, for instance, it takes too long until somebody reacts to a problem. That's one of the metrics you said. How long does it take for us to react to a customer inquiry, a problem, a bug? And the longer this takes, it means we potentially have an ownership issue. I really also like the way that you said, even though it doesn't work for our case at Dynatrace, but if you have the choice to go both on-premise and SaaS, there's obviously challenges with going on-premise, but like in our

case, if it is a core domain, if it is a value proposition, if it's a competitive advantage, then this is something to consider. Always focus on your core domain. I really like your presentation about the worldly maps. I really encourage everyone to check out the slides, to listen and watch the recordings. Really beautiful hand drawings. It's amazing how much effort you put in to these slides. And as you said, I may not have as short of an attention span as you have when watching presentations,

but clearly when I was sitting in your presentation, it was very refreshing, especially because your presentations, your slides are just different. And that's why I think that also kept me engaged and caused me to invite you because it was just the whole package was extremely good and delivered a lot of value for me.

So thank you for that. Thanks a lot. Thank you. Thank you for inviting me. It was a pleasure and an honor participating in this podcast. Oh, thank you very much. One quick last thing.

Do you have, you know, thinking about the August, September or fall, going into fall timeframe, will you be having any speaking engagements currently that you know of? I am going to have, I have to look it up. So I have in September, I might have two and then in November, I have two as well. So, yes. If there's anybody interested in following you, are you on Twitter, I imagine? What would your Twitter handle be or some other way they can follow along with you? Yes. So my Twitter handle, I guess that's the shortest and the easiest to remember.

It's S-U-K-S-R. It's a high-fiber. S-U-K-S-R? Wow. Exactly. Nice and short. All right, awesome. So I'm sure you'd have announcements

of where you're going to be on Twitter. Yes, I will do an announcement. So the problem is I am right now in the middle of a very intense conference season and I forgot where I'm going to be in the next couple of months. So I'm every week in a different country and I forget what country do I have to go now? It's really like confusing right now.

But I will announce it on Twitter. Definitely. Awesome. All right. Well, as Andy said, thank you. It was an honor to have you on as well. Thank you very much for being on today. If anybody has any questions or topics, ideas for the podcast, you can tweet us at pure underscore DT, or you can send an email to pureperformance at dynatrace.com. Thank you very much. I'll try to pronounce it like Andy, Susanna. Perfect. Thank you, Andy. Thank you, everybody. Thank you. Bye.