Suggest modification to this talk

Title

Description

Building services and integrating them into Rails is hard. Often times we talk about how nice it would be if our Rails apps were smaller and we had nicely encapsulated services. And it would be, but services introduce complexity. If you build your application this way from the beginning, you're going to do extra work and probably get some of it wrong. If you wait too long, you've got a mess on your hands.

At Yammer, we work constantly to clean up the mess that worked well in the early days, but has become troublesome to maintain, scale, or handle lots of data. We're tasked with pulling things out of the core Rails app, standing them up on their own, and making sure they do what they do really well and really fast.

With over 20 services now running in production, we've learned some lessons along the way. Services that seem clean and simple in the beginning can turn into development environment nightmares. Temporary data double-dispatching solutions turn into duplication and developer confusion. Monitoring one app turns into monitoring a suite of apps and handling failure between them. This talk is a look into the tradeoffs, mistakes, and solutions that we deal with every day and how we're able to maintain velocity given the additional complexity.

At the end of the day, having services and a smaller Rails codebase makes for scalable development teams, happier engineers, and smoother and more predictable production environments. Getting there is full of tradeoffs and hard decisions -- sometimes we do it right, sometimes we fuck it up, but we usually have a story to tell.

Help us caption & translate this video!

http://amara.org/v/FGbL/

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 this talk titled "Services and Rails: The Shit They Don't Tell You," Brian Morton from Yammer discusses the complexities of building and integrating services into Rails applications. He highlights that while smaller, encapsulated services can improve scalability and maintainability, they also introduce significant challenges. The key points from the discussion include:

- **Recognizing Early Complexity**: Building services should be approached with caution, especially during the early stages of a startup, to avoid unnecessary complexity.
- **Service-Oriented Architecture**: Morton advocates for a Service-Oriented Architecture (SOA) that allows for independent scaling and component reusability.
- **Examples from Yammer**: He shares examples from Yammer’s experience, such as the search interface built using components like Flattery and Completey, illustrating how separation of components has facilitated easier integration in their infrastructure.
- **Development and Team Structure**: Morton discusses the importance of a well-structured team to support service development, referencing Conway's Law, which states that the structure of a company influences the design of its systems. The shift to cross-functional teams has helped keep communication fluid and development agile.
- **Challenges and Trade-Offs**: The transition to distributed services is filled with challenges, requiring teams to adapt continuously and manage technical debts. The need for robust monitoring, alerting, and deployment processes is emphasized, with tools like Dropwizard being cited as beneficial to streamline service management.
- **Conclusion**: Morton stresses the importance of embracing complexity and being prepared for challenges in service development, advocating for a culture that supports learning and adaptation. Overall, the journey of migrating to service-oriented architectures is a balance of navigating new complexities while maintaining the agility of development.

Cancel