Microservices, a Bittersweet Symphony

RailsConf 2015

by Sebastian Sogamoso

In the video titled "Microservices, a Bittersweet Symphony," Sebastian Sogamoso discusses the complex nature of microservices architecture at RailsConf 2015. He emphasizes that while microservices can provide significant advantages over traditional monolithic applications, they also come with a range of challenges that developers must navigate. Sogamoso begins by defining microservices as independent, small applications that can be deployed separately, which has been a topic of debate regarding their classification within service-oriented architecture.

Key points discussed include:

- Microservices Defined: Microservices are often confused with being simply a small size; however, size is not the only defining attribute. Cognitive load plays a crucial role in determining whether an application qualifies as a microservice.
- Cognitive Load: Developers must manage the cognitive load of the services they are working with. A microservice should not overwhelm the team's cognitive limit.

- Transitioning to Microservices: Many developers mistakenly believe breaking a poorly designed monolith into microservices will improve the design. Sogamoso stresses that that is not true; if an application cannot be well-designed as a monolith, it likely won't be better as microservices.
- When to Use Microservices: They are beneficial when parts of a system need to scale differently or be updated independently, as well as when outdated components need replacement.
- Team Requirements: Successful implementation of microservices necessitates that teams be well-equipped in provisioning, monitoring, and quickly deploying new services.
- DevOps Challenges: Increased operational complexity and the need for effective logging and failure management are significant challenges in microservices architecture.
- Design Principles: Employ patterns such as bounded context to manage complexity and avoid coupling between microservices while emphasizing independent deployment.
- Avoiding Common Pitfalls: Errors like sharing databases can lead to maintenance issues; Sogamoso encourages starting with a minimum viable product and iterating from there.

In conclusion, while microservices can enhance the manageability of complexity in system design, they require teams to have the right skills and mindset. As Sogamoso aptly summarizes, the decision to adopt microservices should be driven by the needs of managing system complexity rather than a trend-driven approach.

00:00:11.059 Hello, my name is Sebastian Sogamoso, and I live in Bogota, the capital of Colombia in South America. You can find me at Seva Soga on GitHub. I work for a startup called Ride, where we are reinventing the way people commute to work. You should definitely check us out! Today, we are going to talk about microservices.

00:00:34.260 I don't want to give a lecture about microservices; there are many excellent resources out there that you should explore. Instead, I want to discuss why I believe that microservices can sometimes be a bad idea, and not just sometimes, but quite frequently.

00:00:59.100 Let's begin by defining what microservices are. Microservices are a particular way of designing software by creating many small applications that can be independently deployed. There has been much discussion about whether microservices merely represent a subset of service-oriented architecture, and to some extent, they do. Microservices are a segment of service-oriented architecture with a defined set of rules. One might say that microservices are to service-oriented architecture what Scrum is to Agile. Additionally, microservices are not just a trend among hipster developers; people have been implementing microservices for about ten years now. It’s simply a name given to a certain set of rules in service-oriented architecture.

00:01:49.560 A point of contention among practitioners is how large a microservice should be. The issue is that microservices are designed to fail—which is in their name. The term micro suggests that they should be very small, but size isn't necessarily the most critical aspect; it’s just one part of what defines microservices. Many people argue that the definition of a microservice hinges on the number of lines of code it has, but that can be misleading as it varies widely depending on the programming language. Others, like Amazon, suggest determining a microservice's scale by the size of the team developing it. While this has some merit, I don’t see it as a definitive approach.

00:02:48.720 Another approach suggested by experts like Chad Fowler defines microservices by their size, claiming they should fit on a developer's screen with their hand. If a service expands beyond this, it no longer qualifies as a microservice. However, I find this criterion somewhat limiting. Instead, I think we should consider concepts from cognitive psychology. Cognitive load refers to the amount of information a person is trying to process at any given time, while cognitive limit refers to the maximum number of chunks of information one can handle in working memory. A service can be called a microservice if the cognitive load it represents is less than the cognitive limit for the developers handling it.

00:03:54.659 When talking about groups of people, the cognitive limit tends to decrease as the team size increases. Thus, the larger the team, the lower the cognitive limit, which can be a challenging dynamic. To illustrate my perspective on microservices, I’d like to share a personal story for context.

00:05:14.100 My first job was at a sports stadium where I sold hot dogs during games. Surprisingly, I excelled at it, leading my manager to delegate additional responsibilities like selling foam fingers and making public announcements during innings. I was always up for the challenge and managed to juggle all these tasks, even mowing the lawn before each game. Eventually, due to staff shortages, I was asked to help people find their seats, which happened to coincide with a One Direction concert at the stadium. That day was chaotic, and I decided it was best to resign.

00:07:36.060 At this point, you might realize that this story is not entirely true; it’s more of a metaphor. I’d like to pose a question to everyone: please raise your hand if you have a system that exceeds your team’s cognitive load and wish to break it down into smaller systems.

00:08:05.940 This is a situation common in software development, especially when dealing with monolithic applications. Earlier today, DHH discussed monolithic applications, and I find myself disagreeing with his definition. So let's delve a bit deeper.

00:08:34.380 I believe that having a single Rails application does not necessarily mean you have a monolithic application. What makes an application monolithic is typically poor object-oriented design. Having a single Rails app does not automatically label it as a monolith. A single Rails app can be well-designed and executed.

00:09:59.040 For example, a recent talk highlighted how Cookpad, a Japanese company, has built what could be the world’s largest Rails application, effectively handling vast amounts of traffic with only one Rails app, possibly running on around 300 servers. Therefore, while some systems might be monolithic in design, it doesn't have to be the case.

00:10:40.920 When you’re working within a monolithic application, you typically cannot reuse parts of your system without messing with the entire system. This is known as 'shotgun surgery' and is a frustrating experience for many developers. Having established this distinction between a well-structured system and a monolithic system, let's discuss when it might be appropriate to transition to microservices.

00:11:06.600 Many people mistakenly believe that converting a poorly defined single Rails app into microservices will somehow improve its design. This notion is a fallacy. When you smash a banana, for instance, you don’t get smaller well-defined bananas; you just end up with a squishy mess.

00:11:43.500 If you cannot effectively design a single application, you likely will struggle with designing a microservices architecture. This concept resonated with a tweet I came across, highlighting that if your design skills are lacking in a monolithic app, they won’t magically improve when you switch to microservices.

00:12:20.220 So when should you actually adopt microservices? A solid reason to do so is when you need a specific part of your system to scale differently than the rest of the system. This has happened to us at Ride, where we had to choose whether to scale the whole application or just a specific part that had unique performance needs.

00:12:53.520 Another reason to consider microservices is when you need parts of your system to be easily replaceable. Many large companies struggle with outdated systems built on old technologies, leading to a lack of resources for maintaining them. When you have business logic well-distributed across microservices, it becomes easier to replace a failing microservice with a newer technology without the daunting task of rewriting the entire application.

00:14:27.979 Another reason to consider microservices is when you want to deploy some parts of your system more frequently than others. If you notice specific components of your application often require updates due to changing business logic or other reasons, a monolith can become cumbersome. Deploying a large app often means sitting on many changes before pushing them out, increasing the risk of failure.

00:15:04.500 For those interested in different technology stacks, microservices offer the flexibility to use varying technologies for individual services. However, be cautious; extreme diversity in programming languages can lead to significant challenges in maintenance and complexity. We at Ride use a request for comments (RFC) process before creating a new service to validate the intended tech stack.

00:15:51.060 The most crucial aspect is that your team should possess the necessary skills to support the microservices architecture. Ensure your team can provision new servers, set up monitoring, and respond to failures quickly. Rapid deployment is vital; new microservices should be able to be deployed to production in minutes, not hours or days.

00:16:42.000 If your team lacks these capabilities, it may be best to postpone transitioning to microservices. However, if your team is ready, it’s essential to acknowledge the potential downsides. The most notable downside of microservices is the increased DevOps effort; teams must be proficient in managing numerous services running concurrently.

00:17:16.620 Another challenge is managing logs for each service, which complicates debugging efforts. Centralized logging is necessary to monitor the entire system effectively. Unique identifiers for each request can facilitate tracing issues across services.

00:18:05.400 Another critical aspect to prepare for is the inevitability of failure. While failure management is vital in any architecture, it's particularly challenging in a microservices environment due to the complexity involved. Common failures include network partitions, service unavailability, or data inconsistencies, which all require planned strategies.

00:18:55.200 The CAP theorem highlights the trade-offs necessary to ensure availability and consistency in distributed systems. As you design your microservices architecture, it's crucial to understand these principles and how they relate to your business requirements.

00:19:43.560 When you take the plunge into building microservices, it's beneficial to employ the bounded context pattern to manage complexity. This involves recognizing that each model may behave differently based on its specific context, which can help reduce the overall complexity of your application.

00:20:35.520 Incorporate executable specifications for each microservice, which allows you to conduct tests based on clear contracts. Synchronous communication is generally preferable to asynchronous communications whenever feasible to ease fault tolerance. Opting for schema-based formats over schema-less ones can also streamline data exchanges between services, making future changes considerably more manageable.

00:21:44.760 When embarking on new microservices, don't obsess over perfection. Start by creating a minimum viable product and iterate as you move forward. It's crucial to avoid sharing databases between microservices, as this creates unwanted coupling that detracts from modularity and can lead to severe maintenance headaches.

00:22:45.300 Be mindful of organizational biases, as mentioned by Conway's law, which suggests that a system's design often reflects an organization's structure. Translation: design systems based on functionality rather than trying to mirror the organization. Finally, remember that a vital 'Golden Rule' of microservices is to allow for independent service deployment. If you're struggling with coordinated deployments, you may negate many benefits of microservices.

00:24:46.800 To summarize, while transitioning to microservices can simplify certain aspects of complexity, ensure this change ultimately benefits your overall system. As Michael Feathers wisely puts it, managing complexity is crucial when adopting this architecture. Embrace microservices if it helps you better manage the complexity of the system you are developing. Thank you for your attention!