API workflow design patterns for microservices scenarios

Workflow is fundamental for any multi-component application. Information travels from the source through a set of processes, and any response comes back as the last step. There are a limited number of ways to drive workflow, and the first step in designing a microservice application is to decide which of these workflow options is best. From there, you can choose from a number of API workflow design templates.

In traditional applications, work is directed by application processes. A microservice is then invoked because the logic of another recognizes the need to execute it. The most common model for driving work applications is the API Broker design model, where a master component (the broker, in this case) receives the work from the source process and passes it to a microservice for execution. .

An alternative model inherited from the time of SOA is the service bus design model. With this design pattern, a series of services are attached to a message bus, and the message bus governs the logic (often written in Business Process Markup Language or BPML) that decides which service to run next.

The advantage of this approach is that the processing logic services that it needs to facilitate execution are separated from the workflow logic, now in BPML form. This makes it easier to reuse components, because microservices are now just extracts of processes. It is also a step towards the third model: step by step orchestration.

Best practices for microservices dictate that they be resilient and scalable, which means they can’t keep heavy state data from run to run. Otherwise, only the last service that ran on an entry can perform the next workflow step, making it difficult to scale or redeploy.

State control in microservice applications depends on separating data from logic and providing that data to any associated microservice. The data item can come from the source of the workflow and move with the workflow (front-end health check), reside in a database accessible to all microservices, and run when work arrives (health check back-end) or operate according to a finite stage orchestration machine.

Stage orchestration describes the sequencing of microservices along a workflow, and service buses are the most basic example. Use a switch / router design pattern where the goal is to get work through a predictable sequence of processes, essentially creating a modern implementation of service broker logic. But for a more sophisticated orchestration of complex applications, it is essential to bring in the issue of state control.

The state machine design model is the ultimate stage orchestration model. Any process system can identify itself as a migration following a specific state-guided sequence triggered by events. With this design pattern, a logical state and an event mapping table define each process sequence. The relationships between specific states and events determine which microservice process to run. The mapping table becomes part of the health check data.

The biggest advantage of the state machine orchestration approach is that it deals with scalability and concurrency in parallel. Each process receives its data and state control information as input, and a master process translates the state and event information it needs to activate the appropriate service. This model is also extremely flexible, so it can be used both in a persistent container and in Virtual machine models deployment and serverless deployment.

A final set of design patterns relate to the most general pattern of microservice communications: the service mesh. The service mesh is normally based either on a sidecar design pattern or on a specific design pattern from a service mesh middleware, such as Istio and Linkerd. The service mesh approach is a good way to manage service bus deployment models, because all the microservice communications and load balancing needed can reside directly in the implementation details.

API selection is based in part on best practices and in part on the specific middleware tools you select to help with your implementation. As a general rule, it is recommended to use RESTful API and think in terms of APIs that represent services rather than actions. JSON and XML are the normal mechanisms for encoding data values.

The big question with the API is whether to pass all the data to a process or just the data that the process needs. The former will make microservices maintenance easier by giving everyone access to workflow data and status information, but it will also increase network load and delay in moving work. The “only what is needed” approach should really only apply when the nature of the microservice inherently limits the scope of the information needed.

When designing microservices and APIs, try to take a consistent approach for all applications that might reuse those microservices down the line. Many advanced microservice developers focus on the state machine approach because of its flexibility and because it creates a data model that fully describes process state and variables in one place. This makes debugging a lot easier. But whatever approach you take, remember to be consistent or you’ll run into some debugging and operating issues later.


Source link

Billie M. Secrist

Leave a Reply

Your email address will not be published. Required fields are marked *