2019 03-20 snidane-serie-kuchyne-full

Podívejte se nám
do softwarové kuchyně
Michal Petřík, Aleš Podskalský, Martin Závrbský 20. března 2019

3
Série odborných snídaní
› Pohled na projekty ze
strany dodavatele
› Připomenutí si
best practices vývoje
a údržby SW
› Relevance a jejich
zásadní význam
i v dnešním
„agilním světě“

4
Témata
1. Odhady a práce s nimi
2. Architektura 100x jinak
3. Testování, základní principy pro testovací strategie (Q2/2019)

5
Architektura 100x jinak
09:05 – 10:00 Rozumná a udržitelná architektura je alfou a omegou
každého systému
Osvěžte si s námi základní principy rozumné architektury, které musí ctít každý architekt
a bez nichž je každý projekt odsouzen k záhubě.
10:00 – 10:15 Přestávka
10:15 – 11:10 Architektonický trend současnosti pod drobnohledem
softwarového inženýra
Je masivní migrace stávajícího řešení do microservices architektury jediným řešením
aktuálních problémů a nebo platí osvědčené - “když dva dělají totéž, není to totéž”?
11:10 – 11:30 Závěr, diskuze u kávy

Softwarová architektura
Aleš Podskalský 20. března 2019

Co je to
softwarová architektura?

9
Průzkum
"Softwarová architektura je způsob nebo
forma jakou stavíme a skládáme náš software."

10
Co je to softwarová architektura?
World elite

11
"My name is Martin Fowler: I’m an author,
speaker, and loud-mouth on the design
of enterprise software."
Martin Fowler
https://martinfowler.com

12
Martin Fowler
"Architecture
is social thing.
It is fuzzy
embeded
understanding."
"Software
architecture is
those decisions
which are both
important and
hard to change."
https://www.youtube.com/watch?v=DngAZyWMGR0

13
"Architecture represents the significant
decisions, where significance is measured
by cost of change."
› Grady Booch (2006) "On design"
Simon Brown

14
Simon Brown
"Software
architecture isn’t
about big design
up front."
"A good software
architecture
enables agility."

15
Co architektura řeší
› Splnění požadavků > struktura projektu
› Práce s daty
› Uživatelské rozhraní
› Bezpečnost
› Výkon
› Zpracování chyb
› Odolnost proti chybám
› Provozní pravidla

16
Čas věnovaný přípravám
10-20%
celkového úsilí
20-30%
časového harmonogramu

Design Stamina Hypothesis
https://martinfowler.com/bliki/DesignStaminaHypothesis.html
Cumulativefunctionality
Time
Design payoff line
Good design
No design
… but up here there is no useful trade-off
Down here it may be worth trading off
design quality for time to market.

19
Softwarový architekt
"The software
architecture role
is multi-faceted."
"The software
architecture is not
a relay sport."
Každý tým potřebuje také technické vedení.
Softwarová architektura je o programování,
vedení a spolupráci.

20
Softwarový architekt
Coding
architect
Ivory
tower
VS
PowerPoint
architect
Architecture
astronaut

Vizualizace
softwarové architektury

22
SW architektura – Google obrázky

23
Whiteboard software architecture

25
Standardy a vzory řešení

26
Standardy a vzory řešení
Řešení problému
Vytváří slovník

Reaktivní, asynchronní,
redundantní, …
Potřebujeme to?

30
Důvody změn v architektuře
› rychleji a za méně pěněz
› nároky na uživatelské rozhraní aplikací
› počet uživatelů
› rychlost odezvy
› přenosu velkého objemu dat
› bezpečnost

31
Vlastnosti architektury – současnost
Reaktivní manifest!
https://www.reactivemanifesto.org
Responzivní
Odolný
Zprávami
řízený
Pružný

32
Microservices vs. SOA – Architektonické rozdíly
Monolithic SOA Microservices
Single Unit Coarse-grained Fine-grained

33
0% Autonomy 100% Autonomy

34

35
Softwarové architektury

36
Bez architektury to nejde.
Vizualizace architektury je zásadní.
Neztraťte se v pojmech 

Martin Závrbský 4. března 2019
Mikroservisní architektura

38
Osnova
1. Co je mikroservisní architektura?
2. Příklad 1: návrh nového systému
3. Přínosy a výzvy
4. Příklad 2: použití v existujícím kontextu - možnosti
5. Shrnutí

39
Co je mikroservisní architektura?
› In short, the 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.
James Lewis
Martin Fowler

40
Malé služby – jak velká je „small service“?
Desítky
až stovky LOC
Stovky
až tisíce LOC

41
› Tak velká, že ji již nejde rozdělit, aniž
by ztratila schopnost pokrýt základní
funkční oblast
Conway's law
"Any organization that designs a system
will inevitably produce a design whose
structure is a copy of the organization's
communication structure."
Melvin E. Conway

42
› Tak velká, aby je zvládl pokrýt jeden tým
› Obyvkle
– Tým = do deseti lidí
– Pokrýt = od analýzy přes implementaci, vývoj, nasazení a podporu

43
"If you can't feed
a team with two pizzas,
it's too large."
Jeff Bezos / Amazon founder

44
Jednoduchý komunikační mechanismus
› Obvykle: RESTfull API
› Protokoly: HTTP, JSON
› Cíl: Co nejvíce srozumitelné, samopopisné a snadno
integrovatelné API
› Typicky v rozporu s požadavky na detailní dokumentaci
(katalog), návrh předem a další běžné SOA patterny

45
Jednoduchý komunikační mechanismus
Nástroje:
Swagger, Apiary
Přístupy:
HATEOAS (Hypermedia as the Engine
of Application State)

46
Různé programovací jazyky, rozdílné technologie
pro uložení dat
› Neexistuje nejlepší jazyk nebo datové
úložiště
– Různé týmy = různé preference
– Různé požadavky = různé nástroje
– Vyvarovat se uzamknutí se do jednoho světa
› Od začátku nucená diverzita = v budoucnu
je diverzita možná
› Korporace: centrální správa, licence
> diverzita v zásadě nežádoucí?

47
Nezávislé nasazení a provoz
› Vynucení skutečné separace služeb
› Nasazení jedné služby nevynucuje přenasazení služby jiné
› Lze praktikovat rozdílný release cyklus pro různé služby
› Může být nutné se vypořádat se souběžným během různých
verzí služeb

48
Nezávislé nasazení a provoz – prostředky
API Gateway
Service discovery
Inventory microservices
REST API
Accounting microservices
REST API
Shipping microservices
REST API
Store microservices
REST API
Mobile Client API Gateway
Client
Registry
Service
Service
Service

49
Nezávislé nasazení a provoz
Consumer-Driven Contracts
Consumer
Consumer
Consumer
Provider
Consumer
Contract
Consumer
Contract
Consumer
Contract
Consumer-Driven
Contract
Provider
Contract

50
Plně automatizovaný proces
› Automatické nasazení = nasazení do všech prostředí včetně
produkce musí být tak jednoduché, že ho musí zvládnout každý
› Maximální využívání automatických nástrojů
(Jenkins, TeamCity, Bamboo)
Business
Needs & Use Cases
1
Software
Development Team
2
Software
Check in
3
Automated
Software Build
4
Automated
Test Scripts
5
Software
Deployment
6
Monitoring
& Operations
7

51
Příklad 1: návrh architektury nového systému
› Požadavek: jednoduchý „intranet portál“ obsahující články,
telefonní seznam, kurzovní lístek, diskuse
Hlavička
Články
Kontakty
Kurzy

52
Klasický přístup
User Article Comment …
Home Edit Article Edit Phonebook Read Article
User DAO Articles DAO …
UserService RateService LoginService
CommentService Phonebook Service
GUI vrstva
Homepage, čtení článku, vložení
a editace článku, komentáře, …
DAO, Services
- ArticleService
- CommentsService
- ExchangeRatesService
- PhoneBookService
- …
Datová vrstva

53
Klasický přístup (výsledek)
Enterprise application + max. static content
A monolithic application
puts all its functionality
into a single process...
… and scales by replicating the monolith on multiple servers.

54
Mikroservisní přístup
GUI – jednotlivé moduly, propojení
Articles
API GW
GUI (SPAs, Mobile, …)
Discussions
Security
(IdP, AuthNZ)
…
Exchage
Rates

55
Microservisní architektura v uživatelském rozhraní
Micro frontendsFrontendBackendDatabase
The Shop
Team
The Monolith
FrontendBackendDatabase
Frontend Team
Front & Back
Backend /
DevOps Team
Frontend Team
Microservices
Product
Service
Aggregation Layer (BFF, GraphQL, …)
Product
Service
Product
Service
Product
Service
End-to-End teams with Micro Frontends
Team
Inspire
Mission:
Helps the customer
to discover products.
Team
Search
Mission:
Quickly find the
right product.
Team
Product
Mission:
Present the product
(specs, images, …).
Team
Checkout
Mission:
Provide a good
checkout experience.

56
Mikroservisní přístup
A microservis architecture puts
each element of functionality
into a separate service…
… and scales by distributing these services
across servers, replicating as needed.

57
Přínosy a výzvy
› Mikroservices přinašejí výhody ale něco to stojí
› Je úkolem architekta zvážit kdy je výhodné zaplatit danou cenu
Jasně dané hranice
mezi moduly
Distribuovaný
systém
Nezávislé nasazení Eventuální konzistence
Technologická rozmanitost Provozní složitost
-+
-+
VS

58
Eventuální konzistence
› Relační databáze – ACID – silná konzistence dat – transakce
› Distribuované systémy – obtížné a pomalé zajištění silné konzistence
› Případná konzistence – různé kopie dat v různých částech systému
› Případná konzistence – mechanismy zajištění konvergence
a rekonciliace
› Příklad:
– Šeková knížka, Objednávka kávy
› Kdy se hodí uvažovat o eventuální konzistenci? Je rozdíl mezi
elektronickými novinami, prodejem online videa a zabezpečením
železničního přejezdu?

59
Výzvy neboli některé microservice antipatterns
› Disneyworld
– Všechno je růžové, krásné a fungující… …jenže, není > self-healthchecks, metriky
+ monitoring nutný
› Monolith database
– Společná databáze/model > změny v jedné službě vynucují úpravy služby jiné > mizí
výhoda nezávislých releasů
› Unknown caller
– Služby se navzájem volají, ale neexistuje způsob sledování každé akce > zavedení
CorrelationId
› Synchronous world
– U všech volání se čeká na dokončení operace – u distribuované aplikace vede na
velmi pomalé služby > od začátku třeba využívat asynchronní zpracování kdykoliv
je to možné

60
Příklad 2: skutečný svět
Microservices vyřeší všechny
naše problémy. Co máme vyhodíme
a postavíme parádní nový systém. ?

61
Stávající stav
› Původně malý systém
› Nové funkce, noví klienti
› Customizace pro určité use cases
› Postupně roste technický dluh
Legacy systém
GUI
Web
portál
Logika

62
Stávající stav
› Obtížná orientace pro analytiky, vývojáře i testery
› Duplikace chyb
› Následné zobecnění nákladné
› Viditelné až po letech provozu
› Architektura přestává vyhovovat
Legacy systém – výsledný stav po létech

63
Možnosti
Varianta A
Přepsat celé
na zelené louce
Varianta B
Postupný přepis po
modulech nebo vrstvách

64
Možnosti
› Varianta A: Přepsat celé na zelené louce
– Náklady také na analýzu a testování (aneb co všechno umí stávající systém)
– Nutno přepsat také dobře fungující moduly
– Migrace dat
– Provoz a rozvoj původního systému po celou dobu přepisu
– Často tlak na přechod do nového systému, který neumí všechno co starý > hrozí nekomfort až odpor uživatelů
› Varianta B: Postupný přepis po modulech nebo vrstvách
– Stavba jádra – architektury
– Obalení legacy aplikace API vrstvou / příprava na GUI integrace
– Přepis nejvíce problematických celků – zlepšení se dostaví rychleji
– Nové moduly do nové architektury
– Původní dobře fungující moduly netřeba přepisovat
– Akceptovatelné technické kompromisy
› Vhodnost varianty B roste s velikostí systému

65
Varianta B
Legacy
GUI
Web
portál
Legacy
logika
GUI integrace
API
Nový modul
(microservice)
…
API GW
GUI plugin / microsite

66
Varianta B
› Martin Fowler – Strangler pattern (2004)
› Microsoft – Model utlumení
"All we are doing is writing tomorrow's
legacy software today. By making it easy to
be strangled in the future, you are enabling
the graceful fading away of today's work."
Martin Fowler

67
Shrnutí
› Pragmatický přístup:
– Problém k řešení: existuje vůbec?
– Pro a proti: znám cenu za zvolený přístup a jsem ochoten ji zaplatit?
– Zvolená cesta: zvládnu ji (lépe než stávající)?
› Mircroservices
– Něco za něco: jsem připraven řešit nové výzvy (provoz!)
– Skutečný přínos: vím co dělám a proč?
› Skutečný svět
– Nezměním přes noc ani za měsíc 
– Koexistence nového a stávajícího
– Jak, za kolik, jako dlouho (často navždy!)
"If you can't build a
monolith, what makes
you think microservices
are the answer?"
Simon Brown

69
Shrnutí
› Architektonická rozhodnutí jsou vždy zásadní („něco za něco“)
– Krátkodobé / dlouhodobé dopady
– Udržitelnost / rozvoj
– Týmová organizace
– …
› Vždy je nutné vědět, proč chceme změnu architektury dělat
– Znát přínosy, ale uvědomit si i problémy, které vždy nastanou
› Nikdy nemáme hotovo, musíme počítat s rozvojem
› Nebát se chyb a s chybami počítat

Pohled od historie #1
Cca 5 let nazpět
› Asynchronous Programming
› NoSQL
› Distributed Version Control
› JavaScript & HTML5
› Continuous Delivery
› DevOps
› Cloud
https://qconlondon.com/london2019/presentation/becoming-fully-buzzword-compliant-developer

Cca 2 roky nazpět
› Reactive
› Big Data
› Git
› JavaScript & HTML5
› Continuous Delivery
› DevOps
› Cloud

Dnes
› Blockchain
› Containers
› Serverless
› Security
› Machine Learning / AI
› Ethics

Technologie přicházejí a odcházejí (… a zase se vracejí)
› Prince2
› Scrum
› SVN
› Flash / Applet
› AWT / SWING / JavaFX
› Test Driven Development
› Static Typing

75
Shrnutí
# of reasons
things break
# of things your users
actually care about
# of microservices
Must
reduce
the search
space!

Profinit EU, s.r.o.
Tychonova 2, 160 00 Praha 6 | Telefon + 420 224 316 016
Web
www.profinit.eu
LinkedIn
linkedin.com/company/profinit
Twitter
twitter.com/Profinit_EU
Facebook
facebook.com/Profinit.EU
Youtube
Profinit EU
Děkujeme
za pozornost

2019 03-20 snidane-serie-kuchyne-full

More Related Content

Similar to 2019 03-20 snidane-serie-kuchyne-full

More from Profinit

2019 03-20 snidane-serie-kuchyne-full