Talks
Speakers
Events
Topics
Sign in
Home
Talks
Speakers
Events
Topics
Leaderboard
Use
Analytics
Sign in
Suggest modification to this talk
Title
Description
This talk runs through examples of services creating more brittle systems with worse failure cases. Building on those failure scenarios, I draw out guidelines for if, when, and how to consider Service Oriented Architecture. Software architecture is informed both by principles of software design and principles of operability; for lots of us, there are new skills to learn there. Also, set to music, this talk becomes a cool remake of StarWars, Episode 1. Help us caption & translate this video! http://amara.org/v/H4aN/
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 "Stop Building Services, Episode 1: The Phantom Menace," Rachel Myers explores the pitfalls of adopting service-oriented architecture (SOA) without proper consideration of code complexity and architecture design. Drawing from her experiences, Myers emphasizes the importance of thoughtful architectural decisions backed by evidence rather than relying on common mantras that often misguide developers. Key Points Discussed: - **Introduction to SOA**: Myers defines service-oriented architecture as a model where applications are built from smaller services rather than a monolithic application. She highlights that while SOA is appealing, it can create brittle systems if not executed properly. - **Critique of Common Beliefs**: Myers critiques several widely held beliefs about monoliths, such as their size making them hard to manage or change. She reviews these views with a skeptical perspective, asserting that many stem from confusion about code organization rather than inherent flaws in monolithic architecture. - **Falsifiability in Decision Making**: A significant point Myers makes is the concept of falsifiability, which asserts that good architectural decisions should be based on evidence that can change one's perspective. This leads to more informed, rational choices rather than adhering to buzzwords. - **Case Studies of Failures**: Myers shares several case studies detailing her past mistakes with SOA, specifically how attempts to separate services led to increased complexity and did not simplify code management. For instance, in one case, they mistakenly intertwined an identity service with their main application, resulting in shared points of failure. - **Collaboration Issues**: She addresses how creating separate services did not inherently solve team ownership problems and often exacerbated them, emphasizing that culture and communication within teams are crucial when managing service boundaries. - **Importance of Code Quality**: Myers concludes that improving code quality within a monolith is a more stable first step than hastily implementing service-oriented architecture. She encourages refactoring to clear up code complexity before creating new services. Main Takeaways: - SOA should not be seen as a universal remedy to issues posed by a monolith. - Thoughtful consideration of architecture that prioritizes resilience and team collaboration is essential. - Refactor existing code for comprehensibility before pursuing SOA to enhance overall system performance and maintainability.
Suggest modifications
Cancel