[imauld]

> I feel like it requires a full-time devops engineer to create and manage all of it.

It does.

Kubernetes is a great piece of tech but it is pretty complicated and does add a fair amount of overhead on top of whatever operational concerns you application already has. If you don't have anyone that knows how to build and manage a cluster going to production with it would be extremely risky IMO.

I would recommend trying GKE, Google's managed k8s service, in staging/dev before even considering it as a serious path forward. If you are married to AWS or just don't want to use GCP then kops would be your best bet. I have friends working with EKS, AWS' managed k8s service, and it doesn't sound anywhere near as ready as GKE or as flexible as doing it yourself, frankly it sounds like a real pain. I haven't used k8s on Azure but I have heard that it's pretty good.

I also don't generally recommend deploying a new application as decomposed services either. Unless you have done this a bunch of time it will probably save you a bunch of time to just do it as a monolith and deploy it to standard cloud VM's or on-prem servers. Also be aware that Docker and by extension k8s are not the best way to run stateful applications. It can be done but it is definitely more work to get a k8s based DB working the same way as a non-k8s DB in terms of data retention. I imagine a complex application will need some kind of data store so even if you go with k8s you may still end up with non-k8s instances for you data.

k8s is great but it's overhead con easily outweigh it's benefits if you don't have a someone who can manage it. Start simple if you can and work from there.