Service Oriented Design in Practice

MountainWest RubyConf 2011

by Bryan Helmkamp

In the video titled 'Service Oriented Design in Practice,' Bryan Helmkamp discusses the complexities and practicalities of implementing service-oriented design using Ruby. He draws from experiences at his company, Efficiency 2.0, where they developed an application to provide energy usage insights and recommendations. The talk emphasizes the significance of understanding the nuances that come with service-oriented architectures beyond just theoretical advantages.

Key points discussed include:

Initial Goals and Challenges: The team aimed for isolation and scalability but faced hurdles, including unnecessary complexity from certain services.
Evolution of Architectural Decisions: They optimized dependencies by eliminating services like RabbitMQ that hindered efficiency and simplifying communication paths.
Isolation and Scalability: The benefits of smaller, self-sufficient units allow easier maintenance, and a well-defined API enhances robustness.
Agility and Incremental Upgrades: Service-oriented design can support agility by allowing smoother transitions and quick adaptations to requirements.
Interoperability and Code Reuse: Connected systems through services enhance interoperability and promote the reuse of components across different applications.
Deployment Confusion: Challenges arose from fragmented deployments, which led to discrepancies between tested code and production environments.
Centralized Package Management: Implementing a centralized strategy helped manage deployments effectively, ensuring cohesive functioning across services.
Streamlined Testing and Continuous Integration: A consolidated testing approach was essential to address production discrepancies and enhance deployment practices.

Throughout the discussion, Helmkamp reflects on lessons learned from transitioning from a monolithic approach to a distributed model. He stresses the importance of teamwork and clear operational strategies in navigating the complexities of service-oriented design.

In conclusion, while service-oriented design holds substantial potential benefits, it requires careful consideration and ongoing dialogue about its implementation in relation to specific environments and workflows. Helmkamp encourages viewers to glean insights from their experiences as they enhance their service-oriented strategies, ultimately aiming for efficient practices and improved outcomes.

00:00:12.960 Hello everyone, my name is Frankie, and I'm giving a talk entitled 'Service Oriented Design in Practice.' I hope this serves as a good complement to the material that Chris just presented very well from South Africa. I think I said this is how you can follow me after the talk on Twitter. I work with a company called Efficiency 2.0, and a lot of this talk will share insights from our experiences over the last year in implementing and, perhaps more interestingly, maintaining a service-oriented design throughout the course of building our application.

00:00:30.869 Briefly, our application pulls data about how people use energy and provides targeted recommendations to help them save on their energy bills. The name of my talk is 'Service Oriented Design in Practice.' It's inspired by similar themes discussed by Chris in his talk. In Paul Dix's book about Service-Oriented Design with Ruby on Rails, he offers an insightful quote that I really liked, stating, "Service-oriented architecture has become a loaded term; it implies these tools such as SOAP, WSDL, WS*, or X. This is why we use the term 'design' as opposed to 'architecture.'"

00:00:55.500 This is a paradigm shift where Paul is trying to free the concept of service orientation from the baggage of these enterprise protocols and legacy technologies, allowing for a fresh approach and consideration of it as a problem domain. The point of this talk emphasizes that services, by their second nature, imply a multi-faceted use. This is reflected in a quote by Lewis Brandi, who said, 'Never trust a programmer who says they know C++.'

00:01:20.740 They can easily convince themselves that C++ is simple because it has classes, which is awesome because using objects is fantastic. But after attending a conference, their confidence may be put to the test as they encounter issues with C++ templates, confusing reference types, and the mystery of virtual destructors, among other challenges. The point here is that just like mastering C++, service-oriented design is also complex.

00:01:55.900 In this talk, I will walk through my thoughts on service orientation, developed over the past 12 years. There are key insights to draw from that will outline five primary problems we encountered as we introduced our first service. We began our journey looking for isolation and scalability benefits but were met with hurdles along the way.

00:02:12.380 For context, our team, comprising about five developers, has been working on this project for one or two years. Initially, we had a straightforward user-facing application supported by three key services. However, as we evolved, we reassessed our architectural decisions and the dependencies involved.

00:02:30.600 After some evaluation, we found that we could optimize the number of dependencies, which led us to eliminate unnecessary services, like RabbitMQ, that added complexity without providing the expected benefits. Leveraging clearer communication paths between services allowed us to simplify operations significantly.

00:02:56.940 Throughout this talk, we will explore the various advantages of service-oriented design, such as isolation, scalability, and reusability of code. The benefits of using services are interconnected; for example, effective isolation facilitates easier maintenance and testing.

00:03:12.230 Breaking down components into smaller, self-sufficient units makes them easier to manage, as we all know smaller units are generally more straightforward to maintain. A well-defined API reduces the chances of introducing issues when modifications are made, thus enhancing the robustness of the service-oriented design.

00:03:28.700 Scalability allows us to tailor different sections of our application for diverse operational characteristics, a crucial benefit when managing various workloads. Interestingly, while some might perceive service-oriented architecture as a hindrance to agility, it can actually increase the capacity for incremental upgrades, allowing for smoother transitions and rapid responses to changing requirements.

00:04:05.500 Interoperability between disparate systems improves through service-oriented connected systems, which is exemplified by how various services can provide HTTP endpoints. We benefit from reuse of services across different applications, effectively standardizing our components and processes.

00:04:32.000 However, we also encountered challenges along the way. Early on, as we introduced services, we found issues with maintaining our codebase effectively. For instance, the typical isolation seen in an application could lead to fragmented deployments where service updates didn't sync properly, resulting in downtime.

00:05:10.000 To address this, we implemented a centralized package management system that allows individual contributors to deploy code effectively across various services while ensuring that all components function cohesively. This became an essential part of our development workflow.

00:05:40.300 Additionally, we found that the a variety of deployments led to confusion among our developers—many pushed changes that went unnoticed or unresolved, leading to builds and tests lagging behind actual deployments. Our tests were passing, but production frequently experienced discrepancies, which became a significant challenge.

00:06:09.400 So, as any software team would, we sought to simplify our processes to mitigate such delays. To this end, we established a consolidated testing approach to enable continuous integrations and focused our attention on ensuring that we addressed issues related to our codebases in tandem with our service architecture.

00:07:00.800 Regarding operations, implementing value-driven deployments allows us to streamline the process and reduce risks overall. However, in reflecting on the entire service-oriented design experience, we uncovered a host of lessons learned from early service adoption, transitioning from a monolithic approach to a more distributed model.

00:07:30.600 The prospect of service-oriented design can be daunting, but a key takeaway from our experience is the importance of having a clear operational strategy while also emphasizing team-based collaboration to refine deployment practices. We became adept at managing the intricacies of operational dependencies and navigating challenges as they arose.

00:08:00.100 In conclusion, service-oriented design is a powerful paradigm that offers substantial potential benefits but requires thoughtful consideration of its implementation. Teams must maintain an ongoing dialogue about the pros and cons of such architectures as they pertain to their specific environments and existing workflows.

00:08:30.270 By sharing our experiences and thoughts here, I hope to uncover new insights and practical takeaways that may inspire you and your teams as you navigate your journeys in enhancing your service-oriented strategies and practices. Thank you for your time.

MountainWest RubyConf 2011