Architecture 2023 Success Stories in Embracing Cloud-Native | Predict 2023

All right. Well, welcome welcome everybody to our Cloud native track that's starting this afternoon this morning this evening, wherever you are, we're gonna be talking about a lot about both kind of architecture and where we are in the state of cloud native of applying that within organization some success stories tips Etc things we've learned so we've got a lot of experience under a belt, but we also have a lot to learn probably too as well. My name is Mitch Ashley and I'm principal with tech strong research and also CTO which extra organization Our event today and I'm joined by a fantastic panel.

I'm gonna have them do introductions in just a moment, but I wanted to just highlight our our topic and I went also suggest that you know, there's a security track that's happening in parallel. Just so feel free to check that out at any time recordings will be available for each then. Also, we have some texturing research predictions coming up right after this panel at 2 pm eastern time.

I'll be jumping off to do that as well. So let's let's get into our topic talking about kind of success stories and learnings and where we go with Cloud native in 2023. I want to introduce our panel and have them do a little deeper introduce introductions of themselves Tracy Reagan, you're familiar to a lot of our audience and in the tech strong group, but we have a very large group of folks that have signed up today.

So I'd love to have you introduce yourself. Well, thank you. Thank you for putting me out there first.

Yes, I am Tracy Reagan. I am the CEO of a little company. I always say it's the little company that could called deploy Hub.

We have an open source project that is incubating at the continuous delivery foundation and our focus is gathering the evidence around your ci/cd pipeline and storing it. So for example, if you are generating s bombs to the ci/cd pipeline, they may be more useful. If you're consuming them.

We consume them aggregate them to logical applications and then we track where they're at. So we all try to track on the deployment side and for this particular topic that I think is one of the more important subjects because companies find microservice drift a problem and the number of microservices and clusters you have out there. It becomes more more of a problem.

So I'm hoping we talk about a lot of that about that today. Or between you and Stephen probably Shang too. We could have a software supply chain security conversation too, right Steven introduce yourself, please.

Yeah, I know glad to be back on Mitch and you know joins by Tracy and Chang. My name is Steven Chin. I'm VP of developer relations at J frog where the devops and software supply chain platform that it a lot of people use for their Cloud native development and I'm a developer myself and I'm very pleased to be in a role where I can talk advocate for and help developers to improve their development methodology how they're building their applications how they're deploying to production and I think this is an exciting time that we're in where it's got in so much easier than when I started my career to to build release and and deploy software to customers quickly because at the end of the day, we want people to use our software we want people to be using the stuff we build and there's really great mechanisms to do that rapidly.

It definitely Rock about the developer oriented kind of job. My best experience is go to conference and there's backpacks and t-shirts and I'm with my people right? Hey good to have you here.

Congratulations on their new year on a new Venture after your time at Rancher and Susie and with the acorn lats and love to hear about you and what you're good. Thank you. Thank you Mitch.

It's great to be here. You know, I'm the like like you said, I'm the co-founder and CEO of acorn labs and where we're working on the developer experience application deployment for you know, Cloud native environments, like kubernetes based or serverless-based environments is incredibly exciting and it's Acorn Labs is a brand new company just a few months old previously Mitch, as you said, I was founder and CEO of Rancher which was acquired by Souza a few years back and I I was the president of engineering Innovation at Souza for for over here before I started acronyms And you know, it's funny. I still call him Susie because they learned that before somebody corrected me.

And now it's you know, the anagram is stuck in my head or whatever. It is. So congrats on Acorn wax and for being here with us.

So we were just in our pregame talking about our panel that the cool thing and you really referenced it. Well, it's even we're not starting at the beginning of cloud native. We're not where we were maybe two three to go where we're We're just starting on this Venture.

What's a microservice? How do I design that? And what's kubernetes?

How do we Implement that but also we're not you working in a world of some familiar things, right, you know microservices are different approach. Designing applications service mess service serverless, and of course kubernetes as well, but we've got a got a lot of learnings we're building from too and I think that fits with our theme of Stand and Deliver which is let's make some great things happen. That's great software that people are going to use Stephen.

I'd love you kind of take that that conversation to the next place about where you think we are what are the things we can build upon from a cloud native perspective. Yeah, yeah. No, so I think that as as a developer today, really and you know, we've all we've all experienced this over the past couple years moving from offices to working from home to now hybrid or other arrangements.

Where you can you can be highly productive you can build, you know scalable teams. And as a software developer, you can deliver great code to your to your customers with very little infrastructure, right? So that really we're Cloud native is taking us.

Is now all the tools Technologies languages and capabilities, you need are supported and an easy to deploy to in the cloud. So I think most most developers and most companies start their Journey choosing Technologies choosing their Source Code system, which they want to put their code in figuring out what ci/cd technology which they want to use to to then build their Technologies to get their Technologies into a cloud environments. They'll probably have some sort of package repository or container registry where they're going to deploy their code to push it to production and this this Cloud native workflow with kubernetes is the core really allows you a lot of flexibility where you're deploying to so you're not logged into single vendor or single cloud provider you're able to deploy your codes and scale it.

I think one of the one of the historical challenges as a startup or small company was, you know, are you building for your customers today or are you building for the scale and the vision of what you need tomorrow and with Cloud native development? You're you're doing both right? You're you're building and deploying and you can you can do it very small scale.

And as your customer base grows as your your business becomes more more profitable you can then scale with that in the cloud very easily by scaling up the number of instances and pods and and deploying even geographically to different regions so that you're you're closer to where your customers are providing better services and even layering cdns or other Technologies on top of it. So, I think it's a great time to be a developer and to be building software and Technologies and there's a there's a lot of I'd like to hear from my fellow panelists kind of like what you see is the the kind of the trends and best practices which people are taking advantage of to make sure that you're building scalable architectures as you're starting out and and, you know creating a new effort. I too would like to see some best practices because I don't know if we've defined them yet.

I see everybody approaching this problem in so many different ways. It one of the things that I you know, if we go back to our history, we look at our history. We almost predict our future when developers have access to private servers in the old days.

We wanted to serve under our desk if we were developer. I know I did it and it always worked on my machine right and now I'm seeing kubernetes environments and and the kind of the explosion of clusters across organizations because it's easy become part of the problem. and what I mean by that is that there becomes a point in time where we already are have a complex environment Cloud native is complex.

When you decouple your application and you have microservices running all over the place that everybody could be consuming and you have lots of different clusters you begin realizing that you have an environment that may have sprawled a little too much and you have this version to problem across a lot of the Clusters. I'd love to be able to have a clear discussion of what we're seeing some organizations that we talked to have started tightening up that in particular around testing environments and production environments. And they're starting to figure out how to actually Implement pods and namespaces as opposed to having clusters all over the place with everything installed in every cluster everywhere.

So I think this it really the whole idea of these microservices and this reuse and the sharing does require a particular mindset of how to how to make things common and how to use the the cloud native architecture in a way that can best leverage that architecture. So I'd love to hear what you guys are seeing in terms of that. For example, I think that more companies are starting to be able to focus on how to use a pod or names basis for common microservices.

So they're not installing it in every single cluster or every single name space which I've seen that happen as well. So I think that there is some you know, there's danger ahead if we don't come up with some really common ways and some good best practices to configure the use of kubernetes and how we're defining our clusters and how we're using namespaces and pods and These are terms that you haven't heard yet. Go ahead and read 50 goes to the zoo is pretty pretty awesome.

They really defines what these these how these pieces and parts fit together and then you start realizing that maybe everybody doesn't need it their own cluster and I'd love to get some feedback from both Shea and Steve. Yeah. Yeah, I like to definitely like this.

These are great points. I love to say something about that. I mean I think you know the topic of this session is about Cloud native.

The end and I don't know if you if you search that term on the Web different people Define it a little differently in the way. I came from from a kubernetes a background and Cloud native Computing Foundation. We we tend to Define it in a very technical oriented way meaning, you know, eating Bob's kubernetes containers serverless service mesh.

So so it's it's a very technical this definition. But but really I think the industry at large most people largely think about Cloud native as just the way you develop applications to you know, to develop applications from scratch to to run our clouding environments as opposed to, you know, embedding environments or or on premising environment. So that's certainly another way to look at it.

So as we I think as we think about Technologies, like kubernetes, we always have to Putting mind we have to put these Technologies in the context of teams willing to develop applications. I mean, I think at the end of the day it is the application developer and the teams that are built around to support these application developers that dictate, you know, what technologies to use and and here comes you know, some of the challenges. I mean, I think in the last, you know 10 years or so, there's just been tremendous innovation in the cloud native Computing technology and a lot of complexity, you know is Tracy said have been built up but most organizations frankly find it very difficult to to get their developers to consume.

Are these Technologies and there's a by the way, there's a difference between you know, that the more recent I would say kubernetes based Cloud native Technologies from the last generation of virtual machine and you know ec2 EBS like technology because those are still the conceptual model still was something that developers are very much used to they resemble a physical machine, right and RDS instance look and feel just like a, you know, hosted database on premise. Where is where is the more recent evolution of cloud native technology introduced a lot of Concepts. But but now I think the technology is mature the adoption is taking off.

So now I think in the next, you know, five 10 years, there will be just tremendous opportunity to figure out how to adopt such Technologies in the in the in the day-to-day application development. And deployment and because the technology is proven to be Rock Solid and they definitely enable you to do things. You never been able to do before like, you know, like like H is simple things like ha and more sophisticated things like supply chain security.

It's it's really all included in the in the cloud native technology Suite. So if you can Master it if you can feel all the way to use it maybe build once abstractions on top figure out the way for you know, these organizations, especially get the developers on board with this. I mean, I think we can really at least the next level of productivity with you know, with with Cloud technology to me.

That's what cloud native is really about for the next, you know, five ten years. Yeah, and I think just kind of explain where where we're all coming from and how this relates to developers who are just getting started on the cloud native space. I think Tracy scheng and I were both looking at this from you know, how do you get started with Cloud native development?

How do you how do you build into this? But then how do you avoid architectural complexity and challenges and security issues and problems down the road? But to address Thomas's question about the complexity of cloud native development.

It's actually really easy. To get started and to build your applications to deploy them to to the cloud and to get things running very quickly and easily and there's a lot of great. CD technologies that are Cloud native that you can leverage to do this.

So Tracy and I are both part of the CD Foundation. And you can use Technologies like tecton or Spinnaker. Also, the cncf has some great Technologies like Argo and flux where you can use a getups style of deploying and going straight from git.

Into production, which I think is a great workflow for developers to get started. And so Cloud native development doesn't have to be complex or be fraught with challenges for you to get to production. But I think one of the things to be to be cognizant about as you're building your architectural, I'll give an example to what Tracy was talking about about understanding or what your deployment architecture and scalability is last year.

A lot of developers had to deal with Escalations around log4j as a vulnerability where you you know had to know which systems. Had a vulnerable version of the log4j libraries deployed such that you could go and you know post an update or do a security fix on those instances. and one of the best practices for any any of the cicd tools I mentioned including Argo is to connect that to a A Docker a Docker registry where you are putting your deployed artifacts, you know exactly which versions of dependencies you're using.

You know what you're deploying to production. So then when you have to mitigate a security issue, you know out of you know, maybe initially dozens but in the future as you scale hundreds of servers where you have your application deployed to where where are the vulnerable libraries? What do you have to update and you can quickly mitigate security issues.

So I think there's a scale of kind of architectural complexity as you grow where you want to be doing things simply and quickly from a developer perspective type of great experience. But you also want to do it in a way where it's sustainable where you can you can update quickly you can patch you can deploy new features and also you can quickly mitigate security issues when they come up because that is the the The environment we live in where every day new zero-day vulnerabilities security issues and things which you need to address as a developer to keep your your company and your customers safe is is a part of the software development process. Yeah, and I agree.

We don't you know, we we talk about. Cloud native as being complex but so is monolithic development. So if we really boil it down, let's think about some of the very basic difference between a microservice based application running in Cloud native versus a monolith in a container running in Cloud native.

Both are very valid ways to move forward. But what I have seen is most organizations who they started by containerizing their monolith and running that in kubernetes so that they have those benefits and now they're starting to decouple it. So what does it mean when you decouple that application it means that when you are when you go to do your build your soft your build of your your container?

You no longer are linking statically linking libraries if you have decoupled your your application. So where does that linking happen? It happens.

Dynamically via apis at runtime. There in itself is an area of complexity that we as a it Community have really never gotten quite right and in order to simplify the complexities you have to get that part of it. You have to understand that part of it and get that part of it, right?

I see companies now building teams what they call them feature teams groups of developers who are writing microservices around specific features and domains the whole ideas of domain driven design. It kind of lends to a microservices architecture. And really to really to take advantage of a cloud native environment microservices are pretty cool.

Just think about it in the future of log for Jay was simply a microservice and you had your your kubernetes environment set up where you knew exactly where you needed to install that new microservice for everybody to get the change in a dynamic way as opposed to recompiling every single monolithic application or every container that contained love for Jay. So as you move down this this path of cloud-native this Cloud native Journey. What I really believe we have to do is put our kind of our old hats on our object-oriented programming hats on if you have to to understand the the concepts of reuse and how powerful that reuse can be.

Now reuse can be can create some complexity. But if you have the transparency and you're and you're managing the architecture of your of your kubernetes environments your clusters your namespaces and your pods then this is very very doable. And it doesn't have to be complex.

It's great. You said that because I was just gonna carkin back to developers today, you know start out learning object oriented development. It's not a it's not another thing necessarily but I remember going through that transition when we're all kind of moving to object-oriented languages and C++ and doing them doing learning a new style of how we construct, you know, software and logic and data thinking about it differently.

We're kind of going through that transition right now. I think Tracy to your point of it's another kind of an analogy where Providers and where there's an object in software or it's a microservices in software. It's kind of a similar idea.

It's a reasonable component self-contained. It's got an interface to it happens to be an API instead of inside your own own program space namespace. But but the part of it that's also different is now we're putting it into an environment that manages that that's the kubernetes and quite and containers.

So we're kind of doing it at two levels in parallel and that's where a lot of learning is. Happening and still needs to happen agree. Yes.

Yeah, I mean I could I could I that definitely resonates with me we're adding another layer. You know, that's why some people call it complexity right used to be you know in some ways the developers job used to be easier in you know in the old days of running physical machines or even in the very early days of Amazon ec2 because all you kind of have to worry about is write your coding, you know in Tomcat only weblogic and then and then deploy down to some servers and put a load balancer in front of it and configure DNS, you know worry about storage so developers understand that even though they're not the kind of people they who manage it these things every day, but these days if you think about Ah, the kind of stuff developers are running on their laptop is very different from what's actually the production team is got running it in production and platforms like kubernetes is actually yet another layer that unfortunately the production team has have to manage in addition to the applications that's running on top. So now you've got you know, you've got the Computing infrastructure.

Those are the servers, you know, virtual machines storage networking and and that stuff these days are largely delegated to the call provider then on top of that, you know, you got to manage your your sort of your you know, your your your Cloud native middleware like, you know, like Stephen was talking I mean like start with kubernetes obviously, but also also like, you know, you your CD platform all these other things you also gotta understand then you got applic. Is that that come running on top of it? So so I think the industry is still in the in the midst of trying to figure out how to properly abstract that complexity.

I mean, they're just so many ways of doing it. There are folks who who build tools that that would that would very flexible tools that will provide God rails that would you know adapt to whatever technology you want to use and then there's another line of thought like so like more similar to the past that says I'm gonna just gonna be more opinionated and there's like just pros and cons for either approach, right? And and I don't think there's been a clear winner of where the whole thing is gonna go yet.

But in the meantime the complexity is still growing and so much so that I mean these days I increasingly hear about you know, used to be you just hear like srees or devops Engineers, but now the workload is increased to such a degree that now the whole organization's been They call them, you know, some companies call them platform teams. So now they're you know, they're managing this platform. Even though infrastructure is all managed by the by the cloud provider, but on top of that they got to manage their own platform, which is highly highly unusual because if you think about the I mean fundamentally there's nothing about one company's platform that should be different from another company's platform.

Right? So why are why are these platforms not you know, not a cloud service that that that these companies can just consume cheaply and and and the subscription why do they have to staff the team to do it? But but such is the nature that the where we are in technology in Innovation where you know, all these Cloud native technologies have been developed but I think exactly how they gonna be used in the adopted, you know, that's gonna be figured out in the 5-10 years Okay, anybody want to wrap you know, I think a place we could go next and just to forewarner audience.

We're gonna call it audible hearing about five minutes. Tracy's gonna take over his as moderator while I jumped to help prepare the next next session the panel for that session. You know, what what it this may be too simple to stick of an answer but I really liked the invention or the application of patterns the creation of patterns in software software architecture.

It is it in your your point Shing is that we're dealing with the software architecture of the application and its architecture through microservices and we're dealing with the kind of environment that that's managing that the platform that it's managing that. Is that what we need is some some reusable patterns to help people understand how that can be deploying used and leverage better is it is a technical solution what helps this manage this and create what you first refer to Tracy as best practices. So I'm gonna throw back to you Tracy and then if I jump off as you're in the middle of a good conversation, it was wasn't because you aren't in the middle of a good conversation.

So Tracy, go ahead. So I think that understanding your patterns is pretty critical actually for defining how you're going to build out that architecture that is the whole idea around domain-driven design. If you if you take some time and study domain driven design, it's really about looking at your in each individual Enterprise what those patterns are how they how their teams are put together how they how the data flows.

So I think understanding your your patterns are critical because those patterns will define those features and those features are going to define those microservices. So we have to think about two that the concept of an application in a micros in a microservices environment. Because you may have an application team who's just really building a good portion of their application, but they're consuming these other microservices.

So the application just like just like we did in our build and you created a big fat binary in a monolith in a microservices are a decoupled environment. You still have an application that's consuming other smaller components that are oftentimes called applications. Those are the patterns that you have to start watching who are what what are the reusable components?

How is the Enterprise set up? How do teams work together? Because that will create the Simplicity in your Cloud native environment because you're modeling how your teams are working together.

So yes, the patterns are important and the patterns are important all the way down to You know what version of kubernetes Are We running because it can drift it can drift across teams. Somebody needs a new feature and it dropped all the way down to the kubernetes layer the whole stack. How are those changes managed?

You have to look at your patterns to do that. Again, looks like here the new moderator Tracy I am. Yeah, you know we we only have five minutes left and I would love to in this by asking each of you.

Sorry, I have a dog that's choking. If I asking each of you tell us something tell us something. We don't know.

What we've just we've talked about a lot but there's probably something really front and center that you thought about so Steve. Why don't we tell us something we don't know and I know you know a lot so there's probably a lot that we don't know that we haven't heard today. So what what should we know?

Yeah, so, you know, I think we've chatted a lot about the the back end of the process for like deploying to Cloud native environments to like like how you define your your namespaces and your your architecture and how you build a pipeline to push to production. I think kind of going all the way to the left on, you know taking it from a developer perspective. I think a lot of the decisions you make early on.

In the the languages you're choosing to build for for your technology stack how you're architecture your application make a big difference in your in your success. in Cloud native environments and I think one of the one of the Hot Topics recently has been you know, how how you can build applications which are resilience and can can withstand attacks either software supply chain attacks or in general be better resilience against exposing vulnerability is themselves And I one of the one of the trends which you know, we've been seeing and Tracy and I are both also part of the open source security Foundation. Is a move to away from traditional languages like CNC plus plus where it's very easy to expose memory issues to memory safe languages like rust and other other higher level languages.

And I think this is also one of the big advantages of a cloud native architecture is you have a lot of choices and it supports whatever language whatever technology you want to deploy to and if you're if you're using a microservice architecture like Tracy talked about you can even mix and match different languages in your architecture seamlessly for for different services. So I think another consideration that you know, our audience should should think about is building for security building building and designing so that you're taking a Security First approach and you know looking at different Technologies, which help you do this either to choose languages which are which are memory safe by Design to make sure that you're you're scanning your dependencies early in the process so that you're not pulling in any vulnerabilities that are higher up in the software supply chain. And also making sure that your have an easy way to update your applications in production.

So you can address any security issues, you hit. Now that every Edition. Yeah.

Yeah before that though. I just want to say Frog under Stevens, like kind of Direction has started a new open source project called Persia. It's a decentralized package Network and it really really speaks to securing the build process whether you're building a container for a microservice or a container for an entire monolith.

I highly recommend you take a look at Persia and you can find it at the CD Foundation website. Yeah. No, thanks.

Thanks for that Tracy and I'm horrible at promoting projects, which I'm involved in so I am too but that one's an interesting one and it's new so everybody should take a look at it. Yeah make sense. So so yeah, so from my perspective, I mean, I've been thinking quite a bit about just the notion of an application or a service, you know, how because they're just so many ways to look at it and and I just feel like these terms are very much overloaded from from a developer perspective.

It's a bunch of code and it's sort of an API endpoint, but from From you know from a production perspective that could be a bunch of virtual machines or a bunch of parts or a bunch of kubernetes resources, but you at this point in order I feel like in order to simplify. The the consumption of these Cloud native Technologies and also in order to bring the developers and and these platform teams a little closer. I mean, I feel like a common, you know understanding of what an application is or what a Services would be very very helpful.

And and I think like said earlier, they're just so many ways of approaching it there there. There are a bunch of you know lose ways, you know, some some folks would say I just give my resources a bunch of labels and if they're labeled by, you know, the fact that belongs to an application and that in the case and application in another extreme. There are people designing these these these very strong domain specific languages, you know to define the complete structure of these applications and microservices.

So so this is a very vibrant area of Technology Innovation and Frankly these days and I think folks who can come up with good Solutions are probably not necessary vendors, but people who are out there actually consuming these Cloud native Technologies. So I I would I would just keep an eye out for that. And and and I think if you think traditionally where Innovation would go, right they typically Rise Up from the bottom and move up the stack.

So we've, you know, we, you know, we the CPU and memory layer and then there's there's virtual machine layer, then this you know this container layer and the next layer would be, you know would be applications and some what's in proper application and services abstraction and I think that I'll keep an eye out for that for the next you know the next few years. And what I know that everybody else may already know but I think a lot of people have realized it yet is that in the cloud native architecture things change pretty drastically and it is time to revisit the cicd pipeline. When you have microservices that are moving across the pipeline pretty much all day long and being deployed out all day long.

Every time you do that. You create a new release candidate at the application Level. So as you revisit your ci/cd pipelines, you might consider adding some security to it there.

There's new tooling that's being introduced for improving. Everybody's security profile. Some of its shifts way left starting with s-bombs and some shifts way, right?

monitoring production environments But if you're going to revisit your ci/cd pipeline, you should really consider adding what's needed to support Cloud native as well as what's needed to have more Security in it. And in that I'm going to throw it out to the audience for questions. I'm going to start with Johan asked a question.

This is can you share experience or opinion on organization? To have a platform team that enables multiple feature teams to manage complexity. That yeah, I can I can I can chime in on that because I mentioned about platform team before so so typically where where we're seeing these days is is is just you know, these platform teams were adopt a particular standard and they're just there's a lot out there, you know, the Legacy things like these days you consider legacy platforms like Cloud Foundry to you know, these these new framework CD Frameworks, like other CD or tecton.

So so they would adopt that. They will typically adopt some form of a of you know, a workflow standardized workflow plus some kind of an application or services templating and then and then have you know, the whole organization that I adopted. I mean that the challenges of course different organizations then do it differently.

I mean sometimes so this unfortunately the clear leader hasn't hasn't really emerged yet in the space. And so so there will be a lot of room for experimentation and Innovation and definitely like I said earlier to your question exactly as an area we should keep an eye out for for the next few years. Stephen have an opinion on that.

No, I I agree with Shang. I think that this is something where you know, we we interact a lot with the the devops teams and in large organizations and ultimately especially in bigger companies. It comes down to finding a scalable way to do it across different different teams different language different platforms.

Um, and at some point you have to standardize on a way that makes sense and supports a variety of Technologies and the sort of Technologies open source Technologies Shang was talking about enable you to do that scalably across your organization. And I think this question really brings up the whole SRE. Kind of concept I think that I see the site reliability engineer is a more prominent role in Cloud native than it has ever been in sort of a server-based.

environment But at the same time the whole idea of having these different feature teams that have their own sort of platform manager. If you have the trans if you if you have the transparency and you can really understand what your entire environment looks like. I think that's it's doable.

But we also have to remember that not every feature is equal. You may have some features that have higher security risk to it. Maybe the login feature is not something that you want one team to one team to manage.

Maybe it should be something that is flagged. So everybody knows that that new service is coming down the pipeline. So there's a lot of work to be done on this a great question because there is so much change going on that every more than likely each feature team is probably going to have their own defined Pipeline and workflow and pushing out to all of the Clusters all at the same time and all this change happening again it comes back to how do you have the transparency keeping the data in one place having that single source of Truth?

And those are all topics that everybody is talking about right now. So we have just about one minute left. I want to thank Stephen and Shane and Mitch, even though he's gone and the tech strong group for holding this panel discussion.

I think it's a really good place to start if you're coming from the you know, if you're just moving into Cloud native and you really wanting to understand some of the complexities. I think it's good to know that yes, it's complex, but it doesn't have to be So on that I will say goodbye to all and we'll see you at the next one. Thank you.

Yeah, thanks so much, and it was a pleasure being on the panel.