4 ms·

Kubernetes and containers are a means to service architecture; It enabled scalability but does not require it. You should still be containerizing your applicati

by judge2020 4y ago

Kubernetes and containers are a means to service architecture; It enabled scalability but does not require it. You should still be containerizing your applications to ensure a consistent environment, even if you only throw it in a docker-compose file on your production server.

andrewstuart 4y ago
I don't even use containers - I aim primarily for simplicity and so far I have found I am able to build entire sophisticated systems without a single container. Containers I find make things much more complex.
- John23832 4y ago
  That just means you don't know how to architect a machine with containers (and if you're effective in what you do, that's ok). But it's a pretty objective notation that manually scaled single machines don't scale as well as automation.
- TillE 4y ago
  Docker can be super simple. Like, if I want to run a Python service, that's just a few lines in a Dockerfile and a docker-compose.yml stub. Then I can trivially deploy that anywhere.
  - paulryanrogers 4y ago
    Simple to start. Yet it is more complex at run time, which can complicate (or simplify) debugging, depending on the problem.
    - judge2020 4y ago
      Observability in production is where APM solutions like Datadog, Elastic, and Sentry come in; you can go from just logging errors all the way up to continuously profiling your application and beaming log files to them to correlate with metrics and database query timings. If you're just doing a simple application, Sentry really is the way to go, while Datadog and ELK are agent-based and more intended for complex setups and big enterprises (especially in their pricing structure/infra costs).
- fragmede 4y ago
  Are you at least using Ansible or Chef or something?
KronisLV 4y ago
> You should still be containerizing your applications to ensure a consistent environment, even if you only throw it in a docker-compose file on your production server. I'll say that this is a good point, especially because if you don't use containers or a similar solution (even things like shipping VM images, for all I care), you'll end up with environment drift, unless your application is a statically compiled executable with no system dependencies, like a JDK/.NET/Python/Ruby runtime or worse yet, an application server like Tomcat, all of which can have different versions. Worse yet, if you need to install packages on the system, for which you haven't pinned specific versions (e.g. needing something that's installed through apt/yum, rather than package.json or Gemfile, or requirements.txt and so on). That said, even when you don't use containers, you can still benefit from some pretty nice suggestions that will help make the software you develop easier to manage and run: https://12factor.net/ https://12factor.net/ I'd also suggest that you have a single mechanism for managing everything that you need to run, so if it's not containers and an orchestrator of some sort, at least write systemd services or an equivalent for every process or group of processes that should be running. Disclaimer: I still think that containers are a good idea, just because of how much of a dumpsterfire managing different OSes, their packages, language runtimes, application dependencies, application executables, port mappings, application resource limits, configuration, logging and other aspects is. Kubernetes, perhaps a bit less so, although when it works, it gets the job done... passably. Then again, Docker Swarm to me felt better for smaller deployments (a better fit for what you want to do vs the resources you have), whereas Nomad was also pretty nice, even if HCL sadly doesn't use the Docker Compose specification.
- vbezhenar 4y ago
  When it comes to Java, everything could be used as a directory installation. Like you need JDK, maven and tomcat? Download and extract it somewhere. Modify your current PATH to include java and that's about it. You can build big tar.gz instead of OCI container which will work just fine. So IMO it's perfectly possible to run Java applications without containers. You would need to think about network ports, about resource limits, but those are not hard things. And tomcat even provides zero-downtime upgrades, although it's not that easy to set up, but when it works, it does work. After I've got some experience with Kubernetes, I'd reach for it always because it's very simple and easy to use. But that requires to go through some learning curve, for sure. The best and unbeatable thing about containers is that there're plenty of ready ones. I have no idea how would I install postgres without apt. I guess I could download binaries (where?), put them somewhere, read docs, craft config file with data dir pointing to anotherwere and so on. That should be doable but that's time. I can docker run it in seconds and that's saved time. Another example is ingress-nginx + cert-manager. It would take hours if not days from me to craft set of scripts and configs to replicate thing which is available almost out of the box in k8s, well tested and just works.
ownagefool 4y ago
So the goal is basically being able to do builds whilst running as few setup steps as possible. Containers are a good common denominator because you essentially start with the OS, and then there's a file that automates installing further dependencies and building the artifact, which typically includes the important parts of the runtime environment. - They're stupidly popular, so it basically nullifies the setup steps. - Once setup, they by combinding both OS layers and App, they solve more of the problem and are therefore slightly more reliable. - They're self-documenting as long as you understand bash, docker, and don't do weird shit like build an undocumented intermediary layer. Infrastructure as Code does the same thing for the underlying infra layers and kuberenetes is one of the nicer / quicker implementations of this, but requires you have kubernetes available. Together they largely solve the "works on my PC" problem.

andrewstuart 4y ago

I don't even use containers - I aim primarily for simplicity and so far I have found I am able to build entire sophisticated systems without a single container. Containers I find make things much more complex.

John23832 4y ago
That just means you don't know how to architect a machine with containers (and if you're effective in what you do, that's ok). But it's a pretty objective notation that manually scaled single machines don't scale as well as automation.
TillE 4y ago
Docker can be super simple. Like, if I want to run a Python service, that's just a few lines in a Dockerfile and a docker-compose.yml stub. Then I can trivially deploy that anywhere.
- paulryanrogers 4y ago
  Simple to start. Yet it is more complex at run time, which can complicate (or simplify) debugging, depending on the problem.
  - judge2020 4y ago
    Observability in production is where APM solutions like Datadog, Elastic, and Sentry come in; you can go from just logging errors all the way up to continuously profiling your application and beaming log files to them to correlate with metrics and database query timings. If you're just doing a simple application, Sentry really is the way to go, while Datadog and ELK are agent-based and more intended for complex setups and big enterprises (especially in their pricing structure/infra costs).
fragmede 4y ago
Are you at least using Ansible or Chef or something?

KronisLV 4y ago

> You should still be containerizing your applications to ensure a consistent environment, even if you only throw it in a docker-compose file on your production server. I'll say that this is a good point, especially because if you don't use containers or a similar solution (even things like shipping VM images, for all I care), you'll end up with environment drift, unless your application is a statically compiled executable with no system dependencies, like a JDK/.NET/Python/Ruby runtime or worse yet, an application server like Tomcat, all of which can have different versions. Worse yet, if you need to install packages on the system, for which you haven't pinned specific versions (e.g. needing something that's installed through apt/yum, rather than package.json or Gemfile, or requirements.txt and so on). That said, even when you don't use containers, you can still benefit from some pretty nice suggestions that will help make the software you develop easier to manage and run: https://12factor.net/ https://12factor.net/ I'd also suggest that you have a single mechanism for managing everything that you need to run, so if it's not containers and an orchestrator of some sort, at least write systemd services or an equivalent for every process or group of processes that should be running. Disclaimer: I still think that containers are a good idea, just because of how much of a dumpsterfire managing different OSes, their packages, language runtimes, application dependencies, application executables, port mappings, application resource limits, configuration, logging and other aspects is. Kubernetes, perhaps a bit less so, although when it works, it gets the job done... passably. Then again, Docker Swarm to me felt better for smaller deployments (a better fit for what you want to do vs the resources you have), whereas Nomad was also pretty nice, even if HCL sadly doesn't use the Docker Compose specification.

vbezhenar 4y ago
When it comes to Java, everything could be used as a directory installation. Like you need JDK, maven and tomcat? Download and extract it somewhere. Modify your current PATH to include java and that's about it. You can build big tar.gz instead of OCI container which will work just fine. So IMO it's perfectly possible to run Java applications without containers. You would need to think about network ports, about resource limits, but those are not hard things. And tomcat even provides zero-downtime upgrades, although it's not that easy to set up, but when it works, it does work. After I've got some experience with Kubernetes, I'd reach for it always because it's very simple and easy to use. But that requires to go through some learning curve, for sure. The best and unbeatable thing about containers is that there're plenty of ready ones. I have no idea how would I install postgres without apt. I guess I could download binaries (where?), put them somewhere, read docs, craft config file with data dir pointing to anotherwere and so on. That should be doable but that's time. I can docker run it in seconds and that's saved time. Another example is ingress-nginx + cert-manager. It would take hours if not days from me to craft set of scripts and configs to replicate thing which is available almost out of the box in k8s, well tested and just works.

ownagefool 4y ago

So the goal is basically being able to do builds whilst running as few setup steps as possible. Containers are a good common denominator because you essentially start with the OS, and then there's a file that automates installing further dependencies and building the artifact, which typically includes the important parts of the runtime environment. - They're stupidly popular, so it basically nullifies the setup steps. - Once setup, they by combinding both OS layers and App, they solve more of the problem and are therefore slightly more reliable. - They're self-documenting as long as you understand bash, docker, and don't do weird shit like build an undocumented intermediary layer. Infrastructure as Code does the same thing for the underlying infra layers and kuberenetes is one of the nicer / quicker implementations of this, but requires you have kubernetes available. Together they largely solve the "works on my PC" problem.