Understanding  Microservice  Architecture    (MSA)  

Sagara  Gunathunga  So7ware  Architect  WSO2    

Monolithic  Applica-ons    

Built  as  a  single  unit,  so  they  are  responsible  for  every  possible  funcConality:  

handling  HTTP  requests,  UIs,  execuCng  domain  logic,  database  operaCons,  

communicaCon  with  the  browser/client,  handling  authenCcaCon  and  so  on.  

Drawbacks  of  Monolithic  u  Even  smallest  changes  involves  building  and  deploying  the  whole  

applicaCon.  

u  Scalability  issues  :  have  to  run  mulCple  instances,  even  if  you  know  that  boPlenecks  are  lay  on  one  component.  

u  One  technical  stack  is  defined  for  whole  soluCon,  without  considering  most  suitable  technology  for  each  components.      

u  High  coupling  among  project  teams.      

u  Can’t  evolve  or  replace  part  of  the  applicaCon  easily.    

What  is  ‘MSA’  ?    An  architectural  style  to  developing  a  single  applica-on  

 as  a  suite  of  small  services  

 

     

   

 -­‐  Mar&n  Fowler  

Monolithic  Vs  Microservice  

‘MSA’  -­‐    Two  Architecture  Viewpoints  

The  Inner  Architecture  -­‐  Architecture  of  an  individual  Microservice.  

The  Outer  Architecture  -­‐  Architecture  of  the  ecosystem  in  which  Microservices  

will  be  built,  deployed  and  executed.  

     

   

Inner    Architecture    

Outer  Architecture    

‘MSA’  -­‐    Inner  Architecture    

Inner    Architecture    

Characteris-cs  of    Microservice  

1.  “Micro"  is  a  concept  of  scope  rather  than  size.  A  microservice  

must  have  a  single  purpose  and  be  loosely  coupled  in  design  

 

     

   

•  NOT    a  service  implemented  with  a  small  amount  of  code.  

•  NOT  a    simple  API  to  a  more  complex  service                implemented  as  part  of  a  monolithic  applicaCon.      •  NOT  a  service  exposed  via  API  by  another  party        

2.  Microservices  should  be  independently  deployable  and  

independently    disposable      

   

 

 

     

   

Characteris-cs    Microservice  

•  Microservices  must  to  be  disposable.  If  a  microservice  fails  or  is  superseded  a  bePer  service,  then  simply  dispose  of  the  old  one.    

•  Require  lot  of  support  from  deployment  architecture  and  operaConal  environment  in  which  microservices  will  be  built,  deployed  and  executed.  

3.  Organized  around  Business  CapabiliCes  not  around  management  focused  teams  such  as    UI  ,server-­‐side,  DB        

 

     

   

Characteris-cs  of    Microservice  

4.  Decentralized  Data  Management    

 

     

   

Characteris-cs  of  Microservice  

5.  Supports  Technology  Heterogeneity  among  services      

 

     

   

Characteris-cs  of    Microservice  

MSA  and  SOA  

MSA  is  not  based  on  all-­‐new  architectural  principle;  It  combines  SOA  best  prac-ces  with  modern  applica-on  delivery  tooling  and  organiza-onal  disciplines.    

+  

‘MSA’  -­‐    Outer  Architecture  

Outer  Architecture    

‘MSA’  -­‐    Outer  Architecture  

•  Service  Gateway    •   Expose  services  as  managed  APIs  •  Provides  traffic  and  policy  (security)  management    

•  Service  RouCng  •  Route  message  to  right  service  based  on  clients  and  service  polices  

 •  Load  Balancing  

•  Support  service  scalability  

•  Service  Discovery  •  Register  and  find  services  and  endpoints  dynamically  

‘MSA’  -­‐    Outer  Architecture  

•  Shared  configuraCon  •  Sharing  configuraCon  details  among  new  nodes.    

•  Dependency  management    •  Track  and  manage  dependencies  among  services    

•  Messaging  channels  •  Support  asynchronous  communicaCon  based  on  publish/subscribe  

and  event  sourcing  paPerns.      

MSA  challenges  –  End  to  end  Monitoring    1.  Service  level  (APM)    &  deployment  level  dashboards    

 2.  TransacCon  tracing,  replay  and  log  analysis    

 3.  Service  InstrumentaCon      

 

MSA  challenges  –  Security  

1.  AuthenCcaCon  and  AuthorizaCon    

2.  Security  context  propagaCon  among  services      

MSA  challenges  –  Service  Discovery  

•  Client-­‐side  Service  Discovery              •  Server-­‐Side  Service  Discovery      

MSA  challenges  –  Deployment  Scalability    

•  ApplicaCon  pladorm  as  a  service  (aPaaS)  •  WSO2  AppCloud    

 •  OS  container  management  systems    

•  Google  Kubernetes  •  Apache  Mesos    

 •  Lightweight  server  OS  

•  CoreOS  •  Atomic        

MSA  and  WSO2  Although  aPaaS  pladorms  come  closest,  they  are  sCll  general-­‐purpose  pladorms,  and  there  is  currently  no  such  thing  as  a  holisCc,  commercially  supported  "microservice  pladorm"  that  brings  together  all  of  the  necessary  capabiliCes.    

- Gartner (January 2015)

WSO2  offer  ….      ①   A  compeCCve  Microservice  framework  to  support  “Inner  

Architecture”      (WSO2  MSF4J)  

② A  complete  pladorm  to  support    “Outer  Architecture  “    (  AnalyCcs,  Security,  discovery  ,  gateways,  MQ  etc.)    

MSA  and  WSO2  Service  Gateway    

   

Service  Rou-ng    

   

Service  Discovery  Shared  Configura-on  Dependency  Management  

     

Messaging  

   

Monitoring      

Security    

   

WSO2  MSF4J    

2.30  PM  

MSA  Drawbacks    

•  Complexity  Is  Moved  Not  Removed                        -­‐  Understanding,  managing  and  tesCng  dependencies  is  difficult.    •  Centralized  governance  is  not  possible                    -­‐  Large  numbers  of  Microservices  are  difficult  to  orchestrate    •  Increase  Network  communicaCon                  -­‐  Independently  running  component  interact  with  each  other  using  N/W                          calls.  Such  system  require  reliable  and  fast  network  connecCons.      

MSA  Drawbacks      •  Network  Security                -­‐  Inter  Service  CommunicaCon  need  to  be  secured  to  avoid  any  inter  communicaCon  security  breach  these  applicaCon                      are  more  prone  to  security  vulnerabiliCes.  

•  ProducCon  monitoring                  -­‐  Monitoring  the  applicaCon  in  producCon  deployment  becomes  a  complex  job,  with  mulCple  services.        

Thank  You