Suggest modification to this talk

Title

Description

Your monolithic application is getting unwieldy. Concerns are entangled, response time is getting sluggish, and changing anything in production requires deploying your entire system. Teams facing this challenge often have an "Introduce Services" chore in their backlog that inevitably sinks to the bottom of the list. Despite the realization that your monolithic application will sink under its own weight, you fear the inherent operational complexities of a service oriented system.
The complexity of operating services results from the reality that your system will be only as strong as the weakest dependent service. Synchronous service requests require a round-trip request and response cycle in real-time. Your system's response time now might be only as fast as your slowest service and its uptime might be only as high as your weakest service. This potential brittleness is a high barrier to entry.
The boundaries of our potential services are defined by their communication patterns. One path forward toward service oriented design is to first target the components of your system that communicate asynchronously. These interactions do not require a roundtrip response in real-time and instead rely on incoming messages. First focusing on services that can be addressed through delayed messages will allow us to begin to carve up our application while ensuring the operational integrity of our system.
In this talk we'll look at using message passing patterns when designing our service oriented systems. We'll dig into an evolving feature from being some code sprinkled throughout the app folder in our Rails application to a standalone system that's independently scalable, testable, and deployable. We'll investigate the tactics we use to slice up our monolithic application, the operations and monitoring concerns it introduces, and look at several different messaging tools and protocols along the way.

Help us caption & translate this video!

http://amara.org/v/FG9Z/

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

The video titled "Asynchronous Service Oriented Design" by John Pignata, presented at GoRuCo 2013, explores the challenges of transitioning from a monolithic Ruby on Rails application to an asynchronous service-oriented architecture. Pignata discusses the operational complexities of synchronous services and advocates for focusing on asynchronous message-passing services that can enhance scalability and flexibility. The core issues surrounding monolithic applications stem from their increasing complexity, which makes changes more difficult as they grow. In response, Pignata proposes the extraction of asynchronous components, emphasizing the need for careful service design to maintain operational integrity.

### Key Points:
- **Problem Statement:** Monolithic applications can become unwieldy, leading to entangled concerns and sluggish response times.
- **Service Extraction:** Focusing on asynchronous components allows for better decomposition of the application, facilitating scalability while reducing operational risks.
- **Messaging Patterns:**  Pignata introduces two primary patterns:
  - **Service Mailbox**: A FIFO queue where clients enqueue messages for services to dequeue, ensuring messages are processed independent of real-time response cycles.
  - **Event Stream**: A shared data stream similar to file operations, allowing differing services (like a news feed service) to consume events asynchronously.
- **Case Studies**: GroupMe’s transition from synchronous operations to background processing using message queues and services like Redis and Kafka exemplifies the benefits of service-oriented designs. The messaging system emphasizes delivery guarantees and efficiency in handling user interactions, such as message delivery and updates on likes.
- **Scalability and Agility**: Shifting to smaller, independent services enables more targeted resource management, independent updates, and reduced interdependencies across teams.
- **Operational Challenges**: Monitoring message delivery, defining delivery guarantees, and managing failures within services are critical for maintaining system resilience.
- **Conclusion**: The shift to asynchronous services enhances scalability and allows for loose coupling, but it introduces new challenges such as interface synchronization and durability of messaging. Overall, the lessons learned during this transition can aid in gradually improving service-oriented designs, promoting more resilient system architectures.

In summary, the talk details a structured approach to embracing an asynchronous service-oriented architecture while addressing the complexities and operational demands it entails, offering valuable insights for teams navigating similar challenges.

Cancel