Downloaded 11 times
Uploaded byThurupathan Vijayakumar
Demystifying service based architecture
This document discusses service-based architecture and microservices. It begins by covering early technologies like .NET Remoting, RMI, and SOAP that influenced service-oriented architecture (SOA). It then discusses key aspects of service-based architecture like service contracts, availability, security, and transactions. The document outlines how SOA led to REST and cloud computing. It provides an example of how an online shopping application could be broken into microservices. Finally, it discusses challenges teams may face with microservices like tooling expertise and cross-cutting governance issues.
More Related Content
Similar to Demystifying service based architecture
![Vibe Coding vs. Spec-Driven Development [Free Meetup]](https://cdn.slidesharecdn.com/ss_thumbnails/vibecodingvsspecdrivendevelopment-251209105622-43f455e7-thumbnail.jpg?width=640&height=640&fit=bounds)
Demystifying service based architecture
- 1. Demystifying Service BasedArchitecture - Journey towards microservices and ahead. : Thurupathan :: Associate Solutions Architect, Tiqri Corp ::: Nov 9, 2017
- 2.
- 3. Service Based Architecture •Service Contracts • Service Availability • Security • Transactions
- 4.
- 6. Service Oriented ArchitectureAmbiguity SOA
- 7. How to getSOA
- 8. SOAP in WebServices yielded / evolved to REST
- 9.
- 10.
- 13. I think it’snot a technical problem, it should be a political issue
- 14.
- 15. Mass Rover Mass RoverOnline Shopping Database Client
- 16.
- 17. Product Catalog Service Order ServiceReview ServiceUser Profile Service Product Pricing Service Customer Service Loyalty Service
- 18. Product Service OrderService Review ServiceUser Service
- 19. Product Service OrderService Review ServiceUser Service Client
- 20. Product Service OrderService Review ServiceUser Service Client API Gateway
- 21.
- 22. Service Based Architecture •Service Contracts • Service Availability • Security • Transactions
- 23. Service Contracts • Servicedrive contracts • Client driven contracts • Versioning
- 24. Service Availability • Availability •Responsiveness
- 25.
- 26.
- 27. Security • Centralized • Individual •Short term certificates and tokens*
- 28. Transactions • Transactions inDistributed Systems is hard • Compensating Transactions
- 29. Saga • Transactions inDistributed Systems is hard • Compensating Transactions
- 30. The trick oflogics Product Service Order Service 10 10 /2? 8/10 Only the deduction operation is locked
- 31. Team Challenges Horizontally crosscutting governance : API Master Tooling expertise, Monitoring complexities, CI/CD challenges, Protocol agreements and etc Team dependencies, Naming wars, industry molestation from governance practices Client Separation. Death of Full stack is there anything called full stack ?
- 35. Serverless Event Driven Interactions Event Driven Interactions Groupedor individual deployment / No deployment
- 36. If two arefighting, just introduce a third man to solve the issue.
- 37. Serverless is agood solution for what’s first war. Of course with it’s own downsides
- 38.
- 39.
Editor's Notes
- #2 The theme is to discuss what is a service based architecture, the history and the stress on two major service based architectures
- #3 Having smaller systems – smaller foot print – modules (functional) - domain separation (OOP) – all where thought and embraced. There are logical separations – then became inter process communications – inter process communications became distributed Service based architectures are distributed architectures Language and platform specific implementations All service based architectures are distributed and require some remote communication technology / protocol
- #4 The key 4 aspects of any service based architectures Most of the early implementations failed at the first point itself – technology agnostic implementations were not there XML became savior
- #5 One such highly embraced and practiced/ misused service based architecture is SOA. SOA came to picture as a design paradigm but never defined properly. XML became the standard exchange and new industry tooling has started evolving. Enterprise Service Buses came to picture with solution of addressing other concerns (somewhat) service based architecture. Mainly addressing transactions. SOA was never defined properly – but ensured some sort of a mechanism of messaging technology which is reliable (persistence oriented). This technology is adopted with XML SOA was right but got into the industry war.
- #6 In practice, the message format was standardized over SOAP, which is a standard introduced by W3C in early 2000, which is also based on XML — the service description was standardized over WSDL, another W3C standard and the service discovery was standardized over UDDI — once again a W3C standard. All these were the fundamentals of SOAP-based web services and incrementally, the web services became synonymous to SOA . The WS-* stack (WS-Security, WS-Policy, WS-Security Policy, WS-Trust, WS-Federation, WS-Secure Conversation, WS-Reliable Messaging, WS-Atomic Transactions, WS-BPEL, etc…) introduced by OASIS, further made SOA complex enough
- #8 We got into a time where SOA and web services used interchangeably and often confused. The truth no own defined both so automatically the confusion came. The WS* and the web services confused the SOA implementations and created many confusions Eventually Web Services took SOA – and Web Services became another aspect of service based architectures Advent of HTTP and Web Services moved messaging little by little away from persisted messaging channels. Web Services slowly took over the industry – still they are major part. Industry specific frameworks came into play, ex – WCF, Metro (SOAP over TCP) Primary protocol is TCP with the SOAP message format.
- #9 But Karma played As Web Services boggled the SOA, its own SOAP based complex standards triggered controversies and REST became to the picture During this time Internet has grown bigger and better, reliable networking, device proliferation all ditched SOAP and triggered new way of service communication and system development using disconnected small systems which work together to provide the overall business functionality. Also light weight and less complex messaging formats JSON came to the picture – all yielded REST So systems started talking to each other via REST – since this protocol has less constraints, both in the implementation and cross functional concerns, developers adapted it quickly.
- #10 Since everyone is talking about cloud and tell it has been the change agent, we will also add a little bit of cloud into the service based architecture journey. Cloud helped and shaped the thinking, along with the advent of new technologies, cost associated with them (implementation and running)
- #11 All these made the observations of creating services with simple protocols (as we say) which talk to each other and yield solutions In 2011,the term Microservices was coined and became an architectural paradigm
- #12 The trend really caught the commercial adaption manic stage during late 2014 and early 2015s.
- #15 All these made the observations of creating services with simple protocols (as we say) which talk to each other and yield solutions In 2011,the term Microservices was coined and became an architectural paradigm
- #16 Let’s consider an application Mass Rover online shopping which sells space gadgets. Users can view the products, order them and review the products. Leaving much of the cross cutting concerns of the application, based on this requirement, if we’re to think on a small ASP.NET Web API point of 4 controllers would be enough ? And JS client or mobile or what ever.
- #17 Dividing the services in micro service – It’s tricky. Too big and small
- #18 Too many little ones
- #19 We end up in some somewhat balanced micro services model like this.
- #21 Services talk to themselves as well, (examples)
- #22 Remoting Example
- #25 The key 4 aspects of any service based architectures Most of the early implementations failed at the first point itself – technology agnostic implementations were not there XML became savior
- #26 The key 4 aspects of any service based architectures Most of the early implementations failed at the first point itself – technology agnostic implementations were not there XML became savior
- #27 The key 4 aspects of any service based architectures Most of the early implementations failed at the first point itself – technology agnostic implementations were not there XML became savior
- #29 Other implemenations , ex : Java = Netflix / Ribbon
- #30 The key 4 aspects of any service based architectures Most of the early implementations failed at the first point itself – technology agnostic implementations were not there XML became savior
- #31 The key 4 aspects of any service based architectures Most of the early implementations failed at the first point itself – technology agnostic implementations were not there XML became savior
- #32 SOA has its BPMN and workflows to handle this problem Have a workflow Compensation endpoints Compensation logics, Idompotent