 Thank you so much. Hi, everyone. Thank you for joining. I appreciate your time here today. So yeah, thank you for joining me for this session, where I'm going to be taking a look at breaking down this concept of what does cloud native really mean? How can we go about building applications that don't just barely survive in the cloud, but actually thrive in that cloud environment? So the way I'm going to do this is from more of a biology perspective, kind of comparing and contrasting biology with software and looking at how we break this down into different segments and can maybe learn some lessons from biology in terms of our software evolution going forwards. So the reason I do that is because actually before I jumped into the world of tech, I was a biology graduate doing specializing in fish. So this is me studying coral reefs in the Bahamas. So that was not really necessarily sort of related to my work. But I like to try and bring it in whenever I'm talking about software, especially complex and often very abstract concepts that can be hard to sort of relate to if you don't have something concrete like an analogy. So about five years ago, I graduated and then came to IBM, joined the world of Java, learned all about object-oriented programming in cloud native. It was a fairly steep learning curve. And so I've been doing that for the last five years. And I do a lot of this. I'm a developer advocate. So I do everything from talks to creating demos to writing articles and tutorials. And I specialize mostly in cloud native Java technologies, things like reactive, anything with the JVM in the cloud, really. So that's a bit about me. But jumping into the topic at hand, first let's take a look at my title. So I've called this Cloud Anatomy 101. And that's because I really wanted to paint this picture of really breaking down this concept using this structure of anatomy. So what does anatomy really mean? So I've got a couple of definitions here. It's all about sort of this concept of being concerned with the various different bodily structures in animals or other living things. Really, it's just, if you look at the second definition, it's a bit more of a definition that you could apply to tech, where we're looking at sort of this study of the science of breaking down the internal workings of something. So looking at those individual pieces. And that's what I'm gonna do today is break down this concept of cloud native into the individual chunks and analyze what we need to do to be able to make them effective. So why do we care about making our applications effective on the cloud? What has happened in terms of the evolution that means that we're now having to adapt our applications from what they might have been traditionally in more of a monolithic type system, maybe running on prem. So the first thing we need to look at is the evolution of modern infrastructure. So we might have once had a sort of single core, but now we can take advantage of things like multi-threading and multiple cores. When we're looking at cloud native, we're gonna be taking a look at things like virtualization, containerization, and using the fact that our applications are normally distributed across many different data centers, different servers, when we're uploading them and deploying them to the cloud. So this evolution of the underlying infrastructure, so being able to have virtualization, being able to have containerization, has enabled us not just to evolve that infrastructure, but also to evolve our applications as well. So whereas we might have traditionally have had one large monolithic application that we deploy and develop in a waterfall style, we're now moving more towards sort of breaking that down into smaller segments, into perhaps microservices, and looking at deploying those and developing them in a more agile manner. And so the reason that we've done all of this and the reason that we're interested in making this evolution progress so we can be better at cloud native is because of this. Hopefully everyone's familiar with Toy Story. If you're not, please take that way as homework because it is a fabulous film. In Toy Story, we have these aliens and they get excited about the claw. This excitement is what drives us to build better applications. It's, there's a feeling of, ooh, the cloud. You know, we get excited about what we can achieve when we start deploying our applications to the cloud. Being able to achieve benefits like, for example, cost optimizations, being able to have that scalability, and that scalability be dynamic. So we're not just talking about scaling up our applications but also being able to scale them back down again because we want to be as cost effective as possible, but we also want to be able to provide the best possible service to our end users. Also things like speed of deployment. We can be quite rapid when we're using cloud resources. Things like resiliency, so being able to rapidly spin up new instances if our microservices were to go down at any point, for example, and things like flexibility. So being able to deploy to different platforms and not have to reconstruct our entire application again if we want to be able to achieve that. And then there's a couple of benefits on here that you might not necessarily think of, like fashion, for example. You might not necessarily think of development as a particularly fashionable place to be, but actually when you think about it, we follow fashions in development just as they do in fashion industries and other industries. It is cool to be on the cloud. It is cool to use cloud native technologies. And so that does play a part when we're considering the benefits that we could gain from cloud native. If our application is serving some sort of end client and they look at us and we're still using technologies from 15, 20, 25, keep going years ago, then they might not necessarily see us as innovative, as sort of forward focused. And so that does play a factor in terms of enabling us to be seen as thought leaders and sort of have that advantage in a competitive landscape that we currently have. So now that we're excited about the cloud and we know we want to get onto it and be effective, what does it really mean to be cloud native? And this is where we start looking at definitions. Now I had a look at a few different definitions from cloud native vendors, like, for example, VMware, Red Hat, Microsoft, IBM, et cetera. And a lot of them were quite specific in regards to what technologies you had to use, what infrastructure you had to use, what architecture type, for example. The one that I related to the best when I was looking at these various different definitions was this one. And it kind of makes sense coming from the CNCF. They are literally the cloud native computing foundation, the clues in the name. So in their definition, the bit that I've highlighted is the bit that I sort of really related to the most. So cloud native technologies empower organizations to build and run scalable applications in modern dynamic environments, such as, and again, you can see here they don't limit it. It could be public, it could be private, it could be hybrid, whatever cloud you want to use. And although they do sort of specify some specific technologies, architecture types like containers, service measures, microservices, the nice thing about this definition is that they just say it exemplifies this approach. They don't say you have to use it when you're doing cloud native. And so it's really this sort of being able to enable these organizations to utilize whatever infrastructure, whatever tools they need to, to be able to be cloud native. Because really, all we want to be doing is those key characteristics I pointed out about being scalable, being flexible, being portable. And it's this that it's really trying to highlight in that definition. That's what cloud native is really all about. So if we're looking at being cloud native and we're trying to exemplify these definitions that we see about what does it really mean to be cloud native, how do we go about actually achieving that? And that can sometimes be the hardest step. You can see this sort of light at the end of the tunnel and it looks like paradise. And you're like, that looks amazing. Look at all these wonderful companies like Netflix and everything achieving this and being so amazing. And you want to achieve that too. But sometimes it's the steps in between that are the hardest to be able to figure out. And so hopefully by breaking this down, we can go through steps that can help you consider what you need to do if you want to be able to be cloud native. So the first thing you need to consider when we're looking at cloud native applications is what are you building? What are you actually creating? Because what you're creating is going to play a big part in how you're going to be building it and designing it. Because for example, let's take some biology analogies here because I love them. So let's take the biology analogy of a sponge or an amoeba. These are really simple organizations. A lot of the time with amoeba or bacteria, they are literally just a single cell because they don't need to be anymore. They can absorb food from around them. They don't need a digestive system and a whole system to break down food and take food in and hunt food. And they literally just sit there and absorb food. And that works for them because that's what they were designed to do. But if you're looking at, say, a more complex organism that has, say, more complicated structures, like, for example, a worm, when we're looking at a worm, okay, now we need to move about because we need to go and find the food. So now we have to have muscles involved that are able to move us. Now we have to have digestive systems involved. And that just keeps getting more complex as we work our way up the animal kingdom until we eventually get to highly complex animals like ourselves. We can be looking at apes, dolphins, lots of different types of animals that are actually really rather complex. We have very specialized cells that are designed to do one individual thing. And if any one of those were to go wrong, it can end up in catastrophic situations. And so really the way that you design and architect your system really depends on what's the purpose for that application? What are you trying to achieve with that application? And sort of what is the, really the minimal viable product of that application? What is the minimum number of microservices you need, for example? So by analyzing your application before you start designing, you can start to pick the best application architecture type when you're going through this process of designing and developing. And it's important that you first consider your own application and don't just look at what's cool. Because sometimes what's cool isn't necessarily what's best for you and your application. You might be looking at, say, really great organizations who have achieved some fantastic technical capabilities like, for example, Netflix, who were really pioneering when it came to microservices. And you might look at them and say, well, microservices seems to be the way to go. But is that really what's best suited to your application? There are lots of different architectures that can actually be cloud native, including things like monoliths. It depends on how you build them and how you design them. So you could pick anything from a monolith through to what you might call microservices, which are like bigger microservices, kind of, or smaller monoliths, depending on how you look at it. And then you might go down to microservices or you might go all the way down to functions if that's just what you need. It's about picking what's best for you depending on what you need. And there's a variety of different things that you need to consider, and they're not just technical. People often make this mistake where they look at their application and they say, well, from a technical standpoint, I need X, Y, and Z. Well, actually it's not just technical capabilities you need to be considering. You also need to be considering your organizational capabilities. Is your organization set up in a way that allows you to be able to develop in microservices? If your teams aren't able to go ahead and asynchronously create a microservices, if they're dependent on other teams getting permission from another team and another team and another team, you're probably never gonna have the process in place to be able to actually effectively develop microservices. So that's why I've deliberately included on this scale some of the organizational factors you need to be considering. Like, what's your pricing model? Can you afford to be deploying microservices? Are you flexible in terms of the costs? Things like delivery frequency, how quickly can you deploy and develop those microservices? If it's once a year, you're probably looking more towards the monolith end than the microservices. Things like modularity, network demand, fault isolation. So really it's about laying out these characteristics as well as the technical characteristics as well. And what's quite useful to do is to plot where your organization or your team is on this scale. And the reason I made it a scale and not just categorical segments is because really it is a scale. You could be anywhere on this line and it depends on your own application. I didn't want to silo people into specific segments. So by plotting on there and seeing where the majority of your sort of scales fall when you list out these characteristics can give you a great idea as to whether you should be more on the monolith again, microservices, microservices, or on the functions end. And that can help you to plot that out without just going with the coolest thing you see. So once that you have things like your architecture decided and you're starting to look more at the individual elements of your application, you might be looking at things like containerization to be able to achieve that. So we're looking here at sort of the smallest level of your application really, how we are packaging up various elements of our application. And in the body, this is exactly what we do. We deliberately have containers in the body because that makes it much easier to move them, much easier to replicate them and much easier to fix them and replace them if we need to. We call them cells. It's no different to having a container. Imagine if we just had a body full of like DNA everywhere and mitochondria and everything was just one big mushy soup. It would be a nightmare trying to sort out where the specialist cells were trying to get those functions done, being able to specialize particular cells, being able to have very complex systems like the digestive system, the brain, hormones, etc. This would all be a nightmare because all the DNA would just be really tangled up. So in biology, we've adapted to be able to create these containers to be able to achieve these key characteristics. And these key characteristics are really what we want to be achieving in our software as well. We want it to be easy to move. We want it to be easy to replicate and we want it to be easy to replace and fix if we need to because once we're deploying to these distributed environments, it's highly likely that at some point something's gonna go wrong. So we need to be able to rapidly say tear them down and put new instances back up and be able to replicate them if we have increased load and sort of containerization allows us to be able to do this. So rather than using something like a VM where we have to have sort of a guest OS on each of our VMs and that's taking up quite a lot of memory, we can utilize technologies like for example Docker which if you're interested, there is a Docker booth downstairs, so go and check that out. We can utilize Docker to be able to have a much more streamlined form of containerization where we can basically take out that guest OS and have that running on the underlying server so we don't have to have that in our application clogging it up. So it makes it a lot easier for us to be able to port, make our applications more portable so we can move it to any cloud infrastructure we want, whether that's on the Google cloud, IBM cloud, AWS, whatever we're using, it makes it a lot easier and it means that you can ensure every container is the same. So just like I need multiple heart cells or multiple muscle cells or multiple skin cells, I can make sure they're all the same and easily replicate them. If for example I want my DevOps team to do something with them or I want my development team or testing team, whatever, you can make sure the environment is the same every time. So containerization is really, really helpful when we're moving to a more distributed system and we have multiple aspects to our applications. So now that we have these sort of individual units within our applications, whether that's a microservice or a microservice or somewhere in between, what happens when we're now putting these into this distributed environment? Well now we have to somehow manage them, scale them and ensure that we're able to effectively deploy them. And we do exactly this in biology. So imagine for example that you have suddenly cut yourself, you've fallen over, you've grazed your knee, you've cut your arm, whatever it is, you've now got a hole in your skin that could potentially be a point of infection. Imagine a software a point of failure. So if we've got a point of failure there, we need to do something about it and so our body is able to rapidly deploy cells to that particular area to be able to say right, you need to go to that area, form a clot, we need to protect the body from that potential infection. And the same thing is what we want to achieve in software. We want to be able to rapidly deploy resources or containers, whatever it may be, to that particular point of failure to ensure that it doesn't become a point of failure, it doesn't become a point of infection. So we do that within the body itself. Another one for example is, for example, infection. So this is a classic, especially at the moment, that's why we're all wearing masks. So when you have an infection, what happens is we have this adaptive immune response. So what we're trying to do is rapidly scale up the number of cells that could possibly deal with that infection. And we need to do that really rapidly because otherwise the body could get unwell and worst consequence, we could potentially die. So we need to be able to do this in our body and we have evolved to be able to do this very rapidly, very quickly and effectively because if we didn't, we wouldn't be here today. And so we need to be able to mimic this in our applications if we want to be dealing with those fluctuating loads and ensure our application is always at its best. And so this is where we look to things like, for example, Kubernetes. So utilizing tools that can enable us to automate this deployment, this scaling and essentially managing all of those individual units within our application and being able to do that in effective manner depending on the load to our system. So Kubernetes can be really useful for this. Again, it can also be shortened to K8. This is an open source system and it just automates all of these things for you for containerized applications. We can also use things like reactive principles. So looking at enabling our applications to be agile and flexible and really designing that into our applications designed from the very first word, go. So now that we've looked at sort of the fact that we need to, okay, we've got these individual units. We need to manage them, deploy them, scale them. What about communicating between them? Well, this is something, again, the body does very well and we have different kinds of communication. So we have sort of a more slow but longer lasting form of communication in terms of biosignalling. So that can include things like hormones. But we also have a very rapid form of communication where we can really rapidly form our body to do actions, for example, or respond to events. And that is our nervous system, which allows us, you know, if you've picked up a hot pan to immediately drop that hot pan because that is gonna be no good for your hand. So having this combination allows us to be able to respond to events asynchronously really because when you think about it, when our body kicks off a hormone response, so whether that, for example, is to say, right, we need to shiver because we're cold, maybe the aircon's too high, whether that's that or whether it's dropping the hot pan in that example, we don't have to wait to be able to know, oh, has that message gone through? Did you get that message? Because if we were waiting for that, we'd be holding the pan for a lot longer. We wouldn't be responding to events as quickly as we need to. All of this form of communication is asynchronous. There is no locking involved in terms of, I don't freeze when I'm waiting to start shivering because that would be a ridiculous evolution and we probably wouldn't survive long. So it's important that all of this is asynchronous in order to be able to survive and be effective as human beings. And so the same thing is what we want to achieve when we're doing communication in our cloud native apps. We want to be responding as soon as possible to events that are happening around us or events in the system and doing that in an asynchronous manner. And in order to do that, we can use a variety of different tools, for example, like you might take a look at event-driven or message-driven forms of communication. So you might look at EDA, which is event-driven architecture. It's a really interesting form of architecture where it sort of looks like this. You'll have essentially an event log in the center of your application and you'll have different microservices, either publishing events or subscribing to events or doing both depending on what your microservice needs to do. And the reason this can be a really effective form of communication is because you're no longer having to wait for a response to be able to continue doing something in the meantime. You can essentially broadcast that message to whoever needs to listen. They can listen and act on that in their own time, but you don't have to wait for that to happen. So this can be a lot more effective in cloud native applications because you're not restricting your application to potentially a very slow service that could be very slow to respond. And you're enabling that decoupling of your microservices. You're not reliant on another microservice when you're performing particular processes or transactions. So, and some tools that are useful for that are things like Kafka, MQ, RabbitMQ. There's a load of different open source tools that you can use and utilize. So now that we've taken a look at communication, what about storage of data? Now in the body, so we're getting to sort of the higher levels here. We've gone right down from the very smallest level to the highest level here. We're looking at data storage. And in the body, we have a mixture of different forms of state. Now what I mentioned, okay, data information storage in human biology, you might immediately jump to the brain and go, wow, I've got this massive, great, big brain in my head. It makes me a human. It's very useful, got lots of information in there. And yes, it is a very good form of information storage. We have a very complex system that, you know, we still don't really understand properly to this day where we are able to compartmentalize the various aspects of data that we're storing into different segments of the brain that are specialized for that function and is a very effective form of information storage. But what you might not necessarily know is as well as having that sort of stateless form of data storage. So the fact that, you know, our cells aren't necessarily storing data in them, they're then relying on the brain to be able to store that information, like our memories. We actually do have a form of sort of more stateful which is storing information within the cells itself. So actually in our adaptive immune system on the right-hand side for you guys here, we have something called memory B cells. So B cells are a form of white blood cell, so they're there to help prevent infection. And actually, as the name suggests, memory B cells have state within them. They're able to remember basically how particular viruses or bacteria or infections look so that they can more rapidly recognize them next time you're infected by them. That's why we have things like vaccinations to make it a lot easier for your body to be able to recognize the cell signals and sort of the pattern on the outside in terms of proteins and things when you're infected with something like a bacterius or a virus, for example. And by having this memory stored in state, we can be a lot more rapid in terms of responding to those infections as soon as possible. So we have this combination in our bodies of both stateful and stateless data storage. And really it depends on your application as to which one would be better suited for you. It's a case of essentially looking at, okay, do I have to store state within my microservice? Can I have state stored in an external database or an event log of some kind? And really that's a decision that has to be made by you. It's not one that I can just say, blanket, you should go stateless or stateful. It's very much a consultancy answer, I'm afraid of. It depends. So it's important for you to consider both. A lot of people when they're looking at cloud native automatically jump to stateless because it's so easy to be able to rapidly produce like replica microservices, for example, to be able to essentially tear down ones and re-instantiate them if they go wrong because you don't have to be thinking about re-instantiating the state in that microservice. However, there are times when you may need state within a microservice. We can still do that effectively in a cloud native environment using things like the saga pattern and transactions. So for example, if you need to book a package holiday, you're gonna need multiple read write operations to occur with things like flights, hotels, taxis, car bookings before you can actually do that overall transaction. So you might need to store state in that particular example. So really it's up to you, but if you're interested in learning more about sort of stateful in cloud native, there's a YouTube link there to one of my talks and you can check that out later if you're interested. But this is something to consider whether you wanna do one or the other. Okay, so now that we've taken a look at all these different aspects of development, what happens when inevitably things go wrong? Because it is inevitable when you're putting stuff onto a distributed system that sometimes can go down, sometimes can go wrong. And this happens a lot in the body. In the body, stuff goes wrong all the time. Sometimes we're aware of it, sometimes we're not. But we have lots of different monitoring tools that enable us to be able to distinguish, okay, is the body healthy right now or do I need to do something about this? And this sort of overall monitoring is what we call in biology homeostasis. So this is really this state of steady internal physical and chemical conditions that we need to maintain in order to stay alive. It's as simple as that. And that can include things like water levels. It can also include things like temperature, blood distribution, yeah, like temperature, fluid balance, blood sugar. So it includes all of these things and we have some really sophisticated monitoring tools in lots of different organs in the body to be able to analyze this and monitor it in real time. And this monitoring in real time, this ability to be able to observe what's happening in our bodies is exactly what we need in our applications. We can no longer just go in and say, oh, what are my logs doing? Let's go see what my logs, we don't have that locally anymore. We need to be monitoring our distributed applications in an effective manner through things like monitoring tools. And that can include things like elastic, cabana, prometheus, fluent D. And all of these allow us to gain real time metrics and be able to analyze that to spot trends and know when something is potentially going wrong to be able to do something about it before it potentially becomes a failure point and our application goes kaput. And we can actually utilize monitoring tools that enable us to visualize those monitoring metrics. Things like Grafana can be really useful in enabling dashboards so we can visually see those patterns and more easily spot when there's something that perhaps doesn't look quite right. Maybe there's a dip somewhere or a peak somewhere where there shouldn't be. So this is really important, especially in this distributed environment. And the last thing I wanted to cover is, okay, now that we've looked at all of these pieces, this can actually be quite complicated. Like we've got loads of different microservices, we've got all this communication to worry about, where are we putting it all? How are we communicating? How are we letting people in? How are we monitoring the security? So all of this is things that we have to consider and navigate. We have to navigate this complexity when we're now moving to these distributed systems. And this is the same thing in the human body. The human body is naturally very complex. That's why we don't understand all of it yet. You know, even the top scientists don't, the top doctors. And so it helps a lot that in the body we have this sort of central nervous system that enables us to have a single point of entry and a single point of control for most of our body. So things like you've got the CNS, which is the central nervous system. So that's your brain and your spine. Then you've got the peripheral. So these are the peripheral nerves that go to the rest of your body and help to control it. And by having this nervous system, we have this central point, the brain, that essentially controls most of what we do, arm movements and all the rest of it, breathing, everything. And so by having this central point, we know exactly where often things go wrong is in the brain, even when we're having symptoms elsewhere. And this helps us to at least have that central point of reference when we're looking into this complexity and trying to manage and control it. And we can do similar things in software, so we can enable us to sort of minimize that complexity by having things like, for example, proxies, API gateways that enable us to have that single point of entry into our application and automatically manage where those requests are sent to within our microservice architecture rather than having to direct those right from the get-go from, say, our front end as an example. So we can use tools like, for example, Kong, NGNX. There's lots of different tools that you can use that will enable this sort of single point of entry and help to reduce that complexity. And by going through all of these stages and looking at all of these various different elements of Cloud Native, hopefully what we should achieve is all of these characteristics. So being able to be resilient, to be able to be observable, scalable, have rapid deployment. And really this is what it means to be Cloud Native. These characteristics, it doesn't mean having microservices, having stateless microservices, using a particular language or a particular platform. It's just make an application that does this, that does all of these key characteristics and behaviors. So now that I scared you with all of that and all of the things you have to think about when you're designing Cloud Native applications, how do we actually truly achieve Cloud Native apps? So there are various different methodologies that we could potentially use. Some of them are very helpful in the fact that they're not language or platform agnostic. They're very much broad and can be applied to most applications. So we've got things like the 12 factor app methodology and this lays out 12, as the name suggests, 12 factors that you should follow if you want to achieve Cloud Native. So it goes right from the very word go, like the code base all the way through to external configuration, disposability, dev prod parity, and it can be a really useful one to follow. If you're interested in the 12 factor app methodology, you can head to 12factor.net and that's the original website where it goes through each of the factors. I've also created an article where I link off to some interactive labs where they link to technologies you can use and you can use those labs for free if you want to and it allows you, if you're interested in a particular factor, to get hands on with those technologies that could enable that. As well as the 12 factors, some, the 12 factor was created over a decade ago and so David Hoffman basically created a book that extended this to be the 15 factor apps. So 15 factors, I've given you a huge hint here. Those that I've highlighted are the additional three factors that have been added and some of the others have been slightly modified or edited. And again, I've created an article for this if you want to go through and have a look and get hands on with the technologies. Other methodologies we can use, things like the CNCF cloud native trail map. So this is designed to be a trail that you take from the very top all the way through to the bottom and again, it basically lays out various different stages and steps that you should be following when designing and building cloud native applications including things like containerization, observability like those metrics I was talking about, things like utilizing data storage and what kind you want to use. So that can be a very helpful one. We've also got the IBM garage methodology that you can check out as well which is a field guide you can access for free if you're interested. And then there's obviously a bunch of tools and technologies you can use and the nice thing is that there's loads of open source communities that can enable you and help you in building those applications and tools that you can use from them. So some of my favorites that I'm involved in quite heavily are things like Chikati EE. They're on my t-shirt so you can see I love them. Chikati EE, that helps people who are designing enterprise Java or Chikati EE applications with things like micro profile. Again, looking at those enterprise Java applications and this enables a huge variety of different APIs. So some of them you can see really do link to those different elements that you should be considering like having health and observability so monitoring in real time. Things like configuration. Being able to have things like REST clients in there documenting our APIs, making it really easy for others to be able to utilize your APIs in that distributed environment without having to dig around in your code. So this can be really helpful. And then Open Liberty, this is a cloud native runtime that I helped develop at IBM. It's all open source and actually this is where you'll find those interactive guides that I talked about and you can also try them at our booth downstairs. It's all free and if you have improvements please let us know because it's all open source. So make an issue or create a PR either way, we'd love to hear from you on what you think of our guides and our documentation. But as well as that, we are at the Linux Foundation. So this is one of the sponsors of the event. So there are tons of different tools I just wanted to highlight that you can go to the Linux Foundation website and look at the various different open source projects that you can utilize when it comes to creating cloud native apps. So I do encourage you to try some of these technologies yourselves when you're considering what you're going to be using to design your application. So for example, as I mentioned, we have these interactive guides. So the nice thing about this is that you don't actually have to have anything downloaded locally on your own machine. This is all running in an IBM cloud environment using a Thea IDE. So it's got the IDE, the terminal and the instructions all in there ready to go. And you can just take our GitHub projects and install them in there and play around. And you can access them all at the Open Liberty website slash guides. And have a go there. We've got like over 57 or something on different technologies. So definitely check them out if you're interested. And as if I haven't given you enough links already because everyone loves homework. If you are really interested in this topic, I've put some useful links here just going around various different elements like an overview of cloud native, how to modernize applications if you've got more of a brown field, things like microservices, how to choose the right runtime and just a fun video at the end on containers and cells that I did if you're interested. So with that, hopefully what I've shown you is sort of the various different elements to consider when we're trying to create really truly cloud native applications that thrive in that environment and how we can maybe look to nature to be able to inspire us and sort of conceptualize what can be quite abstract concepts in a more physical way and relate it to things that we know already. So hopefully I've given you guys something to ponder on, something to think about and maybe something to investigate for your own applications. Thanks very much for listening. I've got about, what, three minutes for questions. So if anyone has a question now, I'll take it. But otherwise, you can find me on Twitter at Grace Jansen 27. I'm more than happy to chat to you on there or afterwards at the booth downstairs or just to the side of the room here. Thanks very much.