[HN Gopher] Evolution of code deployment tools at Mixpanel
___________________________________________________________________
Evolution of code deployment tools at Mixpanel
Author : i0exception
Score : 41 points
Date : 2021-06-12 14:26 UTC (8 hours ago)
(HTM) web link (engineering.mixpanel.com)
(TXT) w3m dump (engineering.mixpanel.com)
| Vendan wrote:
| Hey, I'm one of the engineers on the DevInfra team at Mixpanel,
| and worked on the Argo implementation. AMA, and we are hiring in
| general, and for the DevInfra team in specific (feel free to
| email me, just gotta solve the "puzzle" in my profile :D)
| postpawl wrote:
| Off-topic, I know... but do you think it was a good idea to
| disable SSL cert verification by default in your python client
| recently?
|
| You also did it in a way that ignores all insecure cert
| warnings for requests from other libraries too:
| https://github.com/mixpanel/mixpanel-python/pull/102
| Vendan wrote:
| That's not an area I'm involved with, but I'll poke the
| people that are... sorry :(
| gravypod wrote:
| Have you considered using Bazel to build an artifact that
| describes your deployment configuration? This is something that
| I've been thinking about trying to implement for some time.
| Essentially I want to have a way to support defining service
| configurations like this: service_binary(
| name = "foobar", srcs = ["foobar.jsonnet"],
| deps = ["//jsonnet/service.jsonnet"], images =
| ["//a:image"], )
|
| Then make it possible to create a class of `*_test` rules that
| would start up a bunch of docker containers in the same network
| topology they would exist in prod, run your test in the same
| netns, then clean everything up. It could look something like
| this: cc_integration_test( name =
| "...", services = ["//a", "//b"], srcs =
| ["main.cc"] )
|
| There's some BazelCon talks about people doing similar stuff
| but not actually open sourcing their code.
|
| P.S. if you use rules_docker please feel free to open a PR to
| add your company to our README:
| https://github.com/bazelbuild/rules_docker/#adopters
|
| > service_binary
| Vendan wrote:
| We've looked at it, but we have services that aren't using
| rules_docker to build their images, so for now at least, we'd
| rather have everything use as similar of a deployment process
| as possible.
|
| (and we are using rules_docker, and love it! Added a pr,
| gotta look into the CLA stuff (would like to do it from
| employer side, but that will have to wait until monday at
| least))
| cagenut wrote:
| I'm seeing this "we started out with 2 and now there's dozens"
| pattern with k8s everywhere, and just like in this example the
| cause is a one-two-punch combo of proliferation of service
| complexity and geographic replication demands (be they legal or
| performance).
|
| kube was originally meant to abstract the datacenter, is there
| anyone who's abstracting the globe/internet yet? I'd love a geo-
| kube abstraction where based on annotations or something I could
| provision deployments/pods to arbitrary geographic locations. I
| want a scale-to-zero node-pool in every region, and one kube
| master api for the world.
| gravypod wrote:
| There's active work on a standard called kubefed [0] that is
| being worked on.
|
| > I want a scale-to-zero node-pool in every region, and one
| kube master api for the world.
|
| Personally, I'd generalize this to: "I want to describe the
| reliability requirements and configuration for my software and
| have an automated system solve for where, how many, when, and
| how to route to it"
|
| I want to have something where I can say "I need to have high
| availability, lowest latency, and X GB of RAM and Y cores" and
| have a system automatically schedule me wherever compute is
| cheapest while also intelligently routing traffic to my servers
| based on client origins.
|
| [0] - https://github.com/kubernetes-sigs/kubefed
| cagenut wrote:
| does it have to be mulitple federated clusters? can etcd and
| kubelet not just handle 100ms? (or be adapted to).
| p_l wrote:
| While laten ies can get pretty good these days, I'd rather
| not plan on having 100ms ceiling for multiple DCs without
| dedicated lines and considerably close geographic
| locations.
| gravypod wrote:
| If you have multiple federated clusters you can tolerate
| issues that affect an entire cluster of machines. Having 3x
| clusters each with 3x master nodes that do not depend on
| each other, and Volume drivers that are aware of having
| replication across regions, you can make some really
| reliable things.
|
| For most use cases though what you're talking about will
| work and you can do it today with just setting up a VPN to
| have a flat internal network topology.
___________________________________________________________________
(page generated 2021-06-12 23:02 UTC)