In this chapter, we will evaluate the results obtained with the cloud readiness framework.
A closer inspection on Comptel InstantLink is presented in Section 5.1. The used method is evaluated in Section 5.2. Future work on improving the method and cloud compatibility of Comptel InstantLink is presented in Section 5.3.
5.1. Cloud Compatibility of Comptel InstantLink
Comptel InstantLink would benefit from a cloud environment, because of the possibility to scale efficiently and automatically. The amount of data that CSPs handle is growing, and reducing the infrastructure costs will drive CSPs towards using cloud environments.
Due to the performance requirements and data security, the best option would be to deploy Comptel InstantLink to the CSP’s own premises, where the software is also close to the actual network elements. Many CSPs require a high throughput of requests and the largest companies require it to handle over 1 million requests every hour. The latency caused by communicating over public network would have an impact on Comptel InstantLink’s performance, so the components must be kept physically close to each other. Because Comptel InstantLink is a part of a larger system providing functionality to also other products, it would also have to be close to the other parts of the system to reduce latency.
Also the need to customize the software for each customer makes multitenancy difficult to implement.
In its current state, Comptel InstantLink would not gain the benefits of a cloud environ-ment due to limited scalability. The components have to be made more independent, so that they can be scaled better in a cloud environment. Availability would be better when a component would not be a single point of failure and a new one would be fast to provision
as a replacement with proper monitoring and automatic deployment. Currently the RPE is a single point of failure and contains state in the locking list and execution queues. Or-acle Database has a license that is not suited for all virtualized environments, and another database should be used instead. Currently logs are written to files on disk, but in a cloud environment, all the instances might not be using the same disks and would see different log files. The logs should also be stored on a different physical server than Comptel In-stantLink is running on, in order to make sure that they are available if a component is down.
5.2. Method Evaluation
The diagrams in Figures 3.3, 3.4, and 3.5 look complex, but are easy to use. They are a good starting point, and help in finding the main areas of concern when considering migrating to a cloud. The result of each diagram is realistic when used to analyze Comptel InstantLink. Some of the questions in the diagrams are slightly difficult to interpret, for example, when the application is deployed on premise for each customer. The biggest short coming of the method, however, is the third diagram, presented in Figure 3.5, which is used to evaluate the cloud compatibility of the current software architecture. It does not capture all potential issues. In the case of Comptel InstantLink, the result was obtained after considering whether the components are stateless or not. Answering no, takes the user to a result node in the flow diagram, and the user never goes through questions about, for example, the usage of the file system or lack of monitoring.
Comptel InstantLink is always delivered as a part of a system. However, the method was only used to analyze Comptel InstantLink, and the complete software suite was not taken into account. The method could also be used on a large system built from multiple products, but further analysis is needed to find out how useful the result would be. One option is to analyze every part of the system separately, and considering the whole system afterwards.
All in all, the method is easy to use and a good starting point for evaluating cloud com-patibility. It summarizes the potential problems of cloud environments presented in this
thesis, making them more transparent to the user. It is not, however, particularly suitable for complex and large enterprise systems.
5.3. Future Work
In this section we will take a look at further improvements to the method described in this thesis and at work required to move Comptel InstantLink towards a more cloud friendly architecture. Subsection 5.3.1. is about improvements for the method. Changes in the architecture and delivery process of Comptel InstantLink are presented in Subsections 5.3.2. and 5.3.3., respectively.
5.3.1. Improving the Cloud Compatibility Evaluation Method
The third diagram, presented in Figure 3.5, evaluating the software architecture could be improved by adding an arrow from each result node to the next question. This would be beneficial, since it is hard to create a suitable order for the questions. They are not de-pendent on each other, and many of them are equally important. The flow would change so that in case there is a potential problem, the user receives a tip from the nodes that currently are the result nodes, but continues answering through all the questions. An-other option is to handle the evaluation of architecture in a completely different way, for example, using a check list.
The flow diagrams are a good starting point and they could be used to create a web service for cloud compatibility evaluation. The service could present the questions to the user in the same order as in the flow diagrams. The returning arrows in the architecture diagram would allow the user to answer all questions. The service could display a summary for each questionnaire, which would make the result easier to understand. It would also be possible to list additional information and, for example, give advice for further reading.
5.3.2. Moving Towards Microservices
In order to achieve higher availability and performance, the components of Comptel In-stantLink should be more scalable. One way to achieve this is to gradually start moving
towards a microservice oriented architecture, in which the RPE, SMEs, and Task Engines are independent services. In order to do this, a service discovery mechanism should be implemented. A service registry is responsible for keeping track of running instances that send it a heartbeat, and in order to send a request, the client must first query a suitable instance from the service registry. A query to a service registry should also be made, when the request is sent to an SME, and when a task is sent to a Task Engine. Each com-ponent should be monitored in order to be able to recover from crashes. In a microser-vice architecture, each sermicroser-vice instance should have its own database. Different sermicroser-vices can even use different kinds of databases. The database should only contain information relevant to the service and otherwise information should be passed between services in messages. Refactoring the current highly optimized database implementation in Comptel InstantLink is a challenge.
Work is already underway to implement active-active availability for Comptel In-stantLink. No component should be a single point of failure, which means that the RPE and Network Model Manager should also be present in all running instances of Comptel InstantLink. The RPE handles request locking so that there are no parallel requests for a single subscriber, and it also uses an execution queue to handle requests in a priority order. They both are stored in memory by the RPE process and could not be stored to, for example, a database due to high performance requirements. In future versions of Comp-tel InstantLink, the RPE in one of the running instances will take the role of master and function similarly as before. The slave RPEs accept requests, but after backing them up in the database, they forward the request to the master RPE for lock handling. If the master RPE crashes, one of the slaves takes the role of the master. This recovery is faster than the previously supported active-passive setup. [43]
The upcoming architecture makes it possible to have multiple active instances of Comptel InstantLink. By adding a service registry, monitoring, and changing logging, the instances could be running with dynamic scaling as virtual machines in a private cloud. However, in the future the master RPE may become a bottleneck. Further changes have to be made in order to move locking away from the RPEs, so that at least all instances of Comptel InstantLink are equal. If every instance would be able to function independently, they
could better scale out in a cloud environment.
5.3.3. Changing the Delivery Process
Comptel InstantLink is tested using continuous integration and additional performance and system testing, but they are not yet part of the automated pipeline. Continuous deliv-ery could be reached by extending the automated test environments to test the whole de-liverable solution using real customer logics and configurations. Customer environments are highly customized and complex, which makes it difficult to find a representative case.
A version control system for the configuration files should be implemented, since this would also benefit delivery projects.
It should be easy to find which versions of each product were deployed together, and what were the configurations for each of them. When everything would be easily available, a new version could be configured by making necessary changes to the existing settings, and deployed using, for example, blue green deployment. A further improvement, that would make cloud deployments easier, is to implement a Comptel Instantlink specific virtual machine, which functions as a basis of every installation.