A lot of software organizations are running on legacy cloud or on-prem infrastructure, wondering if now is the right time to move towards Kubernetes. But when is the right time to upgrade?
Prior to joining Fairwinds, I co-founded a startup. After a few weeks of hacking on an MVP, I needed to spin up a server to host it, so I turned to AWS, and was amazed at how easy it was to get started with a few EC2 instances. But soon after I made that small decision, it began to snowball into an alphabet-soup of Amazon products. Within months I was storing files in S3, running databases in RDS, and using CodeDeploy to cut releases. I was leaning on AWS for autoscaling, load-balancing, certificate management, and more.
Not all of these products are best-in-class, but AWS tooling plays nicely together, so it quickly became my default for every bit of functionality I needed. It wasn’t until I joined Fairwinds and started hosting software on Kubernetes that I realized there was a better way.
Of course, your status quo will be unique to you. Whether you’re on AWS, GCP, Azure, or are running your own data centers, you’ve probably built a set of skills, habits, and processes that are tuned to that setup. If you’re thinking of making the move to a new cloud provider or modernizing your infrastructure, here are some considerations:
The more you work with a cloud provider’s proprietary concepts and APIs, the more you’ll be shoehorned into their ways of doing things. Vendor lock-in can be deadly - if functionality is deprecated, the price increases, or your needs evolve, it can take months or years to untangle yourself and move to a new provider.
When you opt to go in one direction like EC2, Google Compute Engine, or Azure VMs, you will naturally adopt that cloud vendor’s way of doing things. In order to stay future proof, it’s important to consider the larger ecosystem of tooling you’re buying into. Take a look at what open source and proprietary software you’ll be able to layer on top of your cloud provider as you grow.
Unfortunately, Amazon and other cloud providers tend to keep their public roadmaps at a high-level, so it can be hard to tell where the software will be in 1-3 years. Priorities are set by what’s important to their business, which may or may not align with your own needs. So be sure to look at whatever plans they’ve published, and see if you can get a sense for how much they’re investing in key areas. You’ll also want to look at their track record of following through, and where they may have left users in the lurch with deprecations or abandoned services.
These considerations change when you build your infrastructure on an open source platform like Kubernetes.
Kubernetes is an open source solution that works on top of any of the major cloud providers, and can even be used on-prem inside your own data centers. With Kubernetes, a lift-and-shift from one provider to another (say, for better pricing, functionality, or service guarantees) becomes an order of magnitude easier. With Kubernetes, you get a truly vendor-agnostic platform.
When you choose Kubernetes, it comes with a huge ecosystem of open source tooling and vendors. Kubernetes has been adopted by organizations of all shapes and sizes, so there’s a wealth of knowledge, best practices, and extensions to suit any organization’s needs. And the open source ethos means that the most critical components are all free to use and modify.
Kubernetes keeps an open roadmap, and anyone can join the discussion by opening an issue on GitHub. With new releases available every three months, you can be sure that bugs are being squashed and critical functionality is being added. And being informed by users both big and small yields a better evolution of the technology - the community decides together how Kubernetes needs to improve.
Even if you see the benefits of Kubernetes, you still need to consider the cost of migrating.
There’s always a tradeoff between staying with infrastructure that works for now, versus paying off some technical debt and moving to a more future-proof setup. It will take a lot of work to make the transition, and the impact on your application performance, cloud costs, and engineering morale can be hard to quantify.
But it’s important to realize that when you’re stuck on one vendor or proprietary standard, you’re likely accumulating technical debt (check out our article on migrating off Heroku). Getting your infrastructure working on open standards should be a priority for any organization planning to grow quickly.
So as you migrate, try to focus on open standards like Kubernetes. Your team will still need to learn some new skills, but you’ll be safeguarding your infrastructure for the future.
