Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

WSO2Con EU 2016: Understanding Microservice Architecture

362 views

Published on

Microservices is one of the most popular buzzwords in software architecture today. There are a lot of theoretical discussions on microservice architecture (MSA), but they don’t really explain how you can leverage MSA in practice. This session gives you complete understanding on microservice architecture and how it can be used in practice. It will cover the following topics:

Discuss what MSA is
Explore the characteristics of MSA through real world examples
Examine the relationship between service-oriented architecture and MSA
Demonstrate how to use microservices in modern enterprise architecture (inner and outer architecture, integrating microservices, microservices and enterprise integration)
Lay out WSO2’s strategic initiatives for microservices with WSO2 Microservices Framework for Java

Published in: Technology
  • Be the first to comment

WSO2Con EU 2016: Understanding Microservice Architecture

  1. 1. Understanding Microservice Architecture Kasun Indrasiri Director, Integra.on Technologies WSO2
  2. 2. Microservices?
  3. 3. Monolithic Architecture
  4. 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
  5. 5. Monolithic Architecture •  Use case : Online Retail soBware applica.on which comprises of mul.ple business func.onali.es. JVM
  6. 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
  7. 7. Microservices Architecture
  8. 8. Microservices Architecture •  The founda.on of microservices architecture(MSA) is about developing a single applica.on as a suite of fine-grained and independent services that are running in its own process, developed and deployed independently. •  It is more than just segrega.ng the services in a monolith…
  9. 9. Microservices Architecture •  Use case : Online retail applica.on can be implemented with a suite of microservices JVM JVM JVM JVM
  10. 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. 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. 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. 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. 14. Messaging in Microservices •  Synchronous Messaging –  Client expects a .mely response from the service and waits .ll it get it. –  REST, ThriB
  15. 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
  16. 16. Data Management •  Monolithic applica.ons use a centralized database
  17. 17. Data Management •  Monolithic applica.ons use a centralized database
  18. 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. 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. 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
  21. 21. Service Discovery •  Client-side Discovery
  22. 22. Service Discovery •  Server-side Discovery
  23. 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. 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
  25. 25. Microservices Deployment •  Kubernetes –  Extending Docker capabili.es by allowing to manage a cluster of Linux containers as a single system, managing and running Docker containers across mul.ple hosts, offering co-loca.on of containers, service discovery and replica.on control.
  26. 26. Microservices Deployment •  Use case : The microservices of Online Retail soBware applica.on with can be deployed and scaled with Docker and Kubernetes.
  27. 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. 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
  29. 29. Security •  Microservice security with OAuth2 and OpenID Connect
  30. 30. Orchestra.ng Microservices •  No ESB in MSA. Then how?
  31. 31. Orchestra.ng Microservices •  Point-to-point style - Invoking services directly –  Spaghej integra.on an.-pagern?
  32. 32. Orchestra.ng Microservices •  Orchestra.on at the Gateway Layer
  33. 33. Orchestra.ng Microservices •  Orchestra.on at Microservices Layer
  34. 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.
  35. 35. Microservices in Modern Enterprises Micro Integra.ons
  36. 36. WSO2 MSF4J •  A lightweight, high performance framework for building microservices in Java. •  Agend Sameera’s talk on App-Dev track.
  37. 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.
  38. 38. Reference •  hgp://kasunpanorama.blogspot.co.uk/2015/11/microservices-in- prac.ce.html •  hgp://microservices.io/pagerns/microservices.html
  39. 39. Thank You! #WSO2ConEU Share your feedback for this session wso2con.com/app

×