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.
