Key Challenges: Overview & Complexity

[00:00:00]
>> Erik: So let's talk about the key challenges, right? These are always fun because these are what most people deal with when talking about doing architecture designs. There's a lot of challenges with building architecture designs. And as you go higher up at a company or you deal with more people, basically, you have more challenges, right?

[00:00:21]
If you're just building a system by yourself, sure, you might deal with things like complexity, adaptability, security, and technology, and even potentially resources. But I think the last one there, which is also incredibly important, especially if you work at a company, is your stakeholders. And we'll talk about each one of these in more detail.

[00:00:41]
But again, the main challenges that we're gonna go over are the complexity of an architecture design, the adaptability of it, the security around it, technology, resources, and then, as I mentioned, stakeholders.
>> Erik: First one, and this is probably hands down the one that people deal with the most, which is complexity.

[00:01:05]
I personally have struggled with this a lot in the past because I'm slightly autistic. Building wireframes and charts for me is very soothing, and so I can spend four hours building an architecture and then go step back and go like, my gosh, this is spaghetti. You really want to think of the complexity of the system while you're building it.

[00:01:27]
A lot of times, the higher, or the more often you distribute, the more often you spread out, the more that complexity enhances, right? So you wanna think about handling the intricate details and interdependencies in a system before they become too plex and basically completely, what's the word I'm looking for, uncharitable to other teams or things like that, right?

[00:01:52]
If you have to sit in a meeting and share something for like 20 minutes and then nobody understands what you just talked about, I'm sorry but you actually failed not them that they don't understand it. I know that you might feel that way, but no, it's that you actually might have made too complex of a system that was too hard to communicate.

[00:02:11]
Here's a good example of that. This is actually one of the first systems I ever built. And this was probably when I first started getting into architecture designs. This is actually the V1 of the content creator tools platform that I'm building called Quirk. I had originally built this as kind of an explorative opportunity for me.

[00:02:39]
I was working on a project by myself, I wanted to work with a lot of new systems and try new things. What I didn't realize was the complexities that I had created had become so much that I really needed a team of 10 people to manage that system after I created it.

[00:02:57]
And to showcase that a little bit further, the users are on the left, so you have the main users who access the system, and then you have the developers who actually need to access to build the system. As we go from left to right, the users will send requests to like an ingress, so something like CloudFlare, right?

[00:03:19]
Then that will go to like a load balancer, which I was really interested in getting more comfortable with WAFs at the time and figuring out how to work with CDNs and things like that. But I also really wanted to work with Kubernetes, which if anybody here has ever used Kubernetes before, you probably know that that's not a very simple system, especially for one person.

[00:03:40]
But I was very adamant on using Kubernetes because I wanted to try it. But if anybody here has ever built a system before, you can immediately look at this and go like, this person kinda didn't know what they were doing. And so I wanted to figure out distributed services.

[00:03:58]
And I went as far as even, you'll notice in the middle there with the little purple squares, I went as far as to running my own serverless framework called Knative. Why did I do this? I have no idea. When I could have just used AWS Lambdas, which already existed, which already had robustness, extensibility, all these things around it.

[00:04:20]
But, again, I wanted to be able to learn how does serverless work? How do you deal with it? And again, I think a big takeaway here is that the more complexity you add, the more that you own, right? If you are one person, you probably cannot maintain something like this at scale without never sleeping, which I don't recommend, yeah.

[00:04:45]
>> Speaker 1: Someone's online says they only know one thing on that chart, which is the API.
>> Erik: Yeah.
>> Speaker 1: And things like load balancers and etc are newer to them.
>> Erik: Yeah, I mean, in all honesty, it was It was some of these things were new to me as well [LAUGH].

[00:05:03]
And if a system becomes too complex to where you show somebody something like this, and then they immediately go, you might need to even figure out better ways of showing that complexity. There might be reason why you have complexity, I'm not saying Kubernetes is bad, I love Kubernetes I use it at work, I actually just recently designed our new infrastructure that will be running entirely on Kubernetes, right?

[00:05:30]
But what I realized when I was going through that process was domains, right, figuring out how to separate these things. So maybe we just show the backend for a specific team and how that domain works, right, or how we can separate routing from inter-service communication and things like that, like external from internal.

[00:05:52]
Complexity sometimes is required and just throwing it all in one huge chart like this and kind of making like a where's Waldo, doesn't really help and that's probably the biggest thing I want to be able to showcase, yeah.
>> Speaker 2: You talked about a structured approach to complex problems.

[00:06:09]
And then you have the content media platform. Can you talk a little bit about the questions that you would ask to sort of arrive at this content platform is where I wanna end up?
>> Erik: Yeah.
>> Speaker 2: What are some of those steps that would lead whether it's this complex or simpler?

[00:06:28]
>> Erik: Yeah, okay. I think always having a North Star and what problem you're trying to solve is important, right? I think one of the things that is in the system that doesn't really do a good job of showcasing it is every one of those orange things is basically a container solving a specific problem.

[00:06:51]
You can see that the API in the top left-hand corner is really focused on just serving the frontend requests, things like that, one problem solved. I now have solved where my frontend requests go, right? However, maybe we also have WebSocket requirements that we need, and we don't want those to be coupled with the API because they're two different transports, right?

[00:07:15]
HTTP is normally what you use for an API, which is just normal transactional requests, but then say, okay, I wanna interact with real-time. Should you join those together? Should you separate them? That's kind of a North Star as well. It's like, do you wanna keep those together? Do you want to scale your API and your WebSockets together?

[00:07:36]
Do you wanna separate them? And then as we kina move further in the architecture, you'll see that there's like a Twitch bot there, which allows me to handle all of the Twitch connections and all of the Twitch messages. There's a Discord bot in there. And that separation is, okay, well, I know I could create a bot, but do I want my Twitch logic and my Discord logic together, right?

[00:08:01]
So those are kinda the questions you wanna ask yourself is like, what problem am I trying to solve? And am I solving it too complex? Is it too simple, right? Going into the scaling and robustness and things like that. One of the things that I would say, for example, that was probably a bit overkill was, in this example, the Twitch bot really just fires a lambda for every time a message is sent.

[00:08:27]
Scaling that is not a good thing [LAUGH], right? Especially if you are using something like AWS lambda and you have millions of requests coming in, it may just be better to have it all in one bot, right, and have that just be a process that's running all the time.

[00:08:44]
So considering, again, what problem you're trying to solve, as well as how complex you wanna solve, it should be able to help guide you with those specific components you're trying to make. Does that answer your question?
>> Speaker 2: That's helpful.
>> Erik: Okay, cool, awesome. Yeah, don't be afraid to start simple as well.

[00:09:05]
I know there's a lot of egos in our industry [LAUGH], but the reality of it is, is, if you're building the system for the requirements that you need, everyone else can shut up [LAUGH]. It's true, and I've been in many conversations with that where somebody will say, well, it's too simple.

[00:09:22]
And I'm like, well, have you done this before? And they're like, whoa. And I'm like, okay, well, then let's try this first, and see the easier approach before we make it overly complicated. And that is even something that I would lean on more than not. The biggest thing you wanna do is save your time.

[00:09:38]
And this architecture did not save me time, this architecture also did not save me money. I think it was like 500 dollars a month. And again, I'm just like a balling on a budget [LAUGH], don't have a lot of money. We're taking it, put subscribers, by the way, subscribe.

[00:09:58]
>> Speaker 3: [LAUGH]. But yeah, no, seriously this was entirely not even considering the fact of our budget concerns and how many people were working on it and stuff like that.
>> Erik: Even though it might look really cool [LAUGH], it depends on how valuable it actually is, yeah.
>> Speaker 3: You may touch on it in a minute here but-

[00:10:17]
>> Erik: Sure.
>> Speaker 3: When building out something like this, how do you determine how much new I just wanna explore something, things to get into?
>> Erik: Right, yeah, well, this is a good example of that [LAUGH]. And we will talk about it a little in a little bit, but I think it's that's all about how much value your time has, right?

[00:10:43]
It's really good to explore things when you're at home chilling and watching a stream or watching a YouTube or something like that. But I've even done this as well where I've been like, yeah, don't worry, we'll get it, we'll get it in a week. But then I keep making it more complex, keep digging myself into a hole and then being like, yeah, this is why it's not there, and then they're like, well, why did you do this?

[00:11:08]
Exploration can be great, but as some of our frontiers have also seen, it can also hurt you. So avoiding pitfalls, avoiding things that are completely out of your term or understanding might be good things to kind of avoid, at least if you're at your day job. I personally think software engineering is not just like a job, it's also a passion.

[00:11:31]
I think it's something you wanna be very passionate about. And kind of like doctors are constantly reading medical books, we're constantly looking at tech articles, we're constantly seeing how people are doing things. And so I think having a good guide to why you're exploring can be really important.