SkillLane’s cloud architecture: An overview
Hi! This is the first post on our publication.
Actually, there is a lot of interesting stuffs to share but today’s topic will be our infrastructure and the future of our infrastructure.
If you are the reader from Thailand. You may probably have noticed somewhere that we (Skilllane) recently launched our corporate platform targeting at organisations nationwide. 20,000 initial users were registered for Kasikorn Bank PLC. in April 2018.
The launch of the corporate platform causes a lot of changes in our IT (Cloud) infrastructure.
Why?
This is because our original platform (B2C) is developed in Ruby on Rails which is quite common nowadays because it is really similar to working with the famous LAMP stack. Yes, We have a database, some instances to host our Ruby on Rails application, a load balancer to point to our servers, and some other fancy tools like Redis or Sidekiq for scheduled jobs.
Doing this is very easy with AWS Elastic Beanstalk. All we did was simply spinning up the load balance & security group along with the load balancer using Elastic Load Balancer and the database using AWS RDS.
Please note that all of the above steps were done in a few clicks using Elastic Beanstalk and AWS RDS. Then we just uploaded our zip file to deploy our application.
The discussion to evolve!
There had been a long discussion before the development phase began in late 2017 on whether or not we should use Ruby on Rails or JavaScript stack.
At this point I have to say that the decision to choose modern JavaScript stack over Ruby on Rails evolves everything we have been doing. From MVC to Single Page Application along with many modern toolset we utilise. It is full of challenges and of course, problems to solve.
We decided to be Docker compatible which means most of our applications and services need to be compatible with Docker environment. They should be able to be built and pushed to the registry as containers.
One of the most crucial consideration of this is the migration to Kubernetes and to be really Cloud Native because the ROI decreases as we keep using AWS with all of our platforms.
Working on the new platform
With React and the JavaScript stack. We have added a lot of stuffs to our cloud infrastructure and spend time working on Docker environment. I created a number of droplets on DigitalOcean to host development tools like Jenkins for CI/CD, Portainer to monitor our dockerised applications, and some of the database instances. The simplified picture below may describe our current architecture.
As you can see, we still heavily utilise AWS because of the time factor though there’s a place to plan for the migration, we need to get up and running as fast as possible. Thus, Elastic Beanstalk is still used to host the React SPA applications. AWS Lambda with API Gateway is a good choice for serving our APIs built with Node.js. We use the famous Serverless framework to integrate with AWS Lambda which is really easy and robust.
However, for some reasons, we still deploy some of the APIs on on-premise VMs as containers and monitored by Portainer. MongoDB cluster is still a self-managed one.
What would be discussed next?
This part is just a brief overview of our architecture. In the later posts, we will discuss about the current and the future architectures in details.
