microservice architecture case study
Post on 28-Jul-2015
Embed Size (px)
1. Microservice Architecture By Rudra prasad Tripathy 29th April 2. Contemporary technologies lSOA/ESB lEAI lLayers/tiered/component architecture 3. Gartner pattern 4. Principles lComponentization via Services lOrganized around Business Capabilities lProducts not Projects lSmart endpoints and dumb pipes lDecentralized Governance lDecentralized Data Management lInfrastructure Automation lDesign for failure lEvolutionary Design 5. Use case Desktop Mobile REST Controller Spring core Business process workflow RDBMS Search service 1 2 3 4 5 6 7 N G N I X 6. Use case lThe use case doesn't have spring integration, but using spring controller. lSpring controller can access JPA service in case of Http service operation without core. lWorkflow services also can be accessed directly. lSpring security can be integrated to make it API Gateway. 7. Contemporary technologies lSOA/ESB lEAI lLayers/tiered/component architecture 8. Componentization via Services component is a unit of software that is independently replaceable and upgradeable. One main reason for using services as components (rather than libraries) is that services are independently deployable A service may consist of multiple processes that will always be developed and deployed together, such as an application process and a database that's only used by that service. 9. Organized around Business Capabilities Conway's Law Cross team dependency Smaller services make it easy for small teams working on this without much dependency on other teams. The boundry is easy to define 10. Products not Projects Microservice proponents tend to avoid PROJECT model. The product mentality, ties in with the linkage to business capabilities Smaller granularity of services can make it easier to create the personal relationships between service developers and their users. 11. Smart endpoints and dumb pipes Avoiding approaches that stress putting significant smarts into the communication mechanism itself. Applications built from microservices aim to be as decoupled and as cohesive as possible. Messaging over a lightweight message bus. 12. Decentralized Governance One of the consequences of centralized governance is the tendency to standardize on single technology platforms. Teams building microservices prefer a different approach to standards too. Perhaps the apogee of decentralised governance is the build it / run it ethos popularised by Amazon. Patterns like Tolerant Reader and Consumer-Driven Contracts Centralized governance can be achived through API GATEWAY. 13. Decentralized Data Management At the most abstract level, it means that the conceptual model of the world will differ between systems. As well as decentralizing decisions about conceptual models, microservices also decentralize data storage decisions. Choosing to manage inconsistencies in this way is a new challenge for many development teams, 14. Infrastructure Automation Many of the products or systems being build with microservices are being built by teams with extensive experience of Continuous Delivery and it's precursor, Continuous Integration. Managing microservices in production. Promotion of working software 'up' the pipeline means we automate deployment to each new environment. 15. Design for failure A consequence of using services as components, is that applications need to be designed so that they can tolerate the failure of services. ince services can fail at any time, it's important to be able to detect the failures quickly and, if possible Synthetic monitoring. Unified monitoring 16. Evolutionary Design Agile pattern Evolving architecture 17. Tools and techniques lApache camel lJboss fuse lWSO2 18. Technology changes support Maturity in DevOp API management tool Maturity in REST approach. Asynchronous capability 19. Reference Martin flower.