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

I should probably tinker with something else

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

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.

I think it might be the project

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

-_-

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

Is there even a definition for "microservices"

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

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

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

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

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

it gets hairy

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

and they all run on the same machine

no scaling

I get frustrated with the whole thing quite easily

and each of them in a separate jvm?

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

in production, I think they are in separate processes

but in dev they are all just in one process

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

sounds like pain

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

though actually it's load balanced

i’d prefer to have one codebase and 22 builds

but everything runs at once on those load balanced machines

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

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

src, test, and resources directories, that is

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

call it "lein macroservice"

hah

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

@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

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

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

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

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

like

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

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

because at every boundary is a network call

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

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

that's a good idea

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

That's called correlation id, I think?

yes

I was searching for the name of it 😉

thanks @jaen

I'll be reading up on that

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

+1 on for DDD

to connect the dots I create api gateways

It' really worth reading up on that

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

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

I highly recommend this talk too: http://www.infoq.com/presentations/ddd-microservices

DDD + Ports & Adapters FTW

If we're linking talks

https://www.youtube.com/watch?v=yPvef9R3k-M

Evans on DDD and microservices

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

@jaen I will take a look on it

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

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

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

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

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

Hah, I guess that could be a factor indeed

I really appreciate all the resources. Thanks.

for everyone interested there is a channel #C0LT8HJ67