Talks
Speakers
Events
Topics
Sign in
Home
Talks
Speakers
Events
Topics
Leaderboard
Use
Analytics
Sign in
Suggest modification to this talk
Title
Description
As applications grow, dependency management becomes painful, tests get slower, and development becomes less joyful. Breaking up the application into services can be a great solution to these problems, but not every team is ready to leap fully into a SOA. Carson is Zendesk's compromise to this problem. It's a Rails 3 engine host: an application that contains only a Gemfile full of engines and some configuration. In this talk we'll explore the benefits and drawbacks of delivering features as engines and how this approach can act as a stepping stone from big-ball-of-mud architectures to service-oriented ones. Help us caption & translate this video! http://amara.org/v/FGg0/
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
**Main Topic:** The video presented by James Rosen at Aloha RubyConf 2012 discusses the evolution of app architecture at Zendesk, focusing on Carson—a stepping stone from a monolithic architecture to a service-oriented architecture (SOA). **Key Points:** - **Introduction to Carson:** Carson is a Rails 3 engine host that allows teams to break out features into smaller, independent engines while managing dependencies and tests efficiently. - **The Problem with Monolithic Apps:** As Zendesk's application grew from a Rails 1.2 to a Rails 3 environment, developers faced challenges with increased test times and complicated dependency management. Developer happiness declined as maintenance became burdensome. - **Early Solutions:** Efforts to improve test speed included adopting isolated testing techniques that significantly reduced test execution time and encouraged better coding practices. - **Conway's Law:** Rosen emphasizes the need for teams to mirror the architecture of their applications, advocating for smaller teams when breaking down a monolithic Rails app. This led to the development of their first engine, Sea Monster. - **Transition to Rails 3:** The introduction of the asset pipeline in Rails 3 simplified asset management for engines, enabling a smoother development process and further motivating a transition. - **Concept of Engines:** Carson allows different teams to develop vertical features as separate engines while managing shared concerns through classic gems, significantly improving test suite efficiency and deployment independence. - **Semantic Versioning:** Each engine can be semantically versioned, allowing teams to work independently on their features without worrying about conflicts with others' code until they wish to merge changes. - **Challenges and Anti-Patterns:** The talk also covers issues such as managing global state and schema ownership among engines, and it suggests naming conventions and internal gem server setups to mitigate these risks. - **Benefits of ActiveSupport Notifications:** Leveraging notifications allows for effective communication across various services, helping avoid unnecessary tight coupling between components. - **Future Direction and Challenges:** While Carson serves as a crucial transition point, Rosen cautions against complacency within this architecture, urging teams to remain aware of the need to evolve towards true SOA. **Conclusion:** The presentation highlights how the Carson architecture helps alleviate the common challenges faced in monolithic applications, allowing teams greater freedom and efficiency in development while acknowledging the need for thoughtful transition to SOA. The experience presents valuable lessons on the importance of dependency management and intentional project structuring to foster developer happiness and productivity.
Suggest modifications
Cancel
