Hacker News new | ask | show | jobs
by sneak 1950 days ago
> First, was the network setup. We needed to merge multi-site networks into a mesh topology network where all the nodes could be interconnected which was solved using a hub and spoke topology VPN. Although, it does have its own drawbacks it had a good cost-benefit ratio when it comes to setup and deployment and is working for us for now.

How is "mesh" solved with "hub and spoke"? If your hub goes offline, everything stops; the whole point of a mesh is to avoid the SPOF.

> Next, was building the dashboard which not only required the making of the UI but required figuring out how we’re going to expose and manage resources in our shop network. We decided to build the backend in the spirit of Kubernetes, so it is easy to manage at scale with the addition of new sensors, machines and full-blown sites themselves.

What does that mean? Docker containers?

2 comments

Indeed, as you noticed the networking setup is primitive, but for the time being it works for us. Currently, the hub is chosen to be as reliable as possible and nodes at the end of the spokes are prepared for hub down (ie. they stop safely ).

Kubernetes is more than just Docker containers. Having managed small computing clusters for a decade using custom scripts I find that the value of K8s is how easy it is to manage highly complex applications over an array of loosely connected computing nodes. So in my view k8s includes networking, orchestration and principles of how everything should be done and managed to achieve redundancy, performance and stability.

Containers are just a convenience for simple deployment on asymmetric nodes and is only part of K8s.

If you're actually running kubernetes and you say you're running stuff "in the spirit of kubernetes" it gives the strong impression you are not actually running kubernetes.

I also didn't say your networking was primitive, just that "hub and spoke" and "mesh" are two entirely different things that you seemed to have conflated entirely.

And that is correct. We are indeed not running kubernetes because it is not supported on our hardware and some assumptions were limiting. So we have a new system, but having kubernetes as our ideal.

Hub and spoke is the underlying architecture of the net, but we are achieving mesh like functionality having hub as our central router. The wording might be a bit confusing.

IPIP/IPsec and OSPF would do nicely for efficient site-to-site meshing.

But, adding docker to the equation makes it much more complicated. I'd prefer just operating the machines over IP and get rid of all remote desktop related latency all together.