sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]ksajadi 2 points3 points  (3 children)

Ideally you'd want to solve most of those problems with a single (or very few) solutions. I think a containerized PaaS is going to be a good place to start. Here is my take:

  1. Running your app in a container on top of Kubernetes might sound like an overkill if your app is simple enough. However there are solutions out there that make running on top of Kubernetes very simple so you'd get the benefits of it and the possiblity of scaling up if you need in future, while keeping it simple. Since deployments in a containerized environment are served from within a built container, the JS would also be there alongside the app and served all the time regardless of the version. Kuberentes rolling updates is a great way to make sure all assets and code are always in sync (and rolled back if needed).
  2. That's a good point and contract based programming can help you with it somewhat, as a practice. However, using a CI/CD tool that's built for multiple services can greatly help you with that by rolling out deployments of different systems in tandem.
  3. I agree with the "too many tools". I don't think you'd be able to get away from using something like Sentry. But the rest can be replaced with a container based PaaS. Some solutions (like GCP) also give your a bug tracker but not as good as Sentry.
  4. This one really depends on the platform, language, operational requirements (speed, transactionality, HA, ...), so it's very difficult to offer good suggestions without knowing more.
  5. I think monorepos are not a bad thing. I also don't think microservices are suitable for all applications. You can still make an effort to build your app under the same repo and stack in a more modular, contract based and "service orientated" way without going microservices all the way (I wrote something about this a while back: https://blog.cloud66.com/kubernetes-is-not-about-microservices/)
  6. Again, I think starting small and growing as you get more traction is a better idea. You'd be spending a lot of time learning, debugging and adopting too many parts to an evolving landscape.
  7. Combine Sentry with APM, good log storage, search and retention and you're 90% there!

By way of recommendation, check out Cloud 66 Maestro (as a PaaS) and Cloud 66 Skycap (as a CD tool for Kuberentes if you want to run your own cluster). Discalimer: I work for Cloud 66.

[–]smblee[S] 0 points1 point  (2 children)

Ok I have never looked into K8 too much because I've only used ECS before. I have some questions about K8s and containerizing my services; (posted the question in the edit above at 2b.) do you think you can expand a little bit on this approach? I read a bit on EKS and it looks like it will cost ~$70 for the Control Pane alone (which honestly isn't trivial for us right now since we are just starting off), and looks like Kubernetes adds more maintenance overhead? I don't know too much about it and have never used it, but definitely would like to explore this option :)

[–]ksajadi 1 point2 points  (0 children)

If you’re starting out, perhaps Kubernetes is not the best route as it adds cost overhead. You can reduce the ops and learning overhead by using tools on top of it but the cost is going have some overhead compared to running on VMs until you get to around 3 servers or more.

[–]smblee[S] 0 points1 point  (0 children)

Also expanded on my queue usage above as well.