More Related Content


More from JSFestUA(20)


JS Fest 2019/Autumn. Anton Cherednikov. Choreographic or orchestral architecture, the right way of micro-services communications in nodes

  1. When we developing a loosely coupled and reusable application, often arises the question: how to arrange communication between services or applications? To a large extent, it depends on the nature of the request and the granularity of your applications or services. We will discuss the two classic microservice integration patterns: service choreography and orchestration. What is the difference between these two modes of communication? Which one we should use? How to ensure data consistency? How to implement disturbed transactions? We will discuss these issues, also we do not forget the issues of logging, monitoring and alerting in choreography and orchestration system.
  2. Choreographic or orchestral architecture the right way of micro-services communications
  3. 1 Topics Services… How did we get to this? 2 Micro-services: communication approaches 4 Logging, monitoring, alerting 3 Transactions: how to ensure data consistency between services? 5 Conclusion
  4. Services... How did we get to this?
  5. 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 Monolithic Architecture a monolithic application is built as a single and indivisible unit. Simply means that all of the application code is deployed and run as a single process on a single node.
  6. usually: ● supports multiple message protocols ● maximizes application reusability ● connecting services to each other ● focused on business functionality reuse ● use of a common platform for all services deployed to it ● common governance and standards Service-Oriented Architecture is essentially a collection of services. These services communicate with each other. The communication can involve either simple data passing or two or more services coordinating some activity. Some means of connecting services to each other is needed. Service orientation is a paradigm that frames what you do. (SOA manifesto:
  7. Service-Oriented Architecture - cohesion of components
  8. Microservices, in a way, are the next step in the evolution of Service Oriented Architectures. A bounded context refers to the coupling of a component and its data as a single unit with minimal dependencies. usually: ● CI/CD as core value ● stateless ● minimize on sharing of components ● low coupling ● high cohesion (bounded context) ● native to cloud-based development ● higher scalability and flexibility ● faster turnaround
  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
  10. Micro-services communication approaches
  11. Orchestral approach Orchestration is the traditional way of handling interactions between different services in Micro-Service Architecture. With orchestration, there is typically one controller that acts as the “orchestrator” of the overall service interactions. This typically follows a request/response type pattern. 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
  12. Benefits: ● a good way for controlling the flow of the application ● low coupling ● saving contacts in one place Tradeoffs: ● infrastructure difficulties ● system monitoring complexity ● failure of one component results in a request error ● orchestrator is a single point of failure Provides a good way for controlling the flow of the application when there is synchronous processing. For example, if Service A needs to complete successfully before Service B is invoked.
  13. The World’s Most Popular Open Source Microservice API Gateway&Platform. ● decentralization ● independent deployment ● fault Isolation ● services to develop independently of each other ● invoke serverless functions via APIs ● transform requests and responses on the fly ● kubernetes integration
  14. ● authentication and Security ● dynamic Routing ● load balancing ● static response handling ● multiregion resiliency ● insights and monitoring Zuul is an edge service that provides dynamic routing, monitoring, resiliency, security... How Netflix use Zuul
  15. NodeJS Orchestration Sample The previously proposed solutions do not provide such flexibility in transaction management - which we would like to have. If we need flexibility in managing our transactions, it is recommended to use in-house solution.
  16. 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 Choreography approach - applying a choreography pattern means that one service doesn’t talk to another service in order to instruct an action. Instead each service is observing its environment and acts on events autonomous. Note: When it comes to create/read/update/delete entities the REST protocol should still be a consideration. The service that handles the REST call could then trigger an event that a new entity was created/updated/deleted.
  17. Event driven architecture patterns solve for some of the orchestration challenges listed above.
  18. Benefits: ● faster end-to-end processing ● can be executed asynchronously ● easier to add/update services ● great aligns with an agile delivery model ● teams now focus on particular services ● control is distributed ● no longer a single orchestrator serving as a central point of failure ● several patterns can be use: event sourcing, CQRS… Tradeoffs: ● async mindset ● significant for developers ● complexity is shifted ● count of services are increased
  19. 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 A streaming platform has three key capabilities: ● Publish and subscribe to streams of records, similar to a message queue or enterprise messaging system. ● Store streams of records in a fault-tolerant durable way. ● Process streams of records as they occur.
  20. Patterns of Enterprise Application Architecture by Martin Fowler
  21. ● 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
  22. 03 Transactions How to ensure data consistency between services?
  23. ● 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!
  24. 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
  25. Create order flow
  26. ● no central coordination ● each service produces and listen to other service’s events ● depends on event decides if an action should be taken ● micro-service executes a local transaction ● proceeds till the last service which doesn’t publish any more events, there by marking the end of transaction Choreography approach
  27. Choreography approach - create order flow
  28. Rollback a distributed transaction doesn’t come for free. We have to implement another operation/transaction to compensate for what has been done before.
  29. ● central coordination ● one service listen to other service’s events ● depends on http/grpc response decides if an action should be taken ● micro-service executes a local transaction ● proceeds till the last service send response Orchestration approach
  30. Orchestration approach: create order flow
  31. Orchestration approach - rollback
  32. 04 Logging, monitoring, alerting
  33. Istio — connect, manage, and secure microservices ● Istio uses the Envoy proxy to transparently add in the service mesh functionality ● Istio provides uniform observability, mTLS-based security, and traffic management. ● Istio can be used with both Kubernetes-based workloads as well as workloads deployed on VMs.
  34. Istio features ● Request routing by versions or routing environment ● Leverages service registry (service discovery) ● Load balancing (envoy) ● Service-to-service communication: HTTP1.1 or HTTP/2, gRPC or TCP ● Canary releases
  35. Istio features
  36. ● Elastic - powerful and highly scalable search engine ● Kibana lets us visualize your Elasticsearch data and navigate the Elastic Stack ● Logstash ingests data from a multitude of sources simultaneously, transforms it, and then sends it to elastic. Elastic Logstash Kibana
  37. Prometheus (TSDB) ● open-source systems monitoring and alerting toolkit originally built at SoundCloud ● full monitoring and trending system that includes built-in and 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 ● multiple modes of graphing and dashboarding support
  38. Alerting rules allow you to define alert conditions based on Prometheus expression language expressions and to send notifications about firing alerts to an external service ● Grouping categorizes alerts of similar nature into a single notification ● Defining alerting rules ● Templating - {{ $value }} - {{ $labels.<labelname> }} ● Sending alert notifications by custom channels Prometheus - alerting
  39. Zipkin is a distributed tracing system Zipkin
  40. Conclusion
  41. Orchestration, Choreography - can apply in different scenarios and use cases So, what is better: orchestration or choreography? None is necessarily better than the others or applicable for all needs. Keep in mind that you can also combine these two approaches. Conclusion