This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-11-09
Channels
- # aleph (3)
- # beginners (327)
- # calva (3)
- # cider (20)
- # cljdoc (59)
- # cljs-dev (40)
- # clojure (104)
- # clojure-dev (30)
- # clojure-italy (8)
- # clojure-nl (36)
- # clojure-russia (3)
- # clojure-spec (3)
- # clojure-uk (79)
- # clojurescript (54)
- # community-development (5)
- # cursive (28)
- # data-science (21)
- # datomic (35)
- # emacs (14)
- # expound (1)
- # figwheel (2)
- # figwheel-main (82)
- # fulcro (18)
- # graphql (13)
- # jobs (12)
- # jobs-discuss (38)
- # kaocha (8)
- # lambdaisland (1)
- # lumo (12)
- # off-topic (20)
- # onyx (4)
- # re-frame (51)
- # reagent (12)
- # reitit (8)
- # ring-swagger (1)
- # shadow-cljs (22)
- # slack-help (2)
- # spacemacs (6)
- # specter (16)
- # testing (3)
working in a big team of developers (60-100), is it pragmatic to have theese rules/policy? • We develop our product only using language X. • We use a microservice architecture and all our microservices should be written in X. • No microservice will be written in another language or following a pattern that is not setup from our Language X template for new microservices? • If we find a better way of solving a problem, we will rewrite this in all our microservices, so there is no mismatch and everyone can follow the code. I dont like it, but it may be a good way. I think it's only because I don't enjoy language X as much as Clojure.
They're reasonable as long as you're getting value from it. What problem is being solved is the important piece.
We're not quite as large (around 35 on the technical side at the most), but we've had success with the completely opposite approach: an architecture of decoupled components. The components communicate via interchange formats that do not require a common library to interact with. Components know only about the fields they need and don't pretend to know the entire schema. This has allows components to transition to new languages, frameworks, or other ways of doing things. Components can be allowed to go "stale" when they're not the current product focus; there is no pressure to keep all the code and its deps up to date.
Some people choose microservices architecture in order to be able to use different languages for different problems. But that isn't the only reason to choose it.
It isn't the only one, but I'd want to be damn sure. If I'm using the same language anyway, we can all share a process and stop worrying about transactions and queues.
We had a lot of microservices written in different new and hip languages just because one of the founder felt he wanted to learn something new. Now he is leaving the company and leaving us with a lot of unmaintainable code. So the new policy is “We write everything in NodeJS” just because javascript devs are abundant.
It’s probably pragmatic also from management perspective. It’s easier to hire when you basically only need to ask the candidate “Can you do X?“.
The fourth bullet implies, to me, that when you find a better way to solve a problem you will work very hard to convince yourself it's not better.
So my assumption is that, in the long run, your system will be an amalgamation of all of the worst solutions to common problems.
Netflix is pretty large, and they detailed their journey as 'start with one stack and get to the point where you can deliver that reliably, and then you can start to instill variance.' That way you're not solving problems of DevOps for many stacks at once, each with its own qualities and quirks.
I think having a similar runtime can be a good idea. Like going JVM, or CLR, or Node. This makes Ops simpler. You can build common frameworks, make sure that they're setup everywhere. When you think about that, it is a huge strength of the JVM and CLR actually. At my work, it's all JVM. But people use Java, jRuby, Clojure, Scala, Kotlin, Groovy, etc. Yet everything is compatible, deploys to the same environment, etc.
We're not quite as large (around 35 on the technical side at the most), but we've had success with the completely opposite approach: an architecture of decoupled components. The components communicate via interchange formats that do not require a common library to interact with. Components know only about the fields they need and don't pretend to know the entire schema. This has allows components to transition to new languages, frameworks, or other ways of doing things. Components can be allowed to go "stale" when they're not the current product focus; there is no pressure to keep all the code and its deps up to date.
@ljosa May I be a bit nosy and ask which interchange format(s) you guys use? Avro, transit, JSON?
JSON would be my pick if you're going for language support. But I have to give a shout out to Amazon Ion if you're looking for something as nice as Json to work with, yet as fast as protobuf. Off course, EDN/transit are my favorite if you're only thinking in Clojure
Mostly json. Some edn and redis. We've experimented with some Thrift in the past but don't use it currently.
I’m curious what your approach is to documenting this architecture.
Documentation is fragmented at best, and often falls back to reading code, searching git logs and slack histories, and circulating tech specs to people who have been around a while. It probably helps us that much of our crosscutting data are either in datomic or in events (pageviews, impressions, clicks, etc. for an ad network) that are indexed in ES for awhile and archived forever in S3. So schema-oriented questions can often be answered by looking at historical data to see the real history of how something has been used instead of reading stale docs about what someone once thought about it.
Documentation is fragmented at best, and often falls back to reading code, searching git logs and slack histories, and circulating tech specs to people who have been around a while. It probably helps us that much of our crosscutting data are either in datomic or in events (pageviews, impressions, clicks, etc. for an ad network) that are indexed in ES for awhile and archived forever in S3. So schema-oriented questions can often be answered by looking at historical data to see the real history of how something has been used instead of reading stale docs about what someone once thought about it.