== Some thoughts regarding Microservice-based application
.Distributed Service Placement for Microservice-based Applications
****
Nowadays whith applications becoming more and more powerfull, users more demanding and IOT devices taking swarming our lives, the need for maximizing *_location awarenes_* and minimizing delay has entered the field.
Thus we cannot relliably trust a signle central data point and have to mingrate to versatile and distributed systems moving the brain of our application ever closer to the user (edge).
*_Multi-access Edge (MEC)_* Computing was born.
[TIP]
====
*_Location-aware_* technology is any technology that is able to detect its current location and then analyze this data to control event and information flow. https://en.wikipedia.org/wiki/Location_awareness[Wikipedia^]
*_MEC_* can be defined as cloud services running at the edge of a network and performing specific tasks — in real- or near-real-time https://en.wikipedia.org/wiki/Edge_computing[wikipedia]
====
To adapt to the above we can shift towards:
* small and scalable data-centers placed closed to the cloud edge
* minimalization of backbone data transmission
****
=== this tools will help
*Container technologies* (Docker), and *orchestration/maintenance tools* (Kubernetes, DockerSwarm etc), are becoming the mainstream solution for packaging, deploying, maintaining, and healing applications.
Each microservice decoupled from the application can be packaged as a Docker image and each microservice instance is a Docker container.
Kubernetes for example is one of the best examples for creating cloud-native applications and leveraging the benefits of a distributed system.
=== and here is the problem
*Problem:*
When all of the services are placed on one edge site, network congestion is inevitable.
*Solution:*
With one service deployed on more than one edge site, requests from different end users at different locations can be balanced, so as to ensure the high availability of service and the robustness of the provision platform.
*But*, most tools used have some hard limits concerning this.
* It is often treated as a single abstract service with given input and output data size.
* Time series or composition property of services are not fully taken into consideration.
* Due to the heterogeneity of edge sites, such as different CPU cycle frequency and memory footprint, varying background load, transient network interrupts and so on, the service provision platform might face greatly slowdowns or even runtime crash.
* the default assignment, deployment, and management of containers does not fully take the heterogeneity in both physical and virtualized nodes into consideration.
* Besides, the healing capability of Kubernetesis principally monitoring the status of containers, pods, and nodes and timely restarting the failures, which is not enough for high availability.
* in some cases when the pod failure happens, the outage time of the corresponding service could be dozens of seconds.
** When node failure happens, the outage time could be dozens of minutes
=== Suggestion
Therefore, we have to create a better maybe even using different tools to better manage the distribution of our system data and eliminate the problems mentioned above.
This solution will most likely have to be able to utilize multiple edge applications/host at once to balance out the load on one single node.
However,
* Such kind of service requires redundancy and the amount of hosts needed is difficult to agree upon since the network constantly changes.
* Therefore our best bet is to seperate the different cases and try our best to analyze the data and plan our service.
Another problem , currenty not tackled by any major providers are unique attributes of each location, like traditional or human behavioural patterns (for example parking in cetral Rome or a Greek island!).
Gathering data from different requests and places we have to design an algorithm to better utilize the location-specific information.
Our target would be to slowly adapt to all locations and various unique details of each of them.
* better services for the end users always keeping in mind to best distribute our system
* creation of a general microservice based chain-application that works as one, large, redundant, distributed system
