 Hey everyone and welcome to my webinar about really finding cloud native debugging or as I would like to say never wait for your next deployment ever again. Before we begin, let's do a quick introduction. So, my name is Noah Goldman, I'm a product manager at workout a my favorite thing in the world would be to take complex technical issues and make a super simple and easy to use product out of them. So, let's begin. So before we speak about the different challenges when it comes to cloud native architectures and evolve into the cloud. Let's speak about why cloud is so much fun. So cloud is a major thing in our lives, and there are a lot of reasons for why so one reason can be that cloud as flexible and scalable. So, it's easier to manage higher user traffic if you have them, or maybe if you want to process a big batch of data cloud native architectures makes it a lot more easier to do. Another reason for why cloud is so much fun is that it's reliable right so you can still see data, even when your servers are down, which is a great benefit. Another reason can be that it just saves money. So it reduces costs and your IT team can actually now do different stuff other than maintaining your servers. It has great disaster recovery plans which is another advantage when it comes to cloud native architecture and just security wise it has automatic mandatory update which is great and it has data security monitoring and for all those reasons. This is why cloud native is so much fun and we love to use this. Before we dive into the different challenges. Let's see some numbers and some graphs because graphs are fun. So if we thought that cloud native is a huge deal. It's going to be a much bigger thing in the future and it will take an even greater part in our lives in the next four years. So by 2024 production grade cloud native applications will expand to 70% from 10% of all apps in 2020, which is a major thing cloud is going to be a bigger deal in the future. And this is why we want to learn how to hold those challenges will affect us and we want to learn about those challenges, the cloud native architecture actually brings to us. So we also want to learn how to overcome those challenges and maybe even avoid them in the future. And this is why we're all here it's a good thing that you join me and we will learn all about the different challenges and how we can grow for them and avoid them. So, let's think about the different challenges that cloud native architecture brings to us so one challenge can be just compliance requirements right. So you have to make sure that your application is compliant and ready to be run in the cloud, which is not always that easy. I can take time. Another challenge can be design modifications, sometimes you will have to redesign your app and the different architectures to better fit the cloud native architecture. Another challenge is that downtime can occur here and there when evolving to the cloud. And you know what just lack of expertise you were not always familiar with everything. And we will have to learn how to use the new tool and expense our toolkit. And let's face it, it takes time, and it's not that easy. All of those challenges are super important, we definitely need to learn how to overcome those, but I'm here to speak about one challenge that is especially close to my heart. And it can affect all of us. So, the challenge is the challenge of debugging your cloud native applications. And this is why we're here. So let's speak about this challenge. Before we speak about the actual challenge. I want to speak with you about the traditional debugging methods, all the different debugging tools that we are all familiar with and love. I'm sure all of us have used at least one of those methods. So let's dive into each and every one of those and see that they might be great, but they're not that much of a good fit when it comes to debugging our cloud native architecture applications. So the first one will be command 90 bugging, which is great, but it has a few disadvantage. So the first is eventually to be that it has limited amount of commands. So it's not like you have this great do we with different buttons, you basically have a few commands that you can use. The output is not always clear there if you remember it's a black screen, you see a big batch of data there. It's not always clear and easy to read. You can use again and almost always it will require more investigation. So it's not that you will just get that you need and solve your bug you almost always have to do some more investigation and try to solve the bug in different ways. So again, command 90 bugging. Great tool. But it's not that great. So another tool that we all know and familiar with is local debugging, which is also great, but it has a lot of disadvantages as well. So first of all, one of the drawbacks what we're talking about local debugging is production configurations. And when I'm speaking about production configurations I'm speaking about reproducing your production environment in your local machine right. So it can be your runtime environment, maybe you need to reproduce the production operation systems, or maybe different versions of the operation systems. You need to reproduce your source code versions right you have a certain source code version in your production that you have to make sure you run in your local machine. If you have any dependencies you have to produce them locally in order to find the specific bug, or just network configurations or any other conditions that you have in your production. It's not always the easy and the easiest thing to reproduce them on your local machine when you're troubleshooting a certain bug. Another drawbacks when we're speaking about local debugging is the application state right. The application state can be the actual data. Sometimes it's not the easiest thing to reproduce your production data in your local machine right that I sensitive it's not always possible to produce it. It's not just the actual production bugs you have to copycat your users and try to execute exactly the same flow that they did in order to reproduce the bug locally and reproduce what happened in production locally, and it's not always easy but sometimes it's just impossible. And those are just a few of the reasons for why local debugging it's a great tool for debugging, but it's not that great and it has a lot of disadvantages as well. Another tool can be logging and tracing, which is still great to but it has a few disadvantages as well. If you're not consuming, you have to follow those logs make sure understand them. Can you even predict your bugs, right. Most of the time we cannot predict the bugs, which means we don't always have the right log lines. Do you even really log every line of code that you're right. I know I don't. Most of the line of code that we could write. We don't have log lines from there for them and in the money time. So I have a few log lights this in terms of performance and storage costs. It can cost a lot of money. And you really have to keep maintaining those logs you have to add more logs or remove more logs, and it just constantly this and this for all of those reasons and this is why login and tracing it's not such a great tool when it comes to debugging your cloud native applications. Another great tool can be remote debugging a great again great great great tool, but it stops the app. So you don't always want to stop the application where you'd be bugging it. You need to know your service intimately. It's almost impossible in the cloud, you have many servers, and it's not that easy to connect to them and to understand which server you wanted to bug. And in terms of security, anyone can stop and start the app which is not that great and also you have a port that is left open to accept incoming connections from the client side. It's a TCP port and again it's not that recommended. Another thing that I want to speak with you about is the flow into production likely. Well, if you're doing that good for you. Let me know how it went for you, crossing fingers and hope for the best, but I have nothing to say to you. So good luck with that. So we spoke about all the traditional debugging ways that we all know today. But let's speak about the actual challenges that comes with debugging your cloud native architectures. There are different challenges. So the first one would be that you give it up to control, you don't have the control anymore and this is not always easy to deal with. Another challenge is that it has high complexity complexity architecture. So when I'm speaking about high complexity architecture, talking about multiple microservices communicating with each other. It's hard to get the holistic view of the app when you're dealing with such microservices, and just recreating the application state. It's not that easy when your architecture is so complex. Another drawback is the dynamic environment changes. So it's a huge challenge. You have instances that are deployed and turned down dynamically. And it's not always that easy to deal with. There's no up or process we can actually attach to in traditional debug sense, which make things a lot harder. And you know what just access sometimes you don't have the right access that you need when it comes to debugging your cloud native architectures. And those are just a few of the challenges that are brought to us when we try to debug our cloud native applications. Before we dive into the different solutions, I want you to all think about this story. So you're developing your application, everything is great. You add a new features, everything is going smooth, you all have fun. The team is enjoying their lives and everything is awesome. You try the evening, you have plans for the night, you're thinking about it, you're just dying to go home. And all of a sudden, a client will knock on the door, and they will have a major bug that has to be fixed right now. We're doing shifts from being nice and in joyful mood to panic attack and being all stressed out. I'm sure it all happened to all of us at least once when we're speaking about our development careers. Think about how much you wanted to just solve the bug as quickly as possible and get it over with. Here we want to learn about how we can do that to avoid such panic attacks and how we can solve our clients bug fast and avoid such situations where we all in panic and we just want to finish with the bugs. So I want you to think about this story, and let's dive into the different solutions that we have. So one solution I want to suggest is APM tools. APM tools are application performance management or monitoring tools, depends on how you want to use it. So they collect metrics data and they tell you what's going on within your application. So metrics data can be anything including transactions analytics availability, lock scraping, which are all presented in a beautiful dashboard. Those tools can be you might know them as a new relic of the dynamic dynamic race and there are many more. But they have a few drawbacks as well. So no fidelity data is one of them. The data is collected at low fidelity so while the solution can be relied on to alert you. They provide little direction as to just what that something is and how we can fix it. So again, this is just one drawback. It has significant learning curve. We're not always familiar with this and it takes time to learn it. Multiple tools to monitor various aspects of the application. So again, it's not just one tool that you have to implement and adopt you, you have to install multiple tools and learn how to deal with them. Which again, it's a major drawback and it just consumes more resources and a drop of your costs. So APMs are a great tool, you might want to use them when it comes to debugging your cloud native architecture applications. But they do have a few drawbacks that you might want to take into consideration when debugging your applications. Another solution I would like to bring is exception catching. Exception catchings are tools that automatically capture and track exception as they occur. They will help you identify patterns or repetitive that behaviors within your applications. Such tools, you might know them as century or box dogs and there are many more. They have a few disadvantages as well. So first of all, again, much like APM tools. Those are another tool that you have to use. And bugs also do not always come from exceptions, right? Most of the bugs that we have are actually being created because the developer did something wrong or maybe the business side didn't think about everything through. So most of the bugs are not always coming from exceptions. Exception catching tool can act differently in various environments. So this is one thing that we definitely want to take into consideration when we use it to debug our application. And again, much like different solutions, not all the data is available. So it almost always requires some different investigations when we're trying to debug our applications. Again, exception catching are helpful. They will be great, but then will not solve everything that you need to solve. The final solution I would like to bring up will be live debuggers. So live debuggers are production grade real-time debugging. They collect data from a screenshot of your application. They can do that on demand for many environments without actually having to stop your application. You can do that with just one click. You can set non break and break points, which are the coolest thing in the world, and get data on the fly without actually stopping your app. So it has great advantage. First of all, you don't have to create and reproduce your local state, say your production state locally, because you're basically debugging your production application. The code that you will debug behaves exactly as it is in production because again you're debugging the actual production environments. You're not debugging locally. You're producing bugs. Again, it's a lot easier because you don't have to follow your users step by step and why they didn't reproduce the bug. You can just have it right there in your production environment. It has no performance impact at all. And it has non break and break points, which is the coolest thing in the world. You just place a break point as you know it in your ID, but the difference is that it just doesn't stop your application. So for all those reasons, this is why I recommend live debuggers when it comes to debugging your cloud native architecture applications. Yes, so this is my final solution and I want you to go ahead and think back about the story that we just mentioned a few minutes ago, and think about how cool it will be if you have such solutions and you will be able to solve your cloud native applications a lot faster with not having to deal with such panic attack. You will be able to solve the bug and move on with your life and enjoy your Friday night plans. So yeah, those are all the different solutions that I can offer you when it comes to debugging your cloud native applications. Please feel free to contact me at Nagelmanitruko.com. I'll be happy to answer all your questions. I had great time. Thank you for listening and enjoy the rest of your day. Bye.