[HN Gopher] Using Kubernetes to rethink your system architecture...
___________________________________________________________________
Using Kubernetes to rethink your system architecture and ease
technical debt
Author : kiyanwang
Score : 45 points
Date : 2021-05-23 11:31 UTC (11 hours ago)
(HTM) web link (stackoverflow.blog)
(TXT) w3m dump (stackoverflow.blog)
| MichaelMoser123 wrote:
| Did the stackoverflow architecture change significantly from this
| series of posts? (seems to mentioning 2016-2019) [1] The article
| mentions a rewrite, but it wasn't very specific on the scope of
| the rewrite, and what kind of stack they are using now.
|
| I thought they were running their own farm with most of the
| action on IIS with ASP.net and MSSQL, and some elasticsearch for
| search.
|
| [1] https://nickcraver.com/blog/2016/02/17/stack-overflow-the-
| ar...
| jimminy wrote:
| The article is a guest post from individuals that work at
| Pusher[1], about architectural decisions they made for their
| products and services.
|
| I also thought it would be about StackOverflow until they
| started mentioning all the Pusher related products.
|
| [1] https://pusher.com
| MichaelMoser123 wrote:
| Oh, thanks. Skipped that emtirely. (Too much HN for me)
| commandlinefan wrote:
| > rewrites should be avoided unless they are truly necessary
|
| Which is always.
| Thiez wrote:
| It's always necessary, or they should always be avoided?
| commandlinefan wrote:
| Always necessary.
| toast0 wrote:
| How many lines of code is k8s? Depending on it is adding those
| millions of lines to your tech debt.
|
| Unless you need so many of the features, mostly k8s seems to be a
| way to increase complexity and build resumes. Yes, you need to
| automate building instances and service discovery, but neither of
| those tasks needs millions of lines of code.
| Hackbraten wrote:
| > Kubernetes has great documentation so new starters can get up
| to speed more quickly even if they don't have experience with it.
|
| I strongly disagree. What feels easy for one developer may be
| super hard for others.
|
| For me, the Kubernetes tutorial [1] and documentation [2] [3]
| feels borderline incomprehensible. It introduces several abstract
| concepts at once without telling me what they really mean. It
| raises more questions than it answers.
|
| For example:
|
| > Kubernetes coordinates a highly available cluster of computers
| that are connected to work as a single unit.
|
| What does that even mean? Is that "single unit" the entire
| application? Or rather one component, e. g. the backend? You
| usually don't have more than one service per container, right? So
| what exactly is the cluster here? Why is there not a single
| example?
|
| > The Control Plane is responsible for managing the cluster. The
| Control Plane coordinates all activities in your cluster, such as
| scheduling applications, maintaining applications' desired state,
| scaling applications, and rolling out new updates.
|
| We haven't even established what the cluster is and how it
| relates to an application but now we're already talking about
| several applications? I feel entirely lost.
|
| Ok, let's look at another introductory page [2].
|
| It says things like:
|
| > The worker node(s) host the Pods that are the components of the
| application workload.
|
| But it won't tell me what a Pod is. So I click on the Pods link
| [3].
|
| It says:
|
| > A Pod (as in a pod of whales or pea pod) is a group of one or
| more containers, with shared storage and network resources, and a
| specification for how to run the containers. A Pod's contents are
| always co-located and co-scheduled, and run in a shared context.
| A Pod models an application-specific "logical host": it contains
| one or more application containers which are relatively tightly
| coupled. In non-cloud contexts, applications executed on the same
| physical or virtual machine are analogous to cloud applications
| executed on the same logical host.
|
| I find that explanation outright hostile. Not a single example
| that a newbie can understand. Instead, a pile-up of more and more
| abstract concepts. I still have no clue how a Pod, a node, an
| application, its instances, its components and a cluster relates.
| I'm giving up here.
|
| This documentation is abysmal. How can the blog author possibly
| call this thing well-documented?
|
| [1]: https://kubernetes.io/docs/tutorials/kubernetes-
| basics/creat...
|
| [2]: https://kubernetes.io/docs/concepts/overview/components/
|
| [3]: https://kubernetes.io/docs/concepts/workloads/pods/
| coopreme wrote:
| > Not a single example that a newbie can understand.
|
| K8S (imo) isn't for noobs. A car factory isn't for noobs.
| Ideally you would want to understand how a car is made and
| works, how to run an assembly line, and how to build a factory
| communication systems before building and running the car
| factory. Similarly, you should understand how docker containers
| works, how to run infrastructure, and how to configure system
| networks and dns before building and running a K8S platform.
|
| The analogy may not be perfect... K8S is complicated but not
| impossibly so. Practice, working with something like Rancher,
| and classes will go along way to help understand it.
| Hackbraten wrote:
| Let's say my app has two containers: container A serves a
| static page for my SPA, and container B is a back-end that
| exposes an API for A.
|
| So which set of containers would be a pod here? And which
| would be the nodes? And what would be the cluster?
|
| (For the sake of the example, let's assume that both A and B
| scale independently.)
| coopreme wrote:
| That would be two pods. Each pod would have one container.
| The nodes would be the underlying Infrastructure at the
| containers are running on, so you would have n number of
| worker nodes which are each a full system running either on
| premises, or in a cloud. K8S Will schedule those pods to
| run on those nodes... same as how docker containers run on
| your host system in development. The cluster is the K8S
| body representing the control plane nodes ( your mgmt
| computers running etcd and K8S backend ) and the worker
| nodes (where your pods, demons, statefull sets, containers,
| etc etc etc are running ).
|
| Now if you configure it right, those two pods are two
| deployments. You can scale those up and have a load
| balancer sitting in front of them. That load balancer will
| expose app and send in traffic to the stateless containers
| in the cluster.
| StreamBright wrote:
| Yeah not for noobs is another way of saying that the creator
| of that particular thing did not do a good job.
| develatio wrote:
| Kubernetes is a great piece of software and it definitely has
| it's advantages and use-cases. That said, this post strikes me on
| several fronts.
|
| The writer starts by saying that servers were treated as pets,
| which inherently means difficulty (as the author clears out). I
| assume that, at some point, their services got reworked to a
| shape where they could be deployed in servers treated as cattle.
| This is a work the author had to pay no matter if the final goal
| was Kubernetes, Autoscale Groups or any other solution.
|
| Then the author explains how they got to the conclusion that they
| need to containerise their service(s) in order to be able to use
| K8s, which would then, in turn, allow them to scale properly
| (adding on top the Go rewrite that is mentioned at some point in
| the post). The author also explains that Autoscale Groups were
| discarded because of their complexity.
|
| It's not clear to me that K8s was the actual thing that helped
| them scale, but rather the work they put into reworking their
| services. In my experience, once your service(s) are ready to be
| deployed in servers that can be managed as cattle, the benefits
| show up independently of the deployment solution that is used to
| deploy the service(s) (K8s, Autoscale Groups, etc...).
|
| Just to add on my point, wouldn't the result (in terms of
| performance / resources usage) be the same if instead of
| "containers" the author had chosen "AMIs" and instead of
| "Kubernetes" the author had opted for "Autoscale Groups"?
|
| If that were the case (which I believe it might have), the other
| thing to consider would be the difficulty of managing a K8s
| cluster vs the difficulty of managing an Autoscale Group. I've
| seen quite some horror stories about K8s[1] and I'd rather choose
| ASG over K8s.
|
| [1]: https://k8s.af
| vp8989 wrote:
| If you are a Director of DevOps, what is easier to say to the
| CTO:
|
| "I need X million USD in engineering spend this year because we
| need to be on Kubernetes".
|
| "I need X million USD in engineering spend this year to fix
| half a decade of awful technical execution and decision making
| (that all happened under your watch, BTW)".
| ransom1538 wrote:
| "Hey! I have the code wrapped in k8s! it is now serving an
| endpoint - let's start giving it a _small_ amount of traffic!
| "
| edoceo wrote:
| > awful technical execution
|
| Leave that out. Many right decisions look stupid later. It
| will happen to you to. Time makes fools of us all.
| [deleted]
| yawaramin wrote:
| Neither:
|
| "I need X million USD in engineering spend this year because
| we need to practice DevOps and SRE."
| qw wrote:
| "I need X million USD in engineering spend this year
| because it would improve my CV"
| belatw wrote:
| This reads to me as:
|
| 'I need X million in USD in engineering spend this year so
| I can add "I managed a large SRE/DevOps team" on my
| resume.'
| edoceo wrote:
| Yea. I'm a VM type of admin. One time I got a whole lecture
| from a Docker Zealot about how I need to _not_ treat my servers
| as pets. As if docker was the only path to that end. Never even
| bothered to talk about the existing infra that was managed like
| cattle - and that it was more a function of App-Architecture
| than Docker vs X.
|
| Its nice to love your tools. Don't start thinking they are the
| one true path.
| tisFine wrote:
| Agreed. Software is not hardware.
|
| Behavioral patterns for a user are not tethered to one
| ephemeral implementation.
|
| I ran a huge VMWare cluster in 3 data centers across the
| globe, not so different from an AWS/EKS pipeline.
|
| Yes, I had to treat the hardware like pets to an extent. But
| the developers had no problem pivoting between VMWare and
| what we ran in AWS because the software tooling we provided
| looked the same.
|
| Some folks believe memorizing YouTube videos = expertise.
| ransom1538 wrote:
| "One time I got a whole lecture from a Docker Zealot about
| how I need to not treat my servers as pets."
|
| You can always point out that pods are ran on nodes. Nodes
| use the standard built in GCP Auto-scaler (instance groups +
| load balancer). So its a great wrapper! But, it's a wrapper.
| GCP also! has a way to use a docker image as your VM.
| edoceo wrote:
| Agree and understood. You sound reasonable. IME zealots
| trade reason for enthusiasm and they focus too much on the
| method, not the concept.
|
| This individual was shocked to learn I thought you could
| treat the iron-born servers as cattle too. (But, my first
| clusters were in the late 90s, so got to the cattle concept
| quite some time ago)
___________________________________________________________________
(page generated 2021-05-23 23:02 UTC)