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.
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.
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.
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.
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.
