i happen to be learning swift and, as a newcomer to the language, i have concluded that the level of complexity is pretty much on par with cpp. one thing i have noticed is that swift maintains readability while being complex. that's the surprised to me. complex cpp is simply not pleasant to read.
seems to me that the authors wrote their own library instead of trying to make the ones that didn't meet their need better. well, they never mentioned they tried...
anyways, some of their choices like that long variable name are odd to me. i can understand the unit problem though. golang solves that so nicely!
60s. was wondering how we could add physical units to python? highjack the number literals and variables like this: 1.s, pi.radians? or maybe the way golang does it: 1 * time.seconds?
Which uses the interesting approach of setting all "units" to random floats:
A complete set of independent base units (meters, kilograms, seconds, coulombs, kelvins) are defined as randomly-chosen positive floating-point numbers. All other units and constants are defined in terms of those. In a dimensionally-correct calculation, the units all cancel out, so the final answer is deterministic, not random. In a dimensionally-incorrect calculations, there will be random factors causing a randomly-varying final answer.
Which presumably is done to avoid overhead from carrying around units with each number, but forces you to run calculations multiple times (with different random seeds) to verify the result is correct.
kubernetes is complex and maybe not for all of us. i am starting to think, maybe we should leave operations to operation teams at this point and just be developers. i would be totally fine with it to be honest.
> maybe we should leave operations to operation teams at this point and just be developers
The whole misconception about devops, imho, is that people mistakenly expect everybody to do everything: operations people writing code (have you seen code written by an operations engineer?) and developers maintaining services and infrastructure (have you seen an infrastructure designed/maintained by a developer?).
The whole point of devops is to enable ops and dev to collaborate. Articles about setting up kubernetes are mostly pointless. I've been there, and getting a cluster up in a basic way is as simple as pointless. The complexity is somewhere else.
People willing to advocate about kubernetes should assume a cluster is already running (developers who don't want to get into operations can either download minikube or get a managed instance off digitalocean, google cloud or amazon aws) and start from there, but teaching about the applicative side of k8s: how do I run my workload on a k8s cluster? How do I expose it? How do I get the scheduler and affinity/antiaffinity to work with me instead of agaist me ? How do I manage storage? How do I get traffic routed to my application? How do I observe my application ? How do I poke it with a stick when it's not working as expected?
It's fine not to know everything.
It's fine to read just enough to understand what's going on, but then letting someone else handle the problem.
> kubernetes is complex and maybe not for all of us
Couldn't disagree more. Kubernetes is extremely easy. I work mostly in frontend, and despise devops. Or used to. Until Kubernetes came along I had no way of easily creating a load-balanced scalable service.
First learn Docker. This is independent of Kubernetes. Docker is awesome in and of itself. In Azure you can deploy web sites as docker images and there are tremendous advantages to that over traditional deployment. Once you have learned Docker you are ready to learn Kubernetes.
If your app consists of multiple microservices then you have more than one docker container. This is where Kubernetes is helpful. Kubernetes has built-in DNS, so your microservices can contact each other using DNS names.
Learn how to deploy containers as Kubernetes ReplicaSets. Then learn how to add a Kubernetes Service on top of it, then learn how to add Ingress. None of this is hard.
Kubernetes is a pleasure to use, because of commands such as "kubectl exec" to log into the container, "kubectl log" to see the log without logging into the container, "kubectl cp" to copy files in and out, "kubectl port-forward" to make a service appear to be running on your devbox and so on.
I would not say Kubernetes is extremely easy. Running kubectl commands is easy. Setting up and building a cluster from scratch is not easy. You may have had an easier time, but I wouldn't label the whole process as easy.
That means it isn't easy though. If you are piggybacking on someone else doing 90% of the work then you can only call their service including it easy, not the tech itself.
So compared to docker-compose (which is strangely straightforward, but missing some pieces you'd want for scalable deployments) Kubernetes is more complicated. Or at least getting up to speed takes a fair bit longer.
Right. There are some cases when developers want Kubernetes because it is easy to deploy their application on it and autoscale it but in my experience, this is almost as easy with many other options that do not mean to pull in a giant black box dependency into your project. For those who think Kubernetes is not a black box, just wait for the first outage and measure the time how fast you can recover and what steps are involved. In my limited experience, it is much simpler to recover an autoscaling application on AWS or other cloud platforms that do not have Kubernetes. Why? Because there are significantly fewer things that can go wrong. Some people are ok to trade operational complexity for developer experience. I am fine with that.
The trend has been to blur the lines between roles to get people that are just good enough at all the things to make it work. Hence back-end, front-end -> full stack and DevOps and DevSecOps roles (those weren't meant to be roles)
I don't know if it's a cost-saving measure, business optimization, or just straight ego.
I sort of agree, but beyond deploying, we need to understand how and what to write in order for our code to support scaling to N instances (including N=0), and knowing the target "platform" is a good way to do that.
this is super cool! i clicked on the group names on the right thinking the filtering will happen automatically but you have to select them and apply on the left.
yes the list is certainly not exhaustive. i don't see activepython from active state in there. they've been in the game forever and mu is a newcomer but a really interesting one!
