Migrating Starred to AWS
The first talks of migrating to Amazon started early in June. Although we had no big problems yet, we knew we would run into scalability issues in the long run. Our customers and especially their customers should not feel they're being limited by our systems' performance. Also we take security very seriously, and we did not feel the goals we set were within reach with our current infrastructure. With the perks Amazon offers like load balancing, security, scalability etc. we decided to start a migration project to AWS although we were already operating "in the cloud". To make our infrastructure without any vendor lock in we decided to Dockerise our whole stack in one go as well to support plus it supports our future plans to make our entire platform based on a microservice architecture.
"But what will be different for me as a customer?" I hear you ask. Well, functionally not much. A lot of code refactoring has been going on to make our background services run on docker for example to give us flexibility and scalability, but those will not be visible to the end user. And if we've done our job right it should stay that way when the volumes we process grows. Besides that, we hired an external company to do an ongoing security audit to our system to be sure all customer data is safe. Again, mostly unnoticeable for the end client, but a very important hurdle to take.In this blog post series we will try to give you an insight at the good, the bad and the ugly of migrating Starred.com to AWS. And to start off with the good immediately..
🚀 we officially migrated at the 11th of April! 🚀As you can tell by the time lag between initial brainstormed and actually delivering the migration, it was a big and daunting project. Now almost two weeks post-migration the dust clouds have settled a bit and we are happy to share which issues we had to overcome on software, operations, planning and eventually flipping the switch.
The topics we will discuss in this series are the following:
Roadblocks before even starting
Covering a couple of difficulties we had to tackle before even starting the migration at all.
Docker and its swarm
Docker swarm is a cool new and shiny technology which makes us able to scale and have separation of our core processes. Of course it has some aspects we had to work around because not many companies use it in production yet.
Honey and Beekeeper
Automation is key. This is all about a tool we've written to make our deployments a very smooth process.
No downtime please..
And then the point of no return is coming closer. Obviously we want our end users to be unaware of the migration, so how are we going to do that without any downtime?
Now the migration is all done, are we happy with the end result?
We will put those posts online in the coming week(s) so stay tuned!
Want to receive the new blogs in your inbox? Sign up here