Hi everyone, and welcome to this session at Con 42. I'm thena and I'm thrilled to be a part of this incredible event. A big thank you to Con 42 for organizing this and to all of you for tuning in, even though we are not in the same do. I'm excited to share some valuable insights with you today. So I'm an open source contributor at Gopher. Gopher is a Golang framework for accelerated microservice development. In Golan, we focus on building resilient. Scalable and secure microservices. Over the years, we have faced numerous challenges, building and scaling distributed systems, and Boer is the result of all those hard earned lessons. Boer is designed for efficient interservice communication. Observability and scalability By building microservices, it removes the boilerplate code for you so you can focus on your business logic with minimal lines of code. In this session, we'll explore the challenges of interservice SGTP communication in microservices. Then I'll go on to introduce you to gofer, which simplifies these challenges. We'll dive into the key features of gofer that help you build efficient interservice, SGTP communication architectures like circuit breakers and retry confis. Authentication observability and health monitoring. Finally, we'll see a live demo to show you how easy it is to set up Interservice SGTP communication architectures in Gofer. So let's not waste any more time and let's get going with Gofer. Now, imagine you are building a microservice based e-commerce store. So when a user places an order, the user service calls the payment service to complete the payment. But what if the payment service is unresponsive? Sounds familiar, right? This is one of the many challenges that can arise while interservice communications in microservices. In today's world of distributed systems, microservices are the backbone of modern applications because they allow us to build scalable, modular, and maintainable systems. But one of the most critical aspect of microservices is how they communicate with each other. SGDP is the defacto protocol for this communication, but it is not without its own challenges. For example, every time one service reaches out to another, it can face potential hurdles like latency issues, security breaches, or unexpected failures. So let's break down these challenges and discuss about them in detail. We talk about latency when services communicate over HGTP. Every call adds latency, so if one service is slow, it can create a domino effect slowing down the entire system, even a minor delay in one service can ripple through the system. Needing to significant performance bottlenecks by when we talk about failures in microservices, when no system is immune to failures, be it hardware issues, unexpected spikes in traffics, or simple misconfigurations failures are inevitable when one service fail to respond as expected. It doesn't just affect that one component, but has the potential to have a cascading effect into broader system-wide issues. When we talk about security, with interservice communications actually happening over potentially unsecured networks. Each SGTP call becomes a point of vulnerability. Ensuring robust authentication and secure data transmission is paramount. If a service security is compromised, it could lead to unauthorized access data breaches or even further exploitation. Of other services in the network. Last but not the least, it is also very important to tackle observability as without proper monitoring, diagnosing issues becomes a guessing game, delaying resolution at increasing the downtime of your services. So these challenges aren't just technical, they are business critical. A single outage can cost millions and a security breach can damage your entire reputation. That's why it's not enough to just write code that works. We need to build systems that are efficient, resilient, secure, and observable. And that's where Go For comes in a framework that is designed to tackle these challenges Head on making in the service communication not just manageable but effortless. 'cause with Go For You don't just get a framework, but you get an entire toolkit. Empowers you to focus on building features and not start again with writing the whole boilerplate. Whether it is preventing cascading failures with smart circuit breakers, securing every call with robust authentication, or ensuring that your services stay healthy and monitored. Gopher does it all under one roof. And because it is modular, you only use what you actually need. And since Gopher is open source, it has evolved with its community to stay at its cutting edge with resilient system design. So let's dive deeper into its key features that make it an efficient choice for Interservice communications in microservices. In this section we'll be discussing few of the gophers features like circuit breakers and retry configs in build authentication observability, as well as health monitoring, which form the pillars of resilient microservices. When we talk about retry confis. BofA allows you to add the number of kind the framework must attempt or retry before actually returning your error in case any downstream SGTP service fails. However, cost to remote resources and services can fail due to temporary issues like slow network connections or timeouts. Service, UN availability, et cetera, while transient falls can be mitigated using the RY pattern, there are cases where continual ries are futile, such as severe service failures. In such scenarios, it is crucial for applications to recognize where an operation is unlikely to succeed and hand in the failure appropriately rather than persistently retrying. When we are talking about circuit breakers are a design pattern inspired by electrical systems. Just like a circuit breaker stops the flow of electricity during a fault. A software circuit breaker stops the flow of requests to a failing service. This prevents cascading failures and gives the system time to recover. Go makes implementing circuit breakers effortless. With just a few lines of configuration, you can set up the threshold and intervals for failing calls. For example, if a service fails more than a specified number of times within a time window, gofer automatically trips the circuit breaker. Once the service recovers, gofer resets the breaker, allowing the request to flow again. Next, let's talk about authentication. In a microservices architecture, every SGTP call is a potential security risk. Without proper authentication, unauthorized access can lead to data breaches or even systemwide exploitation. Securing inter-service communication here is non-negotiable. Gofer simplifies authentication with built in support from multiple methods. Whether it is API, keys, basic auth, or O gofer integrates these seamless into your services. You can configure authentication globally or per service, ensuring that every call is secured by default. Now we encourage best practice like token based authentication at award for secure and scale systems, and we also support custom headers so we can pro, so you can propagate authentication tokens or other metadata across services effortlessly. Next, let's talk about observability. Observability is a de facto in a framework. It is one of the most unique points that goer has to offer. Observability comprises of logs, traces, and metrics, which comes by defaulting everything that GOER provides. And similar is the case for Interservice, SGTP communication. All the outbound requests are actually properly logged and the UN traces and metrics are exported to the specified port as well as the tracer URL. We will dive deeper into this in the next section where see a live demo of actually setting up STTP services in gofer. Moving on. If we discuss about health monitoring in distributed systems, we need to know the health of the services all the time. And without proper monitoring, issues can go unnoticed until they escalate into major outages. Gofer provides robust health monitoring out of the box where we can configure the health endpoints for each services. And Gofo performs regular health checks on them. It also collects the metrics and logs giving us the realtime insights into our systems health. Many organizations usually pair these health checks with alerting and dashboards, turning raw data into actionable insights. For example, imagine a service that starts responding slowly, go first's. Health monitoring can help you detect this early, log the issue, and can even trigger alerts. This proactive approach can help you resolve issues before they actually start impacting users. So all these features that is circuit breakers authentication, observability, and health monitoring are just the beginning of what GOER offers. In the next section, we see them in action with a live demo, and you'll get to see how easy it is to build resilient, secure, and observable systems with gofer. Let's not waste any more time, and let's get coding with gofer. Gofer allows you to register SGTP services at the application level using ADD SGTP service method. This means you can easily configure interservice communication while keeping things clean and modular. So in our main function, we can write app at sgtp service. We then give the service name with which we would like to register as well as the service address. Services registered this way are managed automatically by the gophers container. Once registered services can be accessed anywhere using the method on gophers context as c PX dot get sgtp service. So let's define two routes in two different projects in one of our projects. Let's set the STTP port and metrics port as 80, 81 and 2020 respectively. And for the other. Let's keep it at 80, 80 and two. 1 2 1. After setting up our projects, let's define the routes in both of the projects. As for our applications workflow, for simplicity purpose, we'll still be having just a Hello Handler, but the name that we send in the response, we'll actually be fetched from the other service that we call inside a Hello Handler. So for the other service, let's go and define the name handler. And return a hardcoded name. Let's say my name, the we over there. So we write return the We and Nel for the error. Then we go back to our existing project and now add this SGTP service as we will be running the service at STTP Port 80 81. So the service address will be SGTP, local host 80 81, and we then give the service name with which we would like to register it. Moving on, we define a Hello Handler inside, which we then get the registered SGTP service using GET SGTP Service Method on the go first context. Then we call the GET method on that service, specifying the get endpoint that we have registered on our other service, and then give the argument as name that is the endpoint that must be hit on our registered service. We then return the response received if we encounter no error. Now let's run both of our services. And go to Postman and hit a URL that is local host 80 80 slash hello. We can see that we get hello the is actually Freshed from the other server. If we also look at the logs in our terminal, we can see that go for also logs Be call to any external S TT P services that you called inside your running applications. Having the same correlation id. As the parent span where it is called, we can also go and check the traces and see that the traces are in a hierarchy. One of go first's strength is its flexibility in configuring interservice communication, making it both powerful and simple to use. Let's start with authentication methods and then move on to the other configurable options like circuit breakers, retries, and health checks in gopher, authentication in Gopher. When services communicate, they must be secure. Goer provides multiple authentication options to ensure only authorized services can interact like API. Key authentication, basic authentication, and OAuth basic authentication. Uses a username and password to verify identity before processing the request. API Key authentication is a straightforward method. Where request must include a predefined secret, API Key and OAuth authentication is ideal for external API access requiring a client ID client, secret token, URL, et cetera, to fetch authentication tokens dynamically. Each method serves a different security need, allowing you to choose what fits best. Now, while making API requests, we often include headers like. User agent, content type, et cetera. Some of these headers stay the same for all requests, while others change dynamically depending upon the request context, the header, for example, content type application. JSON always remains the same. Most of the times for the API request, so to avoid adding them manually every time. COFA lets you define default headers once, and they're automatically added to all of your requests sent to that SGTP service. Also, when working with multiple services. We must ensure they're available before sending the request. Gofer lets you configure custom health checks that pings a services health endpoint at regular intervals. If the health check fails, gofer marks the service as unavailable and stop sending request. The Health Check. Timeout ensures that if a service doesn't respond within a given time, go for treats it as down. This prevents long waits. And help protect failures faster. Now, these failures happen due to network delays, temporary outages, or high server load. So instead of failing immediately, we can also configure our SGTP services to automatically retry the. Request for a specified number of time. For example, if a payment service times out gofer allows you to set up a retry config that helps you to retry, for example, up to five times before marking it as a failure. This improves reliability by handling temporary issues gracefully. While these retries help with temporary failures, they aren't always the solution because cost to external services can fail repeatedly due to a. Service being completely down high traffic, causing extreme delays and misconfiguration or deployment issues. Rying indefinitely in such cases, can base resources and can overload the failing service, making things even worse. If multiple clients keep retrying, this could even lead to an accidental denial of service attack on your system. So instead of blindly retrying, gofo introduces a circuit breaker pattern that can protect your system by detecting the repetitive failures and stopping request to that service. Changing its state to open when failures exceed the threshold, making periodic requests to the health check endpoint that is by default slash wellknown slash alive at the interval set in the config and automatically resuming this request being sent to the service once the service recovers by. Using this gopher ensures your system stays stable without overwhelming failing services. With this, we come to the end of this video. Let's take a moment to recap what we have covered today. We started by exploring the challenges that you usually face in interservice SG communication. That is latency, failures, and security. We then explored BofA, which is a framework that is designed to tackle these challenges head on and deep dived into its features that is circuit breaker for resilience. Authentication for security observability and health monitoring. And finally, we saw these features in action in a live demo. So if you are as excited about goer as I am, I encourage you to try goer in your own project. Whether you are building a new microservice or enhancing an existing one, goer can help you focus on what matters the most. That is delivering value to your users. For more info checkout or documentation at goer, you can also join our Discord channel for any feedback or design discussions regarding the same. Thank you so much for joining me today. I hope this session can give you a clear understanding of how GOER can simplify interservice communication and microservices. If you have any questions or want to learn more. Please feel free to visit our website and reach out to our community. Let's continue building resilient, secure, and observable systems together. Thanks for watching and enjoy the rest of.