| A few points I'd like to make: 1. You can't "migrate" to microservices from a monolith. This is an architectural decision that is made early on. What "migrating" means here is re-building. Interestingly, migrating from microservices to a monolith is actually much more viable, and often times just means stick everything on one box and talk through function calls or IPC or something instead of HTTP. Don't believe me? See this quote: > The only ways we could break down our monolith meant that implementing a standard ‘feature’ would involve updating multiple microservices at the same time. Having each feature requiring different combinations of microservices prevented any microservice from being owned by a single team. Once something is built as "one thing," you can't really easily take it apart into "many things." 2. Microservices does not mean Kubernetes. The idea that to properly implement microservices, you need to set up a k8s cluster and hire 5 devops guys that keep it running is just flat-out wrong. 3. Microservices are "antifragile," to use a Talebian term. So I think that this paragraph is actually incorrect: > This uncertainty made creating microservices more fraught, as we couldn’t predict what new links would pop up, even in the short term. A microservice is way easier to change (again, if designed properly), than a huge app that shares state all over the place. 4. What's the point here? It seems like the decision was hasty and predictably a waste of time. Any CTO/architect/tech lead worth his or her salt would've said this is a bad idea to begin with. |
You don’t need to use kubernetes but I strongly believe it’s the best choice if you’re not using FaaS. If you pick nomad or bare vms you’ll spend a lot of your time building a framework to deploy/monitor/network/configure etc your services whereas kubernetes has “sane” defaults for all of these
That said - you should use managed kubernetes and not deploy it from scratch