Check out a free preview of the full Introduction to Backend Architectures course
The "Distributed Architectures" Lesson is part of the full, Introduction to Backend Architectures course featured in this preview video. Here's what you'd learn in this lesson:
Erik discusses the differences between generic services and microservices, emphasizing the importance of correctly designing microservices. He highlights the benefits of service-oriented architectures, such as continuous delivery, deployment of large applications, and faster time to market for new features.
Transcript from the "Distributed Architectures" Lesson
[00:00:00]
>> Erik Reinert: So let's talk about distributed or service-oriented architectures. Now one of the reasons why I used this GIF is because I've always felt like services or distributed services are really satellites. They're these things that you throw up into the cloud, you hope that they talk to each other, you hope that they get a signal and work together fine.
[00:00:19]
And you've got a bunch of these floating in the sky somewhere working together. However, distributed doesn't necessarily just mean service-oriented, right? Distributed can mean a lot of things. I'm just going over the service-oriented design because there's two types of services that I wanna talk about. Distributed alone as its own conversation of, how do you handle distributed workloads?
[00:00:46]
There's things like queues, there's things like, again, event busses. There's a lot of different approaches to handling distributed architecture. However, those aren't used as much as just service-oriented or SOA approaches. So that's why we're gonna be talking about service-oriented today. I also wanna note, monolith, distributed, and serverless, the things that we're talking about are normally at almost every company or have been worked on with most companies.
[00:01:18]
A lot of companies are still getting comfortable with event based systems. A lot of companies are still getting comfortable with more advanced approaches, even like PubSub and stuff like that, are still new in the industry and a lot of places. A lot of the forward leading companies are in that because they need to.
[00:01:38]
But monoliths, distributed services, and even serverless are really still like the big beasts that everyone are talking about when we talk about building backend system architectures. So let's get into it. So we're gonna talk about two different types of service-oriented architectures for distribution. The first is gonna be generic services and the second is gonna be microservices.
[00:02:04]
And I'll go into that in a little bit in just a second, but let's do our definition first. So generic services and or microservices architecture is a method of developing software systems that are loosely coupled and independently deployable, smaller services which run have their own processes. Now again, we've talked a lot about architectures, how to define them, how to understand them.
[00:02:28]
My hopes are at this point, you can see why this can be valuable, right? Compared to a monolith, distributed services can make it so that you change smaller things more intricately and more quicker without impacting other parts of the system. However, I do wanna make sure at least in this course that you understand the difference between generic services and microservices.
[00:02:58]
Because a lot of people do not design microservices correctly. [LAUGH] It's something that most people will say, yeah, we use microservices. And I'm, okay, cool, can you show me your architecture? And I'm, no, you're just using generic services. That's not a microservice approach. Companies, again like Google, Amazon, Netflix.
[00:03:19]
These are companies who are separating microservices into teams. So one team is handling one small service that has its all own isolation, its own database, its own running service, its own replicas, its own processes. That is the difference between a generic service and a micro service. Let's talk about the service-oriented overview.
[00:03:40]
This architecture allows for continuous delivery and deployment of large, complex applications. It also enhances the organization's capability to innovate and reduces the time to market for new features. As I said before, when you've already got a lot of infrastructure that you've built, you've worked on, you've iterated over, you've solved for a lot of these problems, and if you distributed it well, it will work.
[00:04:03]
Now let me ask you guys a question in the situation of I wanna have a way to add new features quicker. Which do you think is better using a monolith or using distributed services? Which do you think is actually would get you services or changes out quicker?
>> Speaker 2: Distributed services?
[00:04:24]
>> Speaker 3: It depends on the feature [LAUGH].
>> Erik Reinert: Yeah, it does, it does, it definitely does. And so that's something I want you guys to take away from this is it really depends on the scale, right? And what already exists, right? In a monolith, if you've already got a lot of these things in the monolith, then it could be just as easy to add stuff to the monolith, right?
[00:04:45]
But if you have a large scale of microservices and you're already dealing with things like authorization and security or encryption and things like that. That means that in the future when you wanna add just this one small component. You've already solved a lot of these other challenges in other locations you can automatically again going back to the bot example, right?
[00:05:07]
We know that the way we built the bot engine, I can just easily plug in YouTube. I can easily plug in Twitch, I can easily plug in Discord. That would actually be simpler than me doing it in a monolith approach. Because if I did it in a monolith approach, I'd also have to consider, okay, what about the YouTube connection?
[00:05:24]
What about the Discord connection? What about the Twitch connection? Are they all working together? Is there one that's gonna get disconnected while the other two are working, right? So that's where it kinda becomes circumstantial. But there will be a point where you will have enough of an architecture underneath you to where you should be able to add a small component and then it works with the rest of the components pretty freely.
Learn Straight from the Experts Who Shape the Modern Web
- In-depth Courses
- Industry Leading Experts
- Learning Paths
- Live Interactive Workshops