3 ms·
This is good stuff, not just for Elixir. I've been increasingly heading this way in my Go programs as well, and anything else that I've had to write of any sign
by jerf 7y ago
This is good stuff, not just for Elixir. I've been increasingly heading this way in my Go programs as well, and anything else that I've had to write of any significant size.
One of the interesting side effects is that the whole microservices thing just kinda vaporizes as a consideration when you can just take a chunk of your program and run it on another server or something if you need to. I'm still not doing this as fluidly as I'd like, but I've definitely ripped bits out and also merged some bits before without too much hassle.
One of the major problems I've hit with this is just that the mechanisms for composing these pieces together is all over the board. Do you want to plug in a handler for some chunk of the URL space? That works entirely different from composing in two network services on two different ports, which works entirely differently from creating a new protocol that has plugable components, which works entirely different from composing together two services that both end up sharing the same database connection pool.
The other problem I've had is the availability of code that can be mixed and matched like this. One example I recently fixed up in my code base is that we previously had a module for managing metrics for the entire project, which declared each metric value. It was non-trivial work to take everything that module did and made it so each sub-application could register its own metrics independently. It wasn't hard; the design that leaps to your mind is probably basically what I implemented. But it also added yet another way in which composing these things together is a challenge. Composable configuration is also annoyingly difficult.
There's no one big thing that makes this hard, it's a ton of little things everywhere that afford you tying your program together more tightly than it really has to be. I think that if languages and/or libraries supported this better, it wouldn't be that much more difficult to write solid code that worked this way all the time, but right now there's just impediments everywhere.
- hinkley 7y ago> different from composing in two network services on two different ports I don't think this should be a thing anymore either. Container orchestration is slowly fixing this by default but really, it shouldn't be my server's business to track and figure out where all the other services are. That should be in one place. In production it should be owned by Ops. In local it should be optionally controlled by the dev. The dev should only have to worry about server names when they're collaborating on a bug fix with the owner of a particular service. The rest of the time they should send it all to a single proxy on a single port, with everybody namespaced. Let the proxy talk to Consul or what have you to sort out the rest. This is also one of the tricks you use to break up a monolith, but it has other uses as well.
- jerf 7y ago"I don't think this should be a thing anymore either." I routinely set my primary web services on one port, and the access to debugging and profiling information is available on a web server running on an entirely different port. In principle, this is not necessary, because everybody and everything should be able to route by URLs, and of course, everybody is using these tools and is intimately familiar with them. In practice, if I depend on that, those things tend to "fail open" and mean that if I don't explicitly block my debug routes from being exposed, it will tend to end up set up so just anybody will be able to reach them. By having by debug & monitoring on a separate port entirely, it makes it so that functionality tends to fail closed; if I don't open that port to people explicitly, it just stays entirely inaccessible, which is the failure state I'd rather have. Also, there's a whole world of people who aren't working in an environment where there's a dozen people dedicated to maintaining a kubernetes setup for them, and are still building services that aren't built in that paradigm. Plus it seems to me like having really amazingly separable services, even ones not initially thought of as being separate, is a plus for Kubernetes rather a problem.
- hinkley 7y agoI'm talking about having to configure separate fully qualified URLs for every service in your company, with server name and port, versus talking to a proxy which knows all these mappings. When your apps are >1 the cost of maintaining these lists everywhere becomes painful. I brought up Kubernetes because Kubernetes makes you solve this out of the gate.