Luzne notatki z warsztatow "Microservices in Scala" na Warsjawa 2014
- Wyzszy poziom abstrakcji niz MVC.
- Multiple small apps with REST/HTTP interfac. Porozumiewanie za pomoca REST/HTTP
- Multiple small apps with deferred messafe processing. Aplikacje ktore przetwarzaja male wiadomosci (np. z RabbitMQ)
- Duzo aplikacji dla kazdego kontrolera
- Multiple single-file apps with less than 100 lines of code
- Multiple small apps possibly written in different languages communicating with each other
- Small single-purpose apps with bounded domain enabling polyglot programming
- add your favourite ingredients
- differences from monolithic architecture
- separation of concerns
- sharing data in threads
- komunikacja miedzy serwisami
- kontrakty miedzy modulami
- deployment strategies
- non-functional guarantees
- cache, cluster baz danych, sla
- it is allowed to duplicate domain. Having common library is not effective. In case of a change in common redeployment of all dependend services is required.
- if some modules will not be changed, they can be used as dependencies.
- Caly kod w jednym miejscu
- Wszystkie moduly umieszczane obok siebie
- Dluga kompilacja, tworzymy jedna duza paczke, testy jedn, int, ...
- Migracja DB
- Deployment: kazda z paczek jest identyczna, korzysta z tej samej DB, latwo skonfigurowac
- Zaleznosci: global variables, messages, function calls, data structures, shared memory, multiple levels of indirection
- Managed with: SOLID, encapsulation, dependency injection
- Interfaces vs Contracts: biblioteki wystawiaja swoje API, mozna testowac przez testy i kompilatory, type validations, api calls defined by the language, encapsulation, SRP
- Problems: meta-programming, monkey patching, global state and workaround
- Pojedyncze programy bardzo krotkie
- Obrazy VM ze skonfigurowanymi appkami
- Deployment: kazdy serwis zajmuje sie jedna rzecza, to jest ich duzo, nie ma porzadku, configuration management, service discovery (zookeeper, consul.io), monitoring
- Zaleznosci: different protocols (np. serwisy sie komunikuja po HTTP), shared DB's, shared message queues
- Managed with: contracts
- Interfaces vs Contracts: maja kontrakt miedzy soba, spoken / unspoken, should be defined on 'paper', defined by protocols and technologies used like: HTTP, websockets, RPC, RabbitMQ, shared MongoDB
- Problems: changing contract or having no contract requires changing multiple services, multiple API versions without easy solution for validating consistency
Serwisy musza wykonywac jedno zadanie. Zalety:
- Mala zlozonosc (np. mniej niz 100 linii)
- Nie wiazemy kodu z kodem innych modulow
- 'this big' or one hundred lines of code
- Easy to rewrite
- Rewrite instead of refactor
- Easy to spot inputs and outputs
- Still requires readable logic
- business performance using relevant metrics (np. wystawilem 50000 faktur)
- visaulization (ex. kamon, custom charts)
- continuous deployment metrics
- Mozemy pisac w roznych jezykach ale miec jeden kontrakt (np. HTTP)
- Synchronuous and asynchronous processing
- SLAs and guarantees
- Shared and private databases
- Making layers of micro services
- bare-metal vs platforms
- data-drie systems, eventsourcinf and real-time messaging
- natychmiastowa odp
- fast and hard failure
- asking
- request timeouts
- problematic to debug series of request
ex. chain of HTTP request and getting 200
- post jobs to be processed
- tell don't ask
- fire and forget
- need of pooling and waiting for response
- longer jobs
- failures can be recovered from!
ex. uploading a video file to be processed and getting 'video uploaded successfully'
- Preety strong contract
- Convenient for simple domain problems
- Easier to maintain
- Problems:
- coupling too many services, too deeply
- can become performance bottle-neck
- useful for decoupling and reuse
- useful for performance
- useful for embedding in microservices that abstract complicated domain models
- difficult to maintain, although can many DBs can work on single cluster/instance
- useful for giving microservice authority over some data
- problems
- data sharding
- frontend
- CORS (cross origin resource sharing)
- rendering of HTML: server-side or in js
- moving caches to CDN
- keeping modularity and reusability also on the frontend side
- one backend microservice failure shouldn't break whole frontened
- dns/routing/loadbalancing (wiedza gdzie sa microservicey)
- user facing, services caches (np. autentykacja)
- CORS
- Versioning of API
- Authentication
- Caching
- Loadbalancing
- Security
- internal services workers
- Security
- Scalability
- Monitoring for failures
- Keeping the data consistent
- bare metal servers vs platforms
- high level framework = more difficult polyglot programming + easier maintenance + possible code sharing + more tight coupling opportunities
Unix processes
- finagle
- akka
- jvm
Multiple interfaces
- only rest
- only rabbitmq
- only atom
- state stored in the database
- ex. John has 3122$ on his account
- transactions and locks that enable us to mutate the state
- no state just events
- ex. John got spent 12$
- state is inferred from past events
- every situation can be replayed
- events are immutable = no problem with locking
- Client and server side REST/HTTP libs
- Multiple layers
- Really fast
- Aquired by Typesafe
- Spray => akka-http
- reactive streams
- new building blocks for Play
- HttpRequest => HttpResponse
- Different levels of abstraction, focus: DSL
- Key koncepts: routing, marshalling
- Routing:
- directives:
- transform, extract, filter, side-effecting
- composable
- concatanable (~) - jesli poprzednia dyrektywa odrzuci to nastepna jest wykonywana
- useful directives:
- path, pathprefix
- get, post, put, delete, patch
- parameter
- formFields
- entity
- logRequestResponse
- complete (!) - to co chcemy by wykonalo sie w zapytaniu. Caly kod w complete
- directives:
~re-start po zmianie w kodzie restartuje serwer
- fully blown web framework
- not very well-suited for microservices
- Rails like (M)VC
- routes => controllers => views
Good job!