Why we need to split the logic?
When a nontechnical person things in an application, he visualizes it as an engine to solve a problem in the company in order to generate money, this monolithic concept is widely propagated across business managers and business owners. It's not wrong, because in order to generate profit, all of the parts should act as one big application, however, the different components should be synchronized and run in a coordinate way. The ability to align those multiple parts is responsibility of the enterprise architects who has to understand the view of the managers/owners that are receiving the profit of the engine and is paying to keep it running in a effective way.
In business side, every day the drivers are changing and the company should adapt to those new drivers smoothly and promptly without loose control over the process and ideally reducing cost and increasing quality. The implementation of each change should be performed in all parts of the company, including applications, and it's better if the applications are modular and easy to assembly returning to the original best practice to have loosely coupled software components, reducing the dependencies between the components and making easy to replace or update one component in the big structure.
In order to reach this model, each task identified on the company, should be implemented as a service and must run independently of the other components, at this point, it's very important to have defined the input, output and exception management of the task that the service will represent, each service will receive a set of parameters and will execute a process to transform the parameters in an output following a deterministic process. Also, the service could generate an action over information, such as write a file, send an email, modify information in a database or over any other resources available in the platform. When you have to update a process due to a new requirement from the business, you have change just the services that are covering tasks that are impacted for this change, trying to keep the input, output and exception process according with the original, if it's not possible, it should modify just an small part of the communication.
Also, each component should run in an independent environment, allocating his own resources and avoiding coalitions with other task, in the same way, it could be run using a pool of resources able to run a lot of instances of the same task in parallel without mixing data or fighting for resources; in older architectures models this could be solved with a finite pool of instance of the same component pre loaded, this concept solved a lot of issues but it fails when the pooled instances run out of resources and finally generates a crash in the components. In new architectures based in cloud you could configure unlimited instances on-demand that will be instantiated as soon as are invoked. Those instances should not generate any consumption of resources meanwhile it's idle and also doesn't generate any cost to the company.
To communicate micro services we have to establish a common language to move information between the components, usually, this language requeries to identify the main entities that are playing inside the company processes and generate a detailed documentation of each one, taking care of all the posible stages and all the views that could have each entity.
Micro services must be coordinated by an orquestation process that knows all the capabilities of each service and manage the business logic to generate value to the user, this process act a workflow engine with all the steps and conditions requeried to process a business job with all the exceptions and variations.
No comments:
Post a Comment