Talks
Speakers
Events
Topics
Sign in
Home
Talks
Speakers
Events
Topics
Leaderboard
Use
Analytics
Sign in
Suggest modification to this talk
Title
Description
By, Sebastian Sogamoso Like an espresso, code is better served in small portions. Unfortunately most of the time we build systems consisting of a monolithic application that gets bigger and scarier by the day. Fortunately there are a few ways to solve this problem. Everyone talks about how good microservices are. At a first glance an architecture of small independently deployable services seems ideal, but it's no free lunch, it comes with some drawbacks. In this talk we'll see how microservices help us think differently about writing code and solving problems, and why they are not always the right answer. Help us caption & translate this video! http://amara.org/v/G6rG/
Date
Summarized using AI?
If this talk's summary was generated by AI, please check this box. A "Summarized using AI" badge will be displayed in the summary tab to indicate that the summary was generated using AI.
Show "Summarized using AI" badge on summary page
Summary
Markdown supported
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.
Suggest modifications
Cancel
