Workflow Engines and Microservices – Implementing Strategies

In today’s competitive environment, emerging technologies require changes to business processes if a company wants to remain relevant. In a world of automation, enhancing processes and experiences can future-proof and disruption-proof any business.

This means companies will need to find new ways to make business processes just as much a part of their digital transformation strategy as technology.

In this quick overview, we’ll discuss how workflow engines and microservices enable you to do just that.

Challenges with Business Processes

A whopping 90 percent of companies are still struggling to deliver on the promise of a technology-enabled business model. What seems to be the problem?

Unfortunately, several issues will need to be addressed before companies can be successful with their digital transformation efforts:

• Silos - With numerous teams driving revenue and day-to-day operations, there is often a disconnect in processes and data that hinders collaboration.
• Poor Systems Integration - The ecosystem of internal applications tends to be complex and doesn’t lend well to integration.
• Bottlenecks - Slow processes are often a result of bottlenecks that can harm the customer experience.
• Redundancy - Companies of all sizes suffer from redundancy in process and data all of which dilutes the quality of the process and confuses those involved.

Strategies for implementing workflow engines and microservices

Proper microservice design plays a significant role in how well you realize the benefit of this approach.

Here are a few best practices to help you get started.

1. Follow Single Responsibility Principle

Each microservice should have only one responsibility. Adding more business logic than is necessary bloats the service.

Doing so only reinforces complex workflow design. Combining logic from different processes into one service hinders agility and reduces opportunities for reuse. Consider the following example.

Let’s say you are building microservices for ordering shoes on a website. You might have functions for ordering, checking inventory, paying and delivery notification.

Thus you may decide on the following services:

• Order Service

• Payment Service

• Delivery Notification Service

It would be tempting to place checking inventory in the Order Service.

After all, checking inventory when the customer places an order is logical. However, burying that functionality in the Order Service only adds unnecessary complexity to Order Service.

Not only that, when you need to make a change to either process, you might end up breaking the entire service.

A better approach is to create a separate service for the inventory. What you’d end up with is:

• Order Service

• Inventory Service

• Payment Service

• Delivery Notification Service

This way, the Order Service can focus on taking the order and leave the Inventory Service to perform its function without breaking the other processes.

2. Use asynchronous communications

What happens when each of your services is so tightly intertwined, that when one takes too long to respond, the entire process slows?

This tight coupling not only slows the system but can harm the customer experience.

Ideally, you want each service to be able to communicate without depending on a response to continue the process.

This approach is commonly referred to as asynchronous communication. Let’s continue with our example from above.

When a customer places an order, the delivery may take days. The last thing you want is for the Order Service process to stall waiting on the Delivery Notification Service to finish.

The process should continue without waiting on Delivery Notification Service to complete. Once delivery is complete, the Delivery Notification Service will report its status and close out the process.

3. Fail fast to achieve fault tolerance

There may be cases when your services will rely on another system to respond.

The system could be internal or external to your organization. If that system takes too long to respond or throws errors, every downstream process will be negatively impacted.

What you should do is implement what is known as a circuit breaker to handle these scenarios

Back to our example.

Let’s say Inventory Service depends on an external call to check inventory from your supplier. What happens if the supplier's system is down or it takes too long to respond.

Any other process that depends on Inventory Service would be impacted.

The solution is to implement some type of monitoring service in the process known as a “circuit breaker.”

The circuit breaker watches for errors and timeout issues for remote calls. Once an issue is detected, the circuit breaker “trips.”  The breaker prevents any further calls from going through and returns an error to the caller.

You’d also want some process to detect a tripped circuit and perform the necessary steps to determine when the issues with the supplier are resolved.

Components of workflow engines

A workflow engine requires several key components that work together to coordinate microservices with their associated business processes.

Task Executor - Microservices are autonomous components that require some type of action to execute. The executor’s role is to run the action defined by the microservice.

Scheduler - The scheduler is the core of the engine. It schedules runs and monitors the results of task execution.

Triggers - Microservices are triggered by some event. The event could be an API call, a request from another service, or a user-initiated business process.

Process Repository - A workflow engine requires definitions for each business process. The definitions are what the engine uses to correlate the microservices to each process.

Shared Context - The complexity of the workflow may require some of the components to share information with each other. Information such as environment variables or the current state of other components.

Rather than requiring each component in the workflow to obtain this information individually, this information can be shared across all components in what is known as a shared context.

Metadata Storage - The scheduler requires information to orchestrate the entire workflow. Information such as what components to run, when to run them and what resources are needed to execute the workflow.

This is where metadata storage comes into play. It houses everything the scheduler needs to know to make the process work.

Preparing your business for digital transformation requires more than embracing new technology. The true benefit comes from redefining your business processes alongside the technology.

The processes and the technology must support each other in realizing true transformation.

Using workflow engines and microservices is an ideal solution to do just that.

Adservio's main goal is endeavoring to help companies embrace strategies to meet their digital transformation goals.

Reach out to us to see how we’ve partnered with our clients to deliver quality IT services.