Why split your application in microservices?

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.

Serverless strategy - Micro services vs Traditional Applications

When you are implementing a new application in your organization, you are onboarding in the world of infrastructure management, one of the more expensive areas of the technology and have to start dealing with terms like "end of life" or "extended warranty fees" that usually are more expensive than the application that is generating money for your company.

To setup an application you have to install a server that should run 7/24 because you don't know when the customer or your employees will access the application, you have to buy a good machine that support the load to run all day and all night, then you have to ensure that it will have power and network all time, it's an additional monthly cost. Also you have to hire a company or a team to keep it running and provide support to internal and external users.

General understanding where are the cost of infrastructure in the implementation of an in-house application.

If this fragile infrastructure fails just in the moment that a customer is accessing their information, you have to deal with a unhappy customer.

When you scale it following the growing of your organization, you have to add more servers, more locations and bigger infrastructure support team, that will cost the organization a huge amount of money on daily basis, reducing the space to investing in business growing and a consuming big amounts of money on bills to pay on monthly basis.

The first strategy to solve this issue with multiple locations is to consolidate all the applications in one location with all the technical guarantees to run it 7/24, be compliant with regulations, requirements and keeping the customers and employees happy with your systems and your business. This strategy is costly at the beginning because you have to invest a lot of money in the location, then you have to maintain the infrastructure running renewing the machines periodically, protecting from different kinds of attacks and dealing with the obsolescence of the infrastructure software.

Now, I make a question.

Why do you have to paid a lot of time for an infrastructure that you use 40% of the time to generate income?

The application is not be accessing during night/off work hours, also, during the the working ours is not being used all time, in addition, your company is not using all functionalities all time. What happen if I uninstall the sever that process my taxes during the year and I'm only install it by tax session? What happen if the payroll module shutdown during the month and just start it the day that the company calculate the payroll until the day that pay to the employees and print pay stubs?

In the model that we are evaluating now, the company have to pay in full for the cost of the infrastructure service besides it's in use or not, you have the server connected, you are paying for the rent of the space, you are paying for the technical support, you are paying the license of the operative system, you are paying the energy bill.

What happen if you could pay just for the time and resources that the company is using in a particular period of time?

Now days, the experts in infrastructure are offering a high performance, dependable, secure platform that you could rent by second/minute/hour/day of month, that let you implement whatever you want to generate the income that you like. This platform is the Cloud. Call it AWS, Google Cloud, VMWare or any other solution available, they have the servers, they have the experts, they pay the energy bill, they pay for the license and the provide everything to the customer according with real needs.

As part of those services, the cloud providers offer the opportunity split your application in small parts in order to separate functionalities in a very granular level, and create a new micro environment to run each part of the application and this micro environment will be stay down until the functionality is needed, a simple process trigger the micro environment, this event could be to put a file in a specific folder, or receive a message from a particular source; if you need to use the functionality more than one time in parallel, the cloud will provide you multiple copies of the micro environment to run the functionality in parallel without delays in customer side. Now, you have to pay a rent of the server for the number of seconds that process use to return the information. This cost is very small comparing to the cost of the infrastructure that you have to pay if you have a dedicated server to run this functionality available 7/24.

Other awesome advantage to use this serverless architecture is that you have performance on-demand, because for any invocation that you perform on the application, you will reserve a separate, independent instance with the requirements adapted to the functionally that is running, generating a feeling in the end user side that the server never get overloaded and the information and functionalities are 100% of the time available.

It's particular helpful if you have a business need to resolve particular workloads in response to a business event, like a marketing campaign, sales season or monthly cycles with defined process, that generate a high volume of use of a particular functionality of the application during a defined period of time from business side, this period of time is identified like an event in the architecture such as a new input of a client request in the database or upload a file with a new order in the website; this event will trigger the function and the platform will allocate the resources meanwhile the function process the information.Once the process is finish the resources will be released.

In order to reach this model, the application should be develop using the strategy of micro services, generating a perfect split over the functionalities that let identify all the actions that are possible to perform and a clear sequence between the actions following a workflow that it is aligned with business needs and cover all the details of the process. All the actions should be configured as micro services with a clear input, trigger and output and it should be invoked by an big orchestation process similar to an ESB (Enterprise Service Bus), that knows the workflow and the actions involved in the workflow.

I'll detail in the next article the idea of ESB and workflows to coordinate micro services.

Conclusion:

It's cheaper to implement and maintain microservices as strategy to implement applications in the organization, however, it should be consider from the beginning of the project.