[{"data":1,"prerenderedAt":83},["ShallowReactive",2],{"content-guides-refactoring-serverless-choreography-to-orchestration":3},{"markdown":4,"frontMatterAttributes":5,"bodyRaw":9,"contributorPaths":10,"menuType":14,"contentName":15,"slug":16,"readingTime":17,"menu":18,"nextDocItem":82,"previousDocItem":73},"\u003Ch2>Description:\u003C\u002Fh2>\n\u003Cp>Choreography and orchestration are two modes that distributed microservices can use to communicate with each another.\u003C\u002Fp>\n\u003Cp>In \u003Cem>choreography\u003C\u002Fem>, every service works independently and communicates without tight control. Events flow between services without any centralized coordination. Each microservice listens for events that it is interested in and performs its own actions using an event-driven model.\u003C\u002Fp>\n\u003Cp>In \u003Cem>orchestration\u003C\u002Fem>, a central service called an orchestrator controls the interaction between services. The orchestrator coordinates interactions and the order of service invokes. It acts as control flow for the business logic. \u003C\u002Fp>\n\u003Cp>Many applications use both choreography and orchestration for different use cases. Communication between \u003Ca href=\"https:\u002F\u002Fmartinfowler.com\u002Fbliki\u002FBoundedContext.html\">bounded contexts\u003C\u002Fa> is often how choreography is used most effectively. Within a bounded context, you control the sequence of service integration, maintain state, and handle errors and retries. A standard guideline is to use orchestration within the bounded context of a microservice and use choreography between bounded contexts. \u003C\u002Fp>\n\u003Cp>The following article presents an illustration of two interaction patterns, highlighting their pros and cons, and gives the advice how to select or combine them within a given context.\u003C\u002Fp>\n\u003Cp>\u003Ca href=\"https:\u002F\u002Ftheburningmonk.com\u002F2020\u002F08\u002Fchoreography-vs-orchestration-in-the-land-of-serverless\u002F\">Choreography vs Orchestration in the land of serverless\u003C\u002Fa>\u003C\u002Fp>\n\u003Ch2>Solution:\u003C\u002Fh2>\n\u003Cp>AWS Step Functions is a serverless orchestration service. A workflow in Step Functions is called a state machine. The state machine simplifies the implementation of common tasks and supports features like retries, handling failures, parallelization, service integrations, and observability. \u003C\u002Fp>\n\u003Cp>Original:\u003Cbr>\u003Cimg src=\"\u002Fassets\u002Fexternal\u002Fguides\u002Frefactoring-serverless\u002Fassets\u002Fimages\u002Fchoreography.png\" alt=\"\">\u003C\u002Fp>\n\u003Cp>Refactored: \n\u003Cimg src=\"\u002Fassets\u002Fexternal\u002Fguides\u002Frefactoring-serverless\u002Fassets\u002Fimages\u002Forchestration.png\" alt=\"\">\u003C\u002Fp>\n\u003Cp>See the CDK implementation of this pattern in Typescript on \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Faws-samples\u002Faws-refactoring-to-serverless\u002Fblob\u002Fmain\u002Fpatterns\u002Fchoreography-to-orchestration.md\">GitHub\u003C\u002Fa>.\u003C\u002Fp>\n\u003Ch2>Advantages:\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>\u003Cp>Easier to implement as one system controls the flow between components. The work flow is modelled and version controlled.\u003C\u002Fp>\n\u003C\u002Fli>\n\u003Cli>\u003Cp>Simplifies end-to-end monitoring, reporting using built in visualization, and audit histories.\u003C\u002Fp>\n\u003C\u002Fli>\n\u003Cli>\u003Cp>Transaction management and error management. It is easier to handle transaction errors, timeout, retries etc. \u003C\u002Fp>\n\u003C\u002Fli>\n\u003Cli>\u003Cp>Centralized business logic. Everything is visible in one place. No need for complex architecture diagrams and supporting documents.\u003C\u002Fp>\n\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>Considerations:\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>\u003Cp>A different cost model when using an orchestration service. AWS Step Functions has two modes, Standard and Express Workflows. Standard Workflows charges per state transitions after exceeding the initial 4,000 free state transitions per month. Step Functions counts a state transition every time a step of your workflow executes. Step Functions Express Workflows can run for a maximum of 5 minutes and charges by the number of executions and memory consumption and can reduce costs in some scenarios. For example for 50K requests it costs $3.96 using the original architecture and the refactored architecture using Standard Workflows costs $4.90 and Express Workflows $3.18. \u003C\u002Fp>\n\u003C\u002Fli>\n\u003Cli>\u003Cp>Tight coupling of services with the orchestrator. \u003C\u002Fp>\n\u003C\u002Fli>\n\u003Cli>\u003Cp>Less flexible to add individual components. You need to test the whole system for small changes in workflow.\u003C\u002Fp>\n\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>Applicability:\u003C\u002Fh2>\n\u003Cp>The refactoring can be applied to workflows where you want centralized control over the interactions between microservices. This can help to have a unified view of the system and to make it easier to troubleshoot and make decisions. This can be especially helpful when considering a complex architecture featuring numerous services.\u003C\u002Fp>\n\u003Ch2>Related refactoring:\u003C\u002Fh2>\n\u003Cp>\u003Ca href=\".\u002Forchestration-to-choreography\">Convert Orchestration to Choreography\u003C\u002Fa>\u003C\u002Fp>\n",{"title":6,"authors":7},"Convert Choreography to Orchestration",[8],"Bhuvan Annamreddi","## Description:\n\nChoreography and orchestration are two modes that distributed microservices can use to communicate with each another.\n\nIn *choreography*, every service works independently and communicates without tight control. Events flow between services without any centralized coordination. Each microservice listens for events that it is interested in and performs its own actions using an event-driven model.\n\nIn *orchestration*, a central service called an orchestrator controls the interaction between services. The orchestrator coordinates interactions and the order of service invokes. It acts as control flow for the business logic. \n\nMany applications use both choreography and orchestration for different use cases. Communication between [bounded contexts](https:\u002F\u002Fmartinfowler.com\u002Fbliki\u002FBoundedContext.html) is often how choreography is used most effectively. Within a bounded context, you control the sequence of service integration, maintain state, and handle errors and retries. A standard guideline is to use orchestration within the bounded context of a microservice and use choreography between bounded contexts. \n\nThe following article presents an illustration of two interaction patterns, highlighting their pros and cons, and gives the advice how to select or combine them within a given context.\n\n[Choreography vs Orchestration in the land of serverless](https:\u002F\u002Ftheburningmonk.com\u002F2020\u002F08\u002Fchoreography-vs-orchestration-in-the-land-of-serverless\u002F)\n\n\n## Solution:\n\nAWS Step Functions is a serverless orchestration service. A workflow in Step Functions is called a state machine. The state machine simplifies the implementation of common tasks and supports features like retries, handling failures, parallelization, service integrations, and observability. \n\nOriginal:  \n![](\u002Fassets\u002Fexternal\u002Fguides\u002Frefactoring-serverless\u002Fassets\u002Fimages\u002Fchoreography.png)\n\nRefactored: \n![](\u002Fassets\u002Fexternal\u002Fguides\u002Frefactoring-serverless\u002Fassets\u002Fimages\u002Forchestration.png)\n\nSee the CDK implementation of this pattern in Typescript on [GitHub](https:\u002F\u002Fgithub.com\u002Faws-samples\u002Faws-refactoring-to-serverless\u002Fblob\u002Fmain\u002Fpatterns\u002Fchoreography-to-orchestration.md).\n\n## Advantages:\n\n- Easier to implement as one system controls the flow between components. The work flow is modelled and version controlled.\n\n- Simplifies end-to-end monitoring, reporting using built in visualization, and audit histories.\n \n- Transaction management and error management. It is easier to handle transaction errors, timeout, retries etc. \n\n- Centralized business logic. Everything is visible in one place. No need for complex architecture diagrams and supporting documents. \n\n## Considerations: \n\n- A different cost model when using an orchestration service. AWS Step Functions has two modes, Standard and Express Workflows. Standard Workflows charges per state transitions after exceeding the initial 4,000 free state transitions per month. Step Functions counts a state transition every time a step of your workflow executes. Step Functions Express Workflows can run for a maximum of 5 minutes and charges by the number of executions and memory consumption and can reduce costs in some scenarios. For example for 50K requests it costs $3.96 using the original architecture and the refactored architecture using Standard Workflows costs $4.90 and Express Workflows $3.18. \n\n- Tight coupling of services with the orchestrator. \n\n- Less flexible to add individual components. You need to test the whole system for small changes in workflow. \n\n## Applicability: \n\nThe refactoring can be applied to workflows where you want centralized control over the interactions between microservices. This can help to have a unified view of the system and to make it easier to troubleshoot and make decisions. This can be especially helpful when considering a complex architecture featuring numerous services.\n\n## Related refactoring: \n\n[Convert Orchestration to Choreography](.\u002Forchestration-to-choreography)",[11,12,13],"content\u002Fcontributors\u002Fgregor-hohpe.json","content\u002Fcontributors\u002Fsindhu-pillai.json","content\u002Fcontributors\u002Fbhuvan-annamreddi.json","LIST","Refactoring to Serverless","\u002Fcontent\u002Fguides\u002Frefactoring-serverless\u002Fchoreography-to-orchestration","3 min",[19,43],{"title":20,"content":21},"Introduction",[22],{"title":15,"order":23,"callout":24,"resources":28,"time":17,"path":40,"id":41,"link":42},1,{"title":25,"description":26,"link":27},"Watch the video","This session shows how you can refactor an existing serverless application to fully utilize AWS managed services and make service dependencies explicit, resulting in cleaner and more robust code.","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=F7wxgWaccHs",[29,33,36],{"link":30,"text":31,"type":32},"https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=ttJAIQf7cTw","Building modern cloud applications? Think integration!","video",{"link":34,"text":35,"type":32},"https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=Ud9h1hJgoKk","Modern cloud applications - do they lock you in?",{"link":37,"text":38,"type":39},"https:\u002F\u002Fcdkpatterns.com\u002Fpatterns\u002F","CDK Patterns Collection","website","introduction","introduction.md","\u002Fcontent\u002Fguides\u002Frefactoring-serverless\u002Fintroduction",{"title":44,"content":45},"Refactorings",[46,52,57,62,68,73,78],{"title":47,"time":48,"path":49,"id":50,"link":51},"Extract Send Message","2 min","extract_send_message","extract_send_message.md","\u002Fcontent\u002Fguides\u002Frefactoring-serverless\u002Fextract_send_message",{"title":53,"time":48,"path":54,"id":55,"link":56},"Extract function invocation","extract_function_invocation","extract_function_invocation.md","\u002Fcontent\u002Fguides\u002Frefactoring-serverless\u002Fextract_function_invocation",{"title":58,"time":48,"path":59,"id":60,"link":61},"Replace Lambda with Service Integration","service_integration","service_integration.md","\u002Fcontent\u002Fguides\u002Frefactoring-serverless\u002Fservice_integration",{"title":63,"time":64,"path":65,"id":66,"link":67},"Direct database access","1 min","direct_database_access","direct_database_access.md","\u002Fcontent\u002Fguides\u002Frefactoring-serverless\u002Fdirect_database_access",{"title":69,"time":64,"path":70,"id":71,"link":72},"Replace Polling with Callback","replace_polling_with_callback","replace_polling_with_callback.md","\u002Fcontent\u002Fguides\u002Frefactoring-serverless\u002Freplace_polling_with_callback",{"title":74,"time":48,"path":75,"id":76,"link":77},"Send Message via Pipes","send_message_via_pipes","send_message_via_pipes.md","\u002Fcontent\u002Fguides\u002Frefactoring-serverless\u002Fsend_message_via_pipes",{"title":6,"authors":79,"time":17,"path":80,"id":81,"link":16},[8],"choreography-to-orchestration","choreography-to-orchestration.md",null,1792578866191]