Considerations Q&A

[00:00:00]
>> Speaker 1: So I'm currently working on a large-scale platform for e-learning with a small team for backend devs, so we're starting out the project as modular. So if we need to turn it into microservices, it's easy. We're planning to use DDD, do you have any suggestions for us?
>> Erik Reinert: Planning to use what?

[00:00:19]
>> Speaker 1: Domain-driven design.
>> Erik Reinert: Okay, yeah, I mean, when you use domain-driven design, you really wanna have good structure and understanding of your domains basically, how do you define those domains? What exactly do they connect to? Right, so domains could be something as simple as saying, okay, this is all frontend learning, this is all backend learning, or it could be structured more on the organization, right?

[00:00:45]
Like this team owns this domain versus owning that domain or things like that. Domain-driven designs are really just about you separating how you want to separate your platform. In a way where you can easily organize it, that's really it. So if you're more focused on how to manage and maintain these domains, then it might be helpful to think about the teams that are gonna be working on it or the people that are gonna be working on it.

[00:01:17]
Think about how you isolate those components through those teams so that it's easier for them to do what they need to do, and they're not impacting any other teams. You should probably sit down and break down your company into the domains that you want and then let that trickle through all of your designs and how you do things.

[00:01:43]
>> Erik Reinert: But if you don't know those domains, you gotta start there [LAUGH].
>> Speaker 3: Especially with the user feedback portion you touched on, it feels kinda cyclical of put this out, get it back.
>> Erik Reinert: Yeah.
>> Speaker 3: But working with designs, right? How do you make sure you go back to the design and look at that versus just okay, let's implement this piece kind of thing, is it just diligence?

[00:02:07]
>> Erik Reinert: Yeah, I mean it's a bit of that culture we were talking about before. If you make a design once, and then you keep iterating over it, but you don't really know why it was done the way it was, right or things like that. Then you'll have this algumation of what it used to be and now what it is, right?

[00:02:25]
And you can easily crawl away from why some of the decisions were even made. I've done this myself where I've moved something from asynchronous to synchronous or vice versa. And then somebody being well, no, no, no, we did this because of this, we don't wanna move back, right?

[00:02:46]
Having good context and keeping that context can be really important. I mean, I think this also kind of just is also a bit focused on the organization of your company. For example, at Hippo, we have principal engineers, we have staff engineers, which is really what I am now.

[00:03:05]
And then we also have senior engineers and stuff like that. And I think what happens is, the company needs to have good structure to where it gets to a point where a principal needs to step in, right? And be able to say okay, let's reconsider why we're doing this and let's think about what we did before.

[00:03:24]
That's also, I kinda talk about that in the DevOps for developers course, which is DevOps is not just implementing. Because again, a month later you'll have a completely different system. It's about thinking about, why you're doing what you're doing. Sometimes, it's not the expectation of somebody who's just taking tickets and building things all day to do that.

[00:03:47]
But it is on the responsibility of your engineering manager, of your product manager to be able to say okay, we need to pull in a principle here we need to pull in somebody else to help with the knowledge gap. But understanding that knowledge gap is important. Don't do something just because you can, have reason for it.

[00:04:08]
>> Speaker 1: What's your TLDR answer to when should you use backend architecture design?
>> Erik Reinert: I think, again, kind of going back all the way to this the quote from AI, right? Part of it is noticing a problem that might be happening. You have to have a reason to do it.

[00:04:36]
If you're introducing complexity for no reason, then you're just really doing something for yourself, right? But as I do in DevOps and things like that, my goal is to help better a different part or a certain part of the system, right? So I would start first and foremost by saying, if you have a reason to do the design, then you're already 50% of the way there.

[00:04:59]
But normally these designs come out of problems that you're trying to solve, right? And so if you don't have a problem that you're trying to solve you probably don't need to be doing any of this.
>> Speaker 4: What would be a good key indicator that an existing system that exists needs to be re-implemented or re-architected from scratch?

[00:05:19]
>> Erik Reinert: So there's two parts to that there's first the doesn't need to be implemented, and the second part, which is does it need to be implemented from scratch, right? I think you have to answer them separately not together. When you get to a point in your career where you start just looking at problems as a detective trying to solve them, you need to have some sort of trail of why we're here, right?

[00:05:56]
What has this produced as a problem over a period of time. Where are the breadcrumbs to finding that, right? At the end of the day, you really just don't have any need to change anything if there's no value or reason to it. So that's what I would say is the first part is, find proof, find evidence that helps with your theory, of should it be changed, right?

[00:06:21]
I've heard this a lot, and I've slowly begun to accept it more in my career, which is just because you don't like dealing with something, doesn't mean it should be changed, [LAUGH] right? And a lot of the times in DevOps especially going back to the who are you helping, if you're not helping anyone making that change then there's no value to it.

[00:06:48]
So again, that breadcrumb is really important. The second part of should be changed entirely, that becomes a much bigger scope, right? And sometimes it even is easier to say well, let's change it a little bit now, learn from that change, and then see if we still need to change it on a higher scale or on a bigger scope.

[00:07:09]
And if you do, then I think at that point it becomes buy in. Does anyone else at the company feel the same way you do, right? Can you find those people to jump behind you and say yeah, this is a problem and we need to do this. It's really, really hard to make massive change by yourself at a company, especially a big company.

[00:07:33]
As a good example, like I said, where I work right now we're moving to Kubernetes, right? Do you know what the first thing was said, or when we brought up we should move to Kubernetes? Why, ECS is fine. And they're not wrong, it does work, it does run for us, right?

[00:07:54]
But our only argument with that in the beginning was well, because we wanna make our lives easier. Which was true, but it took us a year of research and development to figure out well, we can also improve our CD, our delivery system. We can also improve our scaling we can also give developers control over routing and things like that, right?

[00:08:17]
And at that point I'm not talking about Kubernetes, I'm talking about problems that I can solve. So if you have a need to make a change at that scale, you also need to have a lot of reasons as to why you should make such a change. And normally, it cannot just be because of you, or what you or even your team wants.

[00:08:40]
You normally want other teams to back you so that that radical change is easier to promote through the company, yeah. Again, it's salesman [LAUGH] why buy this car instead of that car. Well, because that one's a lot more comfortable, [LAUGH] stuff like that.