Stories from the trenches: Migrating our cloud provider

You might be asking yourself why would you migrate in the first place? I will answer that in a bit, first let’s talk briefly about the cloud.

Since the advent of the "cloud" and with the rise of multiple players on this space (Azure, Google Cloud, AWS), tools have made their appearance too. Tooling is indispensable for automation and automation is fundamental for scaling. Tooling will also allow you to do something else: avoiding vendor lock in in favor of a more flexible concept: cost of migration. You can apply this very same concept when you are not as advanced or working with a minor or mid-sized player in the cloud providers arena, and give you the possibility to move to another provider that better suits your needs.

Why would you migrate? There could be several reasons: cost saving, service level and in our case, lack of tooling.

In this talk I’ll cover a one and a half year journey at Packlink, where we migrated from cloud provider and in the way went from:

- Not knowing how many servers were running
- Snowflake servers everywhere
- No automation
- Multiple monitoring tools and no real view of what was going on

To:

- Exact count of resources
- All the infrastructure mapped in Ansible roles
- Fully automated instances creation (Hashicorp’s Terraform) and provisioning (Ansible)
- Trusted monitoring and alerts (Uchiwa, New Relic, Slack)
- Infrastructure as code mindset

Letting you know about the problems we found, solutions implemented and tradeoffs took.

Comments

Comments are closed.