Absolutely disagree, it's really not that hard and it provides a consistent way of doing everything.
Starting with something "simpler" then causes interuption to switch to completely different things.
The choice should more involve the skills of initial team than the size of company/budget/project.
Also starting with microsevices is much easier than splitting a monolith later.
Now I've heavily used K8s a lot I'm wishing I got into it sooner but everyone kept incorrectly saying it's over complex when it really isn't!
Well, i disagree with you, the infrastructure behind k8s is so complicated to deploy and administrate, much more complicated on-premise than on Cloud.
Where is the difference? Where is the easier? When the dev guy need to make a deployment of an app or microservice don't need to ask the infrastructure team for servers, storage and or anything... Just make a deployment on the kubernetes cluster and that's all.
But let me say you that the infrastructure is there, with higher level of complexity.
This is especially true when you over engineer K8s
Eg. Using it for the DB, persistent disks everywhere etc, all things that could be offloaded to 3rd party cloud services
Well, deploying stateless microservices will not dissapear all infrastructure required to run k8s.
The discussion is about k8s does not require complex infrastructure...
That applies to standard tools like databases, not specific ones for your use-case specially if you are building lot of workers and doing cpu heavy computation tasks. i.e not every app is CRUD like.
"Also starting with microsevices is much easier than splitting a monolith later."
It's all about picking the tradeoffs you want to deal with. Personally, I'll take "splitting up the monolith" over "re-architecting a bunch of incorrectly scoped microsercvices" any day of the week.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Absolutely disagree, it's really not that hard and it provides a consistent way of doing everything.
Starting with something "simpler" then causes interuption to switch to completely different things.
The choice should more involve the skills of initial team than the size of company/budget/project.
Also starting with microsevices is much easier than splitting a monolith later.
Now I've heavily used K8s a lot I'm wishing I got into it sooner but everyone kept incorrectly saying it's over complex when it really isn't!
I agree Craig. K8s makes it so much easier for small projects because you don't have to worry about infrastructure as much. It makes CI much easier.
Well, i disagree with you, the infrastructure behind k8s is so complicated to deploy and administrate, much more complicated on-premise than on Cloud.
Where is the difference? Where is the easier? When the dev guy need to make a deployment of an app or microservice don't need to ask the infrastructure team for servers, storage and or anything... Just make a deployment on the kubernetes cluster and that's all.
But let me say you that the infrastructure is there, with higher level of complexity.
This is especially true when you over engineer K8s
Eg. Using it for the DB, persistent disks everywhere etc, all things that could be offloaded to 3rd party cloud services
👏 Don't 👏 run 👏 stateful 👏 services 👏 in 👏 k8s. 👏
Well, deploying stateless microservices will not dissapear all infrastructure required to run k8s.
The discussion is about k8s does not require complex infrastructure...
👏 Don't 👏 run 👏 stateful 👏 services 👏 in 👏 k8s. 👏
I'm new to them, but I feel like I'm about to do that exact thing. What is your solution to it?
Run them outside of k8s in traditional VMs or services like AWS RDS.
That applies to standard tools like databases, not specific ones for your use-case specially if you are building lot of workers and doing cpu heavy computation tasks. i.e not every app is CRUD like.
"Also starting with microsevices is much easier than splitting a monolith later."
It's all about picking the tradeoffs you want to deal with. Personally, I'll take "splitting up the monolith" over "re-architecting a bunch of incorrectly scoped microsercvices" any day of the week.