 Hello, I'm the last person between you and food, but I'm sure you had enough snacks, so you will be able to concentrate for 40 minutes in my presentation. So I'm here to tell you a story, the story of how we migrate our Java services, the typical services, to serverless. But before that, serverless is a very trendy word, so I want to start by giving an introduction to what it is. Because I imagine a lot of you already using serverless, and maybe a lot of you are using it in production without being aware that you're using serverless components. And maybe some of you don't have a clue what I'm talking about, so I want to start by there. And then I will move to my story. First off, I'm Marcia, I'm a developer at Robio, the creators of Angry Birds. Now I hope everybody knows what Angry Birds is, if you're not aware of what it is, get out from your Tupperware and get into real life. Coding is good, but also showing life is good as well. I'm also an AWS community hero. I'm a community hero because I have a YouTube channel where I post a lot of content about serverless, and AWS managed services, and also all kinds of software engineering practices. So if you want to learn more, you can go and check there. I do videos every week, and mostly very hands-on video. My talk is not going to be very hands-on, so you can go and check more there. On my Twitter handle, I'm very active, so you can get to know a lot of serverless there and what I'm up to. And my slides will be full of birds and pigs, so I hope you like them. So let's start with the first thing. What is serverless? Serverless is two things, and that's what it makes it a little bit confusing. From one side, we have backend as a service that is the oldest thing that is around. I imagine 90% of you might know what S3 is, that is the simple storage service from AWS, and I think that's the first serverless component that was available. So a backend as a service is like a third-party component that you integrate into your application using an API. So for your end user, it's totally seamless. You don't know that you are using somebody else's server or service. And when you connect to those third-party services, you usually have some kind of service agreement, and you don't care, well, you care, but you don't have to manage how the services scale or how things are inside the inner of that service. You just pay for using, and you get a service back. There is many, many different types of component. There is authentication, there is databases, there is analytics, there is things like Firebase that holds everything you need to build a mobile application. So backend as a service is something that is coming not only AWS, Microsoft, and Google, but other companies are also starting to bring a lot of components that you can integrate to your application, so it's growing a lot. And that's a very old concept, as I say. That's maybe 2009. But it was not known as serverless. Serverless is a marketing word. Somebody came out and said, oh, serverless sounds very cool. We can brand everything with it. So there are servers. There are things that are running in servers. So that's the first thing to know. In backend as a service, and in functions as a service. And functions as a service is called to be the next iteration of cloud computing. Why? Because, well, we are running it in somebody else's computer. And I want to go first to explain to you how traditional computers work. I'm sure we all know this. In traditional computers or virtual machines or containers or easy to instance, it's more or less the same idea. You have an operating system that you somehow need to maintain. You have an application that you need to deploy. And you have functions inside the application or methods. Your application does something. And this is a lot of things that we are used to it. For example, when we want to make this application grow, depending on the type of system we are using, we might need to configure beforehand. Okay. On Sundays, we will have our peak request. So maybe we want to have 11 nodes. But on Monday, people are not logging to our system. So we want to have two nodes. So you need to manage all the scalability somehow. And then when you deploy something on Friday, you need to make sure that all the versions, the latest versions will be on the nodes on Sunday. Like, nothing gets, like, lost in the way. And then that way around, you need to scale down. So you need to, in order not to waste resources because your application is running all the time. If the node is up, the application is running and it's consuming a lot of resources. So you need to handle that. Also, when you deploy a function, you need to make sure that it's all around. And it's in all the different instances. So those are quite big problems from the traditional way of working that serverless solve. In functions and service, we have a platform. We don't have a host. We don't have an application. In this platform, we will deploy the functions. I put one to three, but you can have as many as you want. And these functions are asleep. They are not executing. They are just asleep. The only way for these functions to execute is that an event comes and wakes them up. So what happened when an event comes? The platform will launch a virtual container. So there are your servers. But this is totally managed by the platform. So you don't need to care about updating the operating system, patching it, and making sure that everything has the right versions on it. The platform will launch this virtual container and will deploy your function. And when the function ends, then the virtual container will be discarded and the function will go back to a sleeping state. Here are two things that are important. First, that your function should be short-lived. In Lambda, that is the platform from AWS, it's five minutes. It cannot execute for more than five minutes. And the second thing is that your function needs to be stateless. So the state should not live in the function. And that's because when you have 100 requests coming at the same time, what the platform will do is launch 100 parallel virtual containers that will be having this function. So then, if you have state, then you will have a mess. So don't have state. And whenever we want to deploy a new version of function to you, what the platform will do, you will deploy it to a platform and the platform will spawn it in the next virtual container. So when a new event comes, it just takes it. It's out of the box, the spreading of these new versions. So that's more or less how functions and service works. So I want to compare it a little bit functions and service and back-end as a service so you understand that they have a lot of similarities. And I will use S3, that is a service that we all know, and Lambda is a new service from 2014 from AWS. So when you use S3, you just drop your files in it and you pay for as much as you use. You pay for the amount of requests, you pay for the amount of files that you have, and you don't need to tell AWS how much storage you are planning to have, you don't need to tell AWS how much you think this file is going to be called, how many times, you don't need to do anything like that. You just put your files and it works. AWS Lambda is the same, and with other platforms as a service as well. You just deploy your functions and you don't need to tell the platform how big is going to be this function, how many times this function is going to be called, what is the life cycle of the function, the platform takes care of everything. So there is not much maintaining in that way. And there is not maintaining the configuration neither. So when you are using S3, you don't need to worry about the scalability of your files. You know your files will be available everywhere in the world. AWS will take care of putting it in the edge of the cloud. You know that they will be safe. They will be replicated with some kind of service agreement that you have with Amazon. And you don't need to worry how Amazon does it. They promise that it will be there and you trust them. And the same happens with Lambda. When you deploy your code to Lambda, you trust that the code will be scaled automatically according to the service agreement that you have that you always have these kind of soft limits that you need to know. And it will be kind of there for you whenever you need it. So there are a lot of similarities in these guys. So to wrap up, we have that there is... These are more or less the features. So we have that it scales automatically. You pay as you go. You have no up-cut fronts. It's event-driven, as I say. And it's microservice. And I haven't mentioned this because you can have a monolith of Lambda and that will be horrible to see. And I hope none of you start putting all the events that will trigger your application to wake up one Lambda because that Lambda will be huge. And when you need to deploy that Lambda into the virtual container, it will take forever. So that kind of warming up will be very slow and it will be very costly. And you also have a size that you can have the Lambda. So you cannot deploy a massive thing. So you need to think of microservices. Some events to one function or one event to one function. And I like to call those nano-services. So you need to think in smaller bits. And there is also no administration. There is some administration. But in the sense of how much you need to configure or how much you need to tell Amazon that this thing will grow or will be in the future. So now we are all in the same page. What is serverless and what is back-end as a service? I can tell my story. Well, last year in the summer, we were a team of free back-end developers. And the managers went on holidays. As always, they do on summer. And the developers stayed working. That's very sad, but that's always how it happens. And we were there and we were gathering together in the beginning of the summer. And we started thinking about how we can solve our technical debt issues. Because when the managers are at work, it's impossible to get anything done because there are always new features, new features, new features. So when they are not at the office, we can solve problems. And I was working in a video-on-demand service inside Robbio that we were distributing cartoons. And it was like Netflix, but for cartoons. And the way that we monetized it was with advertisement. So that's an important thing. So when we start looking at our backlog, we start separating all the technical debt issues. And we figure out that there were two problems that most of the issues were piling into. Either they were piling into the systems that we were using, or not being able to handle our new features, or we're not keeping up with the velocity of our development. And the other pile that our operational costs were high. So this is very important to understand what were the problems. So the legacy system issue, as I call it, we were using a lot of systems that were created inside Robbio in-house when we were a different company, that we were building everything in-house. And then with the time, this project has four years. So with the time, they discovered that they don't want to build things in-house. So they start, every team does their own thing. So a lot of those systems that we were using, nobody was maintaining. They were full of bugs. They were not keeping up with the latest features. It was impossible to use. So we need to find a replacement for them. But we were free backend developers, and we didn't want to grow. So that was the first problem. The first problem was our operational costs. When you're distributing video on the Internet and the only way you make money is with advertisement, your costs are very important because you cannot tell your customers, now we will raise the price because we are very bad at managing our architecture. So you need to improve that. And for doing that, we have tried many things in the past, but nothing seemed to solve the problem. We need to do some big architectural rethinking of our whole platform in order to solve this problem from the root. And I am emphasizing and identify the problems because my problems are not important to you. Your problems are important to you. And whenever you're working in a company or a startup, the problem is the first place you need to go. Because if you don't know what are your problems, you don't know what you're changing the technology or what are you doing. Like you're just having, yeah, let's change the server, cool, yeah, yeah, yeah, how many times we do that? We don't like Angular, let's just react. Why? It's ugly. Like no manager will buy into that, no manager will give you resources to do that. But if you have a problem, like, yeah, you know, I need to change my whole architecture because we can drop the cost of this service by 50%. Then your manager will be like, hmm, money. That sounds good. So you have a tool, and also when you have the problems, then you have a way to know if you are achieving a goal. So for us, these problems were the driving force behind our migration. After that, we decided to train the team because we have an idea, a gut feeling, like a proper developer, whenever you start doing something, you have an idea how you will solve this problem even before thinking about how to solve the problem. But we didn't have a lot of tools in our hands. We were Java developers, we were working in a Java world very inside of instance, and then we were using these Ruby services. But we wanted to understand more about AWS services. So then we became very... Because AWS is the cloud that Ruby will use, so we knew that we need to update that. And we started learning more about AWS services. Then we started going to serverless meetups because by then I was already very interested in serverless and I was already brainwashing all my colleagues about it. And we were like, yeah, maybe that can be an interesting thing to glue everything together. So we started training that. We started going into a lot of meetups and a lot of side projects and things like that to get trained. And also our management saw that as we had a very valuable problem to fix that operational cost, they can invest some money and hire an expert in serverless for us. So you see, problems are good. If you know your problems, you know your value. So we got this expert in the house, and then when we got him in, we didn't got him full-time, we got him a few hours a week. And what we did with him was to get a workshop set up. So we set up a workshop that at the beginning of the project was like a classroom that we sit together and we start talking about, like, yeah, we can do this and that and this is the way you're doing serverless. But by the end of the project, it was like a mini panel of psychology architectural problems. So we were challenging each other and we were forcing each other to be better and to solve the problem in the smartest way that we could. So if you ever are in this place that you're trying to migrate or do something that you don't have a lot of knowledge in your team, don't be afraid, go for it. But try to gather all the minds in one room at least once a week so you can challenge yourself because nothing is worse than an only software engineer trying to solve problems, that they cannot talk to each other and they cannot see that if that's the best idea that you can get because when you talk, you can improve your idea so much. The next step we did, after we have a team that knew more or less what they were doing, we started working on proof-of-concepts and the proof-of-concepts were really important, all of these without putting a line of production code. It was during the summer. We started building proof-of-concepts. So the proof-of-concepts were important to validate that these problems that we had in the first place were having the best solution as possible. So we built five proof-of-concepts. These are our proof-of-concepts. They are not your proof-of-concepts. They are based on my problems. So whenever you are thinking about this, think about your proof-of-concepts and how you can use this proof-of-concept to validate your problems. So for example, the first two are validating the legacy systems. So we picked one of the most important critical legacy systems that we need to replace and we built a proof-of-concept for it and that was the authentication system and the non-SQL database that we have hosted inside the house. So we create a proof-of-concept for that. The second two, the orange sheesh, were to improve the operational cost. When you transfer video or transfer images online, you want to transfer the smallest as possible or the one that looks pretty in the device, but it's the smallest you can get. So for that, we built a pipeline that was totally automated using several technologies. And there was image resizing and video resizing. But the last proof-of-concept was the most interesting because that's the one we spent a lot of time working in and that was the real architecture of our systems when we spent a lot of time thinking how we can restructure this whole thing to be cheap. And that's the next point. Optimize your solution to take advantage of the cloud. So the cloud works in many ways, but it has usually two parts. One part is where the data centers are in somewhere. When you're using AWS, you pick the region and you say my servers might be in Virginia, might be in Ohio, might be in Dublin. And there are your data centers. There is multiple, but there are places where code runs. And then there is the edge of the network where you have your cache. And those are many. And almost every country that is relevant will have a kind of small data center where the cache and the edge is. And when you connect a client to the data center, that's an expensive connection. And usually that's the mindset that I was coming into thinking about like Java services. I will put all the cache in the server, but that means that my client will need to connect to the server. So it will be expensive connection and it will be slow because it needs to go from China to Grusinha. That's not efficient. So what we did is to bring that cache that was in the server to the edge of the cloud. So when Chinese user connects, they connect to a China edge. And then the China edge will talk with the Virginia in their own time and space. And for the client, that will be super fast. And for us, it will be super cheap because there will be less calls to the back. So what I'm trying to say here is that whenever you face a problem, don't grab your code, your Java, for example, code. Put it into lambdas. Create events for your endpoints and just think, oh, we are serverless. It will be fucking expensive. So if you want to think, sorry for my voice. Need to talk in public. So hard. But it will be expensive. You need to rethink how to take advantage of the cloud. The cloud has an edge and that's the place that you want to be. You want your clients to be as little as possible in the data centers and you want to take advantage of that. And in your problem, maybe it's another feature of the cloud that you want to take into advantage. But think about it. Don't just grab whatever you have and drop it into a lambda. That's not the way. The last two points I want to talk about, this one is what the previous talk was about, automate your pipeline. Use code infrastructure as code. If you're coming from a traditional environment, you already might have some kind of automation in place. And when you go to serverless, you need to keep that automation because the serverless word is a very distributed place. You have lambdas and resources like databases that don't belong to you, that you're connecting and creating. You have endpoints and things. There's so many things that you need to keep track of. And when you open your AWS console, if you're working with AWS, it's like hell, everything is disconnected from each other. So you need to keep a framework that can manage that together so you as a developer can keep track of what are the changes. For example, the previous talk was talking about Terraform. There is serverless framework that is for serverless. There is also the AWS framework sum. And there are others that you can use to manage all these resources together and to have your infrastructure as code, put it in a Git repo, and then create a built pipeline that you're able to deploy from a centralized point, that the developer is able to push to GitHub and some machine happens and it goes to your AWS account. So developers are not able to deploy from their computer to the cloud, to any stage, because whenever you don't know what is in production, when you have a team of three, it's already chaos. It's like hurting cats. It's like impossible to know what is the latest version if everybody is deploying to production. So having a centralized place, you know what is the latest thing that is in production. You know what is the latest thing that is in staging and in development. In our case, we use three AWS accounts, one for each stage. And that we use because of isolation. We didn't want things to leak to the production. But also we want to keep our soft limits that I was talking before in order. So yeah, that was important. And the last one, automated testing. Testing is totally underrated and it should not be underrated. It should be very... You should have a process for it because when you have a lot of the couple things that are all having their own life cycle, everything is event-driven. You lose control. And then when you want to do multiple deploys a day, then you need to have something that you can trust. And that's all your tests. So have a process for unit testing, for how to test your resources that are from the cloud, how to do integration tests, how a good separation between your services and the external world. How a good end-to-end testing, because when you're deploying things, you will need to do a lot of manual testing if you don't have a good set of tests in place. So research that and all of these without putting a line of coding production. So after all... You have thought about all this, then you go and you put coding production. So to wrap up, serverless is not perfect. There is a lot of things. Back to testing, monitoring and debugging, I think they are the biggest challenges for the serverless world nowadays. So you need to have very strong tests in order to be able to trust your poor monitoring and your very bad debugging capabilities nowadays. Everything is very decoupled. So debugging line by line is very hard. You will need to bring lots of console logs and you will need to look around those console logs to understand what is going on. So test. Also, there is a lot of change. Still in serverless, it's a very changing thing. Libraries update all the time. You need to keep yourself up to date and you need to change the mind of the developer that just developed codes and throw it to the operational team. You have to be a more ops-minded person. And I think that's a great thing for developers to understand, because the life cycle of an application is six months maybe on development, but then 10 years on ops. So you need to understand how your code is living in the world. So yeah, serverless is a great thing. And there is a lot of things that I love from this technology. So it was a great ride. And if you have any questions, you can ask them in the Twitter handle or I'm sure Jeremy will bring a lot of them. So yeah, thank you. I wonder how many times I say so. No. There's a few questions from Marcia. Before you all rush off to lunch, by the way, you can't actually go to any of the restaurants before one. So darsing out the room won't actually be any use to anyone. So let's just enjoy a few minutes of Q&A first. So the first question was how we can share generic things, i.e. logic, within the serverless environment between different functions. So what I do is, in general, when I come on to the platform, I create this kind of serverless infrastructure project in GitHub, using some kind of cloud formation, or in my case it's cloud formation, but you can use Terraform, and you can have it infrastructure as code, and you build that every time you are going to create a new environment, you use that first, and then you can launch your serverless projects on top. Okay. Are there any ways to estimate sort of a monthly cost if you know what your traffic levels are sort of going to be? How do you adjust that? Well, Amazon has some kind of cost management, and you can use that to track how much you will spend, but it's all about how you implement the thing and how many times your lambdas get called, so you really need to understand your... One good way that I found out is to do like load testing. In this scenario, load testing is kind of pointless because things scale, but when you do load testing with the amount of requests you think, you're generating that traffic and you see more or less, okay, this will cost me X amount of dollars per hour, so you have a clue, that's how we did it, but... Let's go there. How do lambdas perform in a low latency environment since there's the overhead of the virtual container startup? The lambdas perform... I think the important thing for a lambda is that there is like a small package to be deployed to it, so when you start from a lambda that is cold, it starts fast, and then that the lambda itself, if it's becoming very slow, you can tweak the amount of memory, and when you tweak the amount of memory of the lambda, you're also tweaking the amount of CPU, so that you can increase like the faster deployment, but in general, you don't have many options, you can only tweak the memory. And obviously we've talked about lambdas and things. One question was how mature are the competitors to AWS in this place, are there other places that you would recommend? There are Google Functions and Microsoft, I think they're pretty mature, at least I have tried them and they work fine, but I've been using production only AWS. And as a follow-on to that, is there a way to avoid vendor locking? You always have to marry someone. You can use, I think, one way is to... Because the lambdas are JavaScript or Python or whatever modules, so if you write your code in a way that is wrapped around the vendor locking thing, then you are kind of less vendor lock, but if you are using Dynamo and you're using Qs from Amazon and you're using all these back-end as a service, well, you have to choose your battle. Do you want to spend time building these things or you just use it and then when you want to migrate, just change it, so it's all a matter of picking what battles you want to have. Yeah, that makes sense. Thank you very much.