ShipMonk is one of the fastest growing startups in the world of logistics. It brings new procedures, speed, reliability and availability using state-of-the-art technologies. However, this was not always the case, and especially in the beginning there were often problems not only with availability, but also with application updates. As the company grew, the original set up stood in the way of development.
Original setup
ShipMonk had 3 production servers and 4 development servers, which were located at Vultr and Digital Ocean. Due to the monolithic nature of the application, the main production server was one of the largest instances in Digital Ocean.
This set up:
- did not allow scaling, performance could only be increased by adding an instance, which was not only uneconomical but also impossible in the future
- it was not possible to change instances dynamically, and this was costly
- updates were complicated and required short application downtime
None of the providers at that time had separate data centers that could be easily switched to, so our disaster recovery plan included copying and migrating to the other provider. We opted for AWS.
Migration
The migration was preceded by the modification of the application to the microservice. Then in AWS we created the whole environment in Terraform and used Kubernetes for migration.We continued to monitor Kubernetes and helped tune it up and debug it. We prepared a CI / CD pipeline.
Result
- outage resistance – Shipmonk now has 3 separate data centers
- scales automatically – performance increases or decreases as needed
- background updates – updates are invisible and constant
- unlimited deployment of new versions – thanks to the CI / CD pipeline settings, it is possible to continuously test and deploy new versions
With this setting, ShipMonk can further develop, expand its services and application. It is stable because its performance dynamically adapts to current interest of users.
| BEFORE | NOW |
| 3 production servers |  3 separate data centres |
| 4 development servers | dynamic scaling |
| 0 scaling | no outages |
| performance could only be increased by adding an instance | AWS |
| high cost | updates without application downtime |
| application downtime due to updates | cost reduction |
