In a few short weeks, we will complete the lift & shift part of our Cloud Migration, so this is an opportune time to reflect on how we approach the cloud migration and what lies ahead. I’ll try not to delve too deep into the underlying tech, but expect buzzword galore, some of which you may, or may not have heard before.
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.
Through most of ONLINECITY.IO’s history, we have been running on both bare-metal servers co-located in premium Danish data centers and in 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 points of presence and a private network that spans the globe. Their premium tier networking improves our connectivity to both customers and telecoms.
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, home to the European Parliament HQ.
We won’t stop at public cloud, but 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 then the microservice term was not yet in vogue. But we lack(ed) 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.
Kubernetes solves the problem of container orchestration, that is to say, how do you manage, deploy & scale hundreds if not thousands of containers. I think Kubernetes has been the missing piece since Docker emerged in 2013. A piece that when you get it, everything just clicks, and the whole elevates to a higher plane.
Kubernetes is a massive technology enabler, bringing features that would have otherwise been extremely hard to figure out for the masses. Features such as self-healing, automated deployments and automatic scaling. Kubernetes itself is a often described as “a platform for platforms”, and often a (central) piece to a larger puzzle. It’s the perfect platform on which we build our platforms.
Today most public cloud providers offer managed Kubernetes as part of their cloud offering, but this is especially true for Google, who are the original creators of Kubernetes.
Kubernetes will enable us to iterate faster, scale further, and improve reliability.
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 I’m thrilled to be part of the journey, and to share that journey with you. If you made it this far, thank you for reading.
Cover image by Alexander Kliem.
Subscribe via RSS