Container Training

You don't need to split an application into containers, you can have your full app in a container no problem. You can have all your jars in the container. Using containers doesn't mean you know have to split your apps in different ways, it means you ship the runtime, compiled code, whatever libraries are required and all that in a bundle.

Every programming language had its own version of jars, dependency management, etc. that you then need to reproduce everywhere you want those things to run. Containers mostly abstract that away - you just have a container image filled with what you want and you execute it. It also provides a consistent means of isolation. Thats the benefit I see.

Which version of the JVM? The one on your machine, my machine, or the server?

I assume you haven't been through the absolute hell that are Hadoop JARs

It’s actually a Kubernetes focussed course. The JVM isn’t going to auto scale or distribute my service.

its the ability to lower operating cost with less skilled staff.

No need to worry about some some other app using port 8080, dont need to ensure your scripts do a ps and filter out other users stuff, all those kinds of things.

Then theres libraries and vulnerability management which is easier to manage where the blast radius is just a single container.

It complicates it downwards, but simplifies it upwards. For example, containers generalizes the workload in a Kubernetes world, where the JVM would not be a general abstraction. This mainly matters on a scale where Kubernetes or similar solutions are motivated.

Some applications cannot be deployed as a monolith. Maybe they mix native and managed dependencies. Maybe they rely on external software (like, say, ffmpeg) being present. Maybe this external software depends on specific system library versions.

Yes, you can make all of this work without containers. They make all this very easy and reliable though.

So your container has the right Java Runtime Environment and your app inside. I don't even need to know it's Java!

I remember the good old days of having to script my own deployments on our own on-prem servers, with linter free wild west testing. It went to crap pretty easily because we were always customizing something, automating something, customizing the automating of something. Dependency checking was also very manual.

Nowadays we work with way more traffic that incentivizes strict bin packing of traffic within the tightest bounds of the resource pool, with the fastest actuation time. VMs won't give you that. Containerization just makes that so much easier and snappier for large amounts of traffic. But then we had to go global, and orchestrating containers across continents is a PITA. So there's value in k8s for dealing with that. These tools vastly reduce the complexity with regards to managing globally distributed services. But as usual, we start customizing these tools, leading to more complexity.

With that said, I believe startups need to focus on the fastest development and deployment times. So stuff like Docker, Kubernetes or Terraform are entirely unnecessary. As I commented elsewhere before, no one with a total QPS of 10 needs anything beyond GCE or EC2 or on-prem servers. People born in the Cloud age seem to have forgotten that they can just run the cheapest Linux machine with HAProxy and httpd behind a static IP. The focus on always going straight to Cloud complexity, if anything, smells more like engineers in on some VC grift.

Side note: It's hard to hire senior/motivated Java developers. It became a self-fulfilling cycle. Happened somewhere around 2011-2014, no one other than fresh grads graduating from legacy courses still used Java or .NET.

We already tried "JAR containers" for the JVM with this was called WAR and EAR files. We also add clustered servers to which you could dynamically deploy these files and scale up. These most popular "Application Servers" like IBM WebSphere and BEA/Oracle WebLogic could theoretically handle everything for you.

The only problem is that it all didn't work.

First, we've go the "worked on my machine" type of problem: Conflicting dependencies? Different version of the JVM? Native libraries?

Then you had the issues with the application servers themselves. All the configuration was usually done in some tedious GUI environment. Lost your server? Good luck. Want to automate something? Good luck. Want to use CLI? You're not a proper enterprise developer, who hired this crazy Linux hacker, fire him before he'll try to Open Source something. To be serious again, it was just downright uncomposable.

Lastly we had all the devops issues: How do you automate a deployment of a new version?

For classic PHP or cgi-bin apps you'd just upload everything to an FTP server (well, it's not as perfect as classic PHP fanboys make it, you do have to handle deleted files - rsync would still be safer).

For containerized apps, you just create a manifest file (or a Helm chart or whatever suits your fancy) and hit deploy. Kubernetes will take care of everything, including upgrading the container image if necessary.

It's the stuff in the middle that gives me nightmare. It's not enough to just dump a new JAR file on a server. You've got to stop the server and restart it using the new version. At the very least you'll need to have provisions for backup and quick rollback, and probably also a blue-green environment to avoid lost connections. In more critical services you'll want to have canary releases and a pipeline that carries your server through multiple environment.

This is why containers are unavoidable for most kinds of networked service. It's the deployment story. That's why you see people wrapping single-binary go apps in containers, even these binaries are completely static and often don't even depend on libc.

Are containers an overkill sometimes? Yes. They are far from ideal for CLI apps. That's where you want fast startup times, quick download, better package management and better integration with your host environment. But most CLI apps that I've seen using docker went that route because their installation process was too troublesome to bother with. You'd see that a lot with Python apps, which are quite hard to package. But even Java apps could be a hit or miss if you don't have the right JVM.

Ah, the HN "just use"

> jars in the JVM

See "JAR hell"

Also, Node.js, CPython, Ruby, .NET, etc etc versioning.

If you’re interested enough to be curious, it’s worth sitting down for a day with a mini kubernetes distribution and working through the basics of pods, deployments, and services. They are relatively simple conceptually (the hard part is grokking the kubernetes way of doing things) but they give you a feel for the way Kubernetes works.

I don't think so. It's overkill for most stuff and probably not particularly worth learning until you /need/ to.

If you're curious about orchestration concepts in general, something like nomad is a nice way to wade into the pool rather than the whirlpool of obscenity that is k8s.

I'd say so. I've been using k8s as a basis for all my projects for years. It's the best solution I've seen to the problem of packaging and deploying apps. I have a kubespray cluster at home that runs dozens of services flawlessly. Flux is the easiest devops deployment system I've ever had.

For work, having minikube + skaffold is perfect for local dev of complex apps. And it's easy to use production deployment manifests with it. It's also easy to use Kind for running integration and e2e tests. The ecosystem is second to none.

Docker is really easy. A few lines to describe your environment and a handful of commands (docker build, run, ps, images) and you are up and running.

Orchestration is more complex, but not too bad if you are using a managed platform.

A few days and you can get your head around it enough to get started with huge payback in efficiency.

After that, you can spend years really going deep on K8s and fully containerised stacks, but that’s more for DevOps/Cloud engineers rather than Devs.

Using Kubernetes is a skill worth learning and is pretty straightforward to pick up.

Running a Kubernetes cluster, in a shared environment (e.g. not just a hobbyist or single-purpose cluster), is much more involved. I'd never say developing a skill isn't worth it, but it is a deep subject with lots of unintuitive and frustrating corners, and you won't pick it up in a day or without scars. There's a reason lots of small- and medium-sized business just write a check to their cloud provider.

I'd say yes, worth it, just to be aware about its capabilities and caveats, strong and weak sides.

At one point or another someone will say something about K8s, and it never hurts to know more than just the peachy marketing posters from the large cloud providers, so you can have an opinion. What it realistically can and cannot do for you - this kind of stuff.

> Is kubernetes worth learning if you don't use microservices at work?

Maybe. K8s makes orchestration better. (If you disagree look at the last time marathon/mesos/dcos released and propose a better replacement.) Do you need container orchestration? That's a much better question. If you do, reach for k8s, if you don't, don't.

Agreed, and we're actually trying to bridge this gap at our company Kurtosis! Docker is great for doing dev - fine-grained control over the container, strong predictability guarantees, fast, and relatively lightweight (in comparison with Kubernetes), but you can't run Prod on it unless you start rebuilding Kubernetes primitives like Services from scratch.

Our approach has been "build an abstraction over Docker and Kubernetes that can provide the predictability of Docker when you need it (Dev & Test), and the scalability and resilience of k8s when you need it (Prod)", and then handle compiling down to actual Docker & Kubernetes commands. The goal is for the user to have a single environment definition all the way from Dev to Prod, so you don't have to do the dance of "Docker Compose for Dev, Bash on top of Compose for test, and Helm for Prod"

(basically this: https://docs.kurtosis.com/assets/images/kurtosis-utility-665... )

Is Docker swarms easily reproducable? If so, how?

He was there at the very start at DotCloud and worked on Dockers predecessor and then Docker itself. Early adopter is really underselling how much he contributed.

> Past workshops [...] 2021