Video details

How to migrate an existing application to serverless - Marcia Villalba


Marcia Villalba

You want to migrate your existing application to serverless and you don’t know where to start. This is a common problem that a lot of the architects, CTOs and developers have, as it is very rare that we start a project from a Greenfield.
In this talk I will walk you through different strategies to migrate an existing application to serverless. We will look at known architectures existing challenges in applications and how we can overcome them with serverless. And also I will share what I learnt when I worked on the migration of one existing micro services application into serverless.
Check out our links below, and don't miss our next conference!


Hello, everybody, and welcome to this session on how to migrate an existing application to several lists. My name is Mastery's Celera and I will start with just three. If Mike Gallagher works. So this story is my first encounter with Serverless. It was around five years ago and I was working in this company where we were doing a story similar to Netflix, but for Krypton's. The difference with Netflix is that they have a subscription model and we were monetizing with advertisement. But it was existing already for many years. And by that time, we had six BMB. So kids loved their cartoons and they binge on them like crazy. So costs were very important for us. It was beginning of summer and we got a call from the boss boss telling us that our service was too expensive. That was the dread, this call. We always afraid of that call because if our service was too expensive to operate, that means that they will shut you down. But the boss said that we have some chances to make it through if we re architect our application, if we find a solution. We were free. But can developers in that project? This application less cloud native Soad was born in the cloud and was designed with the microcircuits idea in mind by the time of the life of the application. It turned to be free many monoliths because every time we were adding something, we were too lazy to create a new microsurgery. Something happens when you don't have a good ultimate that way of creating micro services that you keep on adding things in existing services because it's easier. So we have these free little monoliths in the cloud who are free, but can developers very challa experience but very who made to make beginners cloud. We didn't know anything about cloud economics on how the cloud works. We have some basics. We could start any instance of the basic things. But we don't understand that there are six things. So we started thinking, OK. Our application is expensive. So let's make changes that we knew can help the project. But we focus on the code changes. So we make the code more perform monthly at caches in our application. We did a lot of things. We did a lot of things, but nothing that help. Later, we got an e-mail from the boss saying that these were still expensive. No matter what we did didn't help. We were like super worried. So we asked her to please give us a breakdown of all the costs so we can start analyzing what the expensive means, because sometimes you just start doing things without really having all the information. Actually, we were so surprised that it took us a long time to get that report back because it was not that easy information to access the cost of an application. You must burliest. You knew that in many different places. But finally, we got it. And by looking at the report, we find that the cost of our application were two big problems. The first one was that we were really not thinking about how the clock work we were doing, like sending a lot of data from the that the centers to our customers. So if you don't know in the cloud, you are charged for all the data that you take out from the cloud. So you have to be very cautious and take a lot of precautions when you are pulling data from your data centers or regions of the songs, whatever is called in your cloud of choice to your customer. So for that, there is many solutions that you can reduce the cost and the latency. But we are not putting anything in place. We are sending our videos, our images, our even metal. They thought everything was coming directly from our sidewards. And the second problem is that we were using a lot of services that were created by our company many years ago. So this company was born in the cloud, but in the very beginnings of the cloud, when the cloud didn't have almost any minute services, it only had like the foundational services. So with time inside the company, we start building a lot of services that we were using, like authentication, our own databases, no squalled at the races. Configuration services use whatever you can imagine. We build them in-house. But with time, our precious migrate out from the Ekho services to something managed by the cloud by third parties. But we were so little people, we never migrate out. So a lot of the internal services were shut up for us. So we realized that that we needed to do a big reactive picture in our application during that summer. I was playing with lumber lumber that was coming out maybe like six months ago, and I was just deploying land and played with a Cervalis framework and doing like little things here and there. And I was so excited of what Cervalis had to promise. I went to my manager and said, let's do architecture like green architecture, everything in several less. And my my Nashwa manager was so overwhelmed that you say, well, whatever, do whatever you want. And that's our spark in the ciani of Sarah Atlas. So I want to take you in these talk in our migration story. It was not the most successful one. I will also take you in other more successful stories for migration. This has been five years already. So a lot of weather has gone under the bridge. A lot of things have changed. But I think. I have learned a lot, not only from my experience of migrating several applications, but from hearing so many customers and really discussing these things outloud. First, I want to introduce myself. I said I myself, I work for eight years as a developer advocate. I'm sure the company like seven months ago. So it's not something I've been doing forever, but I'd be coding forever. So that's something I can I can tell you I've been doing forever. I want to have a YouTube channel where I post videos on several less and cloud computing. There is over 200 videos on these topics with tutorials very hands on size. You want to learn. I recommend you to go to this link and check it out. This is not going to be a very hands on talk. But if you want to Torrijos and how to get started. That's your place. So I want to start this talk with a definition of serverless, a machine. A lot of you already have an idea what Severals is, but I think it's good that we are all in the same page. So Serverless is a middle sheet for planning, building and deploying software in a way that maximizes value by minimizing undifferentiated heavy lifting. This was said by Jeremy Bailey that he's one of the oldest several US heroes. He's our influencer in the area of several us. If you don't know him and you're interested in Cervalis, he's a great guy to follow. He has a newsletter and a podcast with a lot of information out on several lists. But basically what he says here is that the mindset of not reinventing the wheel. We want to bring the most value to our stakeholders. And that's what is Old Serverless about. Also, Derek, Djordje, another influence are in the several, as Elsworth said, that when you're thinking of several less, you have to think of this way. The first, if the platform has it. Use it if the market has it right. If you can reconsider your requirements, do it to us up to whatever is in the platform or in the market some days. There is applications, of course, 80 percent of your functionalities, and that's like the most important part of your functionalities. And you can live with that. Without that 20 percent, you don't need it. So thinking of other requirements help a lot. And then if you have to build it, own it, have good practices of coding and take it to the end with the best quality that you get. So let's do a little bit more like concrete example on several less because, well, it's a middle class. She's very broad. So I want to talk a little bit what it means to a component, a service, something to be several. Basically, it has to. There is four criteria. The first one is that this case automatically meaning that you don't need to worry about scaling. You can just put your right side in a serverless components, different severals components. Go to sleep on your marketing team can make it viral in Korea while you're sleeping on, you know, handle it. Sure. They're not all unicorns and rainbows. There is limits. There's always these limits that you need to know. But there are a lot of them are soft limits that you can increase by just calling support. Others are hard limits. If you're really using a lot of these services. But in general is quite flexible. The second criteria is you pay for your use. This is something that comes from the cloud word. Like since the cloud has been out. We have been used to this concept that you pay us uses like utilities, your pay your electricity or your water or your W.S. bill is another utility in your everyday. Use it and you pay the. The next one is no mention of infrastructure. And here is a little bit different from the cloud, because a lot of the cloud offering is about retail infrastructure, where we get servers with abuse and memories and hard drives, and we need to know how many requests and inputs and outputs and so much things that when we are working with several lists, we don't need to know when we will. I think the most kind of CYA Sudbury thing that you need to do when you're working with LAMDA, for example, I will talk about Lamba in a second, but is them function as a service offering for Metalious is to decide how much memory you want to give. And that's very linked to performance. What is that's the only kind of infrastructure idea that you have to have, but you don't need to worry about it. It's totally obstructed for you. There are Severson Serverless as they are wires in wireless, but you don't have to worry about their obstructive. And finally, the high availability building. And I think this is something super important as well in the cloud. You might not have that by default. For example, if you're working with says, you will need to citing which availability sorry, you are deploying that instance. But when you're working with Severals, the service will work in the region and you don't need to worry about if one available to the SOS goes down for any reason, then it will schuss that are available to the sun, will take over and everything should be fine. So those are the four criteria for something to several. Serverless comes into play worse. What we call functions and service. And then back in this a service function as a service is things like lambed that cloud functions here, functions and things like that. A lot of them, most of the cloud has an offering and also there is some open source offerings. London was like the first one to bid. It came like five and a half years ago or Remen. And it's kind of disrupted the whole ecosystem. And the name Cervalis started out this disruption. I don't know if it's a good or bad name. If you go inside the Cervalis community, there is so much debate on the name. We do some more people. We hate naming things. And I think this was name with market. But that's another discussion. What I meant is that the Phoenician of land that to define back functions as our present thing is a good definition to look at. This is what is in the Web page and it says it will Yeslam that lets you run code without provisioning or mashing servers. Just upload your code. A love that takes care of everything required to run and scale your code with high availability. This two paragraph is basically what we just saw in the criteria's. The difference is that is a function as a service and the difference between a traditional application that is running in a server is that you can trigger that F function from somewhere else. So basically how it works, you work, you typed your function, you deployed in there. I don't do this lambda platform, for example. You can. It works more or less the same in all the providers. And then your function is Idol is not executing until something triggers. And what Country Gardot function? Well, many things can trigger that function. It can be a change in the that the state I record in the device changed. An object was added in your storage, a message in a Q whatever you mention in the state can trigger it to function also on your request HTP request and things like that. Also changes in the states in your application. Say somebody click on both on somebody did something come triggered it and then the functions come in whatever language. As you can imagine, the most popular run times are supported by us out of the box. If you have some runtime that is not supported, you can always bring your own with our support for custom run times. And then these functions start executing and what you can do with it. Basically, anything that you can do with a normal application, the limitation is that it will run for fifteen minutes. That's kind of the biggest limitation compared to traditional application. But you can call it all your services with no problem. You can do HTP request if you want. Calling something in the Internet you can do. I don't know. Business Lussick whatever you mushahid you can do it there. And then we have the other part that is the minor services of the makins as a service. And these are the services that will help you to not reinvent the wheel. So you need us at the base. I know school at the race, key value pair. You sign them all you need. Oh, shucks. Stretch is a story. You need a cue. You ask us. There is not only from a total. Yes. You need an authentication service, for example. You can use or zero or you need a number that the base you can use mobile the atlas. There is so many outside there. And these are like the parts that are not really giving value to you unless your Mongul or your O0, but are making about the base percent. But but if you're in the business of distributing video that we were as we were, this is we don't need to be an hour, a minute hour on that basis is a waste of time and a waste of human resources. So using these services in our application, these are services that fulfill the four criteria for Cervalis components, an S3 anything is the best example as free is stretch. Basically the one of the oldest services from a toll. Yes, use just a store object in there and it's extremely serverless. So we will having Cervalis components since day one off the cloud. So it's a sketch automatically. Nobody ever thought about how many requests you get into your history. It just works. You don't have to manage Infrastructure S3. Who knows where to start? And how many it has been updated and puch and whatever since it was launched in 2006. You know how to pay as you go, and I think this is kind of an interesting example, if we compare with other storage solutions that we are used to like a cloud or drive or Dropbox, that we have to buy like a hundred gigabytes with us. Ray, you just put one fine. That is one million. You pay for one mail or you put petabytes per day and you pay at the price per day. You don't have to commit. You pay for as much as use. And finally, we have the high availability that S3 has in the region. Very high, high availability. So now we are on the same page. All of us. But if we are. Thinking about these, what I just told you about several hours is way more than I knew by the time I was working on this project. So I told my manager I wanted to go to some rallies, but I basically have deployed for LAMDA, so I didn't know much. And I think these concepts were not that polished by then that nobody could explain that to me. There was a lot of benefits out there, but they were more like sales speech benefits. A lot of things have changed since then. So we were standing there with my team of all my colleagues and my boss, and we were thinking like, OK, we have these problems. We want to use these technologies. We can also use these other technologies. We didn't limit it only to several less. So let's try to think a little bit. So we were in this part of the migration, were cautious thinking we did a Schempp on coding something because it's the best way to go. So the first uncertainty that we had to handle is the lack of technology knowledge. So we went to several less. Yes. So now what? Who knows? Odds are released five years ago, there was no YouTube channels. There were no courses, there were no cloud gurus. There was no in Oaxaca things offering several less. There was nothing like what we are used today. So training for learning serverless, it was hard. So my boss told me, well, we don't have a lot of money, but we can find a consultant that has done some little symbolist projects and has a lot of experience with services. Well, yes. And he so that he could come only four hours a week so he could not see to read off the whole week. We need to do the best that we could for those four hours. So this guy came to our pressure. He was amazing, he was, I think, one of my first influences in what it means to the Cervalis applications and what it means to make good quality and distribute that system. We started our workshops first working like a classroom. He was teaching us in the black. In the black were like, yes, this is our release and this is what to do. And as the months progressed, it changed into something that we were doing a Molefe programming. We were all coding together into very interesting discussions where he was learning from our solutions. I think this is a great way to train the team, the three of us, all the backend developers in the team were pressing in those workshops. We were all learning at the same time. And the cool thing is that older developers in our team has very different strengths. I was very focused on the full stack of development with the client work. My friend knew really well the business and all the business logic, all the crazy algorithms, and my other friend was all into their valves and how to reply. These have distribute this application and together, when we start learning all these things with different bits and pieces and we make it work really well and anything think this is a good learning from whenever you are going to the migration that everybody in the team should get involved early on. Their education should be very democratized early on so everybody can feel that they are welcoming their migration and they can commit to it. And the next part I'll send that day that we had was is this whatever we were thinking, Cervalis will. So our problem. We didn't know we have this great crazy idea that Serverless was amazing. The marketing brusher looks great. But will it really work? So what we did is we have these two problems and we started looking at them in more detail. OK. We want to transfer to media and we want to transfer the date that we want to transfer. And we want to replace our authentication. We want to replace our various ones to replace our Qs. And we start looking at all the different things that we need to do. And then we start writing hypotheses somehow. These set are really solutions could help. So, OK, we want to replace our existing reac tables using Dynamo TV. Is that a honeypot? This is. And then we wrote I mean, who will buy our product? Trying to solve that problem. And the cool thing of doing these exercises by the end of this exercise, we have like nine minimal buyer projects that we keep on improving all the time. And then we find something that work. And the cool thing was, is that we learned so much real practice. Cervalis thinks that by just writing these MBBS with no kind of pressure of having to deploy this code to production, it was a great way to see real problems. So in this new way of thinking and it help us a lot. So now we are ready. We have our. We know that this technology can help us. We have a hole where I put this is we know work to focus. We know what the problems that we need to solve. So. The next step is to work on our foundational work. You our migration, I have to be honest. We did some thought about this foundational work of a thing. We didn't have many options when we were doing our migration. The amount of tools and things around for several us were very limited. But thing nowadays, there's so much variety of things that you can take and decisions that you can do that these two step is very crucial. So the first thing you have to have in mind is the cone white law that go way law states that any organization that the science system will inevitably produce, other son who's a structure is a copy of their organization communications structure. Maybe we are familiar with this thing, but basically, if you have one victim, you will make a nice monolith, divide everybody in teams and you might have a microcircuits. And that's basically the reverse of what, manure and structure organization too much. So far you would like to believe. And this is something I wouldn't have thought in retrospect when I was making this a slice that we did in our small team of redevelop race, really naturally. Everybody took on many different micro services that we wanted to build, and we took the leadership and we were very that we took to free each and all of us at different micro services so we could not be lazy. I put everything in one. So it can work. But in bigger teams, you might need to do bigger structures. And if you're working in the Amazon way, how to be stupid subthemes that are at teams that are big, as big as you can feed with two American pizza. So if you have a lot of hungry developers, it will be a very small thing. If your developers, it less can go up farther. Ready to run. Ten, seven, twelve, fifteen. I don't know. Somewhere they are small things where the communication flows fast and you don't have a lot of overload. And after you have decided on your pin structure, now you have to pick your tools. And here you have to pick your programming language, just your deployment framework, your developer tools. We pick no chess, our list framework. We don't have many options. Our original version was in Java. But tell us a board. By that time was not really good for several us. So we had to go to Dallas creep. There was support for Python, but most of the libraries were still a node. So that's how we choose our language. But nowadays you have so many options and you can even choose in one project to have a language. I've never had another one that's up to your team, but do an educated decision and not just let the perfect Menasha decide whatever they want because they like the language. And the same for deployment frameworks, some frameworks, what's best for some particular use cases and others word risk for others. So choose the right one for the exact first shift and that will make your life easier. Another important thing that you need to start thinking of is infrastructure Spode, and this is something that you have to think of day one. We're so lucky that this person that came to help us was a freaking fanatic of infrastructure as code. And you only learn severals through writing cloud formation in my son. Horrible. But I think that's the best way to learn something to do with the right way the first time, because you cannot write production code from the console, at least not for several US applications. You will have to write millions of functions and all kinds of resources. So you have to think about it as infrastructure, as Cody will minimize your risk of bugs and you will be able to deploy these same infrastructure in multiple environments. It makes your life so much easier. For example, we had CSC Pipeline with three for Environment that was in three different NWS accounts and we were just deploying the same infrastructure with just different variables, environmental variables to each of the counts. And it was great. We didn't need to stress about it. So and also, if you follow this path, then your code on your infrastructure can be very close together. I like this a personal thing and everybody may have a different opinion, but I like to put my infrastructure in the same person in the same Yakup brush as my code. And then everything lives together. So when I deployed my functions, they deployed my infrastructure. They deployed a code in the functions. Everything comes together and it makes my life so much easier. And I think you have to have from day one is a CIC pipeline. This is something you can use. If you are migrating, then you might have already one in place. Nowadays, a lot of them support serverless components. So you just need to check if it supports the things that you want. Others might not. Then inside everybody in every cloud provider, you will find tools to help you to SkyCity. So that's super important to create an automated pipeline for everyone tried to be as automated as possible. So you can see your code. The last time you do that, give and commit to whatever rent and then the rest goes out domestically and Newlon seat until it goes to production. It makes your workflow so much more efficient than if you have a lot of manual steps in the middle. And the last thing and this is something we didn't do. And just like every time and think about this, how we didn't do it. I think we didn't do it because there was no tools around. Is the monitoring an observability? Nowadays, there are so many tools for doing monitoring and observability. There is tools, internals to their different cloud providers that will give you something. There is a lot of external tools. There is a lot of tools that you're already using in your existing non serverless projects that have support for several components. So it's not excuse not to have a good monitoring and survivability setup. And this is critical because your application is extremely distributed. That is very hard to do. It's very hard to know where thinks what is happening. It's like herding cats. So if you don't have a good monitoring observability system in place where you can enable tracing and you can start seeing the traces flow inside of your distributers application, and you can start getting familiar on how to split and divide these applications on the monitoring tool. Then the day that you're going to protection, you're going to suffer. And we did because we didn't have these. Good. Now we are really to migrate. Until this point, we have not done anything other homework. So it's good to get to the point of the migration stress that she's presented three. The first one is crap. So when we did, the second one is crap, but it's useful sometimes. And the third one is the one that we are going to focus. So let's start with the first one. The first one is the strategy. Number one is the big rewrite. And the only reason I'm presenting this is because we did it. I don't know why we needed anything, because we were naive. We were afraid of deploying something to the cloud. And also because there were not a lot of tools that allow us to have a mixed system in place. Nonetheless, there is so but because of many reasons we end up going this road and this road was a painful road. It was very happy, happy joy. Joy, at the beginning we started. No pressure. Yeah. Let's go check a ticket. Months passes and nothing has gone to production. You have not tested your foundational work. You don't know if what you're doing is really solving anything. And then seven, eight, nine months down the road, the production day comes. And it's the longest week, month ear of your life, depending on how long it takes you to migrate. It will. You will cry. You will suffer. You will notice all the bugs that you have then. Seven months ago when you coded this thing, that doesn't make any sense right now. You will realize all the things that you've forgotten in your foundational work. You will be tired and motivated. No, don't go this way unless you are writing a very small version. But if you have a big project, though, the second set, this is the monoliths function. And this is something I don't recommend. But there is many examples of the monolith function work in to day interaction. What it means is that you have one big fat function. You grab your existing application and you put it inside along the function. If you love the function is not big enough because you have a very big application. You can use container several less containers like bar gates, for example, or other. Ofri. And this is only good. I would say if you have your application on Prem or in another cloud provider and you want to ring it to the cloud that you want to you then migration to because this step number free, you need to have that code in the cloud. Right. So that's the only reason why I would say that this is like step zero in my next issue, that I'm going to look, if you want to do this, there is some tools here that will help you. Tools for No. Ge'ez, two for Dumar. And if you're using some languages, I'm pretty sure you can find tools as well for that. So now let's move to strategy number three. That is the one that I want to spend their half of my presentation looking at is the strangler pattern, meaning that you have a monolith and you start business out of it like services until you have a very tiny monolith or you have no money at all. Not only means that you take of services, it means that you break the your eyes and you write about it. So it's quite a dramatic break. But go in stapes. So now I want to give you five steps to migrate a service out of this monolith. For that, I want to start with some kind of example application that I might use like three times, so it's not something that you need to bail out the attention, but this is like a typical inventory monisha application, a big monolith or another big but kind of hosting the cloud with three layers of authentication. The inventory Menasha customer monisha orders Monisha, business logic in the middle and then a layer for accessing the database. And then we have a no squelches otherwise. And this is the first step that we need to do is find the seams in the code, the bonded context, the packages, the modules and things like that. So this is something that is super important to do when you have a monolith tidy up. The thing here is that there is many ways to tidy up a monolith. You might have already a very tidy 183 thing in packages or modules in our JavaScript or whatever language you like. But. I think here is very strategic to think how big your micro services you want them to be. I like one quote from some new man, she was speaking before me in another room. He said that micro services should be rewritten in two weeks. And she sent her dad some years ago. I really like that idea. I've been working with my micro services to be big. So then here, when you're finding the bounded context in your code, you want them to be as big as you can write in two weeks. So this will make your struggling pattern very ashamed, very fast. So this is something to have in mind when you're making this package as those modules that they are small to be retreating into. So your application would look something like these orders, customers items, blah, blah, blah. Nothing much. No. Still a nice model. So now we have a tidy monolith and we need to break that, the base layer. And now we need to organize the data here. We will need to make some architectural decisions because we need to break that repository layer into small bits, one for each of the micro services that we have decide in the step before. So we might end up with a lot of repository packages. And here are the first architectural decisions that you will need to do is to give owners to each of the tables. And that sells quite crazy because in some point you might need to decide who owns what table. And you might need to. You might want to replicate the data because it doesn't make sense to have very complex calls and queries into one service or not. So it's easier just to replicate them because now we cannot do shine's of tables that are not in the same package. And this sounds stupid or confusing, but it's important for making our migration easier in the next steps. So here we also have to have in mind that we might need to do two trips to that the base to get a query from feel. So if we want to get, for example, all the customer orders with the detail referrers may need to go to the customers, get all the order IBS for that particular customer, and then we need to go to the order server service and get all the order details for each of those orders ideas that we got from the previous query and then we can shine them together. So this is something that you will need to do, but it will help you a lot in your next steps. So now we have a tidy monolith and it's kind of ready for immigration. The next step is to choose what you are on to make right first, and then we will rebuild that beat that you decide into a Cervalis component and you will end up with something that looks very nice, like. So where to start? Start this one. Start with the least important part of your system. That sounds nice. Get some experience and then you get some experience and you're still migrating the last part of your system. Things start changing and you're like, oh, my God. Maybe that's the right one. So they should choose Thar with a part of the system that has the highest return of the invested time. Sara, with the heart problems. That's just nice. But maybe you want to test your foundation or work or get some experience. So my suggestion is start with the latest critical part of your system. Two, two, three, four, five iterations services out. That's your foundational work. Get experience, get motivated, get pumped up, try on a play and improve and write writing foundational work and iterate and make it better until you're ready to mow. The most critical part of your application and then have a plan and ready to go. So now I cannot tell you how to react. They hold your applications into Serverless because that's will take me forever. And I don't know. Every application is unique. So I can tell you some things that you can make when you're moving to such a list you have in mind that you can just take taking account to get started. So the first thing. And this is something I like, particularly in my experience, I'm building several applications. If you have no Shickel microsurgeons, so you would have a lot of lamda functions that are doing things. And does none of the functions, you have many options to handle them. I like to handle them in the idea of fellowship of Microcircuits of Islam. The functions will belong together. Do something, for example, handle orders or harbor payments, or you can go smaller. It doesn't. They Burnam thing is that all these functions work together. They can talk to one particular another store. Nobody aside from this lumber functions can talk to this particular about the store, so they let the story spread, but do these functions. So it's like a micro services. So everybody that wants to get these, that's a store from outside. Need to make a call. I love the function to the store. And then these are micro service is independently deployed from other logical micro services. So you don't have to think about what is the order or what breaks what. Nothing breaks. Watch. And maybe inside your logical microcircuits, you have lambdas that are depending on the other. So you cannot deploy them independently. So that's something that can happen. And I think it's quite easy to handle. So this is something I like to do. I like to have my logical micro services as one people, for example, one you have Ripple. Would the infrastructure of these logical micro services, all this land us and whatever connectors they're using, what inside this micro service, mischa's and tools and whatever minor services. And also the other ways as well. I can put in there and then everything is deployed altogether in their own CIC pipeline. I like to it like that. But that's one of the ways to do it. There's many others. But this is something that has worked for me very well in all the Cervalis projects I have worked. One concept that I think is important here is that these logical micro services can be rewritten in two weeks. And these thanks very nicely to the idea of the evolutionary architecture that you have where the couple microsurgery says that can be replaced. And they can change. And you can experiment and try things up. For example, we go back to our story. We were coding the solution for sending meta data to our customers. We wrote the whole solution, all the code that November came, rain bands happen and step functions were launch. A step function is a system that will help you to orchestrate multiple lumbar functions. I will talk about that in a moment. But basically we have to throw part of our micro service to thrush and just use the functions. We were able to improve our application by schuss adding a managed service. So that's something it will happen a lot when you're working with several applications of the cloud or third party services will start launching services that solve problems that you have rhythm that are not part of your value offering that you can just replace with those offerings and the evolutionary architectures is a good concept to have in mind of how your services are Vertica couple and modular so you can replace them like level. And then things you have in mind is that Belém does have to be small, simple, and the one thing simple Lambus are secure are you have to give less permissions to them and they perform way better. They're faster to deploy. They have a smaller start. So that's what we want. And you know what they are doing and you can test them very fast. So when we have all this land doing one thing, one thing only, we need to organize them in some way. There is many ways to organize functions or to organize distributed systems. I will be talking about two different partners, but you will find more the most popular. Is there castration pother and the choreography pather castration pattern basically is like Orchestre Monisha that will tell everybody what to do. It knows the status of everybody and it make all the services work together. I like this example, for example. These are each box is an individual function. It does one thing and one thing only. And then we have this orchestrator. But I have not drawn it. But you mentioned like a puppeteer that will get the inputs and outputs and will handle, for example, that in the middle the get order details that will go to the order service and get one order details in parallel. As many times as we have orders and that we orchestrate their server service will help us. We don't need to handle the breading station. And when unhandled when all the function is finished to make the results into one place. If we have a service that takes care of that makes your life so much easier. So that's one Puzder. Then we have the choreography button that is more aligned to one event driven architecture is basically we have all these functions that are waking up to events that are coming when it's an event. I'm ready. Clim has, I don't know, been added and then somebody has to act on that and react. And here one way to do it is that functions react to events at our functions and meet. But that's something that we don't want. We don't want our components to talk to each other. That adds a lot of coupling and that's a mess to our application. So we need some kind of Roder to avoid this mess of producers of events and consumers of events. And it makes our code cleaner and the coupler from each other. So if we change Lambda A, then Lambda B doesn't get a fit that we just need to to change that. That seat. If you're working in the cloud, you will find a lot of these managed services already in place for providing Rotor's, you have Rhoda's one to one like a queue. You put a message to one function and you get it that one with a queue in the middle. It will handle buffering and it will handle the load of the functions it will do out. Lot of work for you. You can have pus pops up one function and an event and then multiple different services will get an event or then have something like an event bus. Somebody put an event and then depending on some kind of rules that was received them as all these are part of an orchestration pattern and they are good again driven components. They will. How did you make your software scale easier? Because these components will of resilience and they will help you to maintain. If you want to change one part of your application, you might not need to change the rest of your application and everything becomes very distributed and a Synchronoss. And that's a thing we want in our distributed systems. Another thing to think when we are thinking about replacing several is migrating to several components is to replace existing functionality with homeowner services. For example, we have an authentication layer that mannus users and rolls and things like that. We can replace that with O0 or cognito and then we don't even code that out. So that's something that is in place as well. Replacing coal kind of things with multiple services, for example, is quite normal to have analytics pipelines. So instead of coding every part of it ourself, because just replacing the whole thing with minor services like Lego parts and vicious glue them together. So when this comes, these means that you need to be very knowledgeable of the cloud that you're choosing when you're moving to several. Sure. It's very easy to get started on writing lambda functions, but the learning curve is very steep when you want to start. You need to know so many minor services to make their decisions. So that's something. If you are planning to move to Serverless, I recommend that you not only educate yourself on the lambda functions, but also educate yourself on what available means. Services are there because they will help you so much in your Ciani to start adopting Serverless. Then we went to the next step, the step for breaking the database. And this is quite simple step we need just to get those tables out and put them in their own that the waste. But here is a good way to start thinking, if that is well, that the base, for example, that we are migrating. It's a good solution. Are we keeping a school? We want to move to no school. I want to move to files. Thank you for how your day. Store. This is a step for that. And the last step is breaking your API here. We need to break the API that is compatible after the migration with our clients. We don't want to change the clients after our migration. And also one thing that is available now and we want because this makes your life so much easier if you use traffic shifting to your new service in a way that is Gruwell. So, for example, there is a load balancers that you can put in front of your new Sirees that will tell you, OK, you can use now 30 percent of that traffic goes to the new service and 70 percent to the all service. And in this way, you confess your new service and not really affect all your users. You can move five percent, one percent. I don't know, depending on the load that you have in your application. So in this way, it makes your migration life ways. So now I want to wrap this up, because when we finish my grading, it took us around eleven months to my grade. It was very painful. And at the end of the day, our person got stealed, canceled. So I wanted to give about a more successful case study. That is the case of Comic Relief. Comic Relief. If you don't know, is it a UK based company that what they do is they take over TV one day with the frame you see shines on humourist people from the very popular people in the UK? If you ever fly with British Airways, you might have seen the ad that they have for security is about comic relief actors. I don't know anybody, but if you are British, maybe you know these guys, what they do, they collect the nations that they and they have the speak of the nation, some 350 their nation specific. Maybe it doesn't sound very big in your head, but remember, donations cannot get lost if you lose other nations. That means that money that is not arriving to some child that may need food or health care. So you don't want to lose any other nation. If somebody donate money, they might not donated again if you lose that transaction. So every other nation is important. You can on duplicate of the nations you donate was you want to collect all the nations in one time. So the scaling becomes a problem. So in 2016, this was their architecture. Basically, they started their migration process more or less in the same time that we started our migration process. They have departmentally and some things they are a was for further. What based on whatever. And the most important service is the donate service. That's the one you need to focus on, because that's the one that needs to handle the other nations. That needs to be very resilient. That's the critical service. That's the most important part of their application. 2017 came and they started doing some changes in their architecture. They migrated to a new version of Drapeau. And there's some body in their architecture team, engineering team decided that maybe they need to re do something new. And what they did, they migrate. One of the least important services that they have into Serverless. And all this kind of fancy getting out from the Drupal monolith into something more molen on an easier to use. So they migrate that this fundraise gallery, that it was just a Nimesh gallery. Do these Nienstedt Melhuish, they validated that. That worked very well. So they pick other services that maybe they were a little bit more important, but not as critical as the night to migrate to this new technology. At the same time, they created some kind of architecture and infrastructure that will support the migration and the creation of new services. They extract the things out from their existing server says, making them smaller and easier. I mean, 2090 know they were very confident on their architecture, on on whatever they were doing with several as we add a node. And now they were ready to migrate that big service that the night service. So they need it. They migrate. It took them a while and got the whole thing up there. Good victories here, if you want to check it out. It's in that link. I will not go into the details, but basically, this is extremely resilient architecture. Everything has a backup. If something fails, something fails somewhat or so. All the nations are patch and nothing gets mease and is a crazy architecture is quite simple. It happens a lot of money. So this is quite at least for me, the first time, and so it was very shocking that costs of running their service during 2015 was eighty four thousand dollars. One day a year. That's just crazy. By not March 2019, the cost of running their service was free. Five thousand four hundred dollars. You still think, wow, that's a lot of money for one day. Now they've run it for one day. They have the availability to donate all Iran because their new architecture allows them to do that. And most of that cost goes to something else because to severals only costs ninety two dollars. That's the cost of running the whole severals infrastructure. They have done it with infrastructure as good and good. But this is so they can rebuild the whole thing if they need it again tomorrow with no stress. So if you went to the night, you can do with only around in this link and there will be helping some some kids that need it. So that's always good. And now I will be doing a little bit closer remarks going for the most important things thing studies infrastructure as code, infrastructure code, infrastructure code that compose your monolith into little micro services that will last for two weeks to write, automate everything, distribute the services are like herding cats. You want to have things that are under control and you can automate. So you don't have headaches when you have to know what is the status of things, asking people it's not an option. Automate everything. Use tools that are standardized across your first Shaikh's. Try to decide on which tools you want and why. And finally, if you want to go through all the steps, lujah, foundational work, move them on to the cloud. Find the seams of your code, your band, the context organizer that the layer move the code to several less break that the base break API and repeat from five to seven until you're done and you're happy. Happy Joy. Joy. And that's it. I will take some questions now on. If we don't have time for more questions, then I'm always active on Twitter. I can reply. They are my messages are always open or having questions. So I will open the slideshow. Let's say. I don't know. Can you see my screen? Now I'm confused. No. OK. I hope you can see my screen. So we have two questions. The first one is, will you choose a serve functions, Overlander, our Parado, us? So what I can tell you about. It's a choreography button. How do you ensure that Lambda functions handles the event successfully? No, no. Lambda will have different mechanisms to handle events. It's important that when you using Lambda that if an an event can be can trigger alarm them multiple times. So it's important that your function is either Potente or however you pronounce that Munish meaning. But if you apply the same function, you always obtain the same result. And the platform will take care of calling the lambda to make sure that the function handles the event. Sometimes you don't get that. And for that, you have this dead letter cues that you can attach to your love, the functions that we collect, all the events. That has not been Hando for some reasons. There were some errors and things like that. So no choreography is not how you ensure that Alanda function handles the event. Use that letter. Q And you use that make any sense that are coming inside the platform? Is there any other questions? So if there is no other questions. Thank you very much. And I will be hanging out around the slack for a while. You can pick me there or then in Twitter at my Twitter user, that is. I don't know. Well, you can find me my them as well. There you find all my information and everything that you could find me online. I'm always happy to answer any questions and have any discussions. So thank you very much. I think we can wrap up this.