WSO2Con EU 2016: Understanding Microservice Architecture
1 like519 views
The document discusses microservice architecture (MSA) as an alternative to monolithic architecture, highlighting its advantages such as independent service deployment, decentralized data management, and enhanced scalability. It covers design principles, messaging methods, and security considerations, emphasizing the importance of adopting lightweight solutions and standards like OAuth2. Ultimately, MSA is presented as a way to improve organizational performance, although it may not wholly resolve all enterprise IT challenges.
WSO2Con EU 2016: Understanding Microservice Architecture
- 4. Monolithic Architecture • All func.onali.es are implemented/deployed into a single soBware applica.on. • Enterprise soBware applica.ons - ERPs, CRMs etc. • SOA/web services: 'coarse-grained' services, broad scope, mammoth services with several dozens of opera.ons and complex message formats
- 6. Monolithic Architecture • Developed and deployed as a single unit. • Overwhelmingly complex; which leads to nightmares in maintaining, upgrading and adding new features. • Redeploy the en>re applica>on, in order to update a part of it. • Scaling : scaled as a single applica>on and difficult to scale with conflic>ng resource requirements whole applica>on down • Reliability - One unstable service can bring the. • Hard to innovate, prac>ce agile development and delivery methodologies
- 10. Designing Microservices : Size, scope and capabili.es • Common Misconcep.ons – Lines of Code – Team size – 'Micro' is a bit misleading term – Use web services and rebranding them as microservices
- 11. Designing Microservices : Size, scope and capabili.es • Common Misconcep.ons – Lines of Code – Team size – 'Micro' is a bit misleading term – Use web services and rebranding them as microservices
- 12. Designing Microservices : Size, scope and capabili.es • Single Responsibility Principle(SRP): Having a limited and a focused business scope. • Scope – Find the service boundaries and align them with the business capabili.es (aka DDD) – Focus on scope of the microservice. – Its not about making services small… • Agile and independent development and deployment of the service. • Microservice should have a very few opera.ons/func.onali.es and simple message format.
- 13. Messaging in Microservices • In Monolithic architecture: – Func.on calls or language-level method calls – SOA/web services : SOAP and WS* with HTTP, JMS etc. – Web services with several dozens of opera.ons and complex message schemas • In Microservices architecture: – Simple and lightweight messaging mechanism.
- 14. Messaging in Microservices • Synchronous Messaging – Client expects a .mely response from the service and waits .ll it get it. – REST, ThriB
- 15. Messaging in Microservices • Asynchronous Messaging – Client doesn't expects a response immediately, or not accepts a response at all – AMQP, STOMP, MQTT • Message Formats – JSON, XML, ThriB, ProtoBuf, Avro • Service Contracts – Defining the service interfaces - Swagger, RAML, ThriB IDL
- 18. Data Management • Decentralized Data management with Microservices – Each microservice can have a private database to persist the data that requires to implement the business func.onality offered from it. – Can only access the dedicated private database but not the databases of other microservices. – You might have to update several database for a single transac.on. In such scenarios, the databases of other microservices should be updated through its service API only.
- 19. Decentralized Governance • Governance – “establishing and enforcing how people and solu.ons work together to achieve organiza.onal objec.ves”, run.me/design .me. • In MSA: – No centralized design-.me governance. – Make their own decisions about its design and implementa.on. – Foster the sharing of common/reusable services. – Run-.me governance aspects such as SLAs, throgling, monitoring, common security requirements and service discovery may be implemented at API-GW level.
- 20. Service Registry and Service Discovery • Service Registry – Holds the microservices instances and their loca.ons • Service Discovery – find the available microservices and their loca.on
- 23. Microservices Deployment • Ability to deploy/un-deploy independently of other microservices. • Must be able to scale at each microservices level. • Building and deploying microservices quickly. • Failure in one microservice must not affect any of the other services.
- 24. Microservices Deployment • Docker – Docker is becoming an extremely popular way of packaging and deploying services. – Package the microservice as a (Docker) container image. – Deploy each service instance as a container. – Scaling is done based on changing the number of container instances. – Building, deploying and star.ng microservices will be much faster as we are using Docker containers
- 27. Security • Security in Monolithic applica.ons – 'who is the caller', 'what can the caller do' and 'how do we propagate that informa>on’ – Implemented at a common security component which is at the beginning of the request handling chain and that component populates the required informa.on with the use of an underlying user repository
- 28. Security • Security in Microservices – A security component has to be implemented at each microservices level that uses a central user repository/store. – Not scalable! – Leverage the widely used API-Security standards such as OAuth2 and OpenID Connect(OIDC) OAuth 2.0 – Access Token : By Reference OIDC – JWT : By Value
- 34. Microservices in Modern Enterprises • Inner and Outer Architecture – Inner Architecture : The pure microservices components which is less complex are categorized under 'Inner Architecture' – Outer Architecture : This delivers the plakorm capabili.es that are required to build a solu.on around the microservices that we build.
- 37. Conclusion • Microservices is not a panacea : It won't solve all your enterprise IT needs. • ‘SOA done right’! • Most enterprise won't be able to convert their en.re enterprise IT systems to microservices. • Enterprise Integra.on never goes away. • Microservices are exposed as APIs. • Interac.on between microservices should be support via a lightweight orchestra.on engine or inside another microservice.