Is Java hopeless for microservices

And the Winner is: Spring (Boot)

  1. Items:Open source project: Oracle wants to release Java EE
  2. Subjects:Oracle, Apache, Eclipse, Java, Linux, Linux distribution, programming language, Red Hat, server applications, IBM

  1. Forums
  2. > Comments
  3. ›Software development
  4. ›All comments on the article
  5. ›Open source project ...
  1. theme

New topic Change view


  1. And the Winner is: Spring (Boot)

    Author: rsaddey 18.08.17 - 18:32

    When EE 7 came out with CDI, I still thought: That was it with Spring. First the bankruptcy with Grails and now completely redundant.

    Not even close!

    A binding collection of standards and their implementations can only be hopelessly out of date and at the same time too expensive if it takes into account everything that should be potentially usable. The fragmentation in profiles doesn't really help either.

    Spring goes the opposite way: Instead of prescribing everything for everyone as in laws, it offers a lean foundation and set of rules to combine (almost) any technology from any source into an individual solution so that it can be used anywhere in the world (where a specified Java VM exists) delivers the same reproducible and scalable results.

    To the Philosopher's Stone in three steps:

    1. In the beginning, unmaintainable code was replaced by unmaintainable XML, Teufel was exchanged for Beelzebub.

    2. Then came the era of annotations. Both aspects, implementation and configuration could again be expressed within one language world, but required total knowledge of everything until even a flat chat application with user administration was running.

    3. Finally, Spring Boot came, to automagically glue the technical (self-implemented) pieces of the mosaic of an application with an abundance of common aspects to an executable application. Together with Coding by Convention, the Bird of Paradise Grails has become obsolete through Spring Boot and (together with its IDE) has been thrown far and wide.

    Back to the roots: java -jar rules :-)

    Also here: https://trends.google.com/trends/explore?date=today%205-y&geo=US&q=grails,spring%20boot,java%20ee

    EE is undead, like the Cobol vampire before, but foreseeably headed for the Cliff. What can only mean for a for-profit company like Oracle: Toxic, sell off immediately, sell for a dollar.

  2. Re: And the Winner is: Spring (Boot)

    Author: werpu 18.08.17 - 21:00

    Spring boot is indeed a good approach also with regard to a micro service architecture, since you only integrate what you really need and boot takes care of the necessary dependencies in cooperation with Maven. By the way, there is a similar project in the JEE environment. I see Spring Boot as the next step in the EE environment.

    Btw. I don't consider microservices to be the holy grail as which it is being pushed. You only move the susceptibility to errors from one instance that is halfway manageable to many server instances and the administration.
    The resource requirement increases enormously because you have to roll out many small server instances with the same libs. The admin effort increases enormously because instead of one server that is clustered, you suddenly have 20 that you have to cluster.
    The approach is not so dissimilar to what used to be done with remote EJBs and before that with Corba or in between with SOAP and SOA. For many projects you have not become happy with it every time.
    Where microservices really solve a lot is in the NodeJS sector, where you can deal with the single threaded problem at high loads.

  3. Re: And the Winner is: Spring (Boot)

    Author: rsaddey 20.08.17 - 21:14

    werpu wrote:
    --------------------------------------------------------------------------------

    > Btw. I don't consider microservices to be the holy grail as it is
    > is pushed. You just shift the susceptibility to errors from one instance
    > The halfway to handle is in many server instances and the
    > Administration.
    > The need for resources increases enormously because there are many small
    > Must roll out server instances with the same libs. The admin effort increases
    > also enormous because instead of a server, the clustered one suddenly becomes 20
    > has to be clustered.
    > The approach is not so dissimilar as it used to be with remote EJBs
    > and before that with Corba or in between with SOAP and SOA.
    > Every time for many projects you have not become happy with it.
    > Where microservices really solve a lot is in the NodeJS sector where you can do that
    > Can handle single threaded problem at high load.

    Microservices are not a philosopher's stone for the "stupid" (no more than x classes and y lines), but architecture rules that reduce the tendency of (even state-of-the-art SOA) monoliths to become octopus-like "everything-depends-on." -allem-ab "(and that through all layers down to persistence) monsters propagated again in maintainable and scalable, and largely self-contained subsystems.

    Here (already known) problem classes come to the fore again, e.g. configuration and orchestration, which could still be covered by ESB in the classic SOA environment, but now no longer exclusively manual (by admins in the role of air traffic controllers) due to the sheer abundance of services ) can be mastered.

    How the concept of microservices is actually implemented is not eternally predetermined by God. The waste of resources you criticize through redundant artifacts characterizes a certain procedure, e.g. "We do that with Docker or Kuberxyz". But here, too, something is happening, e.g. "Serverless Computing", which I had initially and verbatim completely misunderstood :-)

    For me, microservices are a set of rules that allow complex (growing) systems to be broken down into manageable (especially maintainable and scalable) units. I see Amazon (the sales platform) as a prime example: https://www.tigerteam.dk/wp-content/uploads/2015/02/Composite-UI-Amazon.png

  4. Re: And the Winner is: Spring (Boot)

    Author: Lord Gamma 24.08.17 - 22:05

    werpu wrote:
    --------------------------------------------------------------------------------
    > ... Maven ...

    Gradle vs Maven: Performance Comparison: [gradle.org] ;-)

    "This GIF shows the clean build scenario side-by-side so you can get a feel for the difference (without build cache)."
    left gradle, right maven:




    Edited 1 times, last on 8/24/17 10:16 PM by Lord Gamma.

  1. theme

New topic Change view


To comment, please log in or register. You must also go to your account profile under Forum have assigned a username. To the login

© 1997-2021 Golem.de. All rights reserved.