Server migration. It’s inevitable – particularly in my role. We recently helped one of our biggest and longest-standing clients with their migration away from bare metal servers and onto a cloud-based solution. I want to talk a little about what’s involved, why we do this, and the role an agency tech team can play in keeping their clients’ architecture up-to-date.
One of our oldest clients is a financial services company. We’ve worked with them for almost as long as Kyan has been in existence, which means we have a deep understanding of their needs and requirements. There is also a great level of trust between us. Alongside the day-to-day engineering and development work, we can advise them, help them and guide them with more ‘milestone’ pieces of work.
A fitting example is what became our biggest Ruby on Rails upgrade project ever. Check out our blog from 2018.
Moving away from metal
Bare metal servers. They do the job, but they're expensive, they’re a piece of hardware that has a physical location in a data centre, you need to double up for disaster recovery, and you've also got to keep on top of the server’s software to maintain security. With so many literal moving parts, we can find ourselves in situations where a power supply or a hard disk fails. In these cases, someone has to go to that machine, turn it off, fix it, and turn it back on again... and then hope that everything comes back okay. During that time, your site is down. Usually they do these things outside of hours, so it's not the end of the world, but it's still a frustrating process. With hosting having moved along significantly since we first started using these servers, it was a good time to move away from this model.
Docker, Google Cloud Platform and Kubernetes
We have been using Docker for a while now. We use it as a development environment because the benefits of containerisation are huge. Getting new team members up and running on projects is a lot easier because all dependencies are within a container, segregated from everything else. So we can run, for instance, the version of MySQL that we want to run or the version of Ruby that we want to run. If one app uses a slightly different version of Ruby or a slightly different technology, we can do so without it affecting anything else. It's an amazing tool, and we figured, “Well, if we're already using Docker in development, then why not use that same technology in production?”
After speaking to our hosting provider, we decided that the best solution was Google's Cloud Platform with Kubernetes as our infrastructure. This means we can use near identical container images in development and production, and we can test the whole thing in an environment that's safe. An advantage of Kubernetes is its containerisation – containers are ephemeral, so if they die, you can simply bring them back to life again. Although it's a stateful application, we can essentially run it as a stateless application so when one container dies, we replace it with another one and it will self-manage. Thanks to this, it’s easier to scale. We can take a particular app and if we feel there's one thing that app needs more than another, we can adjust that. It also opens us up to other benefits such as continuous deployment and review apps.
The role of the tech team
This kind of upgrade project is always a team effort. This is because there are many processes involved in the overall upgrade, such as upgrading apps, testing, and making sure we are using the latest versions of things like Ruby. We also had to upgrade the database because we were using an older version on the metal servers. The Google Cloud SQL instance was a higher version, so we had to make a big change there, and that was a particularly big team effort. We also had to collaborate with our hosting partner to create the various Kubernetes and Gcloud manifest files that we needed in order to successfully bring up the applications and dependent services.
The role of the agency relationship
Our relationship with our client is on a technical level, but this isn’t always the case. Many of our client relationships require us to consult and advise on the technologies that we expect to use on a project, and to do so in a way that we can all understand and talk about together. In this particular situation, our contacts within the business are technical and they have a good understanding of requirements and architecture around servers and migration.
That said, we still took a proactive approach in this situation – presenting our idea of moving to a cloud-based solution. That was something that they hadn't done before, so it was fairly new territory for them. We presented our proposal with our reasoning, and they were open to it, understanding the value in being more secure and not having to worry about physical machines that can potentially go wrong.
The role of a Head of Engineering
In my role particularly, I’ll be aware of when a particular server or service is coming to the end of its life, and at that point, case and client dependent, I can make one of two decisions: Do we replace and continue like-for-like? Or do we use this window to think about what we can do to improve the whole infrastructure?
It’s these big conversations that I feel agency tech teams should be having with their clients. Clients will challenge us with their briefs, and we welcome those opportunities. In return, we feel it’s our role to not only offer them world-class engineering and development, but to take a wider, more strategic view of how they are running their business, their technology and their services.
Next time you’re at this crossroads, embrace it. To me, it’s one of the most exciting parts of the job.
We are Kyan, a technology agency powered by people.
Previously from our tech team:
Why we love headless content management by Dave Cartledge
Building our own office Jukebox using Mopidy, NodeJS and React by Duncan Robertson
Why do we love Next.js so much? by Dave Quilter
Things I wish I’d known before I started with React Native by Carmen Lopez Guerra
How Ruby if statements can help you write better code by Dave Cocks
