Mikroslužby jako nikoli nový koncept, ale stará známá UNIXová pravidla v novém hávu. Výhody a nevýhody software navrženého podle vertikál. Papoušek (c) Pavel Lahoda.

1. QUOVADIS, MINISTERIUM?
David Ondřich,Aveco

2. MIKROSLUŽBY vs. …
1. komponentizace pomocí služeb
2. služba = vzdálená knihovna,
3. nezávislý deploy
4. business capability, functional teams
5. smart endpoints, dumb pipes
6. decentralised governance
7. decentralised data mgmt.
8. automatizovaná infrastruktura
9. odolnost vůči selhání
10. postupný návrh / vývoj
http://martinfowler.com/articles/microservices.html

3. 1. služby
2. proces poskytuje ≥1 službu
3. program je vyměnitelný za běhu
4. procesy pro jednotlivé funkce
5. zprávy mezi procesy, fronty zpráv v procesech
6. Astra = Java + Groovy (GUI), C++ / C / asm (core), Lua + Perl +
sh (server-side scripting), MPS (DSL), custom script (cfg)
7. import / export, MOS, vysílání, media-mgmt
8. testy + skripty pro deploy, start skripty
9. replikace, orbitální architektura
10. levá ruka neví, co dělá pravá
… vs.ASTRA

5. 1. služby
2. proces poskytuje ≥1 službu
3. program je vyměnitelný za běhu
4. procesy pro jednotlivé funkce
5. zprávy mezi procesy, fronty zpráv v procesech
6. Astra = Java + Groovy (GUI), C++ / C / asm (core), Lua + Perl +
sh (server-side scripting), MPS (DSL), custom script (cfg)
7. import / export, MOS, vysílání, media-mgmt
8. testy + skripty pro deploy, start skripty
9. replikace, orbitální architektura
10. levá ruka neví, co dělá pravá
… vs.ASTRA

7. 1. služby
2. proces poskytuje ≥1 službu
3. program je vyměnitelný za běhu
4. procesy pro jednotlivé funkce
5. zprávy mezi procesy, fronty zpráv v procesech
6. Astra = Java + Groovy (GUI), C++ / C / asm (core), Lua + Perl +
sh (server-side scripting), MPS (DSL), custom script (cfg)
7. import / export, MOS, vysílání, media-mgmt
8. testy + skripty pro deploy, start skripty
9. replikace, orbitální architektura
10. levá ruka neví, co dělá pravá
… vs.ASTRA

10. 1. služby
2. proces poskytuje ≥1 službu
3. program je vyměnitelný za běhu
4. procesy pro jednotlivé funkce
5. zprávy mezi procesy, fronty zpráv v procesech
6. Astra = Java + Groovy (GUI), C++ / C / asm (core), Lua + Perl +
sh (server-side scripting), MPS (DSL), custom script (cfg)
7. import / export, MOS, vysílání, media-mgmt
8. testy + skripty pro deploy, start skripty
9. replikace, orbitální architektura
10. levá ruka neví, co dělá pravá
… vs.ASTRA

11. [values/extrules]
AUDIO=$ON_SELECTION(7fff)!=M,AUDIOMODE,data_values/amode|$VALUE(7fff)!=:2:|
$FROM(7fff)!=AUDIO1|$FROM(7fff)!=AUDIO2¶
AUDIO1=$ON_SELECTION(1)!=S,AUDIOMODE,data_values/amode1¶
AUDIO2=$ON_SELECTION(1)!=S,AUDIOMODE,data_values/amode2¶
UMID=$DATETIME(1)![1,6]=YYMMDD|$VALUE(1)![7,1]=_|$ON_SELECTION(1)!
[8,5]=SRC__,CRIT1,data_values/crit1|$VALUE(1)![13,1]=_|$ON_SELECTION(1)!
[14,6]=SUBSRC,CRIT3,data_values/crit3|$VALUE(1)![20,1]=_|$DATETIME(1)!
[21,4]=hhmm|$VALUE(1)![25,1]=_|$UNIQUEID(1)![26,3]=named[1,25]¶
NAME=$VALUE(1)!=.Pre|$VALUE(2)!=.Middle|$VALUE(4)!=.Post|$VALUE(8)!
=.PostRec|$VALUE(10)!=.NewSelector|$VALUE(20)!=.SaveSelector|$VALUE(40)!
=.PHMiddle|$VALUE(80)!=.ReRecordPost|$VALUE(100)!=.ManualEdit|$VALUE(200)!
=.PreRecord|$VALUE(400)!=.IngestStarted|$VALUE(800)!=.IngestStopped?
$VALUE(8000)!=.NotGenerated¶

12. 1. služby
2. proces poskytuje ≥1 službu
3. program je vyměnitelný za běhu
4. procesy pro jednotlivé funkce
5. zprávy mezi procesy, fronty zpráv v procesech
6. Astra = Java + Groovy (GUI), C++ / C / asm (core), Lua + Perl +
sh (server-side scripting), MPS (DSL), custom script (cfg)
7. import / export, MOS, vysílání, media-mgmt
8. testy + skripty pro deploy, start skripty
9. replikace, orbitální architektura
10. levá ruka neví, co dělá pravá
… vs.ASTRA

13. VLASTNOSTI
• stovky procesů
• tři logovací frameworky, 2× GC
• middleware (remote)
• fail-over + škálovatelnost
• architektonická splácanina
• zpětná kompatibilita

14. ORGANIZAČNÍ OPATŘENÍ
• continuous integration + vyhodnocování buildů
• „černé puntíky“
• checklisty pro kontrolu kvality
• integrační testy
• QA oddělení
• lpění na zpětné kompatibilitě

16. ORGANIZAČNÍ OPATŘENÍ
• continuous integration + vyhodnocování buildů
• „černé puntíky“
• checklisty pro kontrolu kvality
• integrační testy
• QA oddělení
• lpění na zpětné kompatibilitě

17. category topic
basics
all English and meaningful binary name
all
all English and meaningful help for the text commands
all
all the program doesn't use the redirection of file descriptors
all
all
all correct ending by CTRL-C
all background process doesn't stop by CTRL-C
all correct handling of the SIGPIPE signal
all correct handling of other signals
all all related unit tests pass with turned on memtest
all English and meaningful names of configuration variables
all check of RT behavior: sent processes, used timers, etc.
all
all needless SVN branches are deleted
logging
all appropriate logging ID (distinguishable processes)
all appropriate default logging verbosity
all enabled logging into the logserv
all disabled logging into the console and files
all disabled (not compiled in) debug messages
all logged all basic states (i.e. no_comm, comm)
all logged start and stop of the process
all
all English logging messages
status reporting
all appropriate status ID (distinguishable processes)
all periodical live ticks
all reported all basic states (i.e. no_comm, comm)
all localized and meaningful status messages
all
English and meaningful help text for --help or use
all components (client manager, dynvar context, shared
timers etc.) participate in the help text
all chained text commands work (client manager, shared
timers, parent driver class, dynvar context etc.)
correct ending by the konec utility
all extra files (Lua, RNC etc.) are specified in the SMakefile
with the install directive if it's needed
logging of all incoming commands (binary, text) except too
often repeating ones
correct handling of severities (i.e. resolved disaster should
not clean not yet resolved error)

18. ORGANIZAČNÍ OPATŘENÍ
• continuous integration + vyhodnocování buildů
• „černé puntíky“
• checklisty pro kontrolu kvality
• integrační testy
• QA oddělení
• lpění na zpětné kompatibilitě

19. SLUŽBY
• ano, ale…
• duplicity (multi-) kódu
• chaotická architektura
• „levný“ fail-over + horizontální škálování
• snadné extendování (3rd middleware)
• závislosti mezi službami
• verzování API

20. JSOU NĚJAKÉ DOTAZY?!?
Dík za pozornost.
@dondrich, david.ondrich@aveco.com