00:00:12.719
Now please welcome Sebastian!
00:00:20.240
Cool! So, hi! I'm excited to be here today with you guys.
00:00:25.840
My name is Sebastian. I am from Colombia and I live in Bogotá, which is the capital.
00:00:31.119
You can find me as @sevasoga on Twitter and GitHub. I work mainly in backend development.
00:00:43.920
I work for a startup called Ride I at Space in New York, although I work remotely. We're trying to reinvent the way people commute.
00:00:56.840
So far during this conference, we've heard really interesting talks about Trailblazer, Bolt, and Lotus.
00:01:09.200
Well, we almost heard about Lotus, and right now I'm going to talk about microservices.
00:01:15.840
Microservices relate to solving common problems at the application level, but my talk will focus on a system design level.
00:01:39.840
I call this talk 'Microservices: A Bittersweet Symphony' because, while I really like microservices, I am aware they are not perfect.
00:01:51.920
There are many downsides that we will discuss.
00:02:04.560
Before we get into what microservices are, I want to share a story.
00:02:10.560
This is a story about my first job at a stadium. It was a simple job where I sold hot dogs on game days, and surprisingly, I was good at it.
00:02:29.599
My manager decided that, in addition to selling hot dogs, he wanted me to sell foam fingers.
00:02:41.440
So I said, 'Okay, that makes sense. I'll do it.' Then he thought I should also announce substitutions during games.
00:02:54.080
That was a strange request, and I hesitated, but I went along with it.
00:03:00.239
Eventually, my manager lost an employee who mowed the lawn, and I was asked to take on that task.
00:03:07.440
I agreed, thinking it would be extra money. Suddenly, I had multiple responsibilities.
00:03:19.200
Soon thereafter, my manager asked me to help accommodate guests, and I felt overwhelmed.
00:03:30.319
I didn't know how I could possibly handle all of these tasks, but I reluctantly accepted.
00:03:41.680
To illustrate my point, I used an image of One Direction which was the best I could find.
00:03:48.480
Ironically, One Direction showed up, and I was tasked with accommodating them. It was a bit too much for me.
00:04:07.840
Feeling exhausted, I eventually decided to quit because I couldn't handle all the responsibilities.
00:04:15.280
So, that's the end of my story. You probably realize by now that this is a made-up story, but I want to emphasize a point.
00:04:30.240
Let me ask you: how many of you have a system that you'd like to break down into smaller components?
00:04:43.280
Please raise your hands.
00:04:49.040
It's great to see that most of you raised your hands, indicating that you might be working with monolithic applications.
00:05:00.479
For those of you who didn't raise your hands, if you're not working with monolithic applications now, you probably will in the future or have in the past.
00:05:19.360
So what exactly is a monolithic application? Simply put, a monolithic application is the simplest way to build an application.
00:05:30.880
Unfortunately, over time, they often turn into a big ball of mud, primarily due to poor object-oriented design.
00:05:46.280
As new features are added, the amount of poorly designed code increases and eventually causes the application to slow down.
00:06:00.800
The real issue with this type of application is that they become tightly coupled.
00:06:14.479
Things might start off well, but inevitably you'll hit roadblocks when you realize the system is too convoluted.
00:06:20.880
At that point, rewriting the application or quitting might seem like the only viable options.
00:06:35.240
This is where microservices come into play. Now let's discuss what microservices really are.
00:06:54.000
I'm sure many of you already have some ideas. Who would like to provide a definition?
00:07:06.880
Almost, that's close! Who else wants to define microservices?
00:07:21.280
Yes, you're right! Microservices refer to small services that work together, and they can be independently deployed.
00:07:39.039
A common question arises: Are microservices just a form of service-oriented architecture? The answer is yes.
00:08:06.000
However, service-oriented architecture deviated from its initial focus on separation of concerns to discuss aspects like communication protocols.
00:08:18.240
This led to a loss of sight regarding the main ideas, which microservices aim to reclaim.
00:08:37.440
Microservices are not a newer concept; indeed, many ideas have been practiced by companies for over a decade.
00:08:50.880
They just didn't have a specific name until relatively recently.
00:09:02.480
I find the name 'microservices' a bit unfortunate because it implies a focus on size, which isn't the most important aspect.
00:09:21.360
The main question is: How big does a service need to be to be considered a microservice?
00:09:39.040
Some people say it should be less than a hundred lines of code, but measuring in lines is an unreliable metric.
00:09:50.960
Additionally, standards vary between programming languages.
00:10:02.880
A common suggestion is that a microservice should be small enough to be built by a small team.
00:10:20.320
A famous concept from Amazon states that a team should be no larger than what two pizzas can feed.
00:10:38.720
Another way to determine if something qualifies as a microservice is to ask yourself if you would retain it or change it if you had the opportunity to extract it.
00:10:54.560
If you decide to leave it as it is, then it likely qualifies as a microservice.
00:11:02.880
However, if you would extract multiple components, it likely represents a monolithic application.
00:11:12.640
Now, how can we achieve building microservices from monolithic applications?
00:11:38.000
Ironically, you should start with the monolith. I wouldn’t recommend starting from scratch with microservices.
00:11:50.720
It's often unclear what the microservices need to be, so allow the system to dictate its own components.
00:12:06.320
It's crucial to get the design right. If you cannot design a monolithic application effectively, your attempt at microservices will be flawed.
00:12:17.120
There are resources like SOLID principles that help create reusable and loosely coupled components.
00:12:29.440
However, microservices have considerable operational costs, and you should not overload small teams with these responsibilities.
00:12:50.720
To reiterate, designing an architecture is not an easy task, and over time, as complexity grows, the architecture must adapt.
00:13:07.760
Logic boundaries matter: understanding where one responsibility starts and another ends is essential.
00:13:21.280
Using principles like package creation helps determine how to group responsibilities effectively.
00:13:39.760
Ultimately, microservices can help manage complexity better, but they don't remove it, and knowing where complexity lies is crucial.
00:13:50.480
A common pitfall is thinking that moving to microservices will solve all your design issues. Good design principles must be established beforehand.
00:14:06.800
Migrations to microservices won't solve your underlying structural problems; they may even exacerbate them.
00:14:26.720
Microservices introduce new challenges, such as inter-service communication and failure management, which need to be addressed.
00:14:46.800
Working with microservices means being ready for failures, as systems will inevitably experience outages or delayed responses.
00:15:10.080
Your architecture should provide resilience strategies, like retry mechanisms, to ensure a smooth user experience.
00:15:28.799
When building systems, consider the CAP theorem: ensuring you have the proper balance between consistency, availability, and partition tolerance.
00:15:44.480
You must also gather and manage logs across multiple services since debugging can become a cumbersome task.
00:16:01.040
Finally, be sure to leverage available tools and platforms that support microservices like cloud providers or container orchestration.
00:16:18.080
In conclusion, microservices can effectively mitigate complexity in systems, but they demands thoughtful implementation.
00:16:35.280
Emphasizing modular design, independent components, and well-defined responsibilities can lead you to a scalable solution.
00:16:54.560
When assessing whether to adopt a microservices architecture, ask yourself what complexity you can appropriately manage.
00:17:04.960
If you believe microservices will help you achieve better distributed solutions, consider adopting them.
00:17:17.160
Remember, there will always be complexity in your system; ensure the architecture you choose effectively helps manage it.
00:17:31.200
Thank you!
00:17:56.000
Does anyone have questions?
00:18:05.680
You mentioned you shouldn't share databases between microservices; can you elaborate on the problems that arise?
00:18:21.440
The issue arises at all levels. For example, constraints like that a field cannot be nil may not align between different services.
00:18:43.600
Additionally, model validations can conflict, leading to breaches in encapsulation.
00:19:06.160
So the main problem is breaking encapsulation by sharing a database.
00:19:14.880
What’s your preferred method for inter-service communication, sending requests or events?
00:19:26.560
It really depends on the context. For some apps, like mobile or web apps, synchronous requests are necessary.
00:19:41.680
However, I recommend making components asynchronous when possible, as this can help better manage failures.
00:19:57.920
So, while synchronous requests have their role, my advice is to lean towards asynchronous patterns.
00:20:07.440
How do you deal with asynchronous programming in Ruby for communication between services?
00:20:18.640
We use various methods, including a message broker. For instance, we commonly use RabbitMQ.
00:20:34.320
We put messages or payloads into the broker, allowing for a transactional model that continues to function even during failures.
00:20:48.880
If one service goes down, messages held in the queue are not lost, ensuring resilience.
00:21:01.920
On a related note, how do you manage sharing code between different microservice repositories?
00:21:10.560
Instead of sharing code, I recommend creating a new microservice that encapsulates shared behaviors. That way, all microservices can use those behaviors without duplicating code.
00:21:25.440
This also aids in managing complexity as you promote more cohesive service-oriented design.
00:21:40.080
What are your tips for orchestrating synchronous transactions in asynchronous architectures?
00:21:56.320
We have scripts that manage processes through event triggers, enabling effective orchestration.
00:22:12.160
It requires careful design, but it can work, though it's not particularly elegant.
00:22:23.440
Could you elaborate on how RabbitMQ could potentially create a single point of failure?
00:22:39.680
Yes, single points of failure can be a concern. However, we manage this by using replicated instances of RabbitMQ.
00:22:50.480
In the event one instance goes down, the others take over without disrupting the overall communication.
00:23:05.040
While this is a valid concern, we are prepared with a proper architecture to avoid such situations.
00:23:21.600
Thank you for your questions, and I appreciate the engaging discussion!
