title: Orchestrated vs Choreographed Service-Oriented Architecture in large scale?
body: <p>I'm an architect in a large scale financial company and we are in the beginning of implementing a new business oriented infosystem across our different countries.</p>
  
  <p>From the very early on the core idea has been to follow microservice oriented principles as much as possible <em>(and making sure engineers have read Building Microservices book by Sam Newman)</em>.</p>
  
  <p>By now I've come to crossroads. Our services are primarily JSON REST services using Swagger for automated documentation, but in order to use these services in our business processes and making sure not to write business logic into services outside the domain of those services, we've been using Camunda as an orchestration tool. And Camunda is fine <em>(though some have considered Corezoid as an alternative)</em>, but somewhat clumsy in what is an otherwise an elegant set of services.</p>
  
  <p>Now service orchestration is a concept pretty familiar to most engineers. But it is one that I am not entirely happy with due to still having a central engine that drives everything. It is incredibly expensive to replace later down the road <em>(though still cheaper to replace than a monolith)</em>. And even if this central engine is split into multiple engines <em>(which is actually the case today)</em>, it does not necessarily make it much better.</p>
  
  <p>In recent years there has been a movement with microservices towards choreographed <em>(close to event-driven)</em> architecture. It is at this point where I am looking for advice from engineers and architects who have faced similar crossroad decision points.</p>
  
  <p>I absolutely love the idea of decoupled architecture and despite feeling good about killing monoliths and having elegant independent services, I still detect a lot of dependencies in business process as a whole in current orchestrated solution in where it should not actually exist.</p>
  
  <p>And it's not like we are avoiding events. We have actually implemented events on our architecture as well in order to decouple many processes with the core principle that if you don't need a synchronized response and just need to notify of something happening to initiate another process an event is put up that may be caught by another process that starts executing. And orchestration is easier to explain and visualize, it is easier to tweak and modify by more technical minded business users. And I think it is easier to test and validate from business perspective. Orchestrated architecture like this also <em>(usually)</em> expects a good service discovery and quality automated documentation and non-functional requirements which are all things I value greatly. </p>
  
  <p>All of those things that are a question to me in choreographed approach since I don't have first-hand experience in running this in large scale - just some local test prototypes.</p>
  
  <p>But I think you see where I am coming from. I'm trying to consider alternatives without having to regret driving the company all the other way in the end.</p>
  
  <p>Perhaps you can share your own experience with a similar situation or share an interesting link or two? Or am I looking for a silver bullet that doesn't exist yet?</p>