 Okay, the next speaker is Frank Adil who is going to be leaving us on the topic Site Reliability Engineering with Kubernetes. So Frank is an engineering graduate with over 60 years experience building and developing distributed system and Frank has worked as a senior software engineer, principal software consultant, automation and reviews engineer, platform engineer and so much more in the cloud ecosystem. So it's good to have you here, Frank. Hello. Hello. Can anyone hear me? Oh, yes, I can hear you. I just I'll let you have the stage. All right. Okay. All right. That's cool. Yeah. So excited to be here today. And it's a privilege to be part of the CNCF today to actually talk about Site Reliability engineering in the Kubernetes space. So I could rightly say Site Reliability in the cloud native space but now everything is cloud native at the moment. With much further ado, I think I will go ahead to talk about what Site Reliability is actually. We've had the term and the word, the buzz word right now, I'm an SRE, I'm an SRE DevOps engineer as well. So basically an SRE engineer is ensuring systems are reliable and that is how I define it and that is why I coined it. So you've been an SRE, you will cut across the entire stack of the chain of delivery. So you start from the design stage and also monitoring stage as well. So you cut across the entire stack of the divide within the SDLC process as well too. And also you closely with the developers very well and also with their upstream as well. So there is a lot of responsibility as you're being a Site Reliability engineer in the tech space or within an organization or being a consultant as well. So let's dive in. So these are the key areas. I've had so many questions, I've been asked privately either on LinkedIn, either on the Twitter space as well, what is the difference between SRE and DevOps itself? Okay, it's a bit tricky to actually separate both of them. So basically what an SRE does is an SRE extends the functionality of DevOps itself and the School of Thoughts with some of my key folks, some of my IT professionals agree that DevOps should not be coined DevOps engineering and that DevOps is a culture kind of. So there is an argument and there's a School of Thoughts around that as well. So basically what SRE is, SRE leverages on DevOps design to chain and also extend the functionality that DevOps practices actually brings within the tech stack as well. So you're being an SRE or an SRE consultant or an SRE practitioner within a team, you have a lot of key responsibilities that actually falls on you within that space. So you are more consigned about reliability, about availability and also system observability as well. I was very happy when the service matching came up. It was a very, very cool topic and that has really given me a very good leverage to actually start on in terms of system observability and also some strategies with high availability and some DRs and most critically automation as well and built-in for tolerance and also GitOps was pretty much decided when I actually saw the GitOps session as well. It was pretty cool and also with the container spark that was actually taken care of today as well. So I think they have made my presentation a bit easier for me as well and also what we'll call SPF, single point of failure and monitoring. So this is where some of the issues where it comes in in terms of SRE, whether you have to monitor what are the key functionalities that you have to monitor, what are the metrics business is interested in as well. So basically as an SRE for you to be successful within an SRE team or you'll be in a consultant or you'll be a core engineer within the team, you see yourself more as a technical customer within the team itself. So let's say that a customer out there doesn't know when is the system going to fail or what the customer is interested in. It's basically getting reports from my HTTP traffic and I want to do this and I'm able to do it as well. So in this case, in terms of monitoring, what you have to monitor is a very key topic, is a very, very full dose of topic that I will try as much as possible to really dive into some of the key areas that you have to really monitor and some of the tools you can actually use as well. And this is the extension functionality part that comes in in terms of management. As an SRE, you handle all core plans and you prepare incident management tools as well. You do RSAs which is a root code analysis. This is where your tracing comes in using your Yegar and Z Kings and all to actually come up with some very good RSAs and to make sure that is being mitigated. And also we have BlinList Post-Mortem. If you have an SRE or if you are an SRE team, this is a practice that is very, very, very crucial for the team to sustain BlinList Post-Mortem. There is a template for it as well. So what it actually means basically is when anything happens, the entire team take full responsibility not actually pointing out someone else. It was his code, it was that code, it was a bad code that actually caused a problem. So when you have a BlinList Post-Mortem that is documented, it's very, very easy for that issue not to repeat itself again. And most critically is the software design part. You are always part of the architectural design discussions because before the software is actually being released, you are part of every SDLCs process in terms of architecture. So the architecture, you bring in all their key metrics, the service of time, the way the microservice is being built, what kind of machine system. And so there you are actually looking at the observability and you're also looking at availability as well and you know, so on. So software design part is very critical in this. So now let's dive into the next one. I always say this every time. There is nothing much as intelligent as working on an SRE in a Kubernetes environment. It's very, very fun to be working in a cloud native space. Very well. I've never regretted it, but sometimes it comes with very, very big pains as well, trying to resolve some issues that could left you wondering why did you actually choose this failed. Okay, next one. Okay, terms of availability. So I made mention of HAs and DRs as well. So now I think SR is now, we could really say that we are a little bit advantaged when working in an environment where it's not a Kubernetes based or a cloud native driven environment. So here Kubernetes was built, is production ready. Production ready in the sense that it's thought tolerant ready and also is high availability ready. And I actually like the word, the Braille actually used when he made mention of actually checking constantly to every state is actually being maintained. So one of the critical tools as necessary to have within the Kubernetes space is to be able to write some CRDs and play our operators very well. So when you have that at your back, it makes you manage the infrastructure a bit easier. So when you're actually having CRDs, you are actually extending the functionality of the Kubernetes environment itself. Like I agree with you, when he made mention of, it gets to a point Kubernetes cannot take care of itself anymore, you need to enhance it. So that is where you have to have the tool set, the CRDs and the operators. So it is very key for you as an SRE to have that tool set with you. You need to learn how to write some CRDs. Sometimes you have to go as far as doing some go lang as well. So I also write go to NDB or Python as well. So now in terms of availability, fine is build is ready, it's thought tolerant ready and all that, but you have to come in with some level of architecture that you're really having as well. So yeah, you'll need your three, just normal standard, one master, you'll have your two workloads running, which is a normal that you have. Now for you to be much more thought tolerant, you will need an extra three and nodes where you'll have one acting as a load balancer separately, and you'll have the other two acting as masters as well. You have a secondary and the third master as well. So that is a full, highly available environment that you are actually planning because all these things starts at the stage of planning. Remember, I talked about the software design. So you are always part of the design process in there. So these are where you have to come in as an SRE to actually plan out as well. So if you're running a cloud, you are a bit very lucky to really do the configuration and do some add ups to the nodes. But if you're not so lucky and you're doing on bare metal, which happens to be some of the times that the environment are working most of the times, you definitely need to deploy this yourself manually. You need to get extra nodes in there. And I know you'll be wondering what is the ETCD doing out there? So you are an SRE, you care about performance. So for performance driven architecture, it is very crucial for you to have a separate ETCD node or cluster running separately. So with that, you're very sure of your speed and your performance as well running. So here, I use HEPROSY. You can use any other process out there. You can use INGINEX to actually proceed to act and also have your ingress controllers work as well too. So that is that. Please keep your questions coming. If you have questions, I could see them. Then also, in terms of reliability, which happens to be very crucial, I could give you a very case scenario that I've really had in the past when I wasn't in an e-commerce space. Fridays are usually very heavy with traffic and some certain hours of the day is very heavy on traffic as well. And you'll see a huge spike with traffic coming in. And how will you be able to mitigate that? How will you, a very clear example, for instance, is Jumiya doing a Black Friday or doing a promo on a certain hour of the day? How can you really mitigate that traffic coming in as well? And no matter how you try to do some throttling, you'll still face resource drain issues. So managing resources is very critical to service reliability. It is very critical. So some strategies at this level are vertical scaling. You have the vertical scaling running, which is your VPA vertical scaling system, which is the cost of scaling already running. And you also have your horizontal port that also does scaling as well. So it gets to a threshold where the threshold is above 60% that you have set for your HBAs. What it needs is now you need to have your CA, what happens to be your cost of auto scalers have to kick in because the request coming in on this particular day or this particular time is above 60%. So there is an algorithm that is already reading. You use your CRD to actually do that. If you want to really have the full functionality of that, you'll have that reading to really set in and kick in their threshold to handle that. So sometimes I could believe with all the experience way back two, three years ago, you will have there is jam with the, for instance, like the jam portal. Sorry, I'm actually making an example of that. It gets so bad no one could access the site at a particular time because of traffic. You're here, there is so much traffic, the site is inaccessible or it's pretty slow. It takes a lot of time for this to happen. This is the problem. You understand? So as an Acery within the team, you need to make sure you mitigate against that. So how do you do that? So you come up with strategies and this is part of the strategy you have to come up with. This type you have your HPAs to increase the number of poles that are going to be running within your costars. You also need to include the vertical scaling system within your environment as well. And this is so interesting because it happens a lot. And so if you're running the cloud, you have a big advantage over your running in the cloud. You have your auto scalers running in the cloud and it's pretty good working. So how do you handle that in a better metal situation? So that is where the physical nodes have to come in as well that you have to relatively. So that is for that. And also to improve layers, improve traffic, improve latency, you need to come in with your caching system as well. So the very important part of the caching system, most times I help discover during my consulting times has been there is failure to actually have a caching strategy at the back end, which is the database layer within the service and the database layer. Most times they actually mix that part out. And there is always struggling. There is always back and forth communication happening and which really tends to slow queries as well. So in terms of query performance, it is very necessary for you to have some caching strategies. You can use Redis. Redis is pretty cool. Something that we see too have actually worked with as well. And it's also part of cloud native as well too. It's very good to actually work with. And so there are all that caching system out there that you can actually work with. So the whole essence is to make sure you increase query performance at the database back end layer. And this is going to improve the latency from the API layer. I think the previous pick actually made mention of API calls and all that. So this is an extension to what she actually made mention of. Now let's move on to the next one. Please keep the question coming if you have a question. Yeah, in terms of observability, thank you Givry for actually doing some service machine and all. And I think if you missed that, you can actually watch the video to really grasp what service mesh is. So he made mention they're all nice side cars. Very good. So in the SRI world, okay, we can hear words like injection of side cars within a service running and it's still the same thing as what he explained earlier. So if it's very, very crucial and very, very important for an SRI within a team or handling a team to have an eyes into the services that are running at the back end level, which is very, very critical. So if you have a service mesh running, you could directly scrape or monitor the end points for the interconnectivity to actually check which is failing, which is not actually working. And also this will also help you to mitigate against service degradation. It's something I see almost every day in some teams and they have a lot of service that are degraded. They are not picking up again because of the observability strategy they actually use, for instance, they have different strategies you can get into make that work. You can have retries. You can have a single transactions and all there are a lot of strategies that you can really put in to really make that happen. And all this happened within the design stage. So within during the architectural design, if you could remember when I started, I talked about the SRI being part of the software design plan. So you are always in every meetings, you are always giving out your own level of experience, making sure the software that is about to be delivered is 100% or 99% conformity to best practices as well. So you cannot imagine a service being put out there and you are an SRI within the team and there are no service mesh or there are no ways to actually improve the interconnectivity of the micro services that actually are running. You could say, fine, we are running an SBA, just a single application we are running. You can actually have some level of observability within that. You can actually have an endpoint being created periodically to actually check if that endpoint is up. So not necessarily within the microspaces alone. So you can actually have that done in an SBA environment. And also for the distributed tracing, I could remember when I got into a particular team, they were a lot of issues. You don't know where the issues are coming from. You cannot even tell. It's like a 200 or it's a 502 or it's a 504 or all what you see is internal SBA error and it's quite vague and actually having developers or the software engineers to actually start tracing, start checking out and all that. That takes a lot of time and it becomes so mundane and repetitively. So one of the areas that's necessary within the team is improve as much as possible every repetitive task or to make those processes as much as possible. So one of the areas you can actually do is to bring your distributed tracing and a very good tool you can use out there within the microspaces space, which is part of Cloud Native, you'll have the what we call Yeager. You can use Yeager to actually do this. It runs on AWS. It runs on Azure space as well. Also run on Google space as well to also run on bare metals as well. It's something that I've actually have been exposed to a couple of times and it's one of my tools that I use as well. So with the distributed tracing, the developers can actually tell, is it a 200? Is it a 504? Is it a 500? And it comes up and it drills down to the exact service that is actually failing. So you visualize it and you actually see it there. It's another whole big topic on this on that I could talk on and on and on. And so we all can gain clarity on it. And also viewed in APM, I talked about APM right now, an application monitoring, now you're drilling down to a particular endpoint directly and you are scraping every seconds hitting the traffic. You could use permissions for that. You could use other enterprise tools for that. You could use New Relic as well. You can use Datadog as well. But my go-to tool that is quite flexible for me to actually work with is Prometheus. I use Prometheus so I can do this all most of the time. It depends on the environment I find myself as well. So you create dashboards with it as well and you set alerts on the endpoints that you're actually monitoring. If it's failing or if it fails, you see it first before the client or the customer actually sees it. So you have to mitigate it. So when that happens, that is where you have your rollback almost immediately that happens. A very good scenario is usually sometimes when the new release is out and their endpoint fails. So what happens? You have to do a quick rollback. That is where your GitOps comes in as well. I will talk about that I think in a couple of slides as well. And also backend observability is very critical. You have to monitor your database because right now there is even a new role called database observability engineers basically taking care of the database part, getting some logs, checking our latency from queries and building the very best to make sure there is full observability at the backend backend services running on the database part. And also in terms of a lot of us have heard about Fluendee and Fluendee is a very, very good login tool that I think every SRE out there should really have as part of their tooling as well. So with Fluendee, you have a full instance observability into your services that are running. You could do a whole lot with it, a whole lot with Fluendee. I think when I'm giving them this opportunity sometime, I could talk about Fluendee in the SRE space as well extensively. I think I should move to the next slide now. My time is almost gone. Okay. So for tolerance, what is for tolerance? For within the SRE space, you use a chaos mechanism. Fine, you have your QA, your QA is working and so with the photo around you could also automate that process within your pipeline, you build your pipeline, automate your full pipeline that is running. You could be running in the traditional Jenkins environment for instance. And if you're lucky enough, you could be working in a GitHub actions environment as well. So you automate the entire process, you have your QA within it as well. And most importantly that you have to add in to make your Kiosk method complete. Within their pipeline, you need to have endpoints within your pipeline. So before the release happens, the pipeline actually does an API call to the endpoint before the release happens. So if the endpoint fails, it's not getting into production. It's not getting into the sandbox area or within the staging. It's not even making it a staging. So it's a very critical area and a very new system way to make sure before you go to production, everything go 100%. Because business focus is to make sure that the services out there is 100%. They don't want to know if it's 99%. Everything is 100% for business. It's very critical for business. So Kiosk method is one of the critical areas before you go to the production. You have to make sure that happens as well. So also, mesh system has made for tolerant testing also very easy. And so with the diagram here, you can actually see from one, you have the external load balancer that is coming in. And also you have the ingress data plan that is coming in and ingress control plane and the service mesh control plane coming in and hitting the service process that you're actually talking about service processes and all that. So this is an entire communication with the microservice itself. And this also improves the security, in terms of security as well, it improves security in terms of service communication. From what you can see here right now, they are all communicating separately and independently and actually hitting directly to their service process. So each of them has a service process that actually enables for service discovery as well. And how to avoid service degradation. What kind of mechanism are you having? What kind of, how many seconds actually for a service or what constitutes a service to be degraded? Is it after three tries, the service is degraded? And if it's degraded, is there replica or is there a replication? So that is where you have a strategy within the K8 space where you have a stateful set as well that comes in. So with stateful sets, you can almost have as far as tolerance as much as possible. Okay, now to the next one. Automation is a critical part. I think every SRE, I think this is one of the core functions, one of the core functions within the SRE space, talking about automation, code compliance, infrastructure as code, and having help to act as your app management tool set as well. Like I said here, it's one of the cheapest, the yet most expensive practices. Some good practices with good quality, with good quality you can have linters to make sure your infrastructure is code well-taken linters to monitor your YAML and also have your control. And it's also a use case as well as it's one of the cheapest, that's why I said so, one of the case of failovers. So let's give you a practical example. You'll have your infrastructure that has been built using Terraform, for instance, and just part of your EKS or your GKE environment that you're actually managing. And something happens to the region or happens to the data center or you can easily grow back. You could easily spin up the infrastructure almost in a short period of time, like you having to do your snapshots, you have to do some geo-replication that is quite expensive. So it's cheap, but it's expensive when it's built because sometimes that is not being put into perspective as well. So within an SRE in a team, the SRE ensures that every infrastructure is built as a code, not a GUI. A GUI is highly discouraged because of the prone to errors, a mundane approach, and the number of time it takes to actually bring up back if an infrastructure actually goes down, for instance. Okay, then a very good other way is having your backups, your SSL certs, your installations, for instance, you want to install some softwares, you want to install some packages with the pipeline, for instance, you have to use Ansible to do that. So it makes their entire infrastructure more robust and quite easy to maintain. Okay, I think this was dealt with yesterday. I have a very limited time that getups. This was very, very dealt with yesterday and I was pretty cool with it. Talked about Floss and Argo CD as well. There is so much talk about it. Should I go for Argo CD or should I use Floss as well? So Floss can only observe one report at a time. I don't know if they've been able to update that. I think the lady from Weaveworks can actually point correctly on that and why Argo CD can observe multiple reports. So before you actually use the tool, you should actually know the reason why you have to use such a particular tool. So remember I talked about rollback and how quick for you to get back up again to make sure you maintain some level of reliability and availability. Getups Automation has come to stay and we have Argo CD and Floss to actually do that. But I prefer using Argo CD because of the multiple reports that I can actually work with. I think it's one of the areas that Floss has to really improve that. I don't know if they have a new affection that can actually do that at the moment as well. And also it's a source of truth and also release integrity and becomes ownership driven as well. And also for containers, containerization, I really enjoyed the container session that was done by Great. I really loved it and I enjoyed myself and actually learnt as well. So we all know the regular container and health check about containers. We could tell you okay fine, the life cycle, we have Live Nets Probe, Red Nets Probe and Startup Probe and they're pretty cool. But there is more to that. If you are working in a very, in a real, in a cloudy space that is data platform, for instance, and data streaming platform, for instance, you want some other Java days, Python days, goal and base applications to actually run side by side with containers. What you have to do, you have to use any container. So you have to initialize the software first before the containers themselves that have the images actually run. So there are set of scripts that you cannot find within your images. So it's something you will have to write. I think we all know this command, very simple command that we can remember. You know about this SleepSH echo blah blah and sleep and all that. And also you have the unit containers that initialize the containers. They need to run side by side with that. I think I can show you very quickly something here how that works. So by the way, if you're wondering what kind of you are using, sorry, this is one of my tools that I'm using. This is what we call Lens. So this is an example of Enix running. So this is how an Enix runs. So it runs side by side with the app that has the images that are running. So it runs side by side. So the advantage of this is you don't have much of your app throttling or your image throttling or your image shutting down unnecessarily because you're taking the heavy width off. So the code for setup, everything is the other container. So it's like you have this separation of process. So let me move to the next one, my time. Okay. All right. So single point of failure. Single point of failure. Yeah, you have to have the multi-region deployment kind of strategy that you need to have. You need to have your AZs from the diagram here. I think I need to go fast as well. Sorry, Abu Bakar. I'm taking much more time. So yeah, you have the, maybe you could go to the video and actually look through it and see how this actually works as well. You have the multi-region and also, okay, okay, thank you. Thank you. Thank you. Okay. All right. So let me go ahead. Okay, cool. So you have the application. So best strategies to avoid failure in your production environment is actually have a multi-region. Your GIRs, like I mentioned, IACs, which is infrastructure as good. I'm not going to delve into that again. You have the disaster recovery kind of mechanism in your multi-region as well. So in terms of your GIRs, it's always very, very, very critical for you to have your database structured in a GIR process as well. All right. In the GIRs as well. So with your GIRs is for your database, you'll have different, GIRs are very expensive, very expensive. So before you do that, you should know it's going to cost a huge amount of money to really, really do, to go ahead with. So you have the transition logs as well. And also with the, with the Regency having your cluster, the master. So all this actually helps with your replication and also helps with your data performance as well too. And also, I think I will rush through the other ones as well. So I can take questions. Okay. Interesting. I think I'm on the last part now. Cool. This is it. Now we've heard about SLOs, SLIs. I think, Abubakar, you need to bring it back again. So I will talk more about SLO and SLI. So the DevOps community or the Cloud Engine community, some people really understand what an SLO, how to set SLO work is. I could remember my very first consulting was, okay, we want you to drop an SLO for the application or for the company. It was very difficult for me. I had to go through Google documentation to understand what an SLO was and all that. I wasn't looking at it from a business perspective. I was looking at it from an engineering perspective. So the time I started looking at it from a business perspective, it was quite easy for me to actually relate with what is an SLO to business and how important it is for a business. And you're making a call to that application, making that streaming on Netflix, for instance. And the business want to make sense of how the response time is. And a very critical, easy latency. And a typical example of an SLO dashboard that was made in-house was made in-house with PromQL, with drones on Prometheus. And this was done with the Grafano dashboard as well. We have the True Puts. And error budget is something I can talk from now to six hours. Error budget is quite huge. Any company that is running 99.9, what that means that in a whole year is being calculated to know the number of time they're actually losing money. And that is very critical for business. Anytime I always present an SLO dashboard, business get decided about it. So they put more pressure on the team to make sure they perform optimally as well. So I got into a team, they were making 95% and that was a huge loss in terms of error budget. But in their engineering world, 95% is okay. It's a good timing. It's a good one, but no. And Aceri is very, very, very bad time. 95% is not a good one. Not a good one. You can have a 39, you can have a 49, which is fantastic. And most of the time that happens with the question that goes, why are we having bad error budget? Why are we really having error budget? Wrong error budget. So one of the issues with having wrong error budget is the tech stack. Most of them were actually using the environment that had 95% where they were actually using a legacy application. I'm not trying to say some languages are bad and all, but if your application is going to be interoperability, you need to make sure you are running a modern stack. If you understand what I'm trying to say, like you're running a Java replication, for instance, it's quite different from you having an application running in a goal or an application running purely on Python, for instance. The speed is not going to be the same thing. So they were actually using an old stock and they had to really change that into a modern stack and they were able to achieve 98.7%. So that was a great improvement for business. So in a whole year, when that was calculated, and for you to have effective error budget, you need to measure for a minimum of 14 days of that particular service. 14 days. That is where you can actually, okay, you can come up with something. So ASL-O maturity actually starts from 30 days. If you build an ASL-O dashboard now, you're not going to get the exact better. You have to wait for 30 days before you can really make sense of their dashboard that you've actually made for business. So business actually love dashboard. This is one of the beauty about you being an ICER in. You communicate with business. You are a business person within a technical team. You are a technical business person within the team as well to make sure all these parts are followed and also taken care of as well. So in terms of incident management, also there is a template for that. I think you can chat me up or something. I could share that as well. There's a template and also for RCAs. There's also a template as well. And also for post mortem, there's also a template as well to actually work with. And also on call, thankfully, you'll have a lot of software now that does on call rotation. You can use podcasts to make that happen. You can use Neuralica inbuilt on call that you can actually work with as well. Or you can have your own internal on call system to actually handle that as well. So the whole essence of on call is to make sure, well, I think I will also teach that as well. There are procedures that come with on call rotation that comes in when a software goes down. Who do you have to talk to? Who do you need to speak with? Not in our traditional setting. A software goes down. Everybody is haywire. Who don't know who is responsible? Who is the next person? Who is the right person to actually speak with? So SRE brings in processes within the software paradigm. So the entire SDLC chain, you are part of it till the very last part. So everybody goes to sleep. It doesn't necessarily. You are considering how to really make sure the software is in uptime. And it's only been decided. So there are a lot about to talk about you being an SRE so much, so much. So this is quite a limited time for me to actually talk. I would have also love to do some demos as well. But time is not really going to permit me to do that. I can quickly show you. I don't know if I can share this my screen right now. Okay, there's my screen now. What should I share now? Okay, I think I can share something now. All right. So, cool. All right. So this is a dashboard. All right. And this is a streaming dashboard built with Kafka. And so business wants to see this. Business is interested in this. Business actually wants to see how this is happening and all that. And so this is how business actually makes sense of what is happening in the backend. And this is a very classical example of how this works as well. So this is a Kafka running on the backend for data streaming processing which is live right now. So this is happening live and you're getting live streams and seeing the calls that are happening. So this is a practical example of what an SRE your day-to-day is. You have to build it. This is why I call an SRE. You'll be part of it. You build it. You monitor it. So those are the three core areas you have to really look into as well. So thank you. I think I'm good now. Awesome. I've been sharing everywhere that it seems as if Illyria, you're that plan this schedule. So vision and carefully placed your session to be the last one. You've been touching on almost all previous sessions from yesterday and today. Comments are going all around that this is very interesting. And definitely if we had known we'll have made it one hour to the session so that you take complete one hour and deep dive instead of... Do a deep dive. Do a lot of retries and all that. It's quite big. It's quite huge. Yeah sure definitely. But definitely we'll definitely reach out next time if we are hosting more events so that at least you can share more of the SLOs and SLAs. Yeah. It's always very critical. A lot of confusion around that area. We don't have any questions in chat but I've shared your LinkedIn URL so who can reach out if they have any questions and to ask you and yeah. I don't know if you have a Twitter handle most of our community. I have a Twitter handle. Yeah. I have a Twitter handle, food rank, at food rank 29. Can you drop it in the message here so that I don't make a mistake? Okay. Food rank. Don't mind me. I hope I remember on Twitter handle. Okay. So yeah. You want to reach out to Frank. It's at food rank on Twitter so you can have conversations about things you want to learn and around SREs. SREs is a major thing and there are lots of interests and a lot of companies are looking for more talented SREs. Okay. Thank you very much for your time, Frank.