This speech about micro-services, approaches, and practices in their construction. How to effectively build communication between micro-services and what approaches are commonly used for this. We will talk a little about distributed transactions. Will touch the topic of infrastructure, monitoring, and scaling components. I want to inspire my listeners to develop themselves in the direction of backend development. Force to look towards scalable application architecture. You cannot find this information in the documentation :) This speech will also consist of real-life examples.

1. HOW TO BUILD
EFFICIENT BACKEND
BASED ON
MICROSERVICE
ARCHITECTURE
Anton
Cherednikov
Summer. Sea. JavaScript.

2. 1
Topics
Services… How did we get here?
2 Infrastructure
5 GraphQL in micro-service world
3
Micro-services: communication approaches
6 Conclusion
4
Transactions: how to ensure data consistency
between services?

3. WHAT THE HELL AM I DOING NOW?

4. Services...
How did we get here?

5. Monolithic Architecture
Benefits:
● can work very well even for large applications
● easier debugging and testing
● simple to develop/deploy

6. Monolithic Architecture
Benefits:
● can work very well even for large applications
● easier debugging and testing
● simple to develop/deploy
Tradeoffs:
● becomes too complicated to understand when application scales up
● harder to implement changes
● cannot scale components independently
● cannot deploy components independently

7. Service-Oriented Architecture
Service orientation is a paradigm that frames what you do. (SOA manifesto: http://www.soa-manifesto.org)

8. Micro-service Architecture
usually:
● CI/CD as core value
● stateless
● minimize on sharing of components
● low coupling
● native to cloud-based development
● higher scalability and flexibility

9. ● extra complexity: support and set up the connections between all the modules and databases. All
services have to be deployed independently
● system distribution: when creating a new microservices application, we should handle a number of
cross-cutting concerns: logging, metrics, externalized configuration, health checks…
● testing: quality assurance of code, system and contracts
between services is being much harder cause multiple of
independently deployable components
● debugging: holy hell

11. Infrastructure

13. How to be cloud-agnostic?

14. How to be cloud-agnostic?

15. How to be cloud-agnostic?

16. How to be cloud-agnostic?

17. How to be cloud-agnostic?
Anton Grishko - code.store DevOps Architect
“Multi-cloud with Google Anthos and Istio. How to stop worry about infrastructure”

18. LENS <3

19. LENS

20. ● circuit breaker from the box
● load balancing
● native to k8s
● request routing by versions or
routing environment
● service discovery (registry)
● canary releases
● decentralization
● independent deployment
● fault Isolation
● services to develop independently
of each other
● invoke serverless functions via
APIs
● transform requests and responses
on the fly
● k8s integration
● authentication and Security
● dynamic Routing
● load balancing
● static response handling
● multiregion resiliency
● insights and monitoring
How Netflix use Zuul

21. Istio features

22. Elastic Logstash Kibana

23. ● monitoring and alerting toolkit
● built at SoundCloud
● active scraping, storing, querying, graphing, and alerting
based on time series data
● multidimensional data model with time series data identified
by metric name and key/value pairs
● time series collection happens via a pull model over HTTP
Prometheus

24. HOW TO FIND BOTTLENECKS?
HOW TO CATCH GATEWAY ERROR CODES?

25. Environments

26. Environments

28. Micro-services
communication approaches

29. Orchestral approach
Orchestration is a centralized transaction management
usually:
● communicate services via HTTP/gRPC…
● aggregate response from different services
● allows different request flows
● sync/async requests to couple of services
● provide public API

30. Benefits:
● good way for controlling the flow of the application when there is synchronous
processing
● a good way for controlling the flow of the application
● low coupling
● saving contacts in one place
Tradeoffs:
● think about state
● orchestrator is a single point of failure
● if u use kafka BEWARE OF REBALANCING

31. NodeJS Orchestration Sample

32. Choreography approach
usually:
● services are connected to a message brokerё
● services just subscribe channels they are interested in
● once an event series occurs that matters of the service, the service performs the appropriate action.
● now it is easy to add new services to the architecture;
● in the worst case must to ensure that the other services emit the events that the new service requires.
● adding additional events or extending the payload of existing events won’t break existing logic

34. Kafka is generally used for two broad classes of applications:
● Building real-time streaming data pipelines that reliably get data
between systems or applications
● Building real-time streaming applications that transform or react to
the streams of data
spoiler: rebalancing is beautiful

35. ● Our application can’t use ACID transactions - entities are now spread into multiple databases.
● In case of failure in one of micro-service, state recovery can’t be attained by “two phase
commit” while rollback of transaction
● one to many relationships becomes even more challenging
Challenge!
To ensure the data consistency we need to implement distributed transaction

36. Transactions

37. ● saga is a sequence of local transactions where each transaction updates data within a single
service
● each service which changes the state of the database in a distributed transaction can generate
an event which can trigger the next micro service
● in case of a failure, the saga triggers a sequence of compensating roll back events from one
service to the other in the reverse direction.
To handle this scenario, saga pattern can be used!

38. These sagas can be designed using two techniques:
● choreography, in which each service can trigger other service’s event without a central
coordinator
● orchestration, in which a central coordinator makes the decision of triggering the relevant
events in the saga
SAGA

39. Create order flow

40. Choreography approach - create order flow

41. Rollback a distributed transaction doesn’t come for free. We have to implement
another operation/transaction to compensate for what has been done before.

42. Orchestration approach: create order flow

43. Orchestration approach - rollback

44. ● Rebalancing
● Prepare to enjoy of rebalancing strategy:
■ ROUND ROBIN
■ RANGE
● Messaging patterns in NodeJS
● SO! You should be ready to implement each pattern by yourself

45. Patterns of Enterprise Application Architecture
by Martin Fowler

46. GraphQL
in micro-service world

47. Apollo Federation overview
● multiple-services as a single graph
● An implementing service can reference a type that's defined by another implementing service.

52. NOT SO FAST!

53. ● fckn Federation Gateway falls
● k8s rolling update issue
● extended caching
● some of service didn’t respond
● ...
U should be ready to extend Apollo Federation Gateway

54. SPASIBON