Cloud orchestration is the use of programming technology to manage the interconnections and interactions among workloads on public and private cloud infrastructure. It connects automated tasks into a cohesive workflow to accomplish a goal, with permissions oversight and policy enforcement. Home » Tutorial. Video » Ask Video – Orchestration 101: The String Section Tutorial, ENG Ask Video – Orchestration 101: The String Section Tutorial, ENG By Admin April 11, 2019.
What is the standard pattern of orchestrating microservices?If a microservice only knows about its own domain, but there is a flow of data that requires that multiple services interact in some manner, what's the way to go about it?Let's say we have something like this:. Invoicing. ShipmentAnd for the sake of the argument, let's say that once an an order has been shipped, the invoice should be created.Somewhere, someone presses a button in a GUI, 'I'm done, let's do this!' In a classic monolith service architecture, I'd say that there is either an ESB handling this, or the Shipment service has knowledge of the invoice service and just calls that.But what is the way people deal with this in this brave new world of microservices?I do get that this could be considered highly opinion-based. But there is a concrete side to it, as microservices are not supposed to do the above.So there has to be a 'what should it by definition do instead', which is not opinion-based.Shoot. The Book describes in detail the styles mentioned by @RogerAlsing in his answer.On page 43 under Orchestration vs Choreography the book says:As we start to model more and more complex logic, we have to deal withthe problem of managing business processes that stretch across theboundary of individual services. And with microservices, we’ll hitthis limit sooner than usual.
When it comes to actuallyimplementing this flow, there are two styles of architecture we couldfollow. With orchestration, we rely on a central brain to guide anddrive the process, much like the conductor in an orchestra.
Withchoreography, we inform each part of the system of its job, and let itwork out the details, like dancers all find‐ ing their way andreacting to others around them in a ballet.The book then proceeds to explain the two styles. The orchestration style corresponds more to the SOA idea of, whereas the choreography style corresponds to the mentioned in Martin Fowler's article.Orchestration StyleUnder this style, the book above mentions:Let’s think about what an orchestration solution would look like forthis flow. Here, probably the simplest thing to do would be to haveour customer service act as the central brain. On creation, it talksto the loyalty points bank, email service, and postal service.,through a series of request/response calls.
Thecustomer service itself can then track where a customer is in thisprocess. It can check to see if the customer’s account has been setup, or the email sent, or the post delivered. We get to take theflowchart. and model it directly into code.
We could even usetooling that implements this for us, perhaps using an appropriaterules engine. Commercial tools exist for this very purpose in the formof business process modeling software.
Assuming we use synchronousrequest/response, we could even know if each stage has worked.The downside to this orchestration approach is that the customerservice can become too much of a central governing authority. It canbecome the hub in the middle of a web, and a central point where logicstarts to live. I have seen this approach result in a small number ofsmart “god” services telling anemic CRUD-based services what to do.Note: I suppose that when the author mentions tooling he's referring to something like (e.g., ). As a matter of fact the has an awesome set of patterns to do this kind of orchestration and it also offers evaluation details of different vendor tools that help to implement it this way. I don't think the author implies one is required to use one of these tools to implement this style of integration though, other lightweight orchestration frameworks could be used e.g., orHowever, I've read on the topic of Microservices and in general the majority of articles I've found in the web seem to of orchestration and instead suggest using the next one.Choreography StyleUnder choreography style the author says:With a choreographed approach, we could instead just have the customerservice emit an event in an asynchronous manner, saying Customercreated. The email service, postal service, and loyalty points bankthen just subscribe to these events and react accordingly.This approach is significantly more decoupled. If someother service needed to reach to the creation of a customer, it justneeds to subscribe to the events and do its job when needed.
Thedownside is that the explicit view of the business process we see inthe workflow is now only implicitly reflected in our system.This means additional work is needed to ensure that you can monitorand track that the right things have happened. For example, would youknow if the loyalty points bank had a bug and for some reason didn’tset up the correct account?
One approach I like for dealing with thisis to build a monitoring system that explicitly matches the view ofthe business process in the workflow, but then tracks what each ofthe services does as independent entities, letting you see oddexceptions mapped onto the more explicit process flow. The flowchart.
isn’t the driving force, but just one lens throughwhich we can see how the system is behaving. In general, I have foundthat systems that tend more toward the choreographed approach are moreloosely coupled, and are more flexible and amenable to change. You doneed to do extra work to monitor and track the processes across systemboundaries, however. I have found most heavily orchestratedimplementations to be extremely brittle, with a higher cost of change.With that in mind, I strongly prefer aiming for a choreographedsystem, where each service is smart enough to under‐ stand its role inthe whole dance.Note: To this day I'm still not sure if choreography is just another name for (EDA), but if EDA is just one way to do it, what are the other ways? (Also see and ). Also it seems that things like CQRS and EvenSourcing resonate a lot with this architectural style, right?Now, after this comes the fun.
The Microservices book does not assume microservices are going to be implemented with REST. As a matter of fact in the next section in the book they proceed to consider RPC and SOA-based solutions and finally REST.
Important point here is that Microservices does not imply REST.So, What About HATEOAS?Now, if we want to follow the RESTful approach we cannot ignore HATEOAS or Roy Fielding will be very much pleased to say in his blog that our solution is not truly REST. See his blog post on:I am getting frustrated by the number of people calling any HTTP-basedinterface a REST API. What needs to be done to make the RESTarchitectural style clear on the notion that hypertext is aconstraint? In other words, if the engine of application state (andhence the API) is not being driven by hypertext, then it cannot beRESTful and cannot be a REST API. Is there some broken manualsomewhere that needs to be fixed?So, as you can see, Fielding thinks that without HATEOAS you are not truly building RESTful applications. For fielding HATEOAS is the way to go when it comes to orchestrate services.
I am just learning all this, but to me HATEOAS does not clearly define who or what is the driving force behind actually following the links. In a UI that could be the user, but in computer-to-computer interactions, I suppose that needs to be done by a higher level service.According to HATEOAS, the only link the API consumer truly needs to know is the one that initiates the communication with the server (e.g. POST /order). From this point on, REST is going to conduct the flow, because in the response of this endpoint, the resource returned will contain the links to next possible states. The API consumer then decides what link to follow and move the application to the next state.Despite how cool that sounds, the client still needs to know if the link must be POSTed, PUTed, GETed, PATCHed, etc.
And the client still needs to decide what payload to pass. The client still needs to be aware of what to do if that fails (retry, compensate, cancel, etc.).I am fairly new to all this, but for me, from HATEOAs perspective, this client, or API consumer is a high order service. If we think it from the perspective of a human, you can imagine an end user in a web page, deciding what links to follow, but still the programmer of the web page had to decide what method to use to invoke the links, and what payload to pass.
So, to my point, in a computer-to-computer interaction, the computer takes the role of the end user. Once more this is what we call an orchestrations service.I suppose we can use HATEOAS with either orchestration or choreography.The API Gateway PatternAnother interesting pattern is suggested by Chris Richardson who also proposed what he called an.In a monolithic architecture, clients of the application, such as webbrowsers and native applications, make HTTP requests via a loadbalancer to one of N identical instances of the application. But in amicroservice architecture, the monolith has been replaced by acollection of services. Consequently, a key question we need to answeris what do the clients interact with?An application client, such as a native mobile application, could makeRESTful HTTP requests to the individual services. On the surfacethis might seem attractive.
However, there is likely to be asignificant mismatch in granularity between the APIs of the individualservices and data required by the clients. For example, displaying oneweb page could potentially require calls to large numbers of services.Amazon.com, for example,how somepages require calls to 100+ services. Making that many requests, evenover a high-speed internet connection, let alone a lower-bandwidth,higher-latency mobile network, would be very inefficient and result ina poor user experience.A much better approach is for clients to make a small number ofrequests per-page, perhaps as few as one, over the Internet to afront-end server known as an API gateway.The API gateway sits between the application’s clients and themicroservices. It provides APIs that are tailored to the client.
TheAPI gateway provides a coarse-grained API to mobile clients and afiner-grained API to desktop clients that use a high-performancenetwork. In this example, the desktop clients makes multiple requeststo retrieve information about a product, where as a mobile clientmakes a single request.The API gateway handles incoming requests by making requests to somenumber of microservices over the high-performance LAN. Netflix, forexample,how each request fans out to on average six backend services.
In thisexample, fine-grained requests from a desktop client are simplyproxied to the corresponding service, whereas each coarse-grainedrequest from a mobile client is handled by aggregating the results ofcalling multiple services.Not only does the API gateway optimize communication between clientsand the application, but it also encapsulates the details of themicroservices. This enables the microservices to evolve withoutimpacting the clients. For examples, two microservices might bemerged.
Another microservice might be partitioned into two or moreservices. Only the API gateway needs to be updated to reflect thesechanges. The clients are unaffected.Now that we have looked at how the API gateway mediates between theapplication and its clients, let’s now look at how to implementcommunication between microservices.This sounds pretty similar to the orchestration style mentioned above, just with a slightly different intent, in this case it seems to be all about performance and simplification of interactions.Further ReadingThere is a great series of articles recently published in the that I recommend to delve deeper into all these concepts:. @FritzDuchardt not exactly.
While the api-gateway does become a single point of failure, it isn't necessarily a governing authority of any kind. A very simple api-gateway might just authenticate requests and proxy them to their target service. The api-gateway pattern is mostly for simplifying client-backend interactions through a single service, it doesn't directly solve the problem of orchestrating or choreographing the services the API-gateway proxies to (which itself is a service).–Jun 22 '17 at 1:11. Trying to aggregate the different approaches here. Domain EventsThe dominant approach for this seems to be using domain events, where each service publish events regarding what have happened and other services can subscribe to those events.This seems to go hand in hand with the concept of smart endpoints, dumb pipes that is described by Martin Fowler here:ProxyAnother apporach that seems common is to wrap the business flow in its own service.Where the proxy orchestrates the interaction between the microservices like shown in the below picture.
So, how is orchestration of microservices different from orchestration of old SOA services that are not “micro”? Not much at all.Microservices usually communicate using http (REST) or messaging/events. Orchestration is often associated with orchestration platforms that allow you to create a scripted interaction among services to automate workflows. In the old SOA days, these platforms used WS-BPEL. Today's tools don't use BPEL.
Examples of modern orchestration products: Netflix Conductor, Camunda, Zeebe, Azure Logic Apps, Baker.Keep in mind that orchestration is a compound pattern that offers several capabilities to create complex compositions of services. Microservices are more often seen as services that should not participate in complex compositions and rather be more autonomous.I can see a microservice being invoked in an orchestrated workflow to do some simple processing, but I don’t see a microservice being the orchestrator service, which often uses mechanisms such as compensating transactions and state repository (dehydration).
So you're having two services:. Invoice micro service. Shipment micro serviceIn real life, you would have something where you hold the order state. Let's call it order service. Next you have order processing use cases, which know what to do when the order transitions from one state to another.
All these services contain a certain set of data, and now you need something else, that does all the coordination. This might be:. A simple GUI knowing all your services and implementing the use cases ('I'm done' calls the shipment service). A business process engine, which waits for an 'I'm done' event. This engine implements the use cases and the flow. An orchestration micro service, let's say the order processing service itself that knows the flow/use cases of your domain. Anything else I did not think about yetThe main point with this is that the control is external.
This is because all your application components are individual building blocks, loosely coupled. If your use cases change, you have to alter one component in one place, which is the orchestration component. If you add a different order flow, you can easily add another orchestrator that does not interfere with the first one. The micro service thinking is not only about scalability and doing fancy REST API's but also about a clear structure, reduced dependencies between components and reuse of common data and functionality that are shared throughout your business.HTH, Mark. I have written few posts on this topic:Maybe these posts can also help:API Gateway pattern - Course-grained api vs fine-grained apisCoarse-grained vs Fine-grained service APIBy definition a coarse-grained service operation has broader scope than a fine-grained service, although the terms are relative. Coarse-grained increased design complexity but can reduce the number of calls required to complete a task. At micro-services architecture coarse-grained may reside at the API Gateway layer and orchestrate several micro-services to complete specific business operation.
Coarse-grained APIs needs to be carefully designed as involving several micro-services that managing different domain of expertise has a risk to mix-concerns in single API and breaking the rules described above. Coarse-grained APIs may suggest new level of granularity for business functions that where not exist otherwise. For example hire employee may involve two microservices calls to HR system to create employee ID and another call to LDAP system to create a user account. Alternatively client may have performed two fine-grained API calls to achieve the same task.
While coarse-grained represents business use-case create user account, fine-grained API represent the capabilities involved in such task. Further more fine-grained API may involve different technologies and communication protocols while coarse-grained abstract them into unified flow. When designing a system consider both as again there is no golden approach that solve everything and there is trad-off for each. Coarse-grained are particularly suited as services to be consumed in other Business contexts, such as other applications, line of business or even by other organizations across the own Enterprise boundaries (typical B2B scenarios).