17:26:20 GMT <goldstar> are there any clientside cache techniques for redis? to mitigate network latency
17:26:33 GMT <goldstar> and load
17:28:18 GMT <minus> nothing stopping you from dropping an in-memory LRU cache on your application's functions
17:37:08 GMT <goldstar> minus: yeh, its application specific though; am thinking of building a tool that'll basically proxy between the cache server and the client; you can configure it to cache data based on various parameters
17:39:08 GMT <minus> you must have a specific use case for that; i can't imagine where that would be very helpful. adding caching to your code where necessary seems more appropriate, because you can "configure" it in-place (as opposed to having to configure an external tool)
17:41:06 GMT <goldstar> minus: sure, in my case too much network saturation, and not to forget latency, which can be reduced significantly if there is a flexible local cache - you can tell it to cache certain queries for X amount or something
17:41:47 GMT <goldstar> I hate having to add copious cache handling code
17:42:01 GMT <goldstar> and overtime it just turns in spagetti
17:42:18 GMT <minus> heh
17:43:11 GMT <minus> i'm always thinking of python when thinking of caching functions; you just slap on an @lru_cache() on the function and you're good
17:43:34 GMT <goldstar> sure, but not everyone is building apps in py
17:43:44 GMT <goldstar> not a py guy personally
17:44:03 GMT <goldstar> its more seperation of concern I guess
17:44:34 GMT <goldstar> app focuses on modelling the business, and some external daemon handles the caching/proxing or whatever
17:44:51 GMT <goldstar> it'll be well suited for a microservice archecture, which is very chatty
17:45:14 GMT <goldstar> actually, microservices could benefit immensely from it
17:45:43 GMT <goldstar> network latency is a massive bottleneck for "service oriented" designs
17:46:37 GMT <goldstar> it could be extended to support other cache servers too I guess
17:46:54 GMT <minus> or even services directly?
17:47:13 GMT <goldstar> minus: yup
17:48:16 GMT <goldstar> its got to be fast, so no python - probably C :D
17:48:22 GMT <minus> ;P
17:48:36 GMT <minus> how about Go/Nim/Rust?
17:49:07 GMT <goldstar> ah, Go - forgot about that
17:49:21 GMT <goldstar> thanks, will dig around
17:49:51 GMT <goldstar> I'll whip something up, and keep you guys posted on it :)
17:50:08 GMT <minus> one concern i'd have with such a proxy layer is that it's an additional component to deploy, monitor and so on
17:50:14 GMT <minus> what's your take on that?
17:51:27 GMT <minus> and a somewhat unrelated question: what do you build your SOA on? w.r.t. configuration and discovery of services
17:52:38 GMT <goldstar> minus: agree; has its trade offs, although the development community is heading towards containerisation, more service oriented systems (which is a bit of a double edged sword), so adding another component shouldn't be too problematic
17:53:24 GMT <goldstar> if there is network downtime, it can pull copies from the cache
17:53:39 GMT <goldstar> but if IT goes down, then you have other issues; heh
17:53:53 GMT <minus> ;)
17:54:17 GMT <goldstar> minus: cloud foundry here
17:54:24 GMT <goldstar> kubernetes is good also
17:55:00 GMT <minus> how large is the deployment you're working on?
17:56:50 GMT <goldstar> minus: well, we're currently migrating from a 5 year old monolith, very messy - we're expecting about 15 odd services at the end of the project; but we need to be careful, too much seperation and we'll be in serious trouble
17:56:51 GMT <minus> but if you're using cloud foundry it's probably larger
17:57:50 GMT <goldstar> minus: for a microservice/soa deployment, I wouldn't try to re-invent the wheel; CF gives you loads of good tools, and room for good growth
17:58:13 GMT <goldstar> if you do your own plumbing, its going to be hard, real hard
17:58:14 GMT <minus> mhh
17:58:22 GMT <goldstar> esp long term
17:58:33 GMT <minus> currently doing some own plumbing
17:58:57 GMT <goldstar> how many services?
17:59:16 GMT <minus> 4 if i counted correctly
17:59:57 GMT <goldstar> not too bad then
18:00:21 GMT <goldstar> containerised?
18:00:28 GMT <minus> deployment is already scripted with ansible, so it's not too painful deploying every other month or so
18:00:43 GMT <minus> yeah, although that's more of a pain than a gain imho
18:00:49 GMT <minus> docker fails way too often
18:00:52 GMT <goldstar> agree
18:01:03 GMT <goldstar> another fad I guess
18:01:17 GMT <goldstar> its good if you are working towards an immutable infrastructure
18:01:24 GMT <goldstar> but you really need to justify its use
18:01:34 GMT <goldstar> because its more work, maintenance and overhead
18:03:00 GMT <goldstar> ansible is good; being using it for about 2-3 years for our monolith, its gone downhill lately though which is a shame - fortunutely, saltstack guys are still holding out a solid product
18:03:13 GMT <goldstar> been*
18:08:14 GMT <minus> ansible's gone downhill?
18:11:03 GMT <goldstar> yes, annoying bugs - although, I think salstack has always been a lot more mature from get go
18:18:24 GMT <minus> salt requires an agent on the managed host?
18:20:24 GMT <goldstar> yup - actually, thats why we didn't go for it in the first place. But in retro, I think that's a minor aggrievance; when we run ansible playbooks on 20+ hosts, it takes forever, whereas SS would have taken a fraction of the time (due to the agent)
18:24:21 GMT <minus> yeah, in hindsight…
18:24:30 GMT <minus> we went with ansible for the same reason
18:25:17 GMT <minus> but running ansible deployments from europe to east asia or america is terrible