Welcome everybody. Thanks for being here. I'm so happy you all come able to join. Today we're going to discuss a little bit building resilient application. How you can implementing an exaggerated architecture in serverless application with Python. My name is Hazel Sainz. I'm a solution architect and I am an AWS community builder in the serverless category. Okay, today I want to share a little bit. In this session we're going to go deep a little bit about what is an exagonal architecture, where are the use case that you can apply to them? And most of all, what is the story behind how I learned to design this application implementing it. This is a story about how I learned to design resilience application as a rock star. Yeah, it sounds awesome, but it's actually a fact. I start developing software for some years now and in the beginning all that I do was designing applications, thinking always as a monolith because that was the technology back then. So the main focus when I have a problem, I try to design everything in a specific server. With the times go by, I changed that and I started to implement it by using layers. So I started creating my web server, my application server, my database server and so on. And that was a good architecture about that time. But everything is progressing and everything. We're moving forward and new technologies all days come along. So I learned how to design in a different approach. Most of all because when I started to building in cloud, I realized that that approach in some cases we can still using it, but it's not the same effective that had before because now it is a little bit expensive if we do it that way. So with that said, I changed my mind and I started to think differently. And this is what all this session and this architecture is about. We need to start things differently. We need to start think not only at the server level, we need to go deep and change the way that we design our code. Through the time we used to have different type of how to split the code and we have a lot of patterns out there that we can use. We have something like MBC and I already did that too. And when we have like a microservice, that is a good approach. But when you come a little bit more into the serverless world, you will see that sometimes it's been a little hard to maintain. So let's go move forward. Let's talk about hexagonal architecture. Okay, let's go move forward. For start, let's talk about what is an hexagonal architecture. The concept says that hexagonal architecture is a pattern that promotes the separation of code logic of an application from its external interactions. Think about your application as a signal. Each side of the hexagon represents a port that interacts with the outside world to the an adapter. But let's take a passenger. The first ectagonal that this architecture represents is the domain in here. The main target of this section is that all the domain logic, that means all the business logic involved in your application goes. But we're going to have a new approach. So after that we're going to have an outside exagonal that's called ports. And this port we're going to use it AWS like a communication between our domain logic, the adapters and what is the adapters about. The adapters is all the different components that application needs and why this is a good approach and why we should even consider it when we have the domain part in this middle and in the center. That means that you can adapt that device. We call these adapters, you can adapt different inputs, you can adapt different inputs and use the same domain logic. So what happened? If I need to change one of these inputs, I need to change this one for example. I just can add a new one and remove this. But all the main logic, all the business logic will be remain stacked. So that's why Excel and architecture is a good idea. But we have another concept in here. In the beginning I just mentioned that in my journey I started with monolith application, then with a resilient applications, and now we're moving forward to serverless architecture. And in serverless architecture we all know about what is the good to develop in this kind of architecture, what is that? So we'll forget about handling the servers because in the past, every time we develop someone we need to know that disabled was ready, then every disabled was patched and everything. So in this scenario, in this architecture, we forget about that and that's, that's something important. The other thing that we forget about it is that we don't have to worry about if our architecture, we're going to grow as we need it. We forget about that. Why? Because fabulous architecture offers that. So that's why we want to go there. And one use case that is really common is that I can have a combination of a full application in serverless architecture itself. I can have a front end and I can design all my back end using a serverless architecture using different servers and so on. Today we're going to see like a basic application with serverless. What is that? I have an API gateway. I have an API gateway with an interface. So what are the benefits of using an external architecture? If you tried this approach, one of them will be then we enhance the testability. Why? Because the business logic is the couple from the external component. So that make it easy to make your test cases to use only the business logic. You can use mock adapters to your port directly from here and just test specifically that functionality and you isolate your unit testing. That's pretty awesome. What else? Well, you add flexibility into the development and deployment. What happened if you want to shift a monolith database to a microservice? Or perhaps you use user interface change like the mobile for web, or you change the way you connect. That can be easily done by using the adapter. Like I mentioned before, what is the last benefit of using a stagnant architecture that is so important? The maintenance and the scalability as your application grow. Because let's face it, when we start an application, we think we're going to use it right now. But you don't think a lot about what's going to happen in the future. But with this architecture, your code is ready to grow. So aws your application grow, maintain and clean. The separation between the color logic, the external interfaces, easy that you can scale or you can update the parts of the system. Like I mentioned before, you can change what is the adapter that you're going to use. You need to make a change specifically to the business logic. You know exactly where you have to head up. So that's why it's so important and that's one of the benefits that you can have. But just let's go a little bit more deep into the future of the application. So let's talk about serverless architecture. And serverless architecture promotes the idea of building application as a collection of functions that responds to events. That is the concept, right? So this model complements the hexagonal architecture. Why? Because if you remember the hexagonal architecture, its main complaint, the main target is to the separation of concerned. And using functions like lambda function, you go in the same direction, right? So let's talk about a basic API. In here I get the diagram of an API that is connected with a lambda function and this lambda function. Use dynamodb to storage and use simple email notification to send emails to the customer. And in this session we're going to discuss an example that is really simple. It's like create a new user. And when you create that new user sends an email automatically say, okay, welcome, I'm here. That's why I print this diagram in this point of view of this session. But something that is important, like I said, is that the serverless architecture is promote the same idea. This completely separate the functionalities. So that's why hexagonal architecture with serverless it's a good idea. But let's talk about why. Why is the perfect mix? What is that such good idea? So if we remind the concept an exciting architecture offers interchangeability, it help us to separate. Let's talk about a little bit more about that. Why is a perfect. The excel in architectures offer us that is denturchability. That means we have adapters that make easy to change our application interact with the outside world that help us to facilitating testing and the evolution of the support, right? What else? We have simplicity despite of the complex name around it. The exam architecture simplified the application development and maintenance because clearly separate the responsibilities of each functionality and we have the separation of concerns. By keeping the application core logic isolated, developers can focus on the business rules without getting struggle with the external dependencies. It's more easy to think about my business logic without exactly know what adapters we're going to use. I can use the adapter, but I actually don't know what is beneath that. So I can say I'm going to save it in the database, but I don't care what database is because me as the business logic responsible, I only say, okay, this is the record, send it to the database. About serverless. Serverless is an even driving architecture. And what is that is run by Evans. That means everything's come up with an event. If an event occurs, something's going to happen. So this is important because it's treating every interaction with the outside world through events. And remember that in our exaggerate architecture we have this adapter. So what is the main merging here is that every time you have an event, you will use an adapter to actually go and play with your business logic. So that's why it's important. And we have something else. We have something that is called decoupling. Just as a serverless function did decouple from the underlying infrastructure, hexagonal architecture decoupled the application logic. So serverless we have the separation and the decoupling between different functions exaggerate architecture separate even more inside our function. And what happened when we have all these benefits together? Well, we create a resilient and easy maintained application. I know that sounds awesome, right? It sounds like magic. Okay, we're going to have everything separate, all the code is working and do it exactly what we need to do and everything sounds good. So why that's that image. So we have to remember something. With a great power comes a greater responsibility. And that's why I use Spiderman. When you use an exaggerated architecture and you use serverless application, the main responsibility is how you design resilient applications. It is your responsibility to actually split and separate the concern in a proper way. You need to separate in function in the most effective way and inside the function you have to think about the defined. So in the developer world, I saw some cases in the past that when they ask you to do some change, you just go directly to the code and start writing about all what do you need to be done in there? When you use an exaggerated architecture and you use serverless, you have the same requirement, but you need to step down and say, okay, let's design, let's think about how we're going to split the code, how we're going to split in each different function and how it's going to be split it inside the function. So that's why you have a big responsibility as a developer. Implementing an external architecture is not always easy because we have a lot of developers in our team sometimes and it's hard, the process to try to maintain that separation between the requirements is done and then all that transformed to the code. So it is difficult, it's not impossible. You can do it. There are many techniques that you can use, but as a developer you need to be aware that the responsibility when you have this kind of design of these patterns and these architectures is important that you to follow because if you don't, you're going to have mass in there. That's why it's great responsibility. Okay? So after we know all the benefits, all the things that we need to keep in mind and the awareness about when we should use it and when not to use it, let's talk about how we implementing a machine learning architecture, let's put it together to start it. We have a lambda function. Inside the lambda function, we're going to have our exaggerate architecture, okay, that means only the first diagram we put inside the lambda function. But what actually we're going to do. So we're going to have a new adapter, we're going to have a port and that port is going to communicate with the adapter and the adapter, we're going to be in charge of saving the record that being that inside our lambda function, we're going to have the domain part separate from the ports in the adapters, right? We're going to use another adapter and that is to notified and send an email about okay, welcome to the system, remember, so that's why we're going to have a second adapter and we're going to use another one to just connect the app gateway through our application. In some cases in the serverless architecture we're going to have directly the code access adapter and in other ones like it's serverless, we're going to have Evans. That is going to be the trigger for our solution. This is the case for the integration with Apikate win and lambda. Right. And what else we mentioned about the benefits they're going to have to using this architecture, we're going to have the unit testing that the unit testing can be focused into the domain and we're going to have the integration testing. So if you see this diagram, it's really clear what is the separation is happening and why it's important to keep absolutely everything. So we have the domain, all the business logic inside domains part in the first executive we're going to have the port and we're going to have the adapters. Then here we're going to have the communication with the other services, in this case dynamodb and San let's dive in into code. Let's dive into the code. So I have lambda function here and the main difference is that this is my domain of the core of the lambda. This is my handler. And in here the only thing that I have is the business logic. If you see in here, I don't have any logic specifically that use the database or anything else. Only I received the information and then I use this, I implement the adapter for save a user. This is the adapter that manage all the data information. And I have another function here that is in charge to send the email. So this is implemented in another adapter. So the code for each adapter is separate. So I have this one, this is the first one. And in here it contains all the logic related the database. In this case I'm using dynamodb. So I have the definition, the table name, the data that I need to insert into the and I have the return that is returning the user id. Okay, and this is my adapter. I have another adapter that is in charge to send the email and this contains the logic specifically for the implementation of SES. So I have the email sent in here, I have the source, this is an email account that I create just for this session, the address that I'm going to send the email and I have the body message that is going to put in the email to stuff. So how can I trust it? What is the beauty of this is that let's say for example in the future I need to change the database and not use dynamodb and change it for let's say Aurora. Okay. If I'm going to change that, the only thing that I need to change is the adapter and I don't have to change any logic into the business side. The core logic remain the same. If I need to add a new logic related to the business, the only thing that I need to change is the core of this function. So the separation of the concerns is really important because allowed me to grow in the future without impact each other. And I don't have this spaghetti code and I used to have in the other architectures or patterns that I use them before. So let's test this. So if you see here, I create a test case. This is really simple that I have the name, this is my payload, the email that I'm going to send it. I'm going to say hi, I just say Monday night. Okay, I have the email and I just click send with this change. I'm going to check Edith is really receiving it. So give me a minute, I will try to show you that. Okay. So if I go my email here, I did receive the email and I have this thing, the message. So I say thank you for signing up, we're excited to have you on board. So this is great because it is working and if I need to change in the future then I don't need an email, I need an sms. I can do it just to adding a new adapter in here or redefine my adapter. I can remove this and add a new one that only contains the main logic of the new step that I'm going to implementing. So it's really easy and it's not something that is going to take you a lot of time, but it is important to take the time to analyze design this structure in the beginning when you're creating your functions. Why? Because you're going to save it to yourself in the future. When you try to give maintenance into this code, you will be able to remove some logic easily, you will be able to add a new adapters and even you will have less trouble to try to make a knowledge transfer to new developers and so on. So your team will appreciate us. Okay. If you see it's really simple, please make a habit to design your function before turning decoding and let's try to create the more resilient application that we can, and Xavier architecture allow us to do that. Okay. So if you like that little demo, you can try to do it yourself and play around it, change a little bit the logic, change the adapters and you can play with the code. So how you can do it, you can scan this code and you can go and read my article about it. So you're going to have a copy of the code in there so you can put it directly into your console and play a little bit with it and have fun. And just to finish here, I would love to share a phrase with you. This is from Harry Potter. I am a huge fan of the saga. So this is the sentence, it is our choices, Hari, that shows what we truly are, far more than our abilities. Because in this architecture and this design, all is about the choices, all is about your decision and building a resilient application. It depends from you. Thank you for joining me. It was a pleasure to me to be with all of you today. I leave you here my social media. Please follow me. I give all around the world and also write technical content. So if you're interested about knowing a little bit more about serverless, a little bit more about AWS and another things about programming and development and deployment. Nice to see you and thank you for watching.