They say the shoemaker’s children go barefoot but not this time. For today, I’ve decided to prepare a behind-the-scenes look at one of our projects and tell you why we’ve decided to go for cloud migration with our Nsflow platform – and how it all went.
This article is for you especially if:
- you’re facing the on-premise vs cloud choice
- you’ve already decided to move to the cloud and are wondering how to do cloud migration (and when is a good time to do it)
- you’re on the lookout for particular cloud solutions and providers
I’m gonna provide you with insight into our cloud migration project and decision-making process which hopefully will help you to make your own choices. Was it a cloud migration success story? Keep on reading!
What is cloud migration?
Before we head out, I recommend you check out our latest article on the cloud solutions and benefits, that we prepared with Piotr to get you started. You’ll find out there what a public cloud is, its benefits, what are the most popular cloud providers, and how to choose one. A highly recommended read!
Cloud migration – the definition
In a broad sense, cloud migration is the process of moving all company digital assets, such as applications, systems, websites, data centers, from on-premise physical servers to the cloud-based infrastructure. The cloud is supplied by cloud service providers, the most popular ones are Amazon Web Services (AWS), Microsoft Azure, and Google Cloud. The migration can also apply to one or a few components or systems – and that’s exactly the case we wanted to tell you about.
The reasons behind moving to the cloud
Although Polish companies use Nsflow more and more eagerly, our core and target market has always been abroad. The time migration was taking place, we’re running pilot projects for companies located in France and Singapore (which later on extended to the UK, Japan, and Germany as well).
Our old infrastructure relied on a VPS server with all software components installed on it – Node-based web app, RabbitMQ, PostgreSQL database, and so on. The system was dockerized, we used Rancher for container orchestration and had some basic monitoring. It all might have been enough for development but not for production and pilot projects.
What is more, our infrastructure wasn’t cost-optimized. Let’s face it, for the most part, we were paying for heating the air. But still, to be able to serve customers from the manufacturing industry, we had to increase our resources, which would result in even higher overprovisioning. When there were more and more customers, pilots, and trial periods, we decided that it was time to stop clinging to our VPS and scaling it just in case.
That being said, the cloud was a natural direction. We planned to intensify our marketing and sales activities, and needed to be ready for new customers. This meant setting up the brand-new development, staging, and production environments in the cloud.
Our top reasons to move from on-premise to the cloud have been:
- to ensure high scalability – scale up when the traffic is high, scale down when it is lower
- to ensure availability and stability – the system working smoothly even when the traffic is heavier than usual
- to use resources efficiently – avoid overprovisioning and unnecessary costs
- reliable monitoring to react instantly to any unexpected events and support requests
- to be able to implement platform improvements and new versions quickly and efficiently, which translates into business development in general
All above to ensure the best quality of our services, get ready for rapid growth and take customer support and satisfaction to the highest level.
Our process of cloud migration – explained step by step
NeroSYS have been working with the cloud (AWS in particular) for 11 years now, deploying custom web applications built for clients located all over the world. To walk the walk, we’ve decided to move our Nsflow platform for industrial process optimization to the cloud as well.
AWS migration
You might be wondering why we have chosen AWS and not Azure cloud migration or Google cloud migration. As I mentioned above, we had already worked with Amazon Web Services which we felt got us a head start. Thus we’ve decided to migrate all components of our Nsflow application to the AWS cloud. But our first-hand experience wasn’t the only reason to choose this particular provider. We value Amazon for new features released quickly, often before the competition, their accelerating programs, and a lot of ready-made cloud products offered (such as storage, analytics, databases, and developer tools).
Although we’ve got our team of DevOps engineers, at that time they were fully occupied so we had decided to hire an external DevOps agency. Some project requirements, as it always is, changed in the meantime – and they were highly responsive. Our engineers took over the project later on. The project resulted in close and long-term cooperation (cheers to Hostersi!).
Components migrated
As mentioned before, we’ve moved all platform components to the cloud. These were:
- application server
- web applications (Workflow Creator, Admin and Remote Support panel)
- communication hub
- object storage
- monitoring and logging services
- integration services
- webRTC server
- media server/streaming server,
- computer vision and analytical algorithms
Three environments
From the very beginning, we’ve created all three types of environments:
- development environment – for development and internal test purposes
- staging environment – for presentations, pilot projects, and client-side testing
- production environment – for production customers
Continuous integration and delivery
The migration has been conducted with a continuous integration/continuous delivery (CI/CD) approach. It wasn’t a novelty because we use CI/CD in every project for our clients. Don’t get me wrong though, CI/CD isn’t a cloud migration methodology or its direct result. We’ve just used the occasion to design and create CI/CD processes while rooting around in the infrastructure. Still, I believe it’s worth mentioning in this place.
Its main advantage is that it speeds up development, reducing the number of development plus test iterations that every change/new feature must go through to be delivered bug-free.
Without CI/CD
A developer writes code, then someone verifies it manually, then publishes it for testing, and a tester examines it again. If they find bugs, they report it and the process goes all over again. Moreover, many such iterations can take place.
With CI/CD
Not only does the code “publish itself” automatically to testing, but also the system uses a variety of procedures to analyze it beforehand – performs static code analysis, assesses code quality and compliance with design standards, runs unit and integration tests such as Selenium or Cypress (if they exist). If everything goes well, it’s the system that decides that the code is suitable for publishing in the test environment. Only then, the changes are handed to testers. This way, they have less work and it’s less probable that the changes will go back to testers – thus considerably fewer iterations.
This more efficient product development cycle reduces time to market, raises product quality, and, in the long run, improves customer experience. Lastly, what’s important for us, it requires less DevOps team involvement. Developers can take on most of the tasks.
Services and solutions we used:
- Amazon Elastic Container Service for Kubernetes (Amazon Elastic Kubernetes – Service, Amazon EKS) – to run and scale apps
- Amazon Route 53 – cloud DNS web service
- Amazon CloudWatch – monitoring service to collect and correlate data from all AWS resources
- Amazon RDS (PostgreSQL DBs) – a relational database service to set up and scale relational databases
- Elastic Load Balancers (ELB) – for traffic distribution across virtual appliances
- AWS CloudFront CDN – to reduce the content loading time, regardless of the geographical location
- Infrastructure as a Cloud (IaC) with Terraform – to build and manage the infrastructure in a safe and repeatable way
- CI/CD pipelines, which integrate with AWS – monitoring and automation to improve development and deployment
How long does cloud migration take?
The whole process of moving the Nsflow platform to the cloud took us six months. The longest part was designing a new infrastructure that would meet our long-term needs, because we had tried to anticipate as many factors as possible to save time and effort later on. Could it have taken less time? If the requirements didn’t change in the meantime, then yes, probably. But have you heard about such projects? 😉
PS And since we’re Agile, we’re not afraid of changing requirements and circumstances.
The cloud migration results in numbers
Since the successful migration of Nsflow to AWS:
- We’ve reduced the time to get our clients up and running with the platform from 8 to less than 2 hours. It’s 75% time savings!
- Thanks to cloud auto-scaling and the elimination of overprovisioning, we’ve managed to reduce costs significantly. We improved the average use of our resources from 15% to 80%.
- We’ve reduced the average support-request-resolving time from 3 to 1:20 hours.
- Thanks to CI/CD we’ve reduced the number of development-testing iterations and now our team delivers 10 more story points each sprint (42 vs 32), which is over 30% more.
Apart from the above, the cloud benefits we experience are:
- cost reduction – autoscaling and adjusting the computing power, paying for what we use only
- ability to create test environments more easily, with fewer limitations
- high availability thanks to redundancy and production resources allocation in at least two independent data centers
- introducing platform improvements has become easier and developing innovations less risky (particularly these related to artificial intelligence; we’ve added a visual place recognition module recently based on computer vision and deep learning)
- utilizing out-of-the-box infrastructure components, we’re able to prototype and experiment quickly and less costly
- all infrastructure components separation – each service has its own resources or takes the form of a native cloud service, which allowed us to eliminate a single point of failure (SPOF)
- providing first-rate services all over the world thanks to mirroring servers located in different datacenters. It applies particularly to heavy content our clients upload into the platform creating work instructions and training.
… so we’re ready for global expansion.
Please treat the above article as an introduction to moving to the cloud based on our example. But remember, every project is different and migration may be carried out differently. We’re always eager to help or advise. What would you say about a one-hour free consultation with our cloud expert?
