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

1. Understanding Microservice Architecture
Kasun Indrasiri
Director, Integra.on Technologies
WSO2

2. Microservices?

3. Monolithic 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

5. Monolithic Architecture
• Use case : Online Retail soBware applica.on which comprises of
mul.ple business func.onali.es.
JVM

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. Microservices Architecture

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. Microservices Architecture
• Use case : Online retail applica.on can be implemented with a
suite of microservices
JVM
JVM
JVM
JVM

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

16. Data Management
• Monolithic applica.ons use a centralized database

17. Data Management
• Monolithic applica.ons use a centralized database

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

21. Service Discovery
• Client-side Discovery

22. Service Discovery
• Server-side Discovery

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

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. Microservices Deployment
• Use case : The microservices of Online Retail soBware applica.on
with can be deployed and scaled with Docker and Kubernetes.

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

29. Security
• Microservice security with OAuth2 and OpenID Connect

30. Orchestra.ng Microservices
• No ESB in MSA. Then how?

31. Orchestra.ng Microservices
• Point-to-point style - Invoking services directly
– Spaghej integra.on an.-pagern?

32. Orchestra.ng Microservices
• Orchestra.on at the Gateway Layer

33. Orchestra.ng Microservices
• Orchestra.on at Microservices Layer

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. Microservices in Modern Enterprises
Micro Integra.ons

36. WSO2 MSF4J
• A lightweight, high performance framework for building
microservices in Java.
• Agend Sameera’s talk on App-Dev track.

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. Reference
• hgp://kasunpanorama.blogspot.co.uk/2015/11/microservices-in-
prac.ce.html
• hgp://microservices.io/pagerns/microservices.html

39. Thank You!
#WSO2ConEU
Share your feedback for this session
wso2con.com/app