Ruby Video
Talks
Microservices
Sebastian Sogamoso
@sogamoso
#microservices
#software-architecture
#system-design
#scaling
#monolith
Summarized using AI

Microservices

by Sebastian Sogamoso

In this talk titled 'Microservices: A Bittersweet Symphony' at the wroc_love.rb 2015 event, speaker Sebastian Sogamoso discusses the concept of microservices, particularly in relation to system design. He begins by sharing his background as a backend developer and introduces the challenges faced by monolithic applications, comparing them to his own experiences juggling multiple tasks in a job.

Key Points Discussed:

  • Monolithic Applications:

    • Defined as the simplest way to build applications, they can become problematic, leading to a "big ball of mud" due to poor design as complexity increases.
    • Tight coupling in monolithic systems increases difficulty in making changes, leading to the consideration of microservices as a solution.

  • Microservices Overview:

    • Microservices are essentially small, independently deployable services that work together.
    • While often compared to service-oriented architecture (SOA), microservices aim to focus on separation of concerns without drifting into complex communication protocols.
    • They are not a new concept and have been implemented by some companies for over a decade.

  • Designing Microservices:

    • Starting with a monolithic application is generally recommended before transitioning into microservices, allowing the design to evolve naturally.
    • References to SOLID principles help in creating reusable and loosely coupled components critical for effective microservices architecture.
    • Attention to logical boundaries and grouping responsibilities aids in managing complexity.

  • Challenges and Considerations:

    • Adopting microservices introduces new complexities such as inter-service communication and debugging due to increased operational costs.
    • Strategies for resilience and recovery must be part of the architecture to handle inevitable failures.
    • Emphasizes the importance of managing logs across services for debugging and understanding system performance.

  • Best Practices:

    • Encourages using asynchronous patterns for communication between services to improve failure management.
    • Advocates creating new microservices for shared behaviors instead of sharing code to reduce complexity and promote cohesive design.
    • Discusses techniques for orchestrating transactions in asynchronous architectures and managing dependencies carefully.

Conclusion and Takeaways:

  • Microservices can effectively help manage system complexity but require well-thought-out implementation strategies.
  • Always evaluate the complexity that can be appropriately managed within your architecture and avoid the common misconception that adopting microservices will resolve existing design issues.
  • Emphasizing modular design and well-defined responsibilities is crucial for achieving scalability within microservices architecture.
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!
Edit
Explore all talks recorded at wroc_love.rb 2015
+2