Our Cloud (Native) Migration Journey

Back to all posts Zurück zur Übersicht Tilbage til oversigten
Our Cloud (Native) Migration Journey

In a few short weeks, we will complete the lift & shift part of our Cloud Migration. This is an opportune time to reflect on how we approach the cloud migration and what lies ahead. We’ll try not to delve too deep into the underlying tech, but expect buzzword-galore! And maybe even some brand new tech terms!

Lift & shift

Like many others who move to the public cloud, our journey starts with a ‘Lift & Shift’ operation. This is where you move the application and its data to the cloud, but do not re-design or refactor the application. This is a tried and true method, and you gain many of the benefits of the public cloud with minimal investment.

We are, however, taking it a bit further, because we’re also re-platforming, since we’re moving from FreeBSD Jails (a concept similar to containers, but for the FreeBSD operating system), to Docker Containers.

Public cloud

Throughout most of ONLINECITY.IO’s history, we have been running on both bare-metal servers, co-located in premium Danish data centres, and on Amazon Web Services (AWS). We have seen this mix of cloud and metal as a healthy compromise between performance and cost.

Technology is moving at an incredible pace and when, some months ago, we re-evaluated this decision, we chose to go ‘full’ public cloud, gradually cutting the last ties to physical hardware. Simply put the cloud is at a place now where we can get better performance at a lower cost for our use cases.

Our cloud of choice is Google Cloud Platform (GCP), which offers the very best performance, especially on networking, which is vital for GatewayAPI. Google has more than 100 locations and a private network that spans the globe. Their ‘premium-tier networking’ improves our connectivity to both customers and telecoms.

Besides performance and connectivity Google Cloud is a leader in the field of security, with excellent technologies such as zero trust networks and encryption at rest by default.

When it comes to compliance and GDPR, Google is very well covered. We will be processing data in their Europe-West1 region in Belgium, not too far from Brussels, the home to the European Parliament HQ.

Cloud Native

We won’t stop at public cloud, we aim to make GatewayAPI and our other services fully Cloud Native. Cloud Native is a massive movement by big and small tech, that is revolutionizing the software industry.

Cloud Native is defined as:

  • Cloud Native technologies empower organisations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.
  • These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes, frequently and predictably, with minimal toil.

GatewayAPI has been built from the ground up, with a microservice architecture – only back when we started, the microservice term was not yet ‘in vogue’. But we were lagging behind on other technologies, especially containers and automation. So as part of the cloud migration, we are adopting one of the most influential pieces of Cloud Native tech; Kubernetes.

Next steps

Our Cloud Native Trail is just beginning. There is a lot of the Cloud Native Landscape we have yet to experience. We’ll soon be taking a monumental step forward, and we’re thrilled to share that journey with you. Thank you for reading.

Cover image by Alexander Kliem.