4 ms·

I don’t know, is using micro services and a message bus “keeping it simple, stupid”? So far I’ve yet to see a micro services architecture that I don’t think is

I don’t know, is using micro services and a message bus “keeping it simple, stupid”? So far I’ve yet to see a micro services architecture that I don’t think is massively over-engineered. Also you can write your over engineered micro services perfectly fine in Java. There are even very nice tools for that specially designed for Java.

jimbokun 6y ago
My company had a massive, over-engineered monolith that we broke down into more sensible microservices, and the architecture is now much cleaner and easier to maintain, scale, etc. I agree, though, that designing as microservices up front is generally premature optimization, as your initial guesses for where to put the boundaries between the services is likely to be wrong. Both the monolith and the microservices are written in Java with Spring Boot, but I agree with the author that Spring especially leads to runtime code that is extremely difficult for developers to really understand. I am curious whether writing future microservices in a language like Go might be more maintainable in the long run.
- koufatz 6y ago
  I would not agree that Go is a good replacement for Java Microservices. I would suggest looking into something like Quarkus (https://quarkus.io https://quarkus.io) and if Java is to verbose for someone, she/he can checkout Kotlin (https://kotlinlang.org https://kotlinlang.org) which is 100% interoperable with Java but clean, modern and pragmatic. With Quarkus you have a very powerful but simple framework that out of the box (GraalVM) can be compiled also to a single binary if you need very fast startup and very low memory consumption. Go evangelises simplicity but when someone has to use it in a bigger project the lang is very cumbersome. You don't have any functional programming features like filter, map, find to manipulate collections. The not null (nil) safety or the magic with interfaces{} does it make non safe especially compared to modern languages like Kotlin,Swift which have the notion of nullability build in the language itself. Dependency Injection support is very limited. I think Go is hyped because of the excellent single binary feature which you have nowadays via GraalVM also for Java, Kotlin as I described above.
  - deleted 6y ago
    [deleted]
- kasperni 6y ago
  > My company had a massive, over-engineered monolith that we broke down into more sensible microservices, and the architecture is now much cleaner and easier to maintain, scale, 5 years from now you will go from a massive, over-engineered micro service architecture. To a well designed modular monolith that is much cleaner and easier to maintain, scale, etc.
- phendrenad2 6y ago
  That's the thing though. If you have an overengineered or spaghetti-code monolith, often you can get management buy-in to rewrite it by saying "microservices"! Likewise, if you have an over-engineered or spaghetti-code set of microservices, often you can get management buy-in to rewrite by saying "microservices were a fad, we need tighter integration". The style you rewrote in didn't solve your problem, the act of rewriting did.

jimbokun 6y ago

My company had a massive, over-engineered monolith that we broke down into more sensible microservices, and the architecture is now much cleaner and easier to maintain, scale, etc. I agree, though, that designing as microservices up front is generally premature optimization, as your initial guesses for where to put the boundaries between the services is likely to be wrong. Both the monolith and the microservices are written in Java with Spring Boot, but I agree with the author that Spring especially leads to runtime code that is extremely difficult for developers to really understand. I am curious whether writing future microservices in a language like Go might be more maintainable in the long run.

koufatz 6y ago
I would not agree that Go is a good replacement for Java Microservices. I would suggest looking into something like Quarkus (https://quarkus.io https://quarkus.io) and if Java is to verbose for someone, she/he can checkout Kotlin (https://kotlinlang.org https://kotlinlang.org) which is 100% interoperable with Java but clean, modern and pragmatic. With Quarkus you have a very powerful but simple framework that out of the box (GraalVM) can be compiled also to a single binary if you need very fast startup and very low memory consumption. Go evangelises simplicity but when someone has to use it in a bigger project the lang is very cumbersome. You don't have any functional programming features like filter, map, find to manipulate collections. The not null (nil) safety or the magic with interfaces{} does it make non safe especially compared to modern languages like Kotlin,Swift which have the notion of nullability build in the language itself. Dependency Injection support is very limited. I think Go is hyped because of the excellent single binary feature which you have nowadays via GraalVM also for Java, Kotlin as I described above.
- deleted 6y ago
  [deleted]
kasperni 6y ago
> My company had a massive, over-engineered monolith that we broke down into more sensible microservices, and the architecture is now much cleaner and easier to maintain, scale, 5 years from now you will go from a massive, over-engineered micro service architecture. To a well designed modular monolith that is much cleaner and easier to maintain, scale, etc.
phendrenad2 6y ago
That's the thing though. If you have an overengineered or spaghetti-code monolith, often you can get management buy-in to rewrite it by saying "microservices"! Likewise, if you have an over-engineered or spaghetti-code set of microservices, often you can get management buy-in to rewrite by saying "microservices were a fad, we need tighter integration". The style you rewrote in didn't solve your problem, the act of rewriting did.