4 ms·

Microservices in Java – A Second Look

16 points by emforce 9y ago

empthought 9y ago
This line of argument to favor Go over Python or Java is just as valid as the line of argument to favor C over Go. Benchmark OpenBSD http + FastCGI C vs. this.
- paulddraper 9y ago
  THe better argument would be sane concurrency, which Go does better than nearly every other language.
  - merb 9y ago
    *without a library comparing any go concurrency with any java/whatever language concurrency still might lack behind. just java has so many concurrency libraries that are better than the built-in go concurrency mechanism. even java8 made things way better.
    - bsaul 9y ago
      I've recently regained interest in java, so i'm interested if could you give a brief explanation on the "better than built in go concurrency" ?
      - maltalex 9y ago
        I suggest you take a look at RxJava and Akka. RxJava is a reactive programming library from Netflix. Akka is a framework for writing applications using the actor model.
foxylion 9y ago
I don't get it. When you limit the memory of the java process it will be a _lot_ lower. A spring boot server can be started with -Xmx64m. Setting the memory limit to 200mb is more than enough to prevent OOM kills in Kubernetes. We run many spring boot services in that way. With absolutely no issues. Edit: just checked it, -Xmx32m is also usable.
- empthought 9y ago
  > A spring boot server can be started with -Xmx64m That would have required the author to read the manual and think about their problem for a few minutes, which is much less fun than justifying their already-formed preference after the fact.
  - foxylion 9y ago
    Yes... But such blog posts are terrible. They share bad knowledge and so many people trust such blog posts and make decisions based on this.
  - emforce 9y ago
    I believe I addressed this in the 4th paragraph of this article. I can't imagine many teams going back and optimizing their memory usage after they've deployed something to production. Unless you have capacity in your sprint to do some fine grained optimization of these things you'll most likely be looking at extending the platform or picking up potential feature requests. But even still, the point still stands whilst not to the same extreme. You have to actually to set this flag in order to reduce 64MB which is still 60+ times the size of a similar Go service and 3-4 times the size of a thin Java/Python application.
    - foxylion 9y ago
      What you forget is: You get so many features with Spring Boot and you can actually use them without increasing the memory footprint. Yes of course, for a single service with one endpoint that does nothing it is bloat. But which microservice does nothing? Think about a database backend, actuator endpoints, etc. They are all possible with a memory footprint of ~200mb. It can be less is you use another language, but I doubt that Go will give you such a major framework for developing a microservice. And this will save you a lot more time than taking an hour to reduce your memory footprint. And one thing you missed too: Using the JVM should also be combined with a basic knowledge about how the heap works. And if you do not limit it, it will get a lot bigger than required, this should be common knowledge. Comparing this to Go it seems like a much better way. In Go there is afaik no way to limit the heap. In worst case it will grow and grow and grow.
beders 9y ago
Did you just compare running a fully fledged server application framework with a simple Go and Python server? What was the point here?
- mmargerum 9y ago
  What would be in the “fully fledged server framework” that’s not in the Go standard library aside from sessions which is easily added with the gorilla library
  - cosminaut 9y ago
    The article's POM depends on spring-boot-starter-web. Here are some of the things you get with that: * Dependency Injection (@Autowire) * Externalized configuration (change app settings via CLI or environment variables) with profiles (think DEV,PROD) * Out of the box logging (think log levels, configurable per logger) * Remote administration via JMX (runtime administration) * An ORM (Hibernate) * A unit testing framework with mocking (JUnit, Hamcrest, Mockito) * Remote debugging via JVM debugging port Going beyond the simple app, you can take full advantage of the Spring Boot ecosystem of dependencies to pick and choose only the dependencies you need, while being able to do anything that a cloud app might need to do. If you don't need all that, you can always fall back to the simple HttpServer example he gives in the article and still get a small footprint. The article compares Java 8 to the others. I'd love to see a comparison to Java 9, where hopefully the modularization of the JVM will lead to a smaller overall runtime and memory footprint.
    - haglin 9y ago
      JDK 9 also comes with compact strings which can reduce the heap with 5-15%[1] and with -XX:+UseStringDeduplication, AppCDS and AOT the memory footprint can be reduced even more. [1] https://www.infoq.com/news/2016/02/compact-strings-Java-JDK9 https://www.infoq.com/news/2016/02/compact-strings-Java-JDK9

16 points by emforce 9y ago

This line of argument to favor Go over Python or Java is just as valid as the line of argument to favor C over Go. Benchmark OpenBSD http + FastCGI C vs. this.

paulddraper 9y ago
THe better argument would be sane concurrency, which Go does better than nearly every other language.
- merb 9y ago
  *without a library comparing any go concurrency with any java/whatever language concurrency still might lack behind. just java has so many concurrency libraries that are better than the built-in go concurrency mechanism. even java8 made things way better.
  - bsaul 9y ago
    I've recently regained interest in java, so i'm interested if could you give a brief explanation on the "better than built in go concurrency" ?
    - maltalex 9y ago
      I suggest you take a look at RxJava and Akka. RxJava is a reactive programming library from Netflix. Akka is a framework for writing applications using the actor model.

foxylion 9y ago

I don't get it. When you limit the memory of the java process it will be a _lot_ lower. A spring boot server can be started with -Xmx64m. Setting the memory limit to 200mb is more than enough to prevent OOM kills in Kubernetes. We run many spring boot services in that way. With absolutely no issues. Edit: just checked it, -Xmx32m is also usable.

empthought 9y ago
> A spring boot server can be started with -Xmx64m That would have required the author to read the manual and think about their problem for a few minutes, which is much less fun than justifying their already-formed preference after the fact.
- foxylion 9y ago
  Yes... But such blog posts are terrible. They share bad knowledge and so many people trust such blog posts and make decisions based on this.
- emforce 9y ago
  I believe I addressed this in the 4th paragraph of this article. I can't imagine many teams going back and optimizing their memory usage after they've deployed something to production. Unless you have capacity in your sprint to do some fine grained optimization of these things you'll most likely be looking at extending the platform or picking up potential feature requests. But even still, the point still stands whilst not to the same extreme. You have to actually to set this flag in order to reduce 64MB which is still 60+ times the size of a similar Go service and 3-4 times the size of a thin Java/Python application.
  - foxylion 9y ago
    What you forget is: You get so many features with Spring Boot and you can actually use them without increasing the memory footprint. Yes of course, for a single service with one endpoint that does nothing it is bloat. But which microservice does nothing? Think about a database backend, actuator endpoints, etc. They are all possible with a memory footprint of ~200mb. It can be less is you use another language, but I doubt that Go will give you such a major framework for developing a microservice. And this will save you a lot more time than taking an hour to reduce your memory footprint. And one thing you missed too: Using the JVM should also be combined with a basic knowledge about how the heap works. And if you do not limit it, it will get a lot bigger than required, this should be common knowledge. Comparing this to Go it seems like a much better way. In Go there is afaik no way to limit the heap. In worst case it will grow and grow and grow.

beders 9y ago

Did you just compare running a fully fledged server application framework with a simple Go and Python server? What was the point here?

mmargerum 9y ago
What would be in the “fully fledged server framework” that’s not in the Go standard library aside from sessions which is easily added with the gorilla library
- cosminaut 9y ago
  The article's POM depends on spring-boot-starter-web. Here are some of the things you get with that: * Dependency Injection (@Autowire) * Externalized configuration (change app settings via CLI or environment variables) with profiles (think DEV,PROD) * Out of the box logging (think log levels, configurable per logger) * Remote administration via JMX (runtime administration) * An ORM (Hibernate) * A unit testing framework with mocking (JUnit, Hamcrest, Mockito) * Remote debugging via JVM debugging port Going beyond the simple app, you can take full advantage of the Spring Boot ecosystem of dependencies to pick and choose only the dependencies you need, while being able to do anything that a cloud app might need to do. If you don't need all that, you can always fall back to the simple HttpServer example he gives in the article and still get a small footprint. The article compares Java 8 to the others. I'd love to see a comparison to Java 9, where hopefully the modularization of the JVM will lead to a smaller overall runtime and memory footprint.
  - haglin 9y ago
    JDK 9 also comes with compact strings which can reduce the heap with 5-15%[1] and with -XX:+UseStringDeduplication, AppCDS and AOT the memory footprint can be reduced even more. [1] https://www.infoq.com/news/2016/02/compact-strings-Java-JDK9 https://www.infoq.com/news/2016/02/compact-strings-Java-JDK9