From In-house Data Center to Public Cloud
ASI has the ambition to bring the best safety solution for our customers in aviation industry. In aviation industry, there are two main requirements before a solution is considered as good: absolute secure and the ability to scale up the services fast (we will discuss more about these in the case study section below).
Our partner, Opscom company in Norway, has 15 years of experience in creating the software solution for aviation and high profile customers (such as police department in Norway). Therefore, security about information for us and Opscom are an important criteria. As a result, Opscom has been hosting all of their projects in their in-house server. However, there are many drawbacks with the in-house server. One of the drawbacks is that it will slow the collaboration between ASI and Opscom in terms of delivering the product for our clients. In order to help you (the readers) to have the better understand about the drawbacks of in-house server as well as our progress in migrating to public cloud like AWS or Google Cloud, let’s consider a case study.
I. Case study
We will choose AA (we decide not to indicate our customer’s identity here)— our first custom at ASI as a case study. AA is one of the world leading schools in training the students to become experienced pilots after they graduate. For a long time, the management system of AA relies on Microsoft Excel (MS Excel). The management system is used from managing the students and instructors’ profile to class schedules. Clearly, MS Excel is not an efficient solution for this system, especially when AA wants to open more classes or accepts more students. In addition, with MS Excel, they are limited in using data analysis to improve their courses.
II. What does In-house Server offer us?
The advantage of the in-house server is the full ability to control server from the version of the software (version for ReactJS, or version for MySQL, etc.). In addition, we also have the freedom to config the power for our server, i.e. how strong the computer on the server.
On the other hand, maintaining the in-house server requires lots of efforts. There are two ways we can view this problems:
- The hardware for our services
- The software that we use to protect the server
With the first problem, we can use the example from the case study above to illustrate this problem. When students at AA register for classes, the traffics to their website will increase compared to when students are in summer break. In order to handle this traffics, we have to scale up by adding more hardware (or computer) for the in-house server to prevent crashing problem for AA website. This causes another problem is that what will we do with the extra hardware during the summer?
The second problem is to create the software (firewall) to protect the server. Creating the firewall is a difficult problem. Firstly, we have to dedicate a team to write the test cases for the server everyday. Moreover, they also have to manually turn on or turn off the instances when that part of server is down. Another drawback here is that in the future, if ASI needs to deliver product to different customers not AA. The problem here is how to maintain the applications among customers so that when one application is down, it does not effect the rest. On top of that, dealing with different inputs and outputs of applications from different customers also challenges.
With these two problems, they lead us to decide to migrate from the in-house server to public cloud solution. The next two parts, we will layout our current progress.
III. Why do we need docker?
Docker is a great tool for us to ship our code across different platforms without tailoring the configuration for the new environment. We can also boost the development process by centralizing the container, and then each developer at our team can develop the application without worrying about the dependencies. In addition, the philosophy is platform-as-a-service, which means each part of the code can be viewed as an individual service. This is really useful in our cases for two reasons.
The first reason is that we can roll each service to the server at the time instead of the whole application at the same time. Let’s take a look at the picture below.
In the picture, the example project is developed in ReactJS with Redux. If we apply this to our case study, the client-side should contain two things: components for users (students or instructors) and for admin (e.g. operational staffs). Traditionally, we will deploy the whole application to the cloud which is called a monolithic application. The problem with this is that when we update a small part of the codebase above, and it breaks. The whole application will break. To avoid this, we can use Docker to split the client-components into two different services, for example, service for students and instructors and service for admin. Of course, our team is working really hard to design the way to containerize the application in the most efficient way.
The second reason is that by splitting the application into smaller services, we can choose to roll or deploy which part of the code to the cloud. For example, if we want to deploy new feature for admin, we can build the admin container again and deploy that container to the cloud only. As we can see, with this deployment, it save us lots of time to deliver new features, and it also save us time when we need to roll back to the previous version of the container. We will discuss more details about Docker technology in a different blog.
IV. Why Kubernetes is necessary?
In the last couple years, Kubernetes becomes the buzzword in the tech world. The main usage of Kubernetes (in our case) is to manage the containers that are deployed to the cloud. This usage is easy but why do we need Kubernetes at all? Remember the problem with seasonal services? Yes, when students come back and start to register for courses, we need to scale up our services in order to handle the huge amount of traffics into our customers’ service, or maybe we can scale down their services in the case the students go home for their breaks.
All problems have never been easier with Kubernetes. We only need to declare the YAML file and the rest will be taken care by Kubernetes to spin up new instance or closed an instance. In addition, the power of Kubernetes also comes from the way it manages the down instance. For example, let’s say two pods down, it will automatically spin up two new pods.
Another advantage of Kubernetes is the easy management tool for rolling out the features. Let’s say our customers want to improve their UI/UX. After designing the new user interface, we can command Kubernetes to role out the new UI on certain pods and the rest of the pods will be remained the same. We will discuss more about the benefits of Kubernetes in another blog.
V. Conclusion
Although Docker and Kubernetes bring amazing benefits for us, in order to completely migrate our applications and services to public cloud, it will take us a long time to achieve. The reason is because we want to deliver the best services to our customers and their customers. If you find this project is interested, we have good news: we are hiring Fullstack Engineer. You can check it out here
If you have any questions, you can response to this blog, or contact us through: asicompany.vn@gmail.com
