grado en ingeniería de tecnologías y sistemas de telecomunicación
TRANSCRIPT
!
!
GRADO EN INGENIERÍA DE TECNOLOGÍAS Y SISTEMAS DE TELECOMUNICACIÓN
TRABAJO FIN DE GRADO
DESIGN OF AN APPLICATION USING MICROSERVICES ARCHITECTURE AND ITS
DEPLOYMENT IN THE CLOUD
LIDIA FERNÁNDEZ GARCÉS 2016
!
!
!
I!
!
TRABAJO FIN DE GRADO !
TÍTULO: Design of an application using microservices architecture and its deployment in the cloud
AUTORA: Dña. Lidia Fernández Garcés TUTOR: D. Juan Carlos Dueñas López DEPARTAMENTO: Departamento de Ingeniería Telemática (DIT) !
!
!
!
!
TRIBUNAL: Presidente: D. David Fernández Cambronero Vocal: D. Juan Carlos Yelmo García Secretario: D. Luis Bellido Triana Suplente: D. José María del Álamo Ramiro !
!
!
!
!
FECHA DE LECTURA: ___________________________ !
CALIFICACIÓN: ________________________________ !
II!
! !
III!
UNIVERSIDAD POLITÉCNICA DE MADRID
!
ESCUELA TÉCNICA SUPERIOR DE INGENIEROS DE TELECOMUNICACIÓN
!
!
!
GRADO EN INGENIERÍA DE TECNOLOGÍAS Y SERVICIOS DE TELECOMUNICACIÓN
TRABAJO FIN DE GRADO
DESIGN OF AN APPLICATION USING MICROSERVICES ARCHITECTURE AND ITS
DEPLOYMENT IN THE CLOUD
LIDIA FERNÁNDEZ GARCÉS
2016 !
IV!
! !
V!
!
!
Resumen El!diseño!de!grandes!aplicaciones!para!empresas!está!evolucionando!de!arquitecturas!monolíticas! a! arquitecturas! basadas! en! microservicios.! Estas! son! particularmente!adecuadas! para! ejecutarse! en! entornos! cloud! porque! cada! microservicio! puede! se!desarrollado,! desplegado! y! gestionado! individualmente,! lo! que! permite! un! control!mucho!más!detallados!y!un!alto!grado!de!escalabilidad.!
Basado!en!un!ejemplo!concreto,!este!proyecto!debe!desarrollar!una!aplicación!usando!una!arquitectura!de!microservicios,!mostrando!los!desafíos!de!esta!opción,!usando!un!entorno! cloud.! Un! proceso! para! la! autmatización! de! la! infraestructura! sera!desarrollado,!incluyendo!la!integración!continua!y!el!despliegue!continuo.!
!
!
Summary The! design! of!modern! large! business! application! systems! is!moving! from!monolithic!enterprise! architectures! towards! microservices! based! architectures.! These! are!especially!well!suited!to!run!in!cloud!environments,!because!each!microservice!can!be!developed,!deployed!and!managed!individually,!which!allows!much!more!fineFgrained!control!and!scalability.!
Based! on! a! concrete! example,! this! projet! should! build! an! application! using! a!microservice! architecture,! showing! the! most! representative! challenges! of! this!approach,! using! a! cloud! environment.! A! process! for! the! automation! of! the!infrastructure! will! be! developed,! including! continuous! integration! and! continuous!deployment.
!
!
Palabras clave microservicios,! arquitectura! de! microservicios,! cloud,! cloud! computing,! integración!continua,!despliegue!continuo,!desarrollo!continuo,!infrastructure!automation!
Keywords microservices,! microservices! architecture,! cloud,! cloud! computing,! continuos!integration,! continuous! deployment,! continuous! development,! infrastructure!automation!
! !
VI!
! !
VII!
Index 1.!Introduction!and!targets!........................................................................................!1!
1.1.!Context!.......................................................................................................................!1!1.2.!Targets!.......................................................................................................................!1!
2.!State!of!Art!............................................................................................................!2!2.1.!Introduction!to!Microservices!.....................................................................................!2!2.2.!Characteristics!of!microservices!..................................................................................!3!
2.2.1.!Componentization!via!Services!...................................................................................!3!2.2.2.!Organized!around!Business!Capabilities!.....................................................................!4!2.2.3.!Products!not!projects!.................................................................................................!5!2.2.4.!Smart!endpoints!and!dumb!pipes!..............................................................................!5!2.2.5.!Decentralized!Governance!.........................................................................................!6!2.2.6.!Decentralized!Data!Management!...............................................................................!6!2.2.7.!Infrastructure!Automation!.........................................................................................!7!2.2.8.!Design!for!failure!........................................................................................................!7!2.2.9.!Evolutionary!design!....................................................................................................!7!
2.3.!Cloud!for!microservices:!Cloud!Foundry!......................................................................!8!2.4.!CI/CD!for!microservices!.............................................................................................!11!
3.!Design!of!the!application!.....................................................................................!13!3.1.!Description!of!the!application!...................................................................................!13!3.2.!Management!of!Users!Microservice!..........................................................................!14!
3.2.1.!Description!...............................................................................................................!14!3.2.2.!Architecture!..............................................................................................................!14!3.2.3.!API!Design!.................................................................................................................!15!3.2.4.!Client!design!.............................................................................................................!18!3.2.5.!Persistence!Layer!......................................................................................................!20!3.2.6.!Microservice!characteristics!.....................................................................................!21!
3.3.!Management!of!Internships!Microservice!.................................................................!22!3.3.1.!Description!...............................................................................................................!22!3.3.2.!Architecture!..............................................................................................................!22!3.3.3.!Technologies!.............................................................................................................!26!3.3.4.!Design!.......................................................................................................................!27!3.3.5.!Application!Layer!......................................................................................................!28!3.3.6.!Domain!Layer!............................................................................................................!31!3.3.7.!Message!Bus!.............................................................................................................!32!3.3.8.!Persistence!Layer!......................................................................................................!33!3.3.9.!Microservice!characteristics!.....................................................................................!35!
3.4.!International!Exchange!Microservice!........................................................................!36!3.4.1.!Description!...............................................................................................................!36!3.4.2.!Architecture!..............................................................................................................!36!3.4.3.!Design!.......................................................................................................................!36!3.4.4.!Persistence!Layer!......................................................................................................!38!3.4.5.!Microservice!characteristics!.....................................................................................!39!
3.5.!Complete!Application!...............................................................................................!39!3.5.1.!Description!...............................................................................................................!39!3.5.2.!Architecture!..............................................................................................................!39!3.5.3.!Microservices!characteristics!...................................................................................!40!
4.!Continuous!Integration!and!Continuous!Deployment!...........................................!43!4.1.!CI/CD!pipeline!...........................................................................................................!43!
VIII!
4.2.!Version!control:!Git!and!Bitbucket!............................................................................!44!4.3.!Build!Automation:!Grunt!...........................................................................................!45!4.4.!Test!Automation:!Mocha!and!Chai!............................................................................!45!4.5.!Deployment!Automation:!Cloud!Foundry!..................................................................!45!4.6.!Creating!the!pipe:!Strider!CD!.....................................................................................!47!
5.!Results!and!Conclusions!.......................................................................................!48!5.1.!Final!results!..............................................................................................................!48!5.2!Future!work!lines!.......................................................................................................!48!5.3.!Conclusions!...............................................................................................................!49!
6.!Bibliography!........................................................................................................!49!!
!
!
!
!
!
!
1!
1. Introduction and targets 1.1. Context The! design! of!modern! large! business! application! systems! is!moving! from!monolithic!towards!microservices!based!architectures.!These!are!especially!well! suited! to! run! in!cloud! environments,! because! each! microservice! can! be! developed,! deployed! and!managed! individually,! which! allows! much! more! fineFgrained! control! and! scalability.!Microservices! should! be! small! and! focused! on! specific! business! capability,! loosely!coupled!and!language!neutral!to!allow!independent,!frequent!and!fast!updates.
When!building!microservices!architectures,!it!is!usual!to!develop!a!continuous!software!development! strategy.! Through! continuous! integration,! continuous! delivery! and!continuous!deployment,! the! lifecycle!of! the!application! is!automated,!allowing!a! fast!delivery! of! results.! Instead! of! waiting! for! different! versions! to! be! released,! the!software! is! in! a! continuous! process! of! change.! This! leads! to! a! reduction! in! the!deployment!risk!and!facilitates!quicker!feedback!from!users!of!the!application.
1.2. Targets Based!on!a!concrete!simple!example,! this!project!should!build!an!application!using!a!microservice! architecture,! showing! the! most! representative! challenges! of! this!approach,! using! a! cloud! environment.! A! process! for! the! automation! of! the!infrastructure!will!be!developed,!including!continuous!integration,!continuous!delivery!and!continuous!deployment.!
2!
2. State of Art 2.1. Introduction to Microservices Traditionally,! applications! have! been! built! following! a! monolithic! architecture.! In!software! engineering,! a! monolithic! application1! describes! a! singleFtiered! software!application!in!which!the!user!interface!and!data!access!code!are!combined!into!a!single!program!from!a!single!platform.!A!monolith! is! selfFcontained,!and! independent! from!other! computing! applications.! The! design! philosophy! is! that! the! application! is!responsible! not! just! for! a! particular! task,! but! can! perform! every! step! needed! to!complete!a!particular!function.!As!a!result,!monolithic!application!describes!a!software!application!which! is!designed!without!modularity.!Modularity! is!desirable,! in!general,!as!it!supports!reuse!of!parts!of!the!application!logic!and!also!facilitates!maintenance!by!allowing!repair!or!replacement!of!parts!of!the!application!without!requiring!wholesale!replacement.!
There! are!different! solutions! to! reach! this! desirable!modularity.! For! example,! object!based!modularity!provides!the!application!as!a!collection!of!separate!executable!files!which!may!be!independently!maintained!and!replaced!without!redeploying!the!entire!application.!Some!object!messaging!capabilities!allow!object!based!applications!to!be!distributed! across!multiple! computers.! Another!modular! solution! is! serviceForiented!architecture! (SOA).! SOA2! is! design! pattern! based! on! distinct! pieces! of! software!providing! application! functionality! as! services! to! other! applications! via! a!communications!protocol,!typically!over!a!network.
SOA! is! based! on! the! concept! of! a! service.! A! service! is! a! selfFcontained! unit! of!functionality,!such!as!retrieving!an!online!bank!statement.!By!that!definition,!a!service!is! an! operation! that! may! be! discretely! invoked.! However,! in! the! Web! Services!Description!Language!(WSDL),!a!service!is!an!interface!definition!that!may!list!several!discrete!services/operations.!And!elsewhere,!the!term!service!is!used!for!a!component!that!is!encapsulated!behind!an!interface.!For!the!purpose!of!this!work,!we!will!use!the!first!definition!when!referring!to!services.
Depending! on! the! service! design! approach! taken,! each! SOA! service! is! designed! to!perform!one!or!more!activities!by!implementing!one!or!more!service!operations.!As!a!result,!each!service!is!built!as!a!discrete!piece!of!code.!This!makes!it!possible!to!reuse!the! code! in! different!ways! throughout! the! application! by! changing! only! the!way! an!individual! service! interoperates! with! other! services! that! make! up! the! application,!versus!making!code!changes!to!the!service!itself.!SOA!design!principles!are!used!during!software!development!and!integration.
In!the!later!years,!a!particular!SOA!has!gained!popularity:!microservices.!Microservice!architectural!style1!is!an!approach!to!developing!a!single!application!as!a!suite!of!small!services,! each! running! in! its! own! process! and! communicating! with! lightweight!mechanisms,! often! an! HTTP! resource! API.! It! is! distinct! from! a! serviceForiented!architecture!in!that!the!latter!aims!at!integrating!various!applications!whereas!several!microservices!belong!to!one!application!only
3!
2.2. Characteristics of microservices Summarising!from!the!previous!section,!microservice!architectural!style!is!an!approach!to!developing!a!single!application!as!a!suite!of!small!services,!each!running!in!its!own!process!and!communicating!with!lightweight!mechanisms,!often!an!HTTP!resource!API.!These!services!are!built!around!business!capabilities!and!independently!deployable!by!fully! automated! deployment! machinery.! There! is! a! bare! minimum! of! centralized!management! of! these! services,! which! may! be! written! in! different! programming!languages!and!use!different!data!storage!technologies.
Microservices! architectures! have! some! common! main! characteristics:! they! are!composed! via! services,! the! are! organized! around! business! capabilities,! they! are!organised!around!products!(not!projects),!they!have!smart!endpoints!and!dumb!pipes,!they!have!a!decentralized!governance...!
2.2.1. Componentization via Services
In!this!context,!we!understand!component!as!a!unit!of!software!that!is!independently!replaceable!and!upgradeable.!Microservices!architectures!use!services!as!components,!while!monoliths!use!libraries.!We!define!libraries!as!components!that!are!linked!into!a!program!and!called!using! inFmemory! function!calls,!while!services!are!outFofFprocess!components!who!communicate!with!a!mechanism!such!as!a!web!service! request,!or!remote!procedure!call.!Microservice!architectures!will!use! libraries,!but!their!primary!way!of!componentizing!their!own!software!is!by!breaking!down!into!services.
One!main!reason!for!using!services!as!components! is!that!services!are!independently!deployable.! If!we!have!an!application! that!consists!of!a!multiple! libraries! in!a! singles!process,! a! change! to! any! single! component! results! in! having! to! redeploy! the! entire!application.!But!if!the!application!is!decomposed!into!multiple!services,!you!can!expect!many!single!service!changes!to!only!require!that!service!to!be!redeployed.
Another! consequence!of!using! services!as! components! is!a!more!explicit! component!interface.! Most! languages! do! not! have! a! good! mechanism! for! defining! an! explicit!published!interface.!Often!it!is!only!documentation!and!discipline!that!prevents!clients!breaking! a! component’s! encapsulation,! leading! to! overlyFtight! coupling! between!components.! Services! make! it! easier! to! avoid! this! by! using! explicit! remote! calling!mechanism.
Using! services! like! this! has! downsides.! Remote! calls! are! more! expensive! than! inFprocess! calls,! and! thus! remote! APIs! need! to! be! coarsedFgrained,! which! is! more!awkward! to! use.! If! you! need! to! change! the! allocations! of! responsibilities! between!components,! such!movements!of!behaviour!are!harder! to!do!when!you!are! crossing!process!boundaries.!
!
!
4!
2.2.2. Organized around Business Capabilities
When!looking!to!split!a!large!application!into!parts,!often!management!focuses!on!the!technology!layer,!leading!to!UI!teams,!serverFside!logic!teams,!and!databases!teams.!
!
!Figure!1:!Conway's!Law!in!action
When!teams!are!separated!along!these!lines,!even!simple!changes!can!lead!to!a!crossFteam! project! taking! more! time! and! human! resources.! Microservice! architecture!propose!a!different!approach,!based!in!Conway’s!Laws
! Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.’
Melvyn+Conway,+1967
Microservices! approach! splits! up! into! services! organized! around! business! capability.!Such! services! take!a!broad! stack! implementation!of! software! for! that!business! area,!including! userFinterface,! persistent! storage,! and! any! external! collaborations.!Consequently!the!teams!are!crossFfunctional,!including!the!full!range!of!skills!required!for!the!development:!userFexperience,!database,!and!project!management.
!
5!
!Figure!2:!Service!boundaries!reinforced!by!team!boundaries
2.2.3. Products not projects
Most!application!development!efforts!that!we!see!use!a!project!model:!where!the!aim!is! to! deliver! some!piece! of! software,!which! is! then! considered! to! be! completed.!On!completion!the!software!is!handed!over!to!a!maintenance!organization!and!the!project!team!that!built!it!is!disbanded.
Microservice!proponents!tend!to!avoid!this!model,!preferring!instead!the!notion!that!a!team!should!own!a!product!over!its!full!lifetime.!The!product!mentality!ties!in!with!the!linkage! to! business! capabilities.! Rather! than! looking! at! the! software! as! a! set! of!functionality!to!be!completed,!there!is!an!onFgoing!relationship!where!the!question!is!how!can!software!assist!its!users!to!enhance!the!business!capability.
2.2.4. Smart endpoints and dumb pipes
Applications! built! from! microservices! aim! to! be! as! decoupled! and! as! cohesive! as!possible,!receiving!a!request,!applying!logic!as!appropriate!and!producing!a!response.!These!are!usually!choreographed!using!simple!REST!protocols.!
The! two! protocols! used! most! commonly! are! HTTP! requestFresponse! with! resource!API’s!and!lightweight!messaging.!The!first!one!use!the!principles!and!protocols!that!the!world!wide!web!is!built!on.!Often!used!resources!can!be!caches!with!very!little!effort!on! the! part! of! developing! or! operations.! The! second! approach! in! common! use! is!messaging! over! a! lightweight! message! bus.! The! chosen! infrastructure! acts! as! a!message!router!only:!the!smart!part!lives!in!the!endpoints,!producing!and!consuming!messages!in!the!services.
The! biggest! issue! in! changing! a! monolith! into! microservices! lies! in! changing! the!communication!pattern.! In!a!monolith,! the!components!are!executing! inFprocess!and!communication!between!the!is!via!either!method!invocation!or!function!call.
6!
2.2.5. Decentralized Governance
In! a! centralized!governance!model,! the!authority,! responsibility! and!decision!making!power!are!vested!solely!within!a!central!body.!One!of!its!consequences!is!the!tendency!to!standardise!on!single!technology!platforms:!using!the!same!languages!and!the!same!standards!for!the!whole!application.
Splitting!the!monolith’s!components!out!into!services!we!have!a!choice!when!building!each!of!them.!We!can!choose!the!appropriate!languages!and!standards!depending!on!the!job!we!want!to!do.!In!microservice!architecture!it!is!preferred!to!use!the!right!tool!for! the! job! and,! while! monolithics! applications! can! take! advantage! of! different!languages!to!a!certain!extent,!it!is!not!that!common.
2.2.6. Decentralized Data Management
Decentralization!of!data!management!presents! in!a!number!of!different!ways.!At!the!most! abstract! level,! it! means! that! the! conceptual! model! of! the! world! will! differ!between!systems.!For!example,!some!things!that!are!called!customers!in!the!sales!view!may!not!appear!at!all!in!the!support!view.
The! issue! is! common! between! applications,! but! can! also! occur! within! applications,!particularly!when!that!application!is!divided!into!separate!components.!A!useful!way!of!thinking! about! this! is! the! DomainFDriven! Design! (DDD)! notion! of! Bounded! Context.!DDD!divides!a!complex!domain!up! into!multiple!bounded!contexts!and!maps!out!the!relationships!between!them
Microservices!also!decentralized!data!storage!decisions.!Monolithic!applications!prefer!a! single! logical! database! across! a! range! of! applications.!Microservices! prefer! letting!each!service!manage!its!own!database,!either!different!instances!of!the!same!database!technology,! or! entirely! different! database! systems! F! an! approach! called! Polyglot!Persistence.
Decentralizing! responsibility! for! data! across! microservices! has! implications! for!managing! updates.! The! common! approach! to! dealing!with! updates! has! been! to! use!transactions! to! guarantee! consistency! when! updating! multiple! resources.! This!approach!is!often!used!within!monolithics.
Using! transactions! like! this! helps! with! consistency,! but! impose! significant! temporal!coupling,! which! is! problematic! across!multiple! services.! Distributed! transactions! like!this! helps! with! consistency,! but! imposes! significant! temporal! coupling,! which! is!problematic!across!multiple!services.!Distributed!transactions!are!notoriously!difficult!to! implement! and,! as! a! consequence,! microservice! architecture! emphasize!transactionless! coordination! between! services,! with! explicit! recognition! that!consistency! may! only! be! eventual! consistency! and! problems! are! dealt! with! by!compensating!operations.!
!
!
7!
2.2.7. Infrastructure Automation
Infrastructure! Automation! techniques! have! evolved! enormously! over! the! last! few!years!F!the!evolution!of!the!cloud!has!reduced!the!operational!complexity!of!building,!deploying!and!operating!microservices.
Many! of! the! products! or! systems! being! build! with! microservices! are! being! built! by!teams!with!extensive!experience!of!Continuous!Delivery!and!its!precursor,!Continuous!integration.! Teams! building! software! this! way! make! extensive! use! of! infrastructure!automation!techniques.!This!is!illustrated!in!the!build!pipeline!shown!below.
!Figure!3:!example!of!a!basic!build!pipeline
We! will! explain! further! about! infrastructure! automation! in! the! section! ‘CI/CD! for!microservices’.
2.2.8. 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.!Any!service!call!could!fail!due!to!unavailability! oft! he! supplier,! so! the! client! has! to! respond! to! this! as! gracefully! as!possible.! This! is! a! disadvantage! compared! to! a! monolithic! design! as! it! introduces!additional! complexity! to! handle! it.! The! consequence! is! that! microservice! teams!constantly!reflect!on!how!service!failures!affect!the!user!experience.
Since! services! can! fail! at! any! time,! it! is! important! to! be! able! to! detect! the! failures!quickly!and,! if!possible,!automatically!restore!service.!Microservice!applications!put!a!lot!of!emphasis!on!realFtime!monitoring!of!the!application,!checking!both!architectural!elements!and!business!relevant!metrics.
This! is!particularly! important! in!a!microservice!architecture!because!the!microservice!preference! towards! choreography! and! event! collaboration! leads! to! emergent!behaviour.!
2.2.9. Evolutionary design
Service! decomposition! is! a! further! tool! to! enable! application! developers! to! control!changes!in!their!application!without!slowing!down!change.!Whenever!we!try!to!break!a!
8!
software! system! into! components,! the! key! property! of! them! is! the! notion! of!independent!replacement!and!upgradeability.
This!emphasis!on!replaceability!is!a!special!case!of!a!more!general!principle!of!modular!design,!which!is!to!drive!modularity!through!the!pattern!of!change.!Parts!of!the!system!that!change!rarely!should!be!in!different!services!to!those!that!change!often.
Putting! components! into! services! adds! an! opportunity! for! more! granular! release!planning.!With! a!monolithic! any! changes! require! a! full! build! and! deployment! of! the!entire! application:! with! microservices! you! only! need! to! redeploy! the! service! you!modified.! The! downside! is! that! you! have! to! worry! about! changes! to! one! service!breaking!its!consumers.!The!traditional!integration!approach!is!to!try!to!deal!with!this!problem!using!versioning,!but!the!preference!in!the!microservice!world!is!to!only!use!versioning!as!a!last!resort.!We!can!avoid!a!lot!of!versioning!by!designing!services!to!be!as!tolerant!as!possible!to!changes!in!their!supplies.!
2.3. Cloud for microservices: Cloud Foundry Moving!from!a!traditional!monolithic!architecture!to!a!microservices!approach!is!not!a!trivial! change! for! organizations,! and! it! is! full! of! challenges.! Since! microservices!architecture! is! usually! polyglot!we! should!deal!with!multiple! languages,! each!one!of!them! with! the! entire! ecosystem! associated:! tooling,! artifact! repository,! IDEs,! test!frameworks,! etc.! Also,! since! a! microservices! architecture! resides! across! different!servers!and!networks,!we!can!find!the!problems!associated!to!distributed!computing:!latency,!unreliability!and!bandwidth! limits.!We!will!also! find!difficulties!regarding!the!interfaces.!As!the!number!of!microservices!making!up!an!application!increases,!so!does!the! number! of! integration! points.! Associated!with! each! integration! point! is! a! public!interface! allowing! other! microservices! and! applications! to! access! it.! Each! of! these!interfaces!require!a!naming!scheme,!error!handling!protocol,!serialization!mechanism,!and! routing! facility.! Each! of! these! aspects! is! dramatically! more! complex! when! the!intercommunication! is! over! the! network! as! compared! to! via! a! library! call! or! object!message!invocation.
There! are! many! more! challenges:! even! understanding! and! conceptualizing! a!microservices! architecture! is! difficult.! This! is! why! choosing! the! right! tools! is!significantly!helpful.!Luckily,!the!popularization!of!microservices!in!the!last!years!didn’t!come!alone.!New!technologies!appeared!in!order!to!facilitate!the!work!of!building!this!architecture.
One! technology! stands! out! for! being! strongly! related! to! the! development! of!microservices:! cloud3!computing.!Microservices! seems! to!be!nowadays! the!preferred!architecture!for!building!cloud!native!application!and,!as!a!consequence,!we!can!find!multiple!tools!in!this!field!for!deploying!and!operating!this!architecture.!
Cloud!Computing!is!a!model!for!enabling!ubiquitous,!convenient,!onFdemand!network!access!to!a!shared!pool!of!configurable!computing!resources!(e.g.,!networks,!servers,!storage,!applications,!and!services)!that!can!be!rapidly!provisioned!and!released!with!minimal! management! effort! or! service! provider! interaction.! Cloud! computing! has!become!a!highly!demanded!service!or!utility!due!to!the!advantages!of!high!computing!
9!
power,! cheap! cost! of! services,! high! performance,! scalability,! accessibility! as! well! as!availability.
Cloud!computing!is!defined!by!the!following!main!features:
• OnVdemand! selfVservice:! computing! resources! are! delivered! to! the! consumer!without! the!human! intervention.! The! system! is! able! to! scale! via!dynamic!onFdemand!provisioning,!according!to!the!user!needs.!
• Broad!network!access:!cloud!services!are!available!over!the!network,!enabling!users!to!access!them!regardless!of!their!position!or!the!platform!they!use!(e.g.!smartFphones,!laptops,!etc.).!
• Resource! pooling:! cloud! computing! providers! provide! pooled! computing!capabilities!that!are!used!to!serve!consumers!using!a!multitenancy!model;!this!model! reduces! costs! and! utilization,! since! virtual! and! physical! resources! are!assigned!based!on!user!demand.! In!this!case!virtualization!plays!an! important!role,!providing!maximum!flexibility!to!configure!various!partitions!of!resources!on!the!same!physical!machine.!
• Rapid! elasticity:! resources! provisioning! can! adapt! very! rapidly! to! the! instant!demand,! optimizing! resource! utilization! and! increasing! the! perceived! quality,!giving!to!the!consumer!the!impression!of!a!single!dedicated!resource.!
• Measured! service:! clouds! allows! for! transparent! tracing! and! report! of! user!consumption.!This!characteristic!enables!the!adoption!of!a!payFperFuse!model!where!users!are!billed!based!on!their!consumption.!
Though! serviceForiented! architecture! advocates! "everything! as! a! service"4! (with! the!acronyms!EaaS!or!XaaS!or!simply!aas),!cloudFcomputing!providers!offer!their!"services"!according!to!different!models,!which!happen!to!form!a!stack:!infrastructureF,!platformF!and!softwareFasFaFservice:
• Infrastructure! as! a! Service! (IaaS)! provides! machines,! storage,! and! network!resources! that! developers! can! manage! by! installing! their! own! operating!systems,!development!tools,!and!administrative!tools.!
• Platform!as!a!Service!(PaaS)!provides!a!platform!within!developers!can!deploy!their! applications.! A! PaaS! solution! includes! hardware! (servers! and! disks),!operating!systems,!development!tools,!and!administrative!tools.!
• Software!as!a!service!(SaaS)!provides!a!complete!software!application!hosted!by! a! vendor! or! service! provider! and! made! available! to! customers! over! a!network,!typically!the!Internet.!
!
10!
!Figure!4:!Iaas,!PaaS,!SaaS!provided!services
Both! IaaS!and!PaaS!offers!plenty!of! tools! for!building!microservices!architectures,! so!we!should!examine!the!drawbacks!and!benefits!of!each!model.!In!IaaS,!resources!are!available! as! a! service.! This! give! us! control! over! the! infrastructure,! allowing! dynamic!scaling! capabilities,! and! the! cost! varies! based! on! the! infrastructure! selection.! This!model! is!adequate!when!we!need!to!specifically!define!the! infrastructure!needed!for!the! software.! In! PaaS,! we! don’t! have! control! over! the! infrastructure:! it! focuses! in!deploying! the!application.!We!still!have!some!control!over! the!performance! Fwe!can!deploy!several!instances,!configure!a!load!balance!router,!etc.!PaaS!also!simplifies!the!process! of! developing! the! application.! It! offers! databases,! tools! for! managing! and!monitoring!applications,!tools!for!automatic!resources!scale,!job!scheduling,!etc.!Since!the!purpose!of!this!project!is!the!development!of!a!software!architecture,!leaving!the!performance! in! a! second! plane,! we! have! chosen! to! use! a! Platform! as! a! Service.!Running! an! application! on! bare! IaaS! requires! to! define! the! infrastructure! and! to!maintain!it.!An!automated!PaaS!abstracts!the!infrastructure!layer,!allowing!us!to!centre!our! efforts! in! the! development! of! the! application,! and! it! provides! us!with! plenty! of!tools!for!doing!so.
Between!the!different!PaaS!solutions,!we!have!chosen!Cloud!Foundry5.!This!PaaS!offers!certain!advantages!that!we!are!going!to!profit!from:
• Languages:!Cloud!Foundry!Buildpacks!provide!framework!and!runtime!support!for! our! applications.! Buildpacks! typically! examine! userFprovided! artifacts! to!determine!what!dependencies!to!download!and!how!to!configure!applications!to! communicate! with! bound! services.! Cloud! Foundry! offers! a! wide! variety,!allowing!us!to!develop!in!the!language!in!which!we!feel!more!comfortable.!
• Platform! plumbing:! Cloud! Foundry! provides! sophisticated! assistance! in!integrating!services!and!subsystems!into!a!larger!system.!It!can!aid!a!developer!by!supplying!RabbitMQ!messaging;!data!services,!including!MySQLFasFaFservice;!
11!
and!Spring!Boot,!a!deployment!service!that!automatically!includes!a!lightweight!application!server!with!the!application!so!that!it's!ready!to!run.!
• Broad! open! source! integration:! This! includes! Apache! Tomcat,! Jenkins!continuous! integration,! Chef,! or! Puppet! configuration,! Ansible! cluster!configuration! and! task! deployment,! and! Redis! or! MongoDB! NoSQL!unstructured!data!management!system.!
2.4. CI/CD for microservices Although! it! is! not! required,! one! of! the! usual! characteristics! of! microservices!architecture!is!the!infrastructure!automation.!From!the!point!of!view!of!‘products,!not!projects’!explained! in!previous! sections,! the! team!should!own!a!product!over! its! full!lifetime.!This!means!that!each!team!should!be!able!to!develop!the!product,!test!it!and!deploy! it! into! production.! Infrastructure! automation! techniques! have! evolved!enormously! over! the! last! few! years! F! the! evolution! of! the! cloud!has! reduced! the!operational!complexity!of!building,!deploying!and!operating!microservices.!To!perform!this! task,! we! can! find! three! usual! practices:! Continuous! Integration,! Continuous!Delivery!and!Continuous!Deployment6.
• Continuous!Integration!(CI)!is!a!development!practice!that!requires!developers!to!integrate!code!into!a!shared!repository!several!times!a!day.!Each!checkFin!is!then!verified!by!an!automated!build,!allowing!teams!to!detect!problems!early.!
• Continuous!Delivery!(CD)!is!a!development!practice!that!automate!the!testing!tasks!until!a!software!version!that!can!be!used!as!a!release!candidate.!!
• Continuous!Deployment!(CDE)!describes!an!extension!to!CD!that!automatically!deploys!a!release!candidate!to!production.!
Continuous!Integration!and!Development!have!several!perks7:
• Accelerated!Time!to!Market:!CD!lets!an!organization!deliver!the!business!value!inherent! in! new! software! releases! to! customers!more! quickly.! This! capability!helps!the!company!stay!a!step!ahead!of!the!competition.!
• Building!the!Right!Product:!Frequent!releases! let!the!application!development!teams! obtain! user! feedback! more! quickly.! This! lets! them! work! on! only! the!useful! features.! If! they! find! that! a! feature! isn’t! useful,! they! spend!no! further!effort!on!it.!This!helps!them!build!the!right!product.!
• Improved! Productivity! and! Efficiency:! Significant! time! savings! for! developers,!testers,!operations!engineers,!etc.!through!automation.!
• Reliable! Releases:! The! risks! associated! with! a! release! have! significantly!decreased,! and! the! release! process! has! become!more! reliable.!With! CD,! the!deployment! process! and! scripts! are! tested! repeatedly! before! deployment! to!production.!So,!most!errors!in!the!deployment!process!and!scripts!have!already!been!discovered.!With!more!frequent!releases,!the!number!of!code!changes!in!each! release! decreases.! This! makes! finding! and! fixing! any! problems! that! do!occur!easier,!reducing!the!time!in!which!they!have!an!impact.!
• Improved!Product!Quality:!The!number!of!open!bugs!and!production!incidents!has!decreased!significantly.!
12!
• Improved! Customer! Satisfaction:! A! higher! level! of! customer! satisfaction! is!achieved.!
Despite!it!advantages,!we!can!also!find!some!drawbacks:
• Customer! preferences:! Some! customers! do! not! want! continuous! updates! to!their!systems.!This!is!especially!true!at!the!critical!stages!in!their!operations.!
• Domain! restrictions:! In! some! domains,! such! as! telecom! and! medical,!regulations!require!extensive!testing!before!new!versions!are!allowed!to!enter!the!operations!phase.!
• Differences! in! environments:! Different! environments! used! in! development,!testing! and! production! can! results! that! undetected! issues! slip! to! production!environment.!
• Tests! needing! a! human! oracle:! All! quality! attributes! cannot! be! verified! with!automation.! This! requires! humans! in! the! loop! that! slows! down! the! delivery!pipeline.!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
13!
3. Design of the application 3.1. Description of the application For! showing! the! main! characteristic! of! microservices! architecture,! we! are! going! to!develop! a! demo! application! for! a! universitary! association.! The! main! target! of! this!organization! is! the!exchange!of! international! internships.!Each!country!contacts!with!companies! in! order! to! get! internships,! and! then! they! exchange! these! internships,!promoting! the! international! mobility! of! students.! They! need! an! application! for!managing!the!whole!process.
This!organization!has!different!work!teams!depending!on!the!territory.!Each!team!will!represent!a!different!user!in!the!platform,!with!different!permissions:
• General+Secretary:!it!is!the!team!in!charge!of!a!certain!country.+• Delegation:!it!is!the!team!in!charge!of!a!certain!territory!inside!a!country.!They!
always!belong!to!a!General+Secretary.+• Center:!it!is!the!team!in!charge!of!a!specific!university,!whose!students!get!the!
exchanged!internships.!They!always!belong!to!a!certain!Delegation.+• Representative:!this!team!is!the!representative!of!a!certain!country!and!it!is!in!
charge!of!exchanging!the!internships.!+
!
!Figure!5:!Actors!in!the!application
They!have!three!different!types!of!works!during!the!year:
1. Period! of! internships! raising:! General+ Secretary,! with! its! Delegations+ and!Centers!get!internships!in!their!country!for!international!students.!
2. Period!of!exchange:!the!different!countries!exchange!the!internships!that!they!got!with!other!countries.!They!usually!do!it!in!a!week!long!period!in!which!the!Representatives!of!different!countries!meet!in!a!certain!location.!
14!
3. Period! of! development! of! the! internships:! the! students! get! their! internships!and!start!working!on!them.!
The!application!will!have!functionalities!to!help!in!the!first!two!periods,!with!different!microservices!for!doing!so:
• Management!of!Internships!Service:!this!microservice!will!help!the!organization!with!the!period!of!internships!raising.!Each!Center!will!add!the!internships!that!they!raise!to!this!platform,!with!all!the!details.!They!will!be!saved!in!a!common!database,! so! their! correspondent! Delegation! and! General+ Secretary+ can! see!them!also,!and!can!manage!them.!
• International! Exchange! Microservice:! this! microservice! will! help! the!organization! with! the! period! of! international! exchange.! It! will! allow! the!Representatives!to!indicate!in!real!time!which!internships!they!exchanged,!and!what!they!got!in!return.!This!will!allow!them!to!know!the!current!state!of!the!exchange!in!every!moment.!
Management!of!Users!Microservice:!in!order!to!authenticate!the!users!of!the!previous!microservices,! we! will! also! need! a! platform! for! managing! and! authenticating! the!different!users.!
Summarising,! we! will! develop! an! application! composed! by! three! microservices:!Management! of! Internships! Microservice,! International! Exchange! Microservice! and!Management!of!User!Microservice!
3.2. Management of Users Microservice 3.2.1. Description
Our!first!microservice!will!be!Management!of!Users.! In!this!service,!we!will!have!five!different! actors:! Administrator,! Secretary+ Member,! Representative,! Delegation! and!Center.!Each!of! them!will!have!different!permissions! in!the!whole!application.! In!this!particular! microservice,! only! Administrators! and! Secretary+ Members! will! be! able! to!access!to!the!client.
3.2.2. Architecture
The!architecture!for!this!microservice!will!be!client/server.
In! the!client!side,!we!will!have!a! frontend! for! interacting!with! the!microservice!user.!We!will!use! the!markup! language!HTML58!and!the!stylesheet! language!CSS39! for! the!presentation,! in! addition! to! the! programming! language! Javascript10! with! the!framework!AngularJS11.
In! the! server! side,! we! will! develop! a! RESTful! API,! using! the! crossFplatform! runtime!environment!Node.js12.
In!the!persistence!layer,!we!will!use!a!MongoDB13!database.
!
15!
!Figure!6:!Architecture!of!Management!of!Users!Microservice
3.2.3. API Design
We!will!develop!the!next!use!cases!for!the!API:
• As!a!user,!I!want!to!login!to!a!microservice.!• As!a!user,!I!want!to!logout!from!a!microservice!• As! an! Administrator! or! Secretary!Member,! I! want! to! add! a! new! user! to! the!
database.!• As!an!Administrator!or!Secretary!Member,!I!want!to!edit!an!existing!user!from!
the!database.!• As!an!Administrator!or!Secretary!Member,! I!want!to!reset!the!password!from!
an!existing!user!from!the!database.!• As! an! Administrator! or! Secretary!Member,! I! want! to! delete! an! existing! user!
from!the!database.!• As!an!Administrator!or!Secretary!Member,! I!want!to!get!the!list!of!users!from!
the!database.!• As!an!Administrator!or!Secretary!Member,! I!want! to!get! the!details!of!a!user!
from!the!database.!
For! the! API! development,! we!will! use! three! Node.js!modules:! express,!mongoose! y!password.
• Express14! is! a! Node.js! web! application! framework! that! provides! a! set! of!features! for!web!and!mobile!applications,! including!HTTP!utilities! for! creating!APIs.!We!will!use!this!module!for!managing!RESTful!calls.!
• Passport15! is! authentication! middleware! for! Node.js.! It! supports! local!authentication! based! in! user! and! password.! We! will! use! this! module! for!authenticate!our!users.!
16!
• Mongoose16!is!a!MongoDB!object!modeling!tool.!It!provides!a!straightforward,!schemaFbased!solution!to!model!application!data.!We!will!use!this!module!for!the!communication!with!the!database.!
The!RESTful!API!exposes!the!following!interfaces:
!
Title Login
URL /api/login
Method POST
Data!Params username:!String,
password:!String
Success!Response
code:!200
content:
!!{status:!'Login!!!
!!successful‘}
Error!Response
code:!500
content:! {err:! ‘Could!not!log!in!user’}
!
!
Title Logout
URL /api/logout
Method GET
Success!Response
code:!200
content:! {status:! Logout!successful!}
!
!
Title Register!New!User
URL /api/register
Method POST
Data!Params
username:!String,
email:!String,
center:!String,
delegation:!String,
role:!String
!
Title Edit!Existing!User
URL /api/edit
Method POST
Data!Params
username:!String,
email:!String,
center:!String,
delegation:!String,
role:!String
17!
Success!Response
code:!200
content:! {status:!'Registration!successful!'!}
Error!Response
code:!500
content:!{err:!err}
Notes For!registering!a!new!user,!the!session!user!should!be!an!Administrator!or!!a!Secretary!Member
!
Success!Response
code:!200
content:! {status:! 'User!successfully!updated'!}
Error!Response
code:!500
content:!{err:!err}!
Notes For!editing!an!existing!user,!the!session!user!should!be!an!Administrator!or!a!Secretary!Member
!
!
Title Reset! Password! of!Existing!User
URL /api/reset
Method POST
Data!Params
username:!String,
password:!String
Success!Response
code:!200
content:! {status:!'Password! successfully!updated'!}
Error!Response
code:!500
content:!{err:!err}
Notes For! resetting! the!password! of! an! existing!user,! the! session! user!should! be! an!Administrator! or! a!Secretary!Member
!
!
Title Delete!Existing!User
URL /api/delete/:user
Method DELETE
URL!Params
username:!String
Success!Response
code:!200
content:! {status:! 'User!successfully!deleted'!}
Error!Response
code:!500
content:!{err:!err}!
Notes For! deleting! an! existing! user,!the! session! user! should! be! an!Administrator! or! a! Secretary!Member
!
!
!
!
!
!
!
18!
Title List!All!Users
URL /api/users
Method GET
Success!Response
code:!200
content:
!!{
!!!!!!status:! 'Registration!successful',
!!!!!!users:!Objects
!!}
Error!Response
code:!500
content:!{err:!err}!
Notes For! for! listing! all! users,!the! session! user! should!be! an! Administrator! or! a!Secretary!Member
!
Title Get!Details!of!Existing!User
URL /api/users/:username
Method GET
URL!Params
username:!String
Data!Params
username:!String,
email:!String,
center:!String,
delegation:!String,
role:!String
Success!Response
code:!200
content:
!!{
!!!!!!status:!'User!!!
!!!!!!successfully!found',
!!!!!!users:!Objects
!!}
Error!Resp.
code:!500
content:!{err:!err}!
Notes For! getting! the! details! of! an!user,! the! session! user! should!be! an! Administrator! or! a!Secretary!Member
!
3.2.4. Client design
We!have!the!following!use!cases!for!the!client!side:
• As! an! Administrator! or! Secretary!Member,! I! want! to! authenticate!myself! for!accessing!the!microservice.!
• As!an!Administrator,!I!want!to!create,!read,!edit!and!delete!all!users.!• As!a!Secretary!Member,!I!want!to!create,!read,!edit!and!delete!all!kind!of!users,!
except!for!Administrators.!
19!
!
!Figure!7:!Management!of!Members!Domain!Model
As!we!said!before,!we!will!use!AngularJS!for!developing!the!client.!AngularJS!follows!a!MVC!!pattern!implemented!in!JavaScript!and!HTML.!The!Model!contains!the!data!and!logic,! the! View! contains! the! visual! layout! and! presentation,! while! the! Controller!connects! the! two.! The! view! is! defined! in!HTML,!while! the!model! and! controller! are!implemented! in! JavaScript.! !In!AngularJS,!a!$scope!object! injected! into!the!controller!can!be!used!as!the!model!directly.
For!using!inside!the!controllers,!AngularJS!also!provides!services.!Services!are!javascript!functions! and! are! responsible! to! do! a! specific! tasks! only! and! they! are! are! normally!injected! using! dependency! injection! mechanism.! AngularJS! provides! some! services,!and!we!can!also!define!custom!ones.
We!will! implement! in! this!microservice! the! following! service,! controllers,! views! and!models:
20!
!
!Figure!8:!Class!Diagram!for!Management!of!Memebers
3.2.5. Persistence Layer
We!will!use!a!MongoDB!database!for!the!persistence!layer.!All!the!communication!with!the!database!will!be!done!via!API.!The!clientFside!of! this!microservice!will!be!able! to!read! and! write! the! database! through! the! API.! From! outside! this! microservie,! the!
21!
application!will!be!only!able!to!read,!in!order!to!authorize!the!access!of!users!to!other!microservices.
As! we! are! going! to! deploy! the! application! in! the! cloud,! our! microservice! will! be!stateless.!Any!data!that!needs!to!persist!must!be!store!in!the!database,!following!the!twelve! factor! app! methodology,! for! the! sake! of! scalability! and! portability.!Furthermore,!many!important!cloud!technologies!are!not!equipped!to!deal!with!state!data.!
In!the!case!of!Cloud!Foundry,!it!requires!the!applications!to!be!stateless!for!two!main!reasons:!
• The!local!file!system!is!shortVlived.!We!can!have!several!instances!of!the!same!application,!and! if!one!of!them!crashes!or!stops,!all! the!resources!assigned!to!that!instance!are!reclaimed!by!the!platform.!Although!our!application!can!write!local! files! while! it! is! running,! the! files! will! disappear! after! the! application!restarts.!
• Instances! of! the! same! application! do! not! share! a! local! file! system.! Each!application!instance!runs!in!its!own!isolated!container.!If!your!application!needs!the!data!in!the!files!to!persist!across!application!restarts,!or!the!data!needs!to!be!shared!across!all! running! instances!of! the!application,! the! local! file!system!should!not!be!used.!
In! this! microservice,! we! need! to! persist! the! information! about! the! users! of! the!application.!In!order!to!do!so,!the!user!will!have!the!following!fields:
We! will! use! the! different! fields! for! giving! different! permission! to! each! user! and!authenticate!them.
3.2.6. Microservice characteristics
In! the!microservice,!we! can! find! several! examples!of! the!main! characteristics!of! this!particular!architecture.
One! characteristic! that! we! already! talked! about! in! the! introduction! was! the+Componentization+via+Services.!In!this!microservice!we!can!see!that!we!have!developed!an! independent! unit! of! software! whose! communication! is! done! via! web! service!request.!Also,!we!can!observe!that!this!service! is! independently!deployable.!We!only!
22!
need!to!redeploy!this!microservice!if!we!make!changes!in!it,!instead!of!redeploying!the!full!application.
Another! characteristic! that! is! representative! is! the! Organization+ around+ Business+Capabilities.! For! this!microservice,!we!will!need!a! team! focused!around! the!business!capabilities,!which!includes!the!full!range!of!skills!required!for!the!development:!userFinterface,! persistent! storage,! and! serverFside! logic.! This! approach,! opposing! the!traditional! one! in! which! there! are! different! teams! for! each! skill,! promotes! crossFfunctional!team!with!fast!communication.
In!this!microservice!we!can!also!find!an!examples!of!Smart+Endpoints+and+Dumb+Pipes.!The!microservice!is!built!for!being!as!decoupled!and!as!cohesive!as!possible.!The!smart!part! lives! in! the! API! endpoint,! which! receives! an! HTTP! request,! apply! the! logic! and!produce! a! response.! This!way,! the! client! only!works! as! a!message! router,! being! the!endpoint!the!responsible!of!consuming!the!messages.
3.3. Management of Internships Microservice 3.3.1. Description
Our!second!microservice!will!be!Management!of! Internships.!The!main! target!of! this!service!will!be!the!management!of!an!internships!database:!users!will!add,!edit,!view!and! delete! the! internships.! We! will! have! four! different! actors:! Secretary! Member,!Representative,!Delegation!and!Center.!Each!of!them!will!have!different!permissions!in!the!whole!application.
3.3.2. Architecture
For!this!service!we!will!use!an!EventFdriven!architecture.!This!is!a!software!architecture!pattern!promoting!the!production,!detection,!consumption!of,!and!reaction!to!events,!understanding!events!as!a!significant!change!in!the!state!of!the!application.
In! order! to! build! this! architecture,! we! will! use! two! different! patterns,! often! found!together:! Event! Sourcing17! (ES)! and! Command! Query! Responsibility! Segregation18!(CQRS).!Although!neither!of!them!necessarily! implies!the!other,!they!do!complement!each!other.
• Event!Sourcing!is!a!way!of!persisting!an!application's!state!by!storing!the!history!that!determines!the!current!state!of!your!application.!This!will!be!done!by!the!use!of!events,!to!which!the!application!will!react.!
• CommandFQuery! Responsibility! Segregation! separate! Query! and! Command!objects.! The! read! requests! are! handled! by! the! Query! object! and! the! read!requests!are!handled!by!the!Command+object.! !
EVENT!SOURCING
The!Event!Sourcing!pattern!defines!an!approach!to!handling!operations!on!data!that!is!driven! by! a! sequence!of! events,! each! of!which! is! recorded! in! an! appendFonly! store.!Application!code!sends!a!series!of!events!that! imperatively!describe!each!action!that!
23!
has! occurred! on! the! data! to! the! event! store,! where! they! are! persisted.! Each! event!represents!a!set!of!changes!to!the!data.
The!events!are!persisted!in!an!event!store!that!acts!as!the!source!of!truth!or!system+of+record!(the!authoritative!data!source!for!a!given!data!element!or!piece!of!information)!about!the!current!state!of!the!data.!The!event!store!typically!publishes!these!events!so!that!consumers!can!be!notified!and!can!handle!them!if!needed.!Consumers!could,!for!example,! initiate! tasks! that! apply! the! operations! in! the! events! to! other! systems,! or!perform!any!other!associated!action!that!is!required!to!complete!the!operation.!Notice!that!the!application!code!that!generates!the!events!is!decoupled!from!the!systems!that!subscribe!to!the!events.
For!this!purpose,!we!will!have!the!following!elements:
!
!Figure!9:!Architecture!of!Management!of!Internships
In!the!diagram,!we!can!identify!four!main!elements:
• Application! Layer:! responsible! for! presenting! information! to! the! user,!interpreting!user! commands!and!coordinating! the!application!activity.! It!does!not! contain! business! logic! and! It! does! not! hold! the! state! of! the! business!objects.!It!will!be!a!consumer!of!the!events.!This!layer!will!generate!the!events.!
24!
• Domain! Layer:! contains! information! about! the! domain.! The! state! of! business!objects!is!held!here.!Persistence!of!the!business!objects!and!possibly!their!state!is!delegated!to!the!infrastructure!layer.!This!layer!will!consume!the!events.!
• Infrastructure! Layer:! implements! persistence! for! business! objects,! containing!the!databases.!
• Message! Bus:! allows! the! communication! between! the! Application! Layer! and!the!Domain!Layer.!It!is!based!in!a!queue!of!messages!to!which!the!two!different!layers!reacts.!
The! message! bus! is! the! central! element! of! our! EventFdriven! architecture.! As! we!explained!at!the!beginning!of!this!section,!every!change!to!the!state!of!an!application!is!captured!in!an!event!object.!From!a!formal!perspective,!what!is!produced,!published,!propagated,! detected! or! consumed! is! a! message! called! the! event! notification.! This!event! notification!will! be! published! in! the!message! bus.! Then,! the!message! bus!will!create!an!event!object!and!will!be!persist!it!in!a!database.!Also,!when!the!bus!receives!the!message,!all!the!services!which!are!subscribed!to!its!notification!will!react!to!this!event,!leading!to!the!EventFdriven!design!that!we!wanted!to!achieve.
This!event!object!will!be!a!message!that!the!Application!Layer!or!the!Domain!Layer!add!to!the!message!bus,!and!all!the!events!are!persisted!in!a!database.
!Figure!10:!Communication!between!Application!Layer!and!Domain!Layer
!
CQRS
Command! and!Query! Responsibility! Segregation! (CQRS)! is! a! pattern! that! segregates!the! operations! that! read! data! (Queries)! from! the! operations! that! update! data!(Commands)!by!using!separate! interfaces.!This! implies!that!the!data!models!used!for!querying!and!updates!are!different.
The!CQRS!pattern!is!often!used!in!conjunction!with!the!Event!Sourcing!pattern.!When!used! with! Event! Sourcing,! the! store! of! events! is! the! write! model,! and! this! is! the!authoritative!source!of!information.!The!read!model!of!a!CQRSFbased!system!provides!materialized!views!of!the!data,!typically!as!highly!denormalized!views.!These!views!are!
25!
tailored!to!the!interfaces!and!display!requirements!of!the!application,!which!helps!to!maximize!both!display!and!query!performance.
For!writing!data,!we!will!use!CQRS!pattern!with!Event!Sourcing!pattern.! In! the!CQRS!pattern,! the!Application!Layer! send!commands! to! the!message!bus!and! !the!Domain!Layer! consumes! them.! In! the! Event! Sourcing! pattern,! the! Domain! layer! will! send!events! to! the!message! bus! and! the! Application! layer! will! consume! them.! Upon! the!reception!of!an!appropriate!event,!the!application!layer!will!send!a!writing!query!to!the!database.
!
!Figure!11:!Communication!with!ES!and!CQRS
For! reading! data,! the! Application! Layer! will! query! directly! the! database,! and! it! will!upload!the!view.
!
26!
!Figure!12:!Process!for!reading!data
3.3.3. Technologies
In! the! Application! Layer,! we! will! have! a! client! for! interacting! with! the!microservice!database! and! a! server! for! processing! its! changes.!We!will! use! the!markup! language!HTML5! and! the! stylesheet! language! CSS3! for! the! presentation,! in! addition! to! the!programming! language!Javascript!with!the!framework!Backbone.js19!and!Node.js.!For!developing! the! Event! Sourcing! and! CQRS! patterns,! we!will! use! a! collection! of! open!source!node!modules:!domain,!eventdenormalizing,!viewmodel,!read/write+repository,!eventstore!and!businessKrules+and+validation.
In!the!Domain!Layer,!we!will!have!server!for!processing!the!business!rules.!We!will!use!the!programming!language!Javascript!with!the!framework!Node.js.!We!will!also!use!the!open!source!node!module!cqrsKdomain.
For! the! Message! Bus! we! will! use! a! Redis20! queue.! The! different! layers! of! this!microservice!will! be! connected! to! this! queue! in! order! to! receive! the! correspondent!notifications,!depending!of!their!functionalities.!We!will!provide!a!deeper!explanation!about!this!matter!later.
In!the!persistence!layer,!we!will!use!a!MongoDB!database.!
!
!
!
!
27!
3.3.4. Design
We!will!develop!the!next!use!cases:
• As!a!user,!I!want!to!login!to!the!Platform.!• As!a!user,!I!want!to!logout!from!the!Platform.!
!
• As!a!Secretary!Member,! I!want! to!get! the!details!of! the! internships! from! the!database.!
• As!a!Secretary!Member,!I!want!to!add!a!new!internship!to!the!database.!• As!a!Secretary!Member,!I!want!to!edit!an!existing!internship!from!the!database.!• As! a! Secretary! Member,! I! want! to! delete! an! existing! internship! from! the!
database.!!
• As!a!Delegation,!I!want!to!get!the!details!of!the!internships!which!belongs!to!my!Delegation.!
• As! a! Delegation,! I! want! to! add! a! new! internship! which! belongs! to! my!Delegation.!
• As! a! Delegation,! I! want! to! edit! an! existing! internship! which! belongs! to! my!Delegation.!
• As! a!Delegation,! I!want! to! delete! an! existing! internship!which!belongs! to!my!Delegation.!
!
• As! a! Center,! I! want! to! get! the! details! of! an! internship! which! belongs! to!my!Delegation.!
• As!a!Center,!I!want!to!add!a!new!internship!which!belongs!to!my!Delegation.!• As! a! Center,! I! want! to! edit! an! existing! internship! which! belongs! to! my!
Delegation.!• As! a! Center,! I! want! to! delete! an! existing! internship! which! belongs! to! my!
Delegation.!!
• As!a!Representative,!I!want!to!get!the!details!of!the!internships.!!
!Figure!13:!Domain!Model!for!Management!of!Internships
28!
EVENT!SOURCING
As!we!explained!in!the!description!of!this!microservice,!we!will!handle!operations!on!data!with!events.!Events!are!usually!named!in!past!tense:!they!are!a!notification!about!an!operation!that!has!already!been!performed.!For!this!purpose,!we!will!define!three!different!events:
• itemChanged:!it!will!notify!once!an!item!has!been!changed.!• itemCreated:!it!will!notify!once!an!item!has!been!created.!• itemDeleted:!it!will!notify!once!an!item!has!been!changed.!
CQRS
We!will!use!CQRS!for!performing!reading!and!writing!operations.!For!this!purpose!we!will!use!commands.!Commands!are!usually! in!an!imperative!mood:!they!are!an!order!given! to! be! performed.! We! will! define! three! different! commands! for! handling! the!writing!queries:
• changeItem:!we!want!to!give!the!order!of!changing!an!item.!• createItem:!!we!want!to!give!the!order!of!creating!an!item.!• deleteItem:!!we!want!to!give!the!order!of!deleting!an!item.!
3.3.5. Application Layer
This! is! a! thin! layer! which! coordinates! the! application! activity.! It! does! not! contain!business! logic.! It!does!not!hold! the!state!of! the!business!objects,!but! it! can!hold! the!state!of!an!application!task!progress.
This layer will orchestrate the steps required to fulfill the client requests. While!these! services! shouldn't! have! business! logic! in! them,! they! can! certainly! carry! out! a!number!of!steps!required!to!fulfill!an!application!need.
3.3.5.1. Server side
Our!application! layer!will!have!three!specific! responsibilities!on!the!server!side:!send!commands,!receive!events!and!query!the!database
3.3.5.1.1. Send commands
When! this! layer! wants! write! in! the! database,! it! will! send! a! command! (changeItem,+createItem+and+deleteItem)!to!the!Message!Bus!with!a!writing!request,!delegating!the!responsibility.! The! subscribers! to! the! commands! received! in! the! Message! Bus! will!receive!a!notification!and!they!will!react!to!it!in!a!certain!way.
!
29!
!Figure!14:!Communication!from!Application!Layer
3.3.5.1.2. Receive events
When!this!layer!receive!an!event,!it!will!react!to!it.!As!we!said!before,!we!can!receive!three!different!events,!with!different!reactions:
• itemChanged:!it!will!modify!an!item!from!the!database.!• itemCreated:!it!will!send!a!create+request!to!the!database!the!the!details!of!the!
new!item.!• itemDeleted:!it!will!send!a!delete+request!to!the!database!the!the!details!of!the!
new!item.!
!Figure!15:!Communication!to!Application!Layer
30!
3.3.5.1.3. Query the database
When! the! client! side! query! information,! we! will! directly! send! the! request! to! the!database,!without!sending!any!command!to!the!Message!Bus!or!receiving!any!event,!as!we!explained!previously.
3.3.5.2. Server Side: API Design
This! microservice! will! also! have! a! RESTful! API! for! communication! with! other!microservices.
We!will!develop!the!following!use!cases!for!the!API:
• As!a!user,!I!want!to!login!and!logout!to!a!microservice.!• As! an! Administrator! or! Secretary!Member,! I! want! to! add! a! new! user! to! the!
database.!• As!an!Administrator!or!Secretary!Member,!I!want!to!edit!an!existing!user!from!
the!database.!• As!an!Administrator!or!Secretary!Member,! I!want!to!reset!the!password!from!
an!existing!user!from!the!database.!• As! an! Administrator! or! Secretary!Member,! I! want! to! delete! an! existing! user!
from!the!database.!• As!an!Administrator!or!Secretary!Member,! I!want!to!get!the!list!of!users!from!
the!database.!• As!an!Administrator!or!Secretary!Member,! I!want! to!get! the!details!of!a!user!
from!the!database.!
For! the! API! development,! Backbone.js! includes! a! basic! functionality! which! will! be!enough!for!our!purpose.
The!RESTful!API!exposes!the!following!interfaces: !
Title All!Items
URL /api/allItem.json
Method GET
Success!Response
code:!200
content:
!!{status:!'Successful‘,
!!!!items:!Objects}
Error!Response
code:!500
content!{err:!‘Could!not!log!in!user’}
!
!
Title All!References
URL /api/allReferences.json
Method GET
Success!Response
code:!200
content:!
!!{status:!‘Succesful,
!!refs:!Objects}
Notes !!
31!
!
Title Get!Internship
URL /api/internship/:ref
Method POST
Data!Params
ref:!ref
Success!Response
code:!200
content:!
!!{status:!'Successful’,
!!}
Error!Response
code:!500
content:!{err:!err}
Notes For! registering! a! new! user,! the!session! user! should! be! an!Administrator! or! !a! Secretary!Member
!
!
!
3.3.5.3. Client side
We!will! show!4!different!pages! to! the!users:! login,! index,! list! items,! create! item!and!edit!item.
3.3.6. Domain Layer
The!Domain!Layer! implements!the!business!functionality!of!the!application.! It!will!be!the!layer!in!which!our!business!rules!and!logic!will!reside.
This! layer! will! only! have! server! side,! and! it! will! have! three! specific! responsibilities:!receive!commands!and!send!events.
When! this! layer! receive! a! command,! it! will! react! to! it.! As! we! said! before,! we! can!receive!three!different!commands,!each!of!them!with!two!different!reactions:
• changeItem!o It!will!send!an!email!to!the!Secretary!Members!informing!of!the!changes!
produced!in!the!item.!o It!will! send!an!event! itemChanged! to! the!Message!Bus!with!a! request!
for!changing!the!item.!
32!
• createItem!o It!will!send!an!email!to!the!Secretary!Members!giving!the!details!of!the!
item!created.!o It!will!send!an!event!itemCreated!to!the!Message!Bus!with!a!request!for!
creating!the!item.!• deleteItem!
o It!will!send!an!email!to!the!Secretary!Members!informing!of!the!deletion!of!the!item.!
o It!will!send!an!event!itemDeleted!to!the!Message!Bus!with!a!request!for!deleting!the!item.!
!
!Figure!16:!Example!of!communication!between!layers
3.3.7. Message Bus
The!message!bus!will!receive!and!send!events!and!commands.
We!will!have!two!lists!of!subscribers!to!the!message!bus:
• evtSubscriptions:! for! those! services! which! want! to! be! informed! upon! the!reception!of!a!new!event.!
• cmdSubscriptions:+ for! those! services! which! want! to! be! informed! upon! the!reception!of!a!new!command.+
We!will!have!two!messages!queues!in!the!message!bus:
• evt:+for!events.!It!will!send!a!notification!to!the!subscribers!of!evtSubscriptions!when!a!new!event!is!published.!+
33!
• cmd:! for! commands.! It! will! send! a! notification! to! the! subscribers! of!evtSubscriptions!when!a!new!command!is!published.!+
3.3.8. Persistence Layer
We!will!use!a!MongoDB!database!for!the!persistence!layer.!All!the!communication!with!the!database!will!be!done!via!Application!Layer.
Following!the!CQRS!pattern,!we!will!follow!different!ways!for!querying!and!writing!the!database:
• For!querying,!we!will!do!a!direct!request!to!the!database.!
!
!Figure!17:!Reading!request!
• For!writing,!the!Application!Layer!will!follow!the!next!steps:!1. It!will!send!a!command!to!the!Message!Bus.!!2. The!Domain! Layer,! as! a! subscriber! of! the! commands! published! in! the!
Message!Bus,!will!receive!receive!a!notification.!!3. This! will! trigger! two! actions! in! the! Domain! Layer:! it! will! apply! the!
business!rules!and!it!will!send!an!event!to!the!Message!Bus.!!4. The! Application! Layer,! as! a! subscriber! of! the! events! published! in! the!
Message!Bus,!will!receive!receive!a!notification.!!5. Upon! the! reception! of! this! event,! the! Application! layer! will! send! a!
writing!request!to!the!database.!6. Once! updated! the! database,! the! Application! Layer! will! receive! a!
confirmation!response,!refreshing!the!view.!
!
!
34!
!
!
!Figure!18:!Writing!request
!
In!the!Internship!Database,!we!will!store!the!following!data:!
!
35!
In!the!Events!Database,!we!will!store!the!following!data:
3.3.9. Microservice characteristics
Event!Sourcing!and!CQRS!are!very!popular!patterns!in!microservices!architecture,!and!we! can! find! that! they! share! similar! characteristics.! The! most! relevant! ones! among!them!are!Componentization!via!Services!and!Evolutionary!Design.
Componentization! via! Services! is! easy! to! identify! in! both! patterns! and!microservice!architecture.! We! have! four! different! services! as! components:! Application! Layer,!Domain!Layer,!Message!Bus!and! Infrastructure!Layer.!Each!of! them!can!be!deployed!independently.!This!allows!a!high!grade!of!flexibility:!we!can!make!changes! in!one!of!them!without! redeploying! the!others,! reducing! the!possibility!of! breaking! the!whole!application! in! one! release.! In! this! microservice,! each! of! the! components! are!encapsulated,! and! they! expose! their! interfaces! through! different! mechanism.! The!most!important!of!them!are:
• Domain!Layer:! it!exposes! its! interfaces!through!commands!(CQRS)!and!events!(Event! Sourcing),! allowing! the! communication! with! the! Message! Bus,! the!Application!Layer!and!the!Infrastructure!Layer.!
• Application!Layer:!it!exposes!its!interfaces!in!two!different!levels.!o Inside!the!microservice:!it!communicates!with!the!Message!Bus!through!
commands!(CQRS)!and!events!(Event!Sourcing),!and!with!the!database!with!queries.!
o Outside! the! microservice:! it! communicates! with! other! microservices!through!the!API!included!in!the!application!layer.!
Evolutionary! Design! is! an! important! characteristic! when! developing! microservice!architecture,!and!CQRS!and!Event!Sourcing!patterns!offer!a!wide!range!of!advantages!for!this!purpose.!If!we!want!to!add!a!new!business!rule,!we!add!it!in!the!existent!server!of! the!Domain! Layer.! If!we!want! to! implement!new!servers! in! the!Domain! Layer! for!different!purposes,!we! just!have!to!subscribe!them!to!the!Message!Bus! for! receiving!the!commands,!without!making!any!changes! in!the!other!components.! If!we!want!to!provide! a! different! front! end,! we! just! need! to! subscribe! it! to! the!Message! Bus! for!sending!command!and!receiving!events,!without!affecting!the!previous!front!end,!the!Domain!Layer!or!the!Infrastructure!Layer.!
!
!
!
36!
3.4. International Exchange Microservice 3.4.1. Description
Our! third! and! last! microservice! will! be! International! Exchange.! We! will! have! two!actors:! Secretary! Member! and! Representative.! Each! of! them! will! have! different!permissions!in!the!whole!application.!
3.4.2. Architecture
The!architecture!for!this!microservice!will!be!client/server.
!Figure!19:!Architecture!of!International!Exchange!Microservice
In! the!client!side,!we!will!have!a! frontend! for! interacting!with! the!microservice!user.!We!will! use! the!markup! language! HTML5! and! the! stylesheet! language! CSS3! for! the!presentation,!in!addition!to!the!programming!language!Javascript!with!the!framework!AngularJS.! We! will! use! Ionic21,! a! complete! openFsource! SDK! for! hybrid! mobile! app!development.!It!uses!Apache!Cordova22!and!it!is!optimized!for!developing!apps!written!in!AngularJS.
In!the!server!side,!we!will!develop!a!socket!for!updating!the!app!in!real!time.!We!will!use!the!crossFplatform!runtime!environment!Node.js!for!this!purpose.
In!the!persistence!layer,!we!will!use!two!MongoDB!database:!one!for!the!chats!and!one!for!the!state!of!the!internships.
3.4.3. Design
This!microservice!will!have!four!functionalities:
• Show!the!state!of!the!exchange!in!real!time.!• Edit!the!details!of!the!exchange.!
37!
• Allow!communication!between!the!representatives!through!a!chat.!• Show!the!details!of!a!certain!internship.!
We!will!develop!the!next!use!cases!for!the!microservice:
• As!a!user,!I!want!to!login!to!a!microservice.!• As!a!user,!I!want!to!logout!from!a!microservice!• As!a!Representative!or!Secretary!Member,!I!want!to!check!the!current!state!of!
the!exchange!of!internships.!• As!a!Representative!or!Secretary!Member,!I!want!to!exchange!an!internship.!• As!a!Representative!or!Secretary!Member,!I!want!to!read!and!write!in!the!app!
chat.!• As! a! Representative! or! Secretary! Member,! I! want! to! read! the! details! of! a!
certain!internship.!• As!a!Secretary!Member,!I!want!to!edit!the!details!of!the!exchange!list.!
!
!Figure!20:!Domain!Model!for!International!Exchange!Microservice
3.4.3.1. State of the Exchange
Each! internship! will! belong! to! one! specialization.! Depending! of! the! students! needs,!each!country!will!need!a!different!number!of! internships! for!each!specialization.!The!main! target! of! this! functionality! is! to! show! how!many! internships! should! get! in! the!
38!
exchange!for!each!specialization,!how!many!we!already!have!and!how!many!more!we!need.!For!this,!we!will!use!a!table!format!with!a!single!column,!and!each!row!will!show!the!current!numbers.!We!will!use!a!socket!connected!to!the!database!for!updating!the!information!in!real!time.!This!way,!each!time!a!representative!gets!a!new!internships,!the!other!representatives!will!know!immediately.
3.4.3.2. Edit Details of Exchange
Secretary!Members!will!have!the!permission!for!editing!the!data!of!the!exchange.!By!doing!so,!they!can!introduce!the!details!of!the!exchange!for!the!first!time!and!change!them!in!any!moment!if!it!is!needed.!It!will!save!the!changes!in!the!database.
3.4.3.3. Representatives Chat
Both! Secretary! Members! and! Representatives! can! communicate! through! the! chat.!That!allows!them!to!ask!questions!during!the!exchange!or! inform!the!others!users!of!any!incident!or!need.!We!will!use!a!socket!for!developing!the!chat.
3.4.3.4. Internship Details
This! functionality! will! allow! the! users! to! check! the! details! of! an! specific! internship.!They!will!introduce!the!reference!number,!and!they!will!get!the!information.
3.4.4. Persistence Layer
We!will!use!two!MongoDB!databases:!one!for!the!state!of!the!internship!and!one!for!the!chat!messages.!Both!of!them!will!be!connected!to!a!socket,!in!order!to!update!the!information!of!the!microservice!in!real!time,!and!they!will!be!located!in!the!cloud.
For!the!Chat!Database,!we!will!define!the!following!element!for!the!database:
For!the!Internships!Database,!we!will!use!the!following!elements:
39!
In!the!same!way!as!previous!microservices,!it!will!be!stateless:!any!data!that!needs!to!persist!must!be!store!in!the!database,!for!the!sake!of!portability!and!scalability.
3.4.5. Microservice characteristics
We! can! find! some!main! characteristics! of! microservices! architecture! in! this! specific!microservices.!
One!of! them! is!Decentralized!Data!Management:! this!microservice! is!only!connected!directly! to! its!own!databases! (for! current! state!of! the!exchange!and!chat!messages).!For! getting! information! from! other! databases,! it! request! the! information! to! the!appropriate!microservice!through!exposed!interfaces.
This! is! also! a! good! example! of! Smart! Endpoints! and! Dumb! Pipes.! For! getting!information! from! other! microservices,! we! will! just! connect! our! application! to! the!appropriate! endpoint! (Smart! Endpoint),! and!we!will! get! the! data! by! doing! a! simply!request! (Dumb! Pipes).!We!will! get! the! information! without! the! need! of! connecting!multiple!databases!directly!to!our!microservice.!!
3.5. Complete Application 3.5.1. Description
Our! application! will! consist! in! all! the! previous! microservices! interconnected! in! the!following!way:
• Management!of!Members:!it!will!be!connected!to!Management!of!Internships!and!International!Exchange!in!order!to!authorize!their!users.!
• Management!of!Internships:!it!will!be!connected!to!Management!of!Members!for! authorizing! its! users! and! it! will! provide! internships! details! to! the!International!Exchange!Microservice.!
• International!Exchange:! !it!will!be!connected!to!Management!of!Members! for!authorizing! its! users! and! it!will! get! internships! details! from! the! International!Exchange!Microservice.!!
3.5.2. Architecture
We!will! join! the! different! architectures! developed! in! each!microservice,!making! the!correspondent!connections!between!them:!
40!
!Figure!21:!Complete!application!architecture!
3.5.3. Microservices characteristics
3.5.3.1. Componentization via Services
Understanding!component!as!a!unit!of!software!that!is!independently!!replaceable!and!upgradeable,! each! one! of! our! three! microservices! will! be! a! component.! This!components! will! behave! as! services! and! they! will! communicate! between! them! via!REST!calls.!
As! we! explained! in! the! introduction,! there! are! two! main! two! advantages! of! using!components! as! a! service:! services! are! independently! deployable! and! a!more!explicit!component!interface.!
We!can!deploy!each!of!our!microservices! in!an! independent!way.!For!example,! if!we!need!to!make!some!changes!in!the!Management!of!Members!Microservice,!we!do!not!need!to!make!any!modification!in!the!other!two!microservices,!and!the!same!happens!with!the!other.!We!only!need!to!care!about!sending!the!REST!calls! in!an!appropriate!way.!
!
41!
We! have! defined! a! more! explicit! component! interface.! Each! of! our! microservices!expose!its!services!through!REST!calls.
3.5.3.2. Organized around Business Capabilities
Each! one! of! our! microservices! is! organized! around! business! capabilities.! We! have!splitted! the! application! in! smaller! parts! which! need! a! full! range! of! skills:! user!interfaces,! serverFside! logic! and! databases.! Our! microservices! has! the! following!components:
• Management! of!Members:! one! front! end! (UI! side! team),! one! server! (serverFside!logic!team)!and!one!database!(databases!teams).!
• Management!of!Internships:!one!front!end!(UI!side!team),!two!servers!(serverFside!logic!team)!and!two!databases!(databases!teams).!
• International! Exchange:! one! front! end! (UI! side! team),! one! server! (serverFside!logic!team)!and!two!databases!((databases!teams).!
As!a!consequence,!the!team!in!charge!of!each!microservice!should!be!crossFfunctional,!including! all! the! business! capabilities.! This! organization! promotes! communication!between!the!members!in!order!to!save!time!and!human!resources.
3.5.3.3. Products not projects
Each!one!of!our!microservice! is!considered!a! full!product! itself.!To!deliver!a!piece!of!software! is! not! the!main! target:! the! team! in! charge! has! responsibility! over! the! full!lifetime.!They!should!design!it,!develop!it!and!maintain!it.!
For!example,!the!International!Exchange!Microservice.!The!team!is!responsible!of:!
• Analyzing!the!need!of!the!client:!they!need!to!know!the!state!of!the!exchange!in! real! time,! communicate! between! them! and! check! the! details! of! the!internships!that!they!are!exchanging.!
• Designing!a!software!for!satisfying!this!needs:!they!will!provide!a!mobile!app.!It!will! have! an! updated! list! with! the! state! of! the! exchange,! a! chat! for!communication!and!a!screen!for!showing!the!details!of!an!internship.!
• Developing!the!software:!they!will!build!the!software!that!they!have!design.!• Maintain!the!software:!they!will!solve!any!bug!or!error!found!in!the!mobile!app.!
Similar!processes!will!be!followed!for!the!other!two!microservices.
3.5.3.4. Smart endpoints and dumb pipes
The!three!of!them!will!use!HTTP!requestFresponse!API!for!communication,!playing!the!part!of!dumb!pipes.!The! lightweight!HTTP! request!will!produce!a! reaction! inside! the!microservice:! the! smart! part! lives! in! the! endpoints,! producing! and! consuming!messages,!and!creating!a!response.
This! will! provide! a! highly! decoupled! and! cohesive! application,! receiving! a! request,!applying!logic!as!appropriate!and!producing!a!response.!!
42!
3.5.3.5. Decentralized Governance
By!splitting!the!application!into!services!we!have!a!choice!when!building!each!of!them.!We!have!chosen!different!languages!and!standards!for!each!of!them.
• Management!of!Members!Microservice:!developed!with!AngularJS!and!Node.js,!with!a!MongoDB!database.!
• Management!of!Internships:!developed!with!BackboneJS!and!Node.js,!with!two!MongoDB!databases!and!a!Redis!message!service.!
• Exchange!of! Internships:! developed!with! Ionic,! AngularJS! and!Node.js,!with! a!MongoDB!database.!
3.5.3.6. Decentralized Data Management
Our! microservices! decentralized! data! storage! decisions.! Each! of! them! has! it! owns!databases,! and! they! are! not! related! to! each! other.! Although! we! are! using! NonSQL!databases,!if!we!change!one!of!them!for!an!SQL!database!it!will!not!have!any!influence!outside!its!own!microservice.!Each!service!manage!its!own!database,!allowing!Polyglot!Persistence.
3.5.3.7. Infrastructure Automation
We! can! automate! the! infrastructure! of! our! application.! We! can! define! a! different!CI/CD!pipe! for! each!one!of! our!microservice,! or! even!one!pipe!which! includes! all! of!them.! The! microservices! approach! and! new! technologies,! particularly! Cloud!Computing,! has! reduced! the! operational! complexity! of! building,! deploying! and!operating!microservices.
We!will!show!an!implementation!of!infrastructure!automation!in!the!section!‘CI/CD!of!our!application’.
3.5.3.8. Evolutionary design
Each! one! of! our! components! is! independently! replaceable! and! upgradeable.! If,! for!example,!we!want! to! upgrade! the!Management! of! Internship!Microservice,!we! only!have!to!be!careful!about!the!published!interface!in!relation!to!the!other!microservices,!changing!whatever! else!we! need! to.! If,! for! example,! we!want! to! use! an! alternative!Management! of! Users! Microservice,! we! only! need! to! disconnect! the! old! one! and!connect!the!new!one!to!the!other!microservices.!If,!for!example,!we!want!to!add!a!new!mobile!application,!we!only!need!to!connect! it! to! the!microservices!needed,!without!any!need!to!adapt!them.
This!allows!a!decoupled!and!granular! release!planning.!We!can!update!and! redeploy!each!microservice!independently,!avoiding!a!lot!of!versioning!by!designing!services!to!be!as!tolerant!as!possible!to!changes!in!their!supplies.
43!
4. Continuous Integration and Continuous Deployment 4.1. CI/CD pipeline Continuous!Delivery! (CD)! is! a! software! strategy! that!enables!organizations! to!deliver!new! features! to! users! as! fast! and! efficiently! as! possible.! The! core! idea! of! CD! is! to!create!a!repeatable,!reliable!and!incrementally! improving!process!for!taking!software!from!concept!to!customer.!The!goal!of!Continuous!Delivery!is!to!enable!a!constant!flow!of!changes!into!production!via!an!automated!software!production!line.!The!Continuous!Delivery!pipeline!is!what!makes!it!all!happen.
The! pipeline! breaks! down! the! software! delivery! process! into! stages.! Each! stage! is!aimed!at! verifying! the!quality!of!new! features! from!a!different!angle! to! validate! the!new!functionality!and!prevent!errors!from!affecting!your!users.
We!will!create!a!typical!pipeline!in!which!we!will!have!the!following!steps:
1. Version!control:!The!pipeline!will!be!automatically!started!when!committing!a!change!into!our!version!control!repository.!To!have!a!repository!will!allow!us!to!keep!all! the!code! in!a!single!place!and!to!use!hooks!for!starting!automatically!our!CI/CD!pipeline.!
2. Build! automation:! The! pipeline! starts! by! building! the! binaries! to! create! the!deliverables! that! will! be! passed! to! the! subsequent! stages.! New! features!implemented!by!the!developers!are!integrated!into!the!central!code!base!on!a!continuous! basis.! This! is! the! most! direct! feedback! cycle! that! informs! the!development!team!about!the!health!of!their!application!code.!
3. Test!Automation:! Throughout! this! stage,! the!new!version!of! an! application! is!rigorously! tested! to! ensure! that! it! meets! all! desired! system! qualities.! It! is!important! that! all! relevant! aspects! —! whether! functionality,! security,!performance! or! compliance! —! are! verified! by! the! pipeline.! The! stage! may!involve!different!types!of!automated!or!(initially,!at!least)!manual!activities.!
4. Deployment!Automation:!A!deployment!is!required!every!time!the!application!is! installed! in! an! environment! for! testing,! but! the! most! critical! moment! for!deployment! automation! is! rollout! time.! Since! the! preceding! stages! have!verified! the! overall! quality! of! the! system,! this! is! a! lowFrisk! step.! The!deployment! can!be! staged,!with! the!new!version!being! initially! released! to! a!subset!of!the!production!environment!and!monitored!before!being!completely!rolled!out.!The!deployment! is!automated,!allowing! for! the!reliable!delivery!of!new!functionality!to!users!within!minutes,!if!needed.!
44!
!Figure!22:!CI/CD!pipeline
For!each!steps,!we!will!use!the!following!tools:
1. Version!Control:!we!will!use!Git23!and!Bitbucket24.!2. Build!Automation:!we!will!use!Grunt25!for!the!build!automation.!3. Test!Automation:!we!will!use!Mocha26!and!Chai27!as!testing!tools.!4. Deployment! Automation:! we! will! use! StriderCD28! for! implementing! an!
automatic!deployment!in!the!PaaS!Cloud!Foundry29.!
We!will!implement!a!pipeline!for!each!of!our!microservices.!Management!of!Users!and!Management!of! Internships!will! have!a! similar!pipeline,!with! same! steps!but! slightly!different! configurations,! adapted! to! their! particularities.! International! Exchange!Microservice!will!have!the!same!steps!but!the!last:!since!it!will!is!a!mobile!application,!we!won’t!implement!an!automated!deployment.
4.2. Version control: Git and Bitbucket Git!is!a!version!control!system!that!is!used!for!software!development!and!other!version!control! tasks.! As! a! distributed! revision! control! system! it! is! aimed! at! speed,! data!integrity!and!support!for!distributed,!nonFlinear!workflows.
As!with!most!other!distributed!version!control!systems,!and!unlike!most!client–server!systems,! every! Git! directory! on! every! computer! is! a! fullFfledged! repository! with!complete!history!and!full!versionFtracking!capabilities,!independent!of!network!access!or!a!central!server.!
There! are! different! solutions! for! using! Git.! The! most! famous! webFbased!implementations!are!Github!and!Bitbucket.!For!this!project,!we!chose!to!use!the! last!one.!We!decided!to!use!three!different!repositories!for!each!microservice,!giving!each!of!them!an!identificative!new!name:
• MoM!(Management!of!Members)!for!the!Management!of!Users!Microservice.!• PAI! (Platform! for!Administration!of! Internship)! for!Management!of! Internship!
Microservice.!• ANA!(arbitrary!name)!for!Internationational!Exchange!Microservice.!
!
45!
4.3. Build Automation: Grunt Build!automation!is!the!process!of!automating!the!creation!of!a!software!build!and!the!associated! processes! including:! compiling! computer! source! code! into! binary! code,!packaging! binary! code,! and! running! automated! tests.! In! the! particular! case! of! our!application,! written! in! Javascript,! we! will! need! a! build! tool! to! compile,! bundle! and!minify!the!scripts.
There!are!plenty!of!different!tools!for!build!automation!(Apache!Maven,!make,!Gradle,!etc).!For!Javascript,!the!most!famous!ones!are!Gulp!and!Grunt.!Both!are!task!runners!which!allows!us!to!develop!a!build!automation.!Both!are!similars,!so!we!decided!to!use!Grunt! because! of! the! current! wider! community,! providing! us! with! more! plugins! in!order!to!automatize!the!task.
Each!of!our!services!will!have!different!build!steps:
• Management!of!Users:!1. Create!build!directory.!2. Copy!source!files.!3. Minify!html,!css!and!javascript!files.!4. Create!html!files!from!jade!files.!
• Management!of!Internships!and!Exchange!of!internships:!1. Create!build!directory.!2. Copy!source!files.!3. Minify!html,!css!and!javascript!files.!
4.4. Test Automation: Mocha and Chai Since!our!three!microservices!use!Node.js!for!their!server!sides,!we!are!going!to!use!a!Node.js! tool! for! testing! them.! Mocha! is! a! featureFrich! JavaScript! test! framework!running!on!Node.js! and! in! the!browser,!making!asynchronous! testing! simple.!Mocha!tests!run!serially,!allowing!for!flexible!and!accurate!reporting,!while!mapping!uncaught!exceptions! to! the! correct! test! cases.! As! a! complement,! we! will! also! use! Chai,! a!Behaviour! Driven! Development! and! Test! Driven! Development! assertion! library! for!Node.js! and! the! browser! that! can! be! delightfully! paired! with! any! javascript! testing!framework.
We!will!implement!some!simple!test!in!order!to!show!this!step!in!the!CI/CD!pipeline.
4.5. Deployment Automation: Cloud Foundry Deployment! automation! allows! applications! to! be! deployed! across! the! various!environments! used! in! the! development! process,! as! well! as! the! final! production!environments.! This! results! in! more! efficient,! reliable,! and! predictable! deployments.!Solutions! that!automate!your!deployment!processes! improve! the!productivity!of! the!teams! and! enable! them! and! the! business! to! develop! faster,! accomplish! more,! and!ultimately!build!better!software!that!is!deployed!more!frequently!and!functions!more!reliably!for!the!endFuser.
46!
We!chose!to!deploy!the!application!in!the!cloud!using!a!Platform!as!a!Service!(PaaS).!With!the!PaaS!platform,!everything!is!provided!except!the!application!code,!users,!and!data.! Typically,! when! using! a! PaaS,! the! vendor! maintains! the! application! server,!databases,!and!all!of!the!necessary!operating!system!components,!giving!you!time!to!focus!on! the!application!code.! Since! the!vendor!manages! that!platform! for!you,! it! is!often!hard!to!open!up!ports!that!are!not!specifically!called!for!the!application!server,!runtime,!or!database!in!use.!PaaS!also!provides!features!that!are!specifically!meant!for!applications,!including!the!ability!to!scale!the!application!tier!up!based!upon!the!user!demand!of!the!application.!In!most!platforms,!this!happens!with!littleFtoFno!interaction!from!the!developer.
The!are!different!options! to! choose! in! the!PaaS! field.! Some!of! the!most!popular!are!Google! App! Engine,! Heroku,!Windows! Azure,! Red! Hat! OpenShift! or! Cloud! Foundry.!Although! several! of! this! solutions! are! adequate! for! the! project,! we! chose! Cloud!Foundry!for!deploying!our!application.!We!will!use!the!services!provided!for!hiring!our!database!and!we!will!use!its!buildpacks!for!automating!the!deployment!and!focus!just!in!the!application!code.
Cloud! Foundry! uses! a! manifest! to! configure! the! details! of! the! applications.! In! the!manifest! for! our!microservices!we!will! define! the! name,! the! buildpack,! the!memory!needed,! the! name! for! the! host,! the! command! for! starting! the! application! and! the!services!that!we!want!to!bind.
Manifest:+ Management+ of+ User+Microservice
FFF
applications:
F!name:!mom
!buildpack:!nodejs_buildpack
!memory:!128M
!host:!momFtfg
!command:!node!server/app.js
!services:
!!!F!usersdb
!
Manifest:+International+Exchange+(Server)++
FFF
applications:
F!name:!ieFserver
!buildpack:!nodejs_buildpack
!memory:!128M
!host:!ieFserver!Ftfg
!command:!node!chatFnode.js
!services:
!!!F!iedb!!
+
+
+
+
+
+
+
+
47!
+
Manifest:+ Management+ of+ Internships+Microservice+(Host)
FFF
applications:
F!name:!papFhost
!path:!./build
!buildpack:!nodejs_buildpack
!memory:!128M
!host:!papFhostFtfg
!command:!node!server.js
!services:
!!!F!messagesdb
!!!F!eventsdb
!
+
Manifest:+ Management+ of+ Internships+Microservice+(Domain)
FFF
applications:
F!name:!papFdomain
!path:!./build
!buildpack:!nodejs_buildpack
!memory:!128M
!noFroute:!true
!healthFcheckFtype:!none
!command:!node!server.js
!services:!
!!!F!messagesdb
!
!
4.6. Creating the pipe: Strider CD Finally,! we! will! use! Strider! for! automating! the! previous! steps! in! a! complete!pipeline.! !Strider! is! an! Open! Source! Continuous! Deployment! and! Continuous!Integration!platform.! It! is!written! in!Node.JS! and! JavaScript! and!uses!MongoDB!as! a!backing!store.!
Strider! CD! is! extremely! customizable! through! plugins.! Plugins! can! add! hooks! to!perform! arbitrary! actions! during! build,! modify! the! database! schema! to! add! custom!fields,!register!their!own!HTTP!routes,!subscribe!to!and!emit!socket!events,!create!or!modify!user!interfaces!within!Strider,!etc.
We!chose!Strider!CD!because!it!integrates!easily!with!Bitbucket!and!allow!us!to!use!the!tools!chosen:!Grunt!for!building,!Mocha!and!Chai!for!testing!and!Cloud!Foundry!for!the!deployment.
For! the!purpose!of! this!project,!we!will! deploy!a!private! copy!of! Strider!CD! in!Cloud!Foundry! in! order! to! configure! it! for! our! code.! Our! own! configuration!will! consist! in!three!similar!pipelines:!one!for!each!microservice.!We!will!configure!each!on!them!to!be!automatically!started!when!we!do!a!commit!to!the!correspondent!repository.!For!that,! we! will! provide! Strider! CD! with! the! URL! for! each! of! our! three! repositories.! If!needed,!we!will!be!also!able!to!start!the!pipeline!manually.
48!
We! will! describe! four! steps! in! Strider! CD,! using! custom! shell! scripts.! They! will! be!automatically!started!when!we!do!a!commit!to!the!repository!specified
• Environment:!Environment!commands!should!only!be!for!installing!versions!of!languages!and!such!things!that!need!to!come!even!before!the!prepare!stage.!In!this!step,!we!will!install!the!Grunt!Command!Line!Interface!and!Cloud!Foundry!Command!Line!Interface.!
• Prepare:!The!commands!specified! in!this!step!are!run!after!the!repo!is!cloned!but!before!the!tests.!In!this!step,!we!will!install!the!necessary!dependencies!and!we!will!build!the!software.!
• Test:!The!pipeline!will! start! the! tests!defined! in!our!software.! If! the! tests! fail,!the!deploy!won’t!happen.!
• Deploy:!Deploy! commands!are! run!when!you!manually! !or!when! the! job!was!triggered!by!a!commit,!followed!by!a!successful!test!run.!Deploy!commands!are!not!run!when!tests!fail.!
!
5. Results and Conclusions 5.1. Final results The!targets!of!this!project!were!
1. Development!of!an!application!using!a!microservice!architecture,!showing!the!most!representatives!challenges!of!this!approach,!using!a!cloud!environment.!
2. Develop! a! process! for! the! automation! of! the! infrastructure,! including!continuous!integration!and!deployment.!
For! the! first! target,! the! results! have! been! satisfactory.! We! have! developed! an!application!using!a!microservice!architecture!using!a!cloud!environment,!and!we!have!analysed!the!perks!and!drawbacks!of!this!approach.
In! relation! to! the! second! target,!we!have! fulfilled!our!expectations.!A!CI/CD!pipeline!have!been!developed!satisfactory,!choosing!tools!that!take!advantage!of!the!languages!and!technologies!chosen.
5.2 Future work lines For! this!project,!we!have!developed!a! simple!demonstration,! fitted! for! the! time!and!effort!required.!In!real!world,!a!team!would!be!in!charge!of!each!of!the!microservices,!allowing!a!deeper!and!more!complete!work.
In! the! first! target,! the! work! can! be! enhanced! in! several! ways.! For! example,! taking!advantages! of! the! tools! provided! by! the! cloud! environment,! we! can! add! realFtime!monitoring! in! order! to! make! our! application! more! resilient.! We! can! also! add! new!features!to!the!application!or!even!add!new!microservices!for!extra!functionalities.
For! the! second! target,! an! interesting! improvement! would! be! to! develop! a! more!complex! test! environment.! For! avoiding! the! risk! of! obscuring! the! project,! we! did!
49!
simple!tests.!Nowadays,!tests!are!a!significant!part!of!software!development,!playing!a!protagonist!role!in!some!process,!as!TestFdriven!development,!for!example.
For!the!third!target,!we!chose!to!use!a!BlueFGreen!Deployment.!This!is!a!simple!way!to!perform! a! zeroFdowntime! deployment,! but! there! are!more! complete! alternatives.! A!good!option!could!be!a!Canary!Release,!a!technique!to!reduce!the!risk!of!introducing!a!new!software!version!in!production!by!slowly!rolling!out!the!change!to!a!small!subset!of! users! before! rolling! it! out! to! the! entire! infrastructure! and!making! it! available! to!everybody.
5.3. Conclusions Microservices! architecture! is! a! great! option! that! will! spread! in! the! following! years.!Although!it!has!some!added!difficulties!and!drawbacks,!the!benefits!compensate!them.!Many!software!developments!could!take!advantage!of! the!perks!of! this!architecture,!although! we! should! be! cautious:! not! all! software! designs! are! appropriate! for!microservices.!Big!tightly!coupled!monoliths!can!improve!with!microservices,!but!small!applications!can!get!too!complex!if!we!try!to!apply!this!architecture.
Continuous!Integration!and!Continuous!Deployment!are!practices!which!are!gaining!a!lot!of!popularity!in!the!last!years.!Broadly!talking,!they!are!appropriate!for!the!majority!of! software! developments! and! they! can! provide! numerous! perks.! The! pipeline!may!vary! in! order! to! adapt! itself! to! the! different! projects,! allowing! great! flexibility! for!applying!these!tools!to!our!projects.!
!
6. Bibliography 1!"Microservices!F!Martin!Fowler."!2014.!10!Jul.!2016!<http://martinfowler.com/articles/microservices.html>!2!Papazoglou,!Mike!P,!and!WillemFJan!Van!Den!Heuvel.!"Service!oriented!architectures:!approaches,!technologies!and!research!issues."!The+VLDB+journal!16.3!(2007):!389F415.!3!Mell,!Peter,!and!Tim!Grance.!"The!NIST!definition!of!cloud!computing."!14!(2011).!4!Jamsa,!Kris.!Cloud+computing.!Jones!&!Bartlett!Publishers,!2012.!5!"Cloud!Foundry!|!The!Industry!Standard!For!Cloud!Applications."!2011.!10!Jul.!2016!<https://www.cloudfoundry.org/> 6!Humble,!Jez,!and!David!Farley.!Continuous!delivery:!reliable!software!releases!through!build,!test,!and!deployment!automation.!Pearson!Education,!2010. 7!Leffingwell,!Dean.!Agile!software!requirements:!lean!requirements!practices!for!teams,!programs,!and!the!enterprise.!AddisonFWesley!Professional,!2010. 8!"HTML5!F!W3C."!2013.!10!Jul.!2016!<https://www.w3.org/TR/html5/>!
50!
9!"CSS3!.!Info!F!All!you!ever!needed!to!know!about!CSS3."!2006.!10!Jul.!2016!<http://www.css3.info/> 10!"JavaScript.com."!2015.!10!Jul.!2016!<https://www.javascript.com/> 11!"AngularJS!—!Superheroic!JavaScript!MVW!Framework."!2014.!10!Jul.!2016!<https://angularjs.org/> 12!"Node.js."!2014.!10!Jul.!2016!<https://nodejs.org/> 13!"MongoDB!for!GIANT!Ideas!|!MongoDB."!2013.!10!Jul.!2016!<https://www.mongodb.com/> 14!"Express!F!Node.js!web!application!framework."!2015.!10!Jul.!2016!<https://expressjs.com/> 15!"Passport."!2011.!10!Jul.!2016!<http://passportjs.org/> 16!"Mongoose!ODM!v4.5.3."!2010.!10!Jul.!2016!<http://mongoosejs.com/> 17!"Event!Sourcing!F!Martin!Fowler."!2006.!10!Jul.!2016!<http://martinfowler.com/eaaDev/EventSourcing.html> 18!"CQRS!F!Martin!Fowler."!2011.!10!Jul.!2016!<http://martinfowler.com/bliki/CQRS.html> 19!"Backbone.js."!2011.!10!Jul.!2016!<http://backbonejs.org/>!20!"Redis."!2010.!10!Jul.!2016!<http://redis.io/> 21! "Ionic:! Advanced! HTML5! Hybrid! Mobile! App! Framework."! 2013.! 10! Jul.! 2016!<http://ionicframework.com/> 22!"Apache!Cordova."!2013.!10!Jul.!2016!<https://cordova.apache.org/>!23!"Git."!2012.!12!Jul.!2016!<https://git-scm.com/>!24! "Bitbucket! —! The! Git! solution! for! professional! teams."! 2008.! 12! Jul.! 2016!<https://bitbucket.org/>!25!"Grunt:!The!JavaScript!Task!Runner."!2012.!12!Jul.!2016!<http://gruntjs.com/>!26! "Mocha! F! the! fun,! simple,! flexible! JavaScript! test! framework."! 2015.! 12! Jul.! 2016!<https://mochajs.org/>!27!"Chai."!2011.!12!Jul.!2016!<http://chaijs.com/>!28!"GitHub!F!StriderFCD/strider:!Strider:!Open!Source!Continuous!..."!2012.!12!Jul.!2016!<https://github.com/Strider-CD/strider>!29!"Cloud!Foundry!|!The!Industry!Standard!For!Cloud!Applications."!2011.!12!Jul.!2016!<https://www.cloudfoundry.org/>!
!