Suggest modification to this talk

Title

Description

Building services and integrating them into Rails is hard. We want smaller Rails apps and nicely encapsulated services, but services introduce complexity. If you go overboard in the beginning, you're doing extra work and getting some of it wrong. If you wait too long, you've got a mess.

At Yammer, we constantly clean up the mess that worked well in the early days, but has become troublesome to maintain and scale. We pull things out of the core Rails app, stand them up on their own, and make sure they work well and are fast. With 20+ services, we've learned some lessons along the way. Services that seem clean in the beginning can turn into development environment nightmares. Temporary double-dispatching solutions turn into developer confusion. Monitoring one app turns into monitoring a suite of apps and handling failure between them.

This talk looks at our mistakes and solutions, the tradeoffs, and how we're able to keep moving quickly. Having services and a smaller Rails codebase makes for scalable development teams, happier engineers, and predictable production environments. Getting there is full of hard decisions -- sometimes we're right, sometimes we fuck it up, but we usually have a story to tell.

Help us caption & translate this video!

http://amara.org/v/FGdQ/

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 talk titled "Services and Rails: The Shit They Don't Tell You," presented by Brian Morton at Big Ruby 2013, the focus is on the complexities involved in building services and integrating them into Rails applications. Morton shares insights from his experience at Yammer, where the need to adapt and scale a massive Rails app has led to the development of over 20 services. The presentation emphasizes the importance of understanding both the potential benefits and challenges associated with service-oriented architecture.

**Key Points Discussed:**  
- **Need for Services:** With increasing application size, a service-oriented architecture allows for components that can scale independently. Larger Rails applications can become unwieldy, leading to obstacles in development.  
- **Modularity and Reusability:** Morton illustrates the separation of functionalities to create a denormalized data store for their search architecture, enabling features like autocomplete to be added without extensive reinvention.  
- **Loose Coupling Benefits:** Independent updating of services is facilitated by their modular nature, reducing the risk of disruption when changes are made.  
- **Cross-Functional Collaboration:** Establishing cross-functional teams to tackle projects fosters innovative solutions and prevents knowledge silos present in vertically or horizontally divided organizations.  
- **Migration Challenges:** As services are built and moved out of the monolithic Rails app, maintaining oversight and ensuring proper support for new services is crucial.  
- **Monitoring and Performance:** Transitioning from monitoring a single application to multiple services increases complexity in performance evaluation and capacity planning. 
- **Emphasizing Utility Tools:** Morton highlights the importance of using effective tools like "Soup Kitchen" for managing development environments and "Deploy" for seamless service addition, ensuring that developers remain productive. 
- **Cultural Shifts Required:** Adopting services involves not only technical changes but also a cultural shift in team collaboration and communication, with an emphasis on maintaining flexibility and learning from mistakes.

**Conclusions:**  
Morton stresses the necessity of understanding the evolutionary nature of software architecture and the importance of being prepared to adapt without clinging to past decisions. Acknowledging that complex systems can fail is crucial, as is the need for a thoughtful and measured approach towards service orientation.  
Overall, while service-oriented architectures present significant advantages, they require careful navigation of inherent complexities to be successfully implemented.

Cancel