I'm working at a company with two independent SaaS products and a third one in development. We currently run our first product in Docker containers on cloud instances, with some help from ploi and shell scripts, but it feels a bit haphazard. Our second product is on a Kubernetes cluster managed by an external DevOps team, which has been a frustrating experience. Changes can take ages, and I've resorted to using kubectl and GitOps for some of my own changes, although those approvals also take forever.
We want to standardize our infrastructure for all products, and I'm leaning towards Kubernetes since I'm somewhat familiar with it, having run private clusters and completed a course. However, I realize jumping into this on a company level might not be the best idea without proper support. Hiring a dedicated DevOps person isn't feasible with our current workload.
I'm considering a managed Kubernetes solution where we have a partner for support, which seems like a way to leverage Kubernetes features while relieving some operational burdens. But I'm also curious if this is truly the right path for us or if we might be better off looking into simpler solutions like managed services instead.
8 Answers
Honestly, it sounds like you're less questioning the need for Kubernetes and more looking for consistency and control. Kubernetes can help with that, but only if you're the one managing it. Your frustrations seem more tied to the slow external DevOps process than Kubernetes itself. A managed K8s where you have control of your configurations seems reasonable. But consider if your third product needs K8s right from the start—sometimes simpler solutions are better during the phase you're in.
It seems like you're considering K8s just for the sake of it, even though it might not be the best fit without the right internal capabilities. Take a look at simpler alternatives like ECS or whatever is available from your chosen cloud provider, especially given your concerns.
Kubernetes can be a solid choice, but I recommend bringing in a consultant who can help design the architecture properly. This way you can avoid common pitfalls when transitioning to K8s.
Standardizing operations is smart, especially with a third product on the horizon. Just keep in mind, you'll need skilled expertise to make this work smoothly—using what you have now as a cautionary tale.
If you're planning to take things in-house, don't underestimate the amount of DevOps work involved. You might quickly find that you'll need a dedicated hire. It's usually this kind of thinking that got you into relying on poor external solutions in the first place.
Make sure you know where you'll run this—on-prem or with a cloud provider. Kubernetes can add operational overhead without a dedicated team to manage it. Managed options like EKS or GKE are great, but based on your description, I might lean towards something even simpler. AWS ECS could be a better fit, especially since it reduces management needs and can simply run your containers effectively, even if you take a break for a while. We've switched several teams to ECS, and they've loved the experience compared to K8s.
Kubernetes can offer flexibility without being locked into a single provider, and it allows for easy migration across different K8s environments. So, if you're a smaller company without dedicated K8s staff, a managed solution seems like the right call.
Definitely go for a managed Kubernetes service, like AWS EKS or GKE, depending on your cloud preference. Rolling out your own cluster isn't worth the trouble or cost. A setup like EKS with auto features and Argo can really streamline things for you without too much hands-on management, assuming you don't need too many custom configurations.
Just a heads up! AWS options can be a bit tricky. Make sure you're looking at EKS Fargate instead of EKS or ECS Fargate. EKS Fargate runs containers on a managed cluster, which could save you a lot of headaches.
Also, keep in mind that with multiple products, you may need to think about specific configurations, especially if you're using shared compute options. It might not be one-size-fits-all.
We're set to run in the cloud. We're currently avoiding US providers due to legal constraints, so we'll need to focus on EU-based options.