what he revealed: > Envoy proxy instead of enterprise load balancers > sidecar architecture for auth, logging, rate limits > DynamoDB + SQS for async provisioning > Packer + SaltStack for automated VM deployments at scale

I was recently affected by the layoffs made by Atlassian and I wanted to take some time out to reflect on the time that I spent working for Atlassian. I worked there for about eight years. During that time I built a lot of things and I wanted to talk about what I built, mainly the things that I personally found interesting or that I'm proud of. I hope that this video will be useful or helpful to someone who perhaps is or was in the same situation as me and maybe it'll give them some inspiration in terms of how they can tackle the same things that I did or something similar and perhaps avoid some of the mistakes that I've made. I also might talk about non-technical parts of my experience at Atlassian, although most of it will be technical, and this video will be split into chapters so that you can skip to sections that are more interesting to you rather than watching the video from start to finish. So I suppose to start with I'll talk about when I was first hired and even though it was eight years ago I still remember the interview process, which is different nowadays, and the reason why I was hired or at least from my perspective the reason why I was hired and the things that I started working on during the start. So yeah, let's just start at the interview process. So I was interviewed by some people that I now consider friends and I remember having the impression while being interviewed that these individuals were quite intelligent and that was something that was exciting for me. The interview process consisted of a coding quiz on HackerRank which I aced with full marks. Then the first technical interview was with two interviewers and they gave me a white paper and asked me to read it while they sat out of the room for about 10 minutes. They came back in and then asked me questions about the white paper, asked me to basically articulate what was in the white paper, and the white paper was actually about custom domains and the white paper was by Cloudflare. They then asked me a few questions about things like microservices and architectural things like that, containers and whatnot, and they were happy enough, I don't remember this, but they were happy enough with me during that stage. So I continued to the second technical interview which was a troubleshooting exercise where I was asked to essentially prompt the interviewer for information in order to troubleshoot a real incident that occurred in Atlassian and it was an application problem that led to a denial of service and so that was fun. And then I think I was asked something about how latency-based DNS works and my answer was not accurate but perhaps acceptable. I thought about it from first principles and I thought that, for example, I thought that Route 53 did a triangulation based on the actual latency of the client but it is more like that they probably use a geolocation and a database in order to do latency-based routing of DNS requests, of the DNS answers, sorry. Then after that was a values interview and to be honest I don't really remember most of the questions for the values portion but I do remember one thing which was when I asked the interviewer to think about 12 months from now and to look back retrospectively what is the thing that I would have had to achieve in order for you to say it was a good decision hiring this person. And then they told me about an application that they needed to be built for the platform within Atlassian and the application would facilitate self-service load balance, sort of similar to if you were using Amazon application load balancers or the equivalent in any cloud provider, but for the internal developers of Atlassian. And it was essentially just a framework that I personally was not familiar with and I said I could build it because I had confidence in building web apps with Python at that time and they accepted my level of confidence and decided to hire me. So that's the interview portion completed. So I joined Atlassian and they have this classic saying or impression that when you join Atlassian that you are drinking from the fire hose because there's so much information that you have to absorb in the first few weeks and months in order to just sort of get going. My first, my very first task, at least the task that I gave myself, was to build the application that they had told me that they wanted. Let me just open a browser and take a little look-see at what I mean exactly. Let me just save my face a little bit. There's more real estate. Now obviously Excalibur is not what I care about. So they wanted me to build an open service broker. This is a web app with an API which facilitates the provisioning of resources for a platform essentially. So you can, you can see here, it's sort of built to operate in a Kubernetes world where you're submitting these provisioning requests as things come up and down. And it's going to bind a resource to your pod or your cloud instance or whatever it is, as you can see here. And it sort of sits in between these real resources. So you might provision something like a database and then you'll get MySQL. So you'll get something that says you're compatible but that's abstracted away for your internal developers. Anyhow, the spec is here on GitHub. You can take a look at it. It goes into, it goes into like, for example, the catalog endpoint. And the catalog lists all of the services and plans that are available on the OSP and just metadata about them. And you might say query the service broker and then display some of the metadata in your, maybe you've got a console, a console like the Amazon console, but maybe you've got something like that internally where developers can click and provision things. In the Atlassian case, it was all through configuration files that were committed to version control. And then those would be uploaded during, uploaded from a build server to deploy a service. But yeah, so you might have, you know, other APIs like provisioning here. So put and patch for updating and deletes and blah, blah, blah. So you would just basically go ahead and implement this. I mean, if you want to build your own and that is essentially what I did. You can see also there's a, an open API document here that has the endpoints. So I chose to build this in, in Python using Lask. Oh no, in fact, what I, what I built it with first is with a library called connection. This is a Python library which takes an open API document and then creates the API handlers or the paths for the API, for the API routes that are in that document, which is cool. But then we eventually, I eventually migrated that to just pure Flask and then eventually migrated that to FastAPI, which I believe is what it still is at the moment. Okay. So it's the first two weeks and my primary focus is to build sort of what I promised in the interview, which is this web app. It's going to be a broker for the platform and is going to allow self-service provisioning of load balancing in Elastic. So like I mentioned earlier, I started with this library called connection, which took an open API document, turn that into routes, but I'm going to just go with what it ended up as, which is a FastAPI app. Let's just say we've got FastAPI here and then we've got a worker and then we have a database, which was DynamoDB. That's annoying. And we would have a client making requests. That's why it's FastAPI. The client would say, hey, please provision something for me. And the web worker wouldn't do it itself. It would actually send that over SQS. It would drop the task details into SQS and the worker would then handle that. So what does a provisioning task actually look like? It's something like creating DNS records somewhere, maybe creating a cloud front distribution, maybe creating some API calls. And this would be the provisioning task that the worker would do asynchronously while the web and client would wait for it to be completed, essentially. So the client's polling continuously to say, is it ready? Is it ready? When it is completed, the worker writes it to the database, the web server checks the status and then responds saying, yes, it's finished. Or it will say that something went wrong and there was an error. So then we can sort of encapsulate this as the open service broker that I built. Pretty straightforward. To be honest, there's not much more to this, but we're going to go and talk about some of the more complicated bits in just a second. And I will directly link to this as well. So we've got this client requesting, please provision a load balancing. And that is essentially what they were asking for was some kind of load balancing somewhere in the edge infrastructure of Atlassian to allow traffic to go to their service. So that's a good demarcation point to start talking about the next thing that I sort of built. And I built it through necessity of, essentially, I began to understand and unravel the requirements more as I went along. One of the architects had this idea to replace the load balancers at Atlassian, which were enterprise load balancers that had licensing costs, with a open source cloud native sort of commodity proxy. And the tech that we chose for that was Envoy proxy. You may be familiar with Envoy proxy. If you're not, then it's very similar to something like Nginx, but perhaps more modern than Nginx. You can take a look at what's great about it. If you want, you can just read through like why choose Envoy, blah, blah, blah. But essentially, we wanted to replace the enterprise load balancers we have. Make them self-service so that devs effectively didn't have to talk to us to go set up their load balancing. So Envoy has an API that allows you to configure it dynamically. Being able to reload the configuration at runtime means that you can deploy a whole bunch of proxies and have them sit there running all the time. And then when someone needs different configuration for their particular service, then they can push out a change through the provisioning task detailed here, and those changes should flow to the proxy somehow. And so now that's a good time to talk about the Envoy management server that we built, which we call the Envoy control plane. And this was, it's essentially quite similar to this. Yet again, we used a fast API, but this was slightly different actually. Let's go into a little bit of detail here. I'm just going to wing this because I should be able to wing it because I know it quite well. This is actually a, I open sourced this software and I called it Sovereign. You can actually go find that on Bitbucket. It's a public repo, at least for now. I don't know if that's going to be the case always, but essentially Sovereign runs a fast API app. And some of the things that it takes in as a configuration are templates and context. And so the app polls these. It's obviously got, let's just say this is the configuration. Now, so the templates might be particular resource types. And in Envoy, you've got stuff like clusters, routes, listeners, and let's just leave it at that for the moment. You'd have these kinds of templates. And so when this management server loads up, it'll read in these templates in the context and make these available as APIs for the proxies. So then you can imagine, let's just say you've got an Envoy here. It is going to request these things and Sovereign is going to respond by taking the context, putting it into the templates and rendering out different content as the context changes. Now, where does the context come from? Well, this is part of this management server that is dynamic. So let's just do a bit of flip around here with the context here. The context actually comes from this database, but we are requesting it from the broker. So we're requesting data from the broker and other sources. In fact, let's just add another source here. Let's just say we have a little S3 bucket with some data, and maybe that data is changing over time. So we take that data. It's dynamic. We feed that into the templates. The templates have logic that spits out particular Envoy configuration. And then the proxy changes over time. So what happens is we've got a client that's making provisioning requests to our broker. The worker is doing some provisioning tasks and then writing the new data to the database. Then the management server is then pulling that data from various places and generating new configuration. That configuration hits the proxy and then it starts doing different stuff. That's essentially the second part of what I built. So we've got a broker, we've got a management server, we've got the client, we've got the proxy. Why did this detach? Anyway, so now we've figured this stuff out. This is all at a very high level. So we've got this created. Now we can think more about more infrastructure type things. We've got this proxy, but how do we end up with this proxy? How does that actually get provisioned? What is it? Where does it live? Well, let's start with one thing, which is that these proxies, there's many, many, many of them, as you would expect, and they are provisioned by a cloud formation template. This is an AWS thing that allows you to essentially do infrastructure as code. It allows you to create resources in AWS that you would normally create via the console if you were just, let's say, a basic user. So what kind of stuff do we create in here? Well, if we were to do this stuff from scratch, we'd probably have a VPC, and then we'd have a subnet inside that VPC, and maybe we'd have an internet gateway, and maybe we'd have a good old security group. Maybe we'd have a key pair, maybe an IAM role. Oh, of course, we need to have the autoscaling group. Of course, that's what's going to be creating these EC2 instances, and well, the autoscaling group needs an AMI, doesn't it? Indeed, it does need an AMI. IAM role has to be attached to all these. The key pair goes on these. Security group is attached to this. Well, it's probably attached to the autoscaling group, to be fair. Well, the EC2 instances would inherit it from the ASG, blah, blah, blah. So we've got all these blocks of resources and stuff like that. Cool. So yeah, we've got a little template going on here, and it's creating these proxies in many different regions. We've got an NLB in here for layer 4 proxying, and we'd have maybe a bit of ACM. Of course, these acronyms might mean nothing to some people, but for people that have used AWS, they would know what these things are, and they know it's not really that complicated. It's like pretty basic building blocks, and this is what we created. 2,000 proxies, something like 13 regions, blah, blah, blah. And we also had a little bit of route 53 records for a lot of stuff. Now, the AMI, it's not really provisioned by the template. It's more like it's referenced by the template, isn't it? So that would bring us on to the next piece of this thing that I built, which is, well, we need to produce an AMI. We need to produce a standard image for these proxies, and it's going to include all the important stuff in there. So how do we create this image for the proxy? Well, in this case, we had a repository that was using HashiCorp Packer, and we had a SaltStack, let's call it configuration. And so we would use Packer to, let's say we have the EC, we'd use the EC2 provisioner, and so we would create an EC2 in a dev account. We'd then upload all of our SaltStack configuration. SaltStack, by the way, is very similar to Puppet, Ansible, and Chef, in case you're not aware of what those are. It is configuration management tools, and that's a fancy way of saying that I want to run, I want to install packages, put files, and run services on a machine in a particular way, in a particular order, and it automates that process, makes that process declarative for you. Well, not for you, but it helps you to make it declarative. So we created a little EC2, live running EC2 here, we dump the config on there, we do a provisioning step, and then we take the, essentially, turn this into an image, like cut it down, whatever, snapshot it, and turn it into an image. So that essentially would just produce this AMI. Now, what was included in here? Let's say we can just, we can include a few things here. Let's just say we had states for Envoy, let's say install, configure, let's say just install and configure, Envoy, logging agent, security, let's say slash hardening, network tuning, containers, tracing, let's just say, let's just say observability agent there, and that can cover, that can cover logging, tracing, metrics, so that's essentially what's going on here, produces the AMI, CloudFormation template takes this AMI, provisions these EC2s, and they're running with all this stuff, and then when they, when they get provisioned, ah, that's something that we forgot here, there's parameters, parameters, pump this up, make it neat, so we've got the parameters, and these at runtime would pass in secrets, and keys, and blah, blah, blah, and then these, these proxies would grab their resources, be configured, and then they would be running and accepting traffic, boom, that's it, everything's done working, this was essentially the first two years of working at Atlassian, so now when a developer says, I want to run my service, and I want it to be, uh, I want it to be accessible on the internet, with all the fancy bells and whistles, and routing, and advanced stuff, we'd say, yes, no problem, let me just get that provisioned for you, we send off the provisioning task, we write something to the database, we tell them it's ready, and the management server hits the, uh, broker, says what's the current state of things, takes that data, plus other data, puts it into the templates, creates resources out of those templates, gives them to Envoy on when it requests them, and this was all pre-provisioned, that's long-lived infrastructure with CloudFormation, and the CloudFormation is relying on an AMI that it can use to provision those images, those machines, so yeah, that is probably the first 24 months. So what was next after this? So this was the foundation of our team, essentially the product that we were going forward with, um, which is, uh, centralized load balancing managed by our team, and all of the features that we provided to our customers would live in logic defined in these templates. We've now laid the foundation for the team, we've got proxy infrastructure that's reacting dynamically to services that are being deployed with different configurations over time. What was next after that point? The big thing after that was taking some of the larger products and making it possible for them to use this platform component. That was one big part, and the second big part was migrating all of the microservices within Atlassian to use this, and that was relatively easier because we could enforce that through the platform. Essentially what that means is that the platform was previously providing very basic load balancing to every service, and they forced a switch to where you could no longer expose your service publicly through their load balancer, which was too basic, and you had to go through our centralized load balancing infrastructure and to explicitly configure it as a way of signaling your intention for that service to be publicly accessible, whereas previous it could have just been maybe accidental that your service was public and not very well protected. So that was the big major push. We got products like Jira, Confluence, Bitbucket, StatusPage, and many others behind this edge infrastructure. And then what was after that? Well now we can sort of talk more about, let's say we can talk more about the Envoy-based product that we had here. So this particular thing, we've got this groundwork of being able to take basic inputs from a developer and to turn that into templated configurations. Now Envoy has a lot of configuration. It has a lot of stuff you can configure. Let's just look at the routes, for example. Let's look at the virtual host, for example. You can configure what domains to accept traffic on. Pretty basic. You can do routing. Sort of basic, but once you delve into how you can do this, it gets pretty complicated pretty quickly. You can match on different things, you can route it in different ways, you can do direct responses, you can do redirects, blah blah blah. You can add and remove headers. I guess you could say that's pretty standard, but you can also choose, for example, when you're configuring a route action, you can also choose to send to any cluster that's on the proxy. So then if I have a thousand devs, or a thousand services, and they each have their own cluster, and any route consents to any cluster, well it sort of brings up this point of, well, this data here needs to be validating that, and abstracting that, and so on and so forth. So there was definitely a concentration of a lot of the development work around this logic here, making sure it was validated here, in terms of the parameters were validated, such that when those parameters were run through the logic in these resources, that it would produce valid resources. Pretty standard, I suppose you could say. I don't know, maybe. I do feel like I have the curse of knowledge, and that this stuff seems easier to me now because I've done so much with it. But there's a lot, there's a lot in here. And if we go into, for example, extensions, there's a lot of extensions that can be applied to a listener or a cluster. For example, you might have, where is it? You've got network filters here, you've got all kinds of network filters, and a big one that we obviously used was a HTTP connection manager, where you could configure routing, and how to handle proxies, and web sockets, and all this stuff. And then if we go a little bit before that, there's also things like external processing, and external authorization, and this sort of brings us to, oh, let's say something that happened next. So I did briefly mention that some of the big parts after building this was to migrate big products onto it. Let's assume that's all finished. It took some time, it took probably a couple years, because there were many features that needed to be built out here and wherever else in order to support the larger products and their special cases to work on what's effectively a generic multi-tenanted platform. So let's just assume that they're all migrated. Then we have more features that we want to add. I did sort of allude to, we have this groundwork, we have this dynamic configuration. What I'm trying to say is we created opportunity. We created opportunity to centralize logic and to handle concerns early in the chain of requests. What I mean by that is a customer, let's just make a custom smiley customer, and customer is someone that's using our cloud products or Atlassian cloud products. They are hitting the, that's them being proxied to these books. Yes. If we can deal with the problems here before they reach a service, let's say, let's give a square, let's call it a backend service. So the requests are flowing in the customer to the proxies and to the pretty standard stuff. If we can deal with certain concerns here before it reaches here, we save a lot of time. We save some money, which is, and it saves the customer time. It's great for everyone really. And one of those things, now this is where the diagram becomes complicated. So let's move off to the side. Let's just copy a few of these. Let's grab three things. Let's move over to the side. We've got the customer talking to the proxy and the proxy is talking to the backend. Now, of course, the request comes back up and back out to the customer. Fine and dandy. Yes, this is a proxy. Whatever. There's no surprises here. Now, with the products that Atlassian runs, there's all kinds of stuff that needs to happen, like authentication, for example, or authorization, or DDoS protection, or rate limiting, or access logs, all this kind of stuff that needs to happen. And it's just turns out that we can deal with them here instead of on a bazillion, bazillion backend services. Just imagine that there are a bazillion, a zillion of these, just zillions upon zillions. See Daisy? Just zillions and zillions, like a gazillion. Now, can you imagine if a thousand dev teams needed to deal with all this stuff plus more on their own service? It would be a tremendous waste of money for the company. It would slow down features. The customer wouldn't get their features when they need them. And stuff is already hard enough to deliver as it is. Thus, the platform and centralized management of resources and centralized implementation of these features. So how were some of these things implemented? Well, DDoS protection was really provided by CloudFront. And that was spearheaded by a colleague of mine who is very smart and conscientious. And essentially, let's make this a bit more accurate. Let's just say, get rid of these. There's an NLB here, blah, blah, blah, blah, because it's two-way. So that's one way that we can take care of that concern for these backend services. Great. We've solved the concern for that. Fantastic. These others? Well, access logs. What we can do is something like, we can use these network filters. Yes, we use the network filters. For example, in the HCM, we have access logs. Access log. Now remember, all of this configuration is dynamic. It's all dynamic and it is created by templates which abstract away the resource configuration from the developer who wants to configure it. They provide simple parameters. Those parameters are then validated and then they are fed into the template as context so that we produce the correct template. That means that they send us a little bit of JSON and we set up this whole thing for them with all the access logging and blah, blah, blah, whatever. So that is done, in fact, inside the proxy natively. Fantastic. Some of these things, however, are a little bit more complicated. These things, we need to use a sidecar model where Envoy is talking out the side and then these are their own services running locally on the proxy. So these would be like containers, essentially. We've got this sidecar model and those sidecars, some of them are contributed by other teams and some of them were created by me and our team. The authentication sidecar was created by me, written, of course, in the Lord's language, Rust. Authorization was done by another team and rate limiting was done by another team. And so they were able to contribute these sidecars, which, by the way, were set up and were downloaded and configured onto the AMI by this provisioning, AMI provisioning log. Great. So now we have a programmable proxy with sidecars that have their own separate logic from the proxy and they, too, can actually receive configuration, which is dynamic, over the wire locally and make it even more programmable. So we're solving all these concerns before they hit these backends and in very, very little time. So that was, essentially, that is some of the stuff I worked on after migrations and blah, blah, blah. Yay. What had some non-technical requirements come through, more compliance and things like that. And that effort was very tedious and boring for me personally. It didn't involve building new stuff. It involved taking all of this, making sure that it was compliant in certain ways, very boring checklist ticking work, blah, blah, blah. So I said earlier that I would also go over the non-technical things that I had to go through while working at Atlassian. Obviously, all of that stuff is sort of high-level technical stuff that I just showed. What was some of the other stuff that I went through during my eight-year slog at Atlassian? The first few things that come to mind is that I have grown tremendously in my diplomacy skills, conflict avoidance, probably conflict resolution as well, being able to persuade, propose ideas, being able to teach, educate, mentor. These are the non-technical things that you probably don't hear a lot about. But after... Another thing is that the ability to maintain things, maintain software and systems, to see where the cracks show up and to build things so that those cracks don't show up, or at least to make them show up late as possible. That's definitely something that I picked up. Let's just talk about that maintenance for a second. I noticed over the eight years that I was there, when I built these apps, these services, that there's obviously that at the very start, there's the requirement to onboard people and write documentation and train people so that they understand how things work, know how to contribute to them and debug them. So that when they go on call, they know where to look, what could go wrong, where do things break, essentially. Whether that's knowing what particular log messages mean, what sort of metrics to check when something is going wrong and what those metrics could allude to, how to resolve those particular expected problems if they're not automated away. And this could be like, Amazon could have an outage and the database is in excess, for example. What do you do in that case? What if SQS stops working and you can't do any provisioning tasks? What impact does that have on the services that need to provision their resources and how do you resolve it? What happens if a proxy receives bad configuration? What if it receives configuration that's valid but that destroys the traffic that's flowing through? How do you pick up on those? What do you check? Etc, etc. So there's obviously a lot of that at the start when you build something. There's a lot of that at the start. But the thing that's more difficult is, over time, people come and go. People get hired. People leave for other jobs and whatnot. And so you get, you have to do that onboarding again, obviously. But you should have more people that are able to do that onboarding collectively. But then you sort of bring in new opinions. People look at an existing codebase and they want to change things. They want to make it better and so on and so forth. And so they do that. And change ends. I suppose there's this concept of churn in the codebase. The area that churns, it's sort of, it becomes predictable where all the churn is going to be at a certain stage. And once you notice that there is some churn, it's sort of a smell. It's an indication that that part of the service or project is going to keep increasing in size or complexity. And something there needs to happen. Something needs to be done to avoid that mess. It's just how software goes, I suppose. It'll be interesting with all these vibe-coded apps and AI-assisted apps to see how we handle that. When we have people that are not really familiar with what they've created and the maintenance burdens appear. They don't appear at the beginning. There's just not enough going through. It hasn't been around for long enough. There hasn't been enough changes. Building something is easy. Changing it and making sure that you can still change it over time is difficult. Because as you change things, it slowly becomes harder to change. Things start to get coupled and all of a sudden when you change something in one area, it affects another. And you have to deal with the task of detangling. And you might be able to find these areas quite quickly. Get an LLM to perform the detangling for you. I think that's, if we can do that, that's fantastic. But I don't want to be too optimistic just in case. So there's that. That's my opinion on the maintenance side of things. The next thing I want to talk about is when I mentioned diplomacy, what I'm really trying to say is that I was exposed to different types of managers and colleagues over time. And everyone has different personalities and styles of working. And because I was exposed to so many different types, I experienced conflicts with certain people. And even though I had conflicts, they're still people that I respect. It's just something that happens when your personality doesn't mix with their personality. And that's just something that's a bit inevitable. And I think that the only thing you can really do in those situations is to try to have the self-awareness and the awareness of the other person and the, I suppose, understanding of psychology and how people work to an extent so that you can be responsible for that difference and the potential for conflict and to handle it effectively, to anticipate the conflict that's going to arise and to do something to make the relationship work. And maybe it's impossible, I don't know, but that was definitely a source of great stress. And at times it affected my performance. And so I do think that because it affected my performance that I took it quite seriously and I learned and changed as a result. So the next time that those situations come around, I do firmly believe that I'll be able to handle them quite a lot better. And then some of the other things, in fact, one of the things that I found quite challenging was mentoring. And so I find it easy to help people to point out areas where they need understanding and to deliver that understanding to them, to break down complex things into simple terms so that they can build a mental model of the system that they're working. I have that ability, I'm quite good at that. But mentoring is distinct from that. I had an intern in the last year and I will first say that the result of their internship was that they got the highest rating possible. And it essentially guarantees an offer to work at Atlassian. The project that they worked on was very impressive and how they approached it and built it was very impressive. And so that's why they got that excellent rating. What I found personally difficult was striking the balance between, it was essentially striking the balance between how much time I give to the mentee and what that time would consist of. Whether it's, you know, I don't want to give them answers to problems, but I don't want them to get so stuck that they become frustrated. I have no idea if I reached that balance, but I suppose the results speak for themselves. But I'm not sure if I can attribute the results to me necessarily. The intern was helped by some of my other colleagues in areas that I'm much weaker in. So they effectively got subject matter experts in a few different areas to contribute to their success. But then they did the majority of the legwork to actually build the thing and to test it and to make design decisions and stuff like that. And it was very successful. But I still have this lingering impression or feeling that mentoring is difficult for me and that I don't have a good way of figuring that out because I've never been mentored myself. So I don't really know what to expect and what they do. But I want to emphasize that that's a very specific type of mentoring that I'm not too sure about. Whereas training my colleagues, getting them to understand, working through problems with my colleagues, that was essentially my bread and butter during the last half of my employment. You know, jumping on a call and going through stuff. The feedback that I got from my colleagues all the time was that I was always available to help and that I could boil down hard topics into something that was understandable, which I'm pretty proud of. And I've been yapping for a while. I think that covers quite a lot. If I remember more, I'll probably just make a second video. And maybe if people are interested, I could actually go through and build some of these things. I could actually go through and build some of these things from scratch on stream or just a video uploaded to kind of show, I guess, essentially what I made and maybe recreate and sharpen my skills a little bit more. Maybe. I've got a lot of stuff on my to-do list, so maybe, maybe not. It depends on the demand. Anyway, I'm going to cut the video from here. If you listened all the way through or to portions, then thank you very much. I hope it was interesting and enlightening and whatever else. I'll catch you around.