Contino Webinar - Migrating your Trading Workloads to the Cloud
From Components To Services
1. From Components to Services –An observation on paying back Technical Debt Presented by Jamie Phillips http://devblog.petrellyn.com
2. Who is Jamie Phillips Senior Software Engineer with over 12 years experience in the Telecomm, eCommerce, Finance and Healthcare industries. Professional experience based on the .NET framework (versions 1.0 – 4.0) Passionate about engineering and design principles. Natural ability to adapt to change has lead to becoming a practicing SCRUM Master and evangelist.
3. A phrase coined by Ward Cunningham to describe the effect of choosing a design that has high returns in the short term but increases complexity and maintainability in the long term. Debt can be classified as: Unintentional – typically where poor code has been written through ignorance or lack of experience; could be addressed with peer code reviews, etc. Intentional – where design decisions are made for short-term benefit because of release dates (“we’ll sort it out in the next release”) – this is harder to resolve and often requires re-design / re-factoring. What is Technical Debt?
4. The fundamental basis of Software Architecture is the reduction of complexity through abstraction and separation of concerns. Good use of Design Patterns and a clear Roadmap lead to good Architecture. Good Software Architecture is essential to the success of a Software company. Poor Software Architecture is the Achilles Heel and can be the catalyst for declining sales of a software product. Thoughts on Software Architecture
5. Does not mean “dumbing down” Does mean the division of a large system into smaller, more manageable parts Utilize the simple (and historic) theory of “Divide and Conquer” Once smaller, more manageable parts are defined, system can be overhauled a piece at a time. Reduction of Complexity
6. Separation of concerns is achieved by applying fundamental Design Patterns (such as Dependency Injection, MVC, etc). Allows for refactoring and flexibility when changing the design at a latter stage. Facilitates better testing and more robust code. Can become overly complex – needs to be coordinated and thought through. Separation of Concerns
7. Roadmaps can encompass Products, Technologies and even Enterprises. Roadmaps help separate business divisions in an enterprise work towards a common goal. Software Architecture is driven by both Technology and Product roadmaps. Technology Roadmaps are the domain of Software Engineering – Product Roadmaps are the domain of Product Marketing / Management. Roadmaps are essential for success.
8. With software vendors building on their previous successes/failures: Quite often the foundations are not based on the previously mentioned principles. Products based on out-dated technology and / or design limitations (i.e. not scalable). Tribal knowledge is lost as people move on. Stating the obvious does not always take place – it can be forgotten or overlooked in the mêlée to deliver the next version. So what’s new?
9. Start with the exercise of creating the Product and Technology roadmaps. Scrutinize the existing architecture (or lack of) with a view to identifying problem areas. Get buy-in from all involved (Executives to individual contributors); otherwise the effort will be doomed from the beginning. Set expectations early by planning a phased approach – few complex software products can be re-written in a short period of time. It is not too late!
10. “A well-placed pebble can change the course of a river.” – unknown Utilize a pilot project as proof of concept. Small dedicated team of domain experienced individuals. Executive sponsor. Minimal impact on main product code line. Provide regular updates, highlighting technologies, patterns used (relate to Roadmaps for validation of work) Once project is complete review the outcomes with a larger audience to familiarize people with the concepts. The pebble
11. Services represent capabilities: SOA PrimerWhat is a Service I assist the customer in selecting products Facilitates invoicing the customer for purchases made. Salesperson Invoice Service Translates I deliver purchased products to customer address Facilitates organizing inventory according to customer purchases. Delivery Driver Inventory Service
12. Service Contract is the Interface implemented by the Service Class (Service classes can implement more than one Interface). Operation Contract is one or more methods on the Interface that the Service Class implements. Data Contract is one or more parameter types or return type related to the Operation Contract. SOA PrimerAnatomy of a Service IServiceA Service A Service A Capability X Capability Y
13. The Service Inventory represents the sum total of all of the enterprises Services that are available for use. Services are added once they become available. SOA PrimerService Inventory Service Inventory
14. Services (from a SOA perspective) bring the following to bear on the Software Architecture: Organizational Agility Improved Interoperability Business and Technology Alignment Reduced IT Burden Where do Services fit in?
15. Refers to the speed and ease which an organization can respond to change. Maintaining an inventory of highly standardized and reusable services facilitate changing requirements. Inventory is built up of standalone services that can be orchestrated in many different topologies for a variety of application uses. Agility comes with maturity and size of inventory – not a one release hit. Organizational Agility
16. A variety of Services make up the inventory and is representative of emergent architecture. Organizational Agility (cont) Invoice Timesheet Inventory Service Inventory New services are added as they become available
17. Traditional Client-Server applications that are required to work together need periods of integration. Typically, established applications were not designed to interact with each other. Services, by the nature of their design, are implicitly intended to interact with other systems. Services can be “orchestrated” together (from a Service Inventory) to provide the necessary functionality. Improved Interoperability
18. Done correctly, Services will force decoupling between various layers of a software system. A system that is too tightly coupled will suffer from (to name a few): High costs for maintenance – any changes that have to be made can be too complicated / too time-consuming. Change is both difficult and painful; refactoring can become so difficult that it may outweigh the effort involved. The more complex the system the harder it is to locate the source of an issue. Improved Interoperability (cont)
19. Traditional applications are not always prepared for interoperability - implicit overhead for design and testing. Improved Interoperability (cont)
20. Services, by their nature, are prepared for interoperability from the get-go. Services can be orchestrated together to provide specific functionality. Improved Interoperability (cont) Service Inventory Service Composition
21. Services can be defined in terms of their business assets as opposed to simple grouping of functional capabilities. Business and Technology Alignment Process Order Business Process Definition Invoice Inventory Business Entity Model
22. Enterprises that offer suites of integrated applications; often carry the burden of tight coupling and spaghetti references (built up over time) Reduced IT Burden
23. Services are profiled and documented in a Service Inventory that can be used to build functionality for a variety of different applications. The inventory reduces clutter and clearly defines the capabilities. Reduced IT Burden (cont)
24. Two client-server applications originally designed for different aspects of the same domain. FaceForward is a client application for the Sales division; uses its own database for storing client information and sales information. DispatchIt is a backend application for the Shipping division; uses its own database for storing shipping information (with some client information) A tale of two productsFictional case study based on actual experiences
25. A tale of two productsFictional case study based on actual experiences.In the beginning: Two separate products in their own right FaceForward DispatchIt UI UI Business Logic Business Logic Data Access Data Access
26. A tale of two productsFictional case study based on actual experiences.Then: Products “merged” as an application suite. FaceForward DispatchIt UI UI Business Logic Business Logic Data Access Data Access Triggers / components used to Synchronize common data
27. A tale of two productsFictional case study based on actual experiences.Migration towards Services – identify new common features. FaceForward DispatchIt New functionality takes advantage of the new architecture. UI UI Business Logic Business Logic Data Access Data Access Services
28. A tale of two productsFictional case study based on actual experiences.Services begin to form basis of architecture. FaceForward DispatchIt Over successive releases more and more features use the new architecture. UI UI Business Logic Business Logic Data Access Data Access Services
29. A tale of two productsFictional case study based on actual experiences.Services assume bulk of processing for thin clients. FaceForward DispatchIt UI UI Services
30. Services provide ideal decoupling because the service consumer only needs to know about: the Service interface (Service Contract). what methods (Operation Contracts) are available. what parameters (Data Contracts) are needed. Typically service calls are done through XML Serialization / De-Serialization, so consumers have no knowledge / dependency on the Services dependencies. Services from a client perspective
31. B Once a component contains a reference, it exposes these references to calling components. Typical Component Dependency Tree Application A contains implicit references to components D and E A C D E
32. Due to the nature of the Service Contract the underlying references of a Service are not exposed: Services hide underlying references Application A contains explicit references to the Service Proxy and has no concept of components D and E used by the Service class B. A B D E
33. Phase 1 – inject the “call-through” Service between client and components. Migration from Component Architectureto Services Architecture Service B B D E D E
34. Phase 2 – replace “call through” Service external references with new internal modules. Migration from Component Architectureto Services Architecture Service Service B B1 D E D1 E1
