As we described in an earlier blog, microservices are mini-applications which are devoted to a single, specific function. They are discrete (independent of other services in the architecture), polyglot with a common messaging or API interface, and they have well-defined parameters.
As application development and IT operations teams have started streamlining and speeding up their processes with methodologies like Agile and DevOps, they have increasingly begun treating IT applications as microservices. This breaks up potential bottlenecks, reduces dependencies on services used by other teams, and can help make IT infrastructure less rigid and more distributed.
One area where we are seeing this looser, more distributed approach to service development is with business rules.
Business rules and processes in a traditional structure tend to be centralized, with the complete set of functionality defined for all workflows. The problem with centralization is because there is a single, centralized collection of business rules, any changes to one set of rules can affect many other sets, even those for different business functions.
Micro-rules essentially treat each functional set of rules as its own service -- well-defined, highly focused, and independent of other rules.
Like microservices, this allows business rules to be distributed and localized to the teams that need them, and to be reusable to other development teams and applications.
As these micro-rules are incorporated into larger applications or workflows, those applications are incorporating relevant business logic. This allows them to behave inline with business requirements.
Process- or rule-driven applications are made to be responsive to application or customer events and to provide more immediate and automatic actions based on those rules -- without requiring manual intervention.
Breaking business rules and processes into smaller, microservice-style applications allows business rules to be more easily incorporated into cloud-native and microservice application architectures.
Because micro-rules are discrete and well-defined, this can actually smooth collaboration between IT, development, and business users who are all required for the creation and deployment of rules. It’s easier to understand what the rule is for and where it will fit within the application infrastructure.
Additionally, updating and testing the effectiveness of micro-rules is easier than with a larger, more monolithic approach to rules development. New rules or modifications to rules can be rolled out to specific audiences for A/B testing or major updates can be released in phases (e.g., canary deployments) to minimize risk. Rules can even be rolled back, without affecting other rules in the environment.
- Code downloads, tutorials and quickstarts, and documentation
- Customer documentation and support articles
About the author
Deon Ballard is a product marketing manager focusing on customer experience, adoption, and renewals for Red Hat Enterprise Linux. Red Hat Enterprise Linux is the foundation for open hybrid cloud. In previous roles at Red Hat, Ballard has been a technical writer, doc lead, and content strategist for technical documentation, specializing in security technologies such as NSS, LDAP, certificate management, and authentication / authorization, as well as cloud and management. She also wrote and edited the Middleware Blog for Red Hat and led portfolio solution marketing for integration and business automation.