# A Microservices-Based Control Plane for Time-Sensitive Networking
## 5 Microservices as Deployment Strategy: A Qualitative Analysis  
We have seen in the experiments that the characteristics of the hardware have a dramatic impact on the run times of certain computationally intensive tasks--specifically, the  
\begin{table}
\begin{tabular}{c c c c c c c c c} \hline \hline  & \multicolumn{4}{c}{**Local Machine**} & \multicolumn{4}{c}{**M25n Large**} \\ \cline{2-10}
**Streams** & **Average** & **Min** & **Max** & **Std. Dev.** & **Average** & **Min** & **Max** & **Std. Dev.** \\ \hline
40 & 57.570 & 51.236 & 64.660 & 4.675 & 2.201 & 2.024 & 2.328 & 0.089 \\
45 & 87.403 & 75.829 & 105.118 & 8.256 & 3.070 & 2.673 & 3.598 & 0.212 \\
50 & 138.381 & 112.855 & 163.418 & 14.569 & 4.255 & 3.779 & 4.573 & 0.247 \\ \hline \hline \end{tabular}
\end{table}
Table 6: Seconds to find a solution: local machine vs. M5 Zn.large using Gurobi, depending on the number of streams.  
Figure 16: Seconds to find a solution: local machine vs. M5 Zn.large using Gurobi.  
time schedule calculation--and the conclusion is that the run times of the ILP are much smaller if we use a specially designed machine with a high frequency of operation. In contrast, other tasks, e.g., the topology collection, do not require such stringent hardware specifications. This highlights the advantage of assigning different software tasks to separate microservices, to better align the hardware resources to their requirements. This represents a clear advantage of using the microservice approach above a monolithic implementation.  
In an ideal scenario, the ILP should run on a high-capacity hardware computer, with the maximum operating frequency for its processor and using an efficient solver like Gurobi. In contrast, the rest of the elements could run on general-purpose machines, using container orchestration tools such as Kubernetes or OpenShift. Both tools allow us to manage where and when the containers containing the microservices are deployed and store their configuration parameters. They also provide components to expose the microservices to the outside and mechanisms to select the nodes on which the microservices can be deployed. However, these two technologies have significant differences: Kubernetes is a widely adopted, highly scalable, open-source container orchestration platform, which provides robust tools for container cluster management, application deployment, and autoscaling; on the other hand, OpenShift is a Kubernetes-based application platform developed by Red Hat that offers an additional layer of added value by providing a more complete and enterprise-ready experience. OpenShift incorporates Kubernetes but adds additional features and functionalities, such as deployment automation, application lifecycle management, and a more intuitive and simplified approach to application deployment. In short, while OpenShift is focused on offering a complete and enterprise solution, Kubernetes is a more basic and flexible option.  
From all the previous considerations, we concluded that the ideal scenario to deploy our \(\mu\)TSN-CP solution consisted of a Kubernetes cluster comprising two groups of nodes. The first group is made up of machines specifically designed to operate at high frequency (for example, the AWSs M5 Zn.large machine group), intended for the ILP Calculator microservice, while the second group comprises general-purpose hardware and is used to run all the other microservices. Figure 17 illustrates this approach.