Fork me on GitHub
#off-topic
<
2016-02-10
>
jcromartie19:02:26

after an especially grueling couple of sprints on this project I'm afraid I'm losing my faith in Clojure!

jcromartie19:02:45

I should probably tinker with something else

jcromartie19:02:30

but I'm afraid Clojure might suffer from the same old dynamic language problem where it's too easy to make a mess

jan.zy19:02:57

after 9 months of coding full-time in clojure in a project which is almost 3 years old now I can say that I have even more faith in Clojure! There’s very little mess and I need to try really hard to break things. I am still able to quickly deliver new functionalities. My productivity is roughly the same when compared to my work as a Scala developer. simple_smile

jcromartie19:02:29

I think it might be the project

jcromartie19:02:58

there are supposedly 4423 users here, so my coworkers might chime in simple_smile

jcromartie19:02:05

@jan.zy: do you have any experience with "microservices" architecture?

jcromartie19:02:56

Is there even a definition for "microservices"

jcromartie19:02:11

"microservices: a system comprised of way more web apps than you actually need"

jan.zy19:02:38

Yeah, I am not sure how small a service should be to call it a microservice simple_smile

jan.zy19:02:24

and how many of them we would need to say that a system has a microservices architecture simple_smile

jan.zy19:02:11

answering your question - most of my experience comes from writing monolithic apps

jcromartie19:02:48

we've got 10 app projects, 12 lib projects, and one project to tie them all together, and one top-level project.clj for lein modules

jcromartie19:02:50

it gets hairy

jaen19:02:54

Well, the first rule of microservices club is Don't Write Microservices.

jcromartie19:02:58

and they all run on the same machine

jcromartie19:02:15

I get frustrated with the whole thing quite easily

jan.zy19:02:20

and each of them in a separate jvm?

jaen19:02:26

The seconds rule of Microservices Club is If You Absolutely Have To - First Write a Monolith Using Hexagonal Architecture.

jcromartie19:02:37

in production, I think they are in separate processes

jcromartie19:02:43

but in dev they are all just in one process

jaen19:02:53

I don't know how complex your app is, but 22 projects sounds like a lot of stuff

jan.zy19:02:14

sounds like pain

jcromartie19:02:20

well, it's simple enough to run in a single process in development, and on a single machine in production! simple_smile

jcromartie19:02:32

though actually it's load balanced

jan.zy19:02:33

i’d prefer to have one codebase and 22 builds

jcromartie19:02:50

but everything runs at once on those load balanced machines

jcromartie19:02:21

I've been thinking of undertaking an effort to bring it under one codebase

jcromartie19:02:40

it should just entail merging the src, test, and project.clj files

jcromartie19:02:59

src, test, and resources directories, that is

jcromartie19:02:15

there should be a tool that automates merging project.clj dependencies simple_smile

jcromartie19:02:24

call it "lein macroservice"

jan.zy19:02:10

with optional step of wrapping it into javax.servlets, war and deployment to jboss

esnunes22:02:03

@jcromartie: it is a hard decision, I'm new to Clojure however I develop lots of microservices using nodejs. The company I work for has lots of products, I believe that at the moment we may have around 50 microservices. The product I'm working on has 12 microservices and as you mentioned it is pretty complex to handle them. At production we have a very structured deployment system based on continuous integration/deployment, we also run our products on fair large servers, so no problems on it however in development the things sometimes get hard. We reproduce our production environment in our development environment so we run a CoreOS VM and deploy each microservice as an individual docker container, it is ok to do it but you need a lot of memory resource

esnunes22:02:26

some people suggest microservice-first and others to postpone it till is really needed

esnunes22:02:09

at the company I work for we share microservices between projects, at least the ones that don't have a business logic attached to them like, user management, profile management, e-mail/sms/ios/android notifications, etc

esnunes22:02:03

the approach you are taking of having one big project that group all microservices is a good one, to simplify things you can try to create a small CLI tool to boot all microservices making it easy to add / remove services

jcromartie23:02:00

the hardest thing, I've found, is tracing logic

jcromartie23:02:31

the user wants to create a record, so it goes to service A, which in turn needs to store the record, so that calls service B, and after storing the record in datastore X, it puts a message on a queue service C, in order that the record can be indexed by service D into datastore Y, and finally the user can retrieve the record by hitting service E which retrieves the data from datastore Y

jcromartie23:02:16

so, tracing the flow of a single record through that is obviously going to be difficult

jcromartie23:02:23

because at every boundary is a network call

jcromartie23:02:32

and you can't tell what handles it on the other end

esnunes23:02:28

in order to identify this flow you can add a header on each request hop

jcromartie23:02:51

that's a good idea

esnunes23:02:16

you can even identify its order by concatenate them e.g.: 'id1.id2.id3.id4'

jaen23:02:23

That's called correlation id, I think?

esnunes23:02:54

I was searching for the name of it 😉

jcromartie23:02:14

I'll be reading up on that

esnunes23:02:46

I always try to make the microservices as dump as possible, they usually manage something using DDD concept

jaen23:02:02

+1 on for DDD

esnunes23:02:07

to connect the dots I create api gateways

jaen23:02:15

It' really worth reading up on that

esnunes23:02:36

the api gateways connect all microservices and add more business logic to them

jaen23:02:38

I'm currently reading Evans' book with Vaughan next in line; mostly read internet articles thus far

esnunes23:02:26

DDD + Ports & Adapters FTW

jaen23:02:01

If we're linking talks

jaen23:02:10

Evans on DDD and microservices

esnunes23:02:39

this guys also refers a lot Evans' book and "Building microservices" book

esnunes23:02:49

@jaen I will take a look on it

esnunes23:02:35

@jaen what about your experience, are you building microservices? If you do, what approach you are taking?

jaen23:02:06

Hah, I can't speak much in the way of practical experience; all I know is mostly theoretical.

jaen23:02:41

Didn't have any chance to build something complex enough for long enough that microservies would (IMO) start to make sense.

esnunes23:02:41

I guess that I do it a lot because of JS. I've managed a system with more than 100k lines of JS and it is not a good experience. Microservices help you keep things loosely coupled

esnunes23:02:38

nodejs has memory alloc limit, so you have to break it down in order to create a medium sized project

jaen23:02:24

Hah, I guess that could be a factor indeed

jcromartie23:02:22

I really appreciate all the resources. Thanks.

esnunes23:02:39

for everyone interested there is a channel #C0LT8HJ67