vertx vs Java EE 7
2,176 views
Skip to first unread message
J Guedouar
Jan 20, 2016, 10:33:57 AM1/20/16
to vert.x
Hello,
As I have to start soon a new project, we will test a new type of architecture: the micro services.
We have to choose between Java EE 7 and Vertx.
I wanted to know what are the advantages using Vertx over JavaEE7, as far as I know I will compare this like:
vertx: ( micro server )
verticle ( modules ) non-blocking full async framework using an EventBus to exchange data between verticles.
We need to use modules/extensions in order to use DI, JDBC, security, SMTP, ....
Also there is no JPA like extension on vertx, writing SQL queries by hand is a little... deprecated...
JavaEE7: ( we can also use micro server like wildfly-swarm )
Non blocking - Async can be done via:
REST with @Async and @Suspended annotations ( Jersey 2 supports it )
@Resource(name = "DefaultManagedExecutorService")
ManagedExecutorService executor
We can use JMS for the EventBus.
We can add RxJava for parallel calls.
No need to use extensions because JavaEE stack already include REST, DI, SMTP, JMS, ...
Here we can find a good exemple of JavaEE 7 + RxJava:
http://www.lordofthejars.com/2014/07/rxjava-java8-java-ee-7-arquillian-bliss.html
Also is it possible for vetx verticles to talk each other on the event bus on different locations ?
Example:
10.254.151.5 verticle 1
194.165.154.5 verticle 2
verticle 1 sends message on eventbus, verticle 2 can catch it ?
So in conclusion, I wanted to know what is the advantage using vertx over JavaEE for microservices when a Java Developer is on the story. ( Suppose we don't care about polyglot )
Thank you !
As I have to start soon a new project, we will test a new type of architecture: the micro services.
We have to choose between Java EE 7 and Vertx.
I wanted to know what are the advantages using Vertx over JavaEE7, as far as I know I will compare this like:
vertx: ( micro server )
verticle ( modules ) non-blocking full async framework using an EventBus to exchange data between verticles.
We need to use modules/extensions in order to use DI, JDBC, security, SMTP, ....
Also there is no JPA like extension on vertx, writing SQL queries by hand is a little... deprecated...
JavaEE7: ( we can also use micro server like wildfly-swarm )
Non blocking - Async can be done via:
REST with @Async and @Suspended annotations ( Jersey 2 supports it )
@Resource(name = "DefaultManagedExecutorService")
ManagedExecutorService executor
We can use JMS for the EventBus.
We can add RxJava for parallel calls.
No need to use extensions because JavaEE stack already include REST, DI, SMTP, JMS, ...
Here we can find a good exemple of JavaEE 7 + RxJava:
http://www.lordofthejars.com/2014/07/rxjava-java8-java-ee-7-arquillian-bliss.html
Also is it possible for vetx verticles to talk each other on the event bus on different locations ?
Example:
10.254.151.5 verticle 1
194.165.154.5 verticle 2
verticle 1 sends message on eventbus, verticle 2 can catch it ?
So in conclusion, I wanted to know what is the advantage using vertx over JavaEE for microservices when a Java Developer is on the story. ( Suppose we don't care about polyglot )
Thank you !
J Guedouar
Jan 22, 2016, 5:21:01 AM1/22/16
to vert.x
Nobody wants to participate on the discussion ?
Paulo Lopes
Jan 22, 2016, 5:49:59 AM1/22/16
to vert.x
Hi,
Your comparison is not that trivial, mostly because JavaEE and Vert.x are two different projects and aim at different problems although have some small overlap of features.
When you speak of micro-services I assume you're referring to a HTTP server serving a REST API. This is also a very simplistic view, a micro service is not required to be an HTTP server. [1]
The same way you add components to your swarm project on you can add to vert.x. In fact all vert.x modules are also maven modules, for example, adding database support is just adding to your pom the JDBC client or the async client if you prefer and an RDBMS driver.
Since async in vert.x is true (not run on a thread-pool) [2] you will probably have better scalability from vert.x, however, this requires a benchmark and every problem is different so you will not find a good/valid benchmark until you make a prototype of your app.
The Vert.x cluster can be composed of nodes all around the world or processes on the same machine, it does not matter, of course, you'll face higher latency with nodes distributed across the world but that is a fact no matter which cluster you're building.
Vert.x proxygen gives you a way to define a contract. Something that SOA tried to solve but we all end up hating :) With vert.x (if you want) you can define your contract as a java interface we will compile bindings for all languages and even allow its use across the bridges. This is a feature you won't see in other microservice frameworks.
Vert.x is built on top of HA, when a node dies it can respawn somewhere else in the cluster and even have a quorum of nodes of for specific service/task. Usually, you need some extra tooling and monitoring to get this on other frameworks.
Vert.x allows you to have simple deployments, we can build a fat jar and even run with just 10MB of RAM on a raspberry pi 2 for example. This number will be hard to achieve for other frameworks for sure (I'm not counting nodejs or python, just javaEE ones).
Vert.x is message driven and the defacto message format is JSON this allows us to bridge vert.x event bus to external apps running on the JVM as well node and C or even android, it will be hard for other frameworks to form clusters and send/receive messages if the framework is not embedded within the 3rd party app.
The event bus bridge can even be done without the need to embed or write code, for example, you can bridge the event bus to ActiveMQ or any message queue system that speaks stomp protocol.
Monitoring and metrics are also present we can bridge with drop wizard metrics, hawkular, etc...
Logging we can log to log stash or whatever you prefer so your ops team will be able to monitor and act in order to keep your app healthy
This are not all the features, but some i can just enumerate out of my head in a minute or two... this would give you already a good start for a comparison.
[1] https://en.wikipedia.org/wiki/Microservices
[2] unless some special cases such as worker threads or when in last resort when the underlying API is blocking
Your comparison is not that trivial, mostly because JavaEE and Vert.x are two different projects and aim at different problems although have some small overlap of features.
When you speak of micro-services I assume you're referring to a HTTP server serving a REST API. This is also a very simplistic view, a micro service is not required to be an HTTP server. [1]
The same way you add components to your swarm project on you can add to vert.x. In fact all vert.x modules are also maven modules, for example, adding database support is just adding to your pom the JDBC client or the async client if you prefer and an RDBMS driver.
Since async in vert.x is true (not run on a thread-pool) [2] you will probably have better scalability from vert.x, however, this requires a benchmark and every problem is different so you will not find a good/valid benchmark until you make a prototype of your app.
The Vert.x cluster can be composed of nodes all around the world or processes on the same machine, it does not matter, of course, you'll face higher latency with nodes distributed across the world but that is a fact no matter which cluster you're building.
Vert.x proxygen gives you a way to define a contract. Something that SOA tried to solve but we all end up hating :) With vert.x (if you want) you can define your contract as a java interface we will compile bindings for all languages and even allow its use across the bridges. This is a feature you won't see in other microservice frameworks.
Vert.x is built on top of HA, when a node dies it can respawn somewhere else in the cluster and even have a quorum of nodes of for specific service/task. Usually, you need some extra tooling and monitoring to get this on other frameworks.
Vert.x allows you to have simple deployments, we can build a fat jar and even run with just 10MB of RAM on a raspberry pi 2 for example. This number will be hard to achieve for other frameworks for sure (I'm not counting nodejs or python, just javaEE ones).
Vert.x is message driven and the defacto message format is JSON this allows us to bridge vert.x event bus to external apps running on the JVM as well node and C or even android, it will be hard for other frameworks to form clusters and send/receive messages if the framework is not embedded within the 3rd party app.
The event bus bridge can even be done without the need to embed or write code, for example, you can bridge the event bus to ActiveMQ or any message queue system that speaks stomp protocol.
Monitoring and metrics are also present we can bridge with drop wizard metrics, hawkular, etc...
Logging we can log to log stash or whatever you prefer so your ops team will be able to monitor and act in order to keep your app healthy
This are not all the features, but some i can just enumerate out of my head in a minute or two... this would give you already a good start for a comparison.
[1] https://en.wikipedia.org/wiki/Microservices
[2] unless some special cases such as worker threads or when in last resort when the underlying API is blocking
Arnaud Estève
Jan 22, 2016, 6:21:55 AM1/22/16
to vert.x
Hi !
From a very quick look, it sounds to me like the main difference between Vert.x and JavaEE7 is the threading model, but I'm absolutely not sure about that and I'd like to read some reliable info about it before writing nonsense.
Do you have any pointer to the threading model in JavaEE 7 ? Is the reactor pattern involved somewhere ? Is there an event loop runiing on OS-threads only or is this just green threading with a worker pool thread ? (and in this case I would not understand what @Async does)
-------
Re. other stuff :
A major difference still is that Vert.x is a toolkit. Not a spec. not a way of doing things implemented by vendors, etc.
You don't need an application server, a container, you don't need to rely on any other piece of software. You don't write an application to be run against some server, you're building a self-running application : a jar. Adn every microservice can be just that : a runnable.
There's also a major difference to me, int the granularity in integration testing.
In both world you can just unit test your classes, methods, ... In both worlds you can use high-level (funcitonal) integration tests to assert everything works well.
But there are more "layers" in testing with Vert.x. Since a verticle (a deployment unit in Vert.x) can be deployed programmatically, it allows you to write tests agaist this verticle and nothing else. Isolating side-effects. That helps a lot (really) with developping, separating concerns, and especially debugging your software.
Since a verticle pretty much has a contract (answering to the event bus, pushing updates within a websocket). You can test it reacts how you wanted it, to external signals (event bus messages, incoming http requests, ...).
Since everything is programmatic in Vert.x, to write this kind of tests you don't need any annotation, mocking framework, or whatever. It's just basic programming. You have access to the Vert.x toolbox, just mock what you need to, just send the signals you want to.
Such "intermediate" testing layers are very helpful when your application stack starts to grow and you have complex user stories. Even if you isolate a chain of events that lead you to a major failure (which is already hard) there's no guarantee you'll be able to write a single, isolated test case that reproduces this issue (because you'll have to mock JMS, then mock something else, and so on). I've never face such an issue with Vert.x.
Last example I have in mind : I had to deal with a malformed http response from an external API endpoint : how to reproduce that in a single test ? writing : vertx.createHttpServer(...).requestHandler(...).listen() (basically : mocking the external endpoint), at the top of the test and I was good to go. Simple, straightforward, flexible.
I have other stuff in mind, but I'd like to focus on the threading stuff before anything else.
Hope this helps you, that's a very interesting question.
On Friday, January 22, 2016 at 11:21:01 AM UTC+1, J Guedouar wrote:
J Guedouar
Jan 22, 2016, 6:41:51 AM1/22/16
to vert.x
Nice comment Arnaud,
This is true for what you mentionned but you should know that companies are trying to use standards and vertx is again another "tool" with an "unknown" future.
Let me explain, if the project dies tomorrow, all the apps using "verticles" will die too, also I don't know if Vertx offers Enterprise support ? This is a very important point for professionals.
For the micro service, the fat jar, do you know these JavaEE micro servers:
http://wildfly-swarm.io/
https://dzone.com/articles/how-micro-is-payara-micro-1 ( 17mb heap only !!!!! )
So JavaEE is also ready for micro services and mocking services like JMS or other modules is not a problem for a strong Java developer.
The EventBus of vertx is exactly the same behavior as the JMS which has been implemented since..... many years !
Also you should see this example:
http://www.lordofthejars.com/2014/07/rxjava-java8-java-ee-7-arquillian-bliss.html
We can perfectly do the same as vertx with Java EE 7 and RxJava !
Vertx also uses some specific concepts ( verticles, workers, eventbus, ...), so its not standard and it forces developers to learn again new stuffs. ( its like JavaEE vs Spring )
Also the argument of polyglot is a not really concerning everybody, there are always some experts in specific languages.
Anyway, I am not against vertx but I really want to know what he brings ( expect the easy dev/code ) for a company that want to make aync/reactive apps based on Java.
And last thing: I don't hear from any big companies like NetFlix, Google, FB, Twitter.... that uses Vertx...
So what are the big production applications thats uses Vertx today ? And thaht can really proves thaht the benchmarks are even better than JavaEE/Java8 ?
This is the same discussion when people says: NodeJS will replace Java servers, this is simply a joke because I am a JavaEE professional developer and I never see in my career this kind of proposition.
Interesting topic :)
This is true for what you mentionned but you should know that companies are trying to use standards and vertx is again another "tool" with an "unknown" future.
Let me explain, if the project dies tomorrow, all the apps using "verticles" will die too, also I don't know if Vertx offers Enterprise support ? This is a very important point for professionals.
For the micro service, the fat jar, do you know these JavaEE micro servers:
http://wildfly-swarm.io/
https://dzone.com/articles/how-micro-is-payara-micro-1 ( 17mb heap only !!!!! )
So JavaEE is also ready for micro services and mocking services like JMS or other modules is not a problem for a strong Java developer.
The EventBus of vertx is exactly the same behavior as the JMS which has been implemented since..... many years !
Also you should see this example:
http://www.lordofthejars.com/2014/07/rxjava-java8-java-ee-7-arquillian-bliss.html
We can perfectly do the same as vertx with Java EE 7 and RxJava !
Vertx also uses some specific concepts ( verticles, workers, eventbus, ...), so its not standard and it forces developers to learn again new stuffs. ( its like JavaEE vs Spring )
Also the argument of polyglot is a not really concerning everybody, there are always some experts in specific languages.
Anyway, I am not against vertx but I really want to know what he brings ( expect the easy dev/code ) for a company that want to make aync/reactive apps based on Java.
And last thing: I don't hear from any big companies like NetFlix, Google, FB, Twitter.... that uses Vertx...
So what are the big production applications thats uses Vertx today ? And thaht can really proves thaht the benchmarks are even better than JavaEE/Java8 ?
This is the same discussion when people says: NodeJS will replace Java servers, this is simply a joke because I am a JavaEE professional developer and I never see in my career this kind of proposition.
Interesting topic :)
Tim Fox
Jan 22, 2016, 7:05:33 AM1/22/16
to ve...@googlegroups.com
This is beginning to sound like a
JavaEE sales-pitch but I'll bite...
On 22/01/16 11:41, J Guedouar wrote:
Nice comment Arnaud,
This is true for what you mentionned but you should know that companies are trying to use standards
As the old adage goes: The good thing about standards is there are
so many to choose from ;)
The truth about JavaEE as a standard is it has never been that easy to migrate a JavaEE from one app server to another as inevitably the app is using implementation specific features.
And some of the most popular software in middleware (e.g. Spring) is not standards based. I've always been a believer that the "standards are important" argument is massively overrated.
The truth about JavaEE as a standard is it has never been that easy to migrate a JavaEE from one app server to another as inevitably the app is using implementation specific features.
And some of the most popular software in middleware (e.g. Spring) is not standards based. I've always been a believer that the "standards are important" argument is massively overrated.
and vertx is again another "tool" with an "unknown" future.
Let me explain, if the project dies tomorrow, all the apps using "verticles" will die too, also I don't know if Vertx offers Enterprise support ? This is a very important point for professionals.
For the micro service, the fat jar, do you know these JavaEE micro servers:
http://wildfly-swarm.io/
https://dzone.com/articles/how-micro-is-payara-micro-1 ( 17mb heap only !!!!! )
Vert.x is one of the pioneers of pushing a microservices based model
before it became fashionable and everyone has now jumped on the
bandwagon. Wildfly swarm is basically an app server deployed as a
fatjar - so if you like app servers that's great.
Vert.x fatjars are typically significantly more lightweight and pull in far fewer dependencies than app servers repackaged as fatjars as Vert.x was built from day 1 for this kind of model - it hasn't been retrofitted on a later date.
Vert.x fatjars are typically significantly more lightweight and pull in far fewer dependencies than app servers repackaged as fatjars as Vert.x was built from day 1 for this kind of model - it hasn't been retrofitted on a later date.
So JavaEE is also ready for micro services and mocking services like JMS or other modules is not a problem for a strong Java developer.
The main issue JavaEE has in terms of APIs is most of it is still
blocking. Sure, there is some async stuff (especially in recent
additions), but it's still very difficult to write a completely
async JavaEE app. And... even if you do manage it, then often the
async implementation in JavaEE app servers are just thread pools
wrapping blocking IO, so you still have the scalability issues.
Vert.x has been engineered from day one to be non blocking from end
to end, so it scales amazingly well.
The EventBus of vertx is exactly the same behavior as the JMS which has been implemented since..... many years !
This is not really true (and I wrote the JMS implementation that's
in Wildfly ;) ).
There are parts of JMS that are async, but there's also a lot of stuff in JMS which is synchronous, so you have your scalability issue again. Also the Vert.x event bus is a p2p messaging system, whereas JMS requires servers to be running. Having to deploy JMS servers to get your app to work is very un-microservicey .
There are parts of JMS that are async, but there's also a lot of stuff in JMS which is synchronous, so you have your scalability issue again. Also the Vert.x event bus is a p2p messaging system, whereas JMS requires servers to be running. Having to deploy JMS servers to get your app to work is very un-microservicey .
Also you should see this example:
http://www.lordofthejars.com/2014/07/rxjava-java8-java-ee-7-arquillian-bliss.html
We can perfectly do the same as vertx with Java EE 7 and RxJava !
Vertx also uses some specific concepts ( verticles, workers, eventbus, ...), so its not standard and it forces developers to learn again new stuffs. ( its like JavaEE vs Spring )
How terrible! Developers having to learn new stuff ;)
The truth is good developers _want_ to learn new stuff. They want to keep up with the latest developments so their CVs can remain relevant.
One issue that we here from our users is that some of the best developers just don't want to do JavaEE any more as it's seen as yesterday's tech, so using JavaEE can actually be an obstacle to attracting and retaining the best devs.
The truth is good developers _want_ to learn new stuff. They want to keep up with the latest developments so their CVs can remain relevant.
One issue that we here from our users is that some of the best developers just don't want to do JavaEE any more as it's seen as yesterday's tech, so using JavaEE can actually be an obstacle to attracting and retaining the best devs.
Also the argument of polyglot is a not really concerning everybody, there are always some experts in specific languages.
Anyway, I am not against vertx but I really want to know what he brings ( expect the easy dev/code ) for a company that want to make aync/reactive apps based on Java.
And last thing: I don't hear from any big companies like NetFlix, Google, FB, Twitter.... that uses Vertx...
Did you look on the web-site? We have a whole page on that (and
that's just a small selection of our users).
Our production users include many of the biggest banks in the world, the largest retailers in the world and other very high volume sites such as TicketMaster
Our production users include many of the biggest banks in the world, the largest retailers in the world and other very high volume sites such as TicketMaster
--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/b666472e-d58b-49f4-8b07-4979b93e756c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Mark Little
Jan 22, 2016, 7:21:46 AM1/22/16
to ve...@googlegroups.com
On 22 Jan 2016, at 12:05, Tim Fox <timv...@gmail.com> wrote:This is beginning to sound like a JavaEE sales-pitch but I'll bite…
On 22/01/16 11:41, J Guedouar wrote:
Nice comment Arnaud,
This is true for what you mentionned but you should know that companies are trying to use standards
As the old adage goes: The good thing about standards is there are so many to choose from ;)
The truth about JavaEE as a standard is it has never been that easy to migrate a JavaEE from one app server to another as inevitably the app is using implementation specific features.
That’s not peculiar to JavaEE though - all standards have areas where they are underspecified, and often deliberately, to give vendors the option to provide extensions. And then some standards have optional features, which makes portability even harder.
And some of the most popular software in middleware (e.g. Spring) is not standards based. I've always been a believer that the "standards are important" argument is massively overrated.
YMMV. Standards for portability are a good thing in general but people need to understand their limitations. Standards for interoperability are typically more useful on a day-to-day basis. Some standards try to address both (e.g., CORBA). Some take a stand on only one. JavaEE (or J2EE back in the day) did try to tackle both, by adding in CORBA IIOP for interoperability and there’s an argument it did a better job of interop than portability in the early days. Over the years the interop vs portability aspect of JavaEE switched and now IIOP is optional.
However, I agree with what I think is your sentiment: standards are not a global panacea. They’re important but they won’t solve all of your problems.
and vertx is again another "tool" with an "unknown" future.
Let me explain, if the project dies tomorrow, all the apps using "verticles" will die too, also I don't know if Vertx offers Enterprise support ? This is a very important point for professionals.
For the micro service, the fat jar, do you know these JavaEE micro servers:
http://wildfly-swarm.io/
https://dzone.com/articles/how-micro-is-payara-micro-1 ( 17mb heap only !!!!! )
Vert.x is one of the pioneers of pushing a microservices based model before it became fashionable and everyone has now jumped on the bandwagon. Wildfly swarm is basically an app server deployed as a fatjar - so if you like app servers that's great.
Agreed, though Swarm builds strip a lot out of WildFly when creating the fatjar.
Vert.x fatjars are typically significantly more lightweight and pull in far fewer dependencies than app servers repackaged as fatjars as Vert.x was built from day 1 for this kind of model - it hasn't been retrofitted on a later date.
So JavaEE is also ready for micro services and mocking services like JMS or other modules is not a problem for a strong Java developer.
The main issue JavaEE has in terms of APIs is most of it is still blocking. Sure, there is some async stuff (especially in recent additions), but it's still very difficult to write a completely async JavaEE app. And... even if you do manage it, then often the async implementation in JavaEE app servers are just thread pools wrapping blocking IO, so you still have the scalability issues. Vert.x has been engineered from day one to be non blocking from end to end, so it scales amazingly well.
+1
The EventBus of vertx is exactly the same behavior as the JMS which has been implemented since..... many years !
This is not really true (and I wrote the JMS implementation that's in Wildfly ;) ).
Well I think it’s more accurate to say you had an important hand in creating JBossMessaging and HornetQ, as you were the project(s) lead, and wrote significant chunks of the code while you held that position. However, let’s give the whole team a bit of credit where it’s due :)
There are parts of JMS that are async, but there's also a lot of stuff in JMS which is synchronous, so you have your scalability issue again. Also the Vert.x event bus is a p2p messaging system, whereas JMS requires servers to be running. Having to deploy JMS servers to get your app to work is very un-microservicey .
Also you should see this example:
http://www.lordofthejars.com/2014/07/rxjava-java8-java-ee-7-arquillian-bliss.html
We can perfectly do the same as vertx with Java EE 7 and RxJava !
Vertx also uses some specific concepts ( verticles, workers, eventbus, ...), so its not standard and it forces developers to learn again new stuffs. ( its like JavaEE vs Spring )
How terrible! Developers having to learn new stuff ;)
The truth is good developers _want_ to learn new stuff. They want to keep up with the latest developments so their CVs can remain relevant.
One issue that we here from our users is that some of the best developers just don't want to do JavaEE any more as it's seen as yesterday's tech, so using JavaEE can actually be an obstacle to attracting and retaining the best devs.
Also the argument of polyglot is a not really concerning everybody, there are always some experts in specific languages.
Anyway, I am not against vertx but I really want to know what he brings ( expect the easy dev/code ) for a company that want to make aync/reactive apps based on Java.
And last thing: I don't hear from any big companies like NetFlix, Google, FB, Twitter.... that uses Vertx...
Did you look on the web-site? We have a whole page on that (and that's just a small selection of our users).
+1
And Apple uses Netty extensively and we all know how important Netty is to Vert.x. Not suggesting Apple should be listed as a Vert.x user, but I still think it’s (almost) relevant :)
Our production users include many of the biggest banks in the world, the largest retailers in the world and other very high volume sites such as TicketMaster
+1
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/56A21B07.9040205%40gmail.com.
Tim Fox
Jan 22, 2016, 7:31:11 AM1/22/16
to ve...@googlegroups.com
Fair enough. I didn't mean to imply I single handedly wrote it!
But when I left I was by far the largest contributor and it seems I'm still one of the biggest contributors even though I haven't contributed for over 5 years ;)
https://github.com/hornetq/hornetq/graphs/contributors
But that aside, the point I was trying to make was that the Vert.x event bus is very different from JMS and I'm saying that as someone who has worked deeply with both.
But when I left I was by far the largest contributor and it seems I'm still one of the biggest contributors even though I haven't contributed for over 5 years ;)
https://github.com/hornetq/hornetq/graphs/contributors
But that aside, the point I was trying to make was that the Vert.x event bus is very different from JMS and I'm saying that as someone who has worked deeply with both.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/65481BD3-6E51-4FBA-8D4B-1CB54BC17997%40gmail.com.
Mark Little
Jan 22, 2016, 7:32:51 AM1/22/16
to ve...@googlegroups.com
On 22 Jan 2016, at 12:31, Tim Fox <timv...@gmail.com> wrote:Well I think it’s more accurate to say you had an important hand in creating JBossMessaging and HornetQ, as you were the project(s) lead, and wrote significant chunks of the code while you held that position. However, let’s give the whole team a bit of credit where it’s due :)
Fair enough. I didn't mean to imply I single handedly wrote it!
But when I left I was by far the largest contributor and it seems I'm still one of the biggest contributors even though I haven't contributed for over 5 years ;)
Agreed. That’s what I meant by “significant chunks”. :)
https://github.com/hornetq/hornetq/graphs/contributors
But that aside, the point I was trying to make was that the Vert.x event bus is very different from JMS and I'm saying that as someone who has worked deeply with both.
+1
J Guedouar
Jan 22, 2016, 8:05:42 AM1/22/16
to vert.x
Thank you Tim for your comments,
I am just playing now the evil advocate :)
But for the support, what happens if a company has a problem with Vertx ? They should rely on this community forum ? If yes then its a risk...
Most of JavaEE vendors have a professional support ( Redhat, Oracle ) and this is big point for many big companies.
Also Vertx is a totally new concept with his event loop, most of Java developers have to change their knowledge then.
You said: the best developers does not follow the standards, this is not very true and this is a personal point of view, you have to come at Devoxx and you will see that most of best presenters are Java/JavaEE defenders...
Thomas SEGISMONT
Jan 22, 2016, 8:25:39 AM1/22/16
to ve...@googlegroups.com
Hi,
For the sake of transparency, I am the
maintainer of vertx-hawkular-metrics module and I work for Red Hat in
the team in charge of the Hawkular platform.But Vert.x gives you real control, while Wildfly hides all the details. For example, it's not possible to *properly* manage backpressure on the HTTP server with Wildfly.
To me, control is a major difference. vert.x is a toolkit, you bend it as you need.
Jez P
Jan 22, 2016, 8:28:58 AM1/22/16
to vert.x
Actually, having attended 3 Devoxxes, I think the best presenters overall (ignoring Stuart Williams' fantastic introduction to vert.x back in 2013) were those presenting Spring, which technically isn't part of the Java EE standard. There were, of course, great JavaEE presenters too, and I wouldn't want to be seen as ignoring them (David Blevins and his work on TomEE really stand out).
Also, you rather ignore those enterprises cheerfully implementing node.js solutions (and there are plenty out there) and other JVM technologies not built on JavaEE. I think it is true that many enterprises will move slowly and will stick with JavaEE because of the "standards" but many don't want to wait for RFC agreement before using, for example, websockets (Spring, for example, were ahead of Java EE on that one, similarly the Java batch JSR lagged Spring Batch significantly and offered less). The Java EE standards are always behind other technologies (that's what happens with standards, it's not a fundamental problem with Java EE) and some very sizeable companies and organizations will adopt other technologies which enable to them to achieve their goals more quickly rather than wait for the "standards". So it's not all about standards.
Also, you rather ignore those enterprises cheerfully implementing node.js solutions (and there are plenty out there) and other JVM technologies not built on JavaEE. I think it is true that many enterprises will move slowly and will stick with JavaEE because of the "standards" but many don't want to wait for RFC agreement before using, for example, websockets (Spring, for example, were ahead of Java EE on that one, similarly the Java batch JSR lagged Spring Batch significantly and offered less). The Java EE standards are always behind other technologies (that's what happens with standards, it's not a fundamental problem with Java EE) and some very sizeable companies and organizations will adopt other technologies which enable to them to achieve their goals more quickly rather than wait for the "standards". So it's not all about standards.
I'm working for a very large and conservative organization right now, which will have next to no Java EE in its stack in the long term, although all code will be in Java.
Jez P
Jan 22, 2016, 8:30:04 AM1/22/16
to vert.x
And just to be clear, vert.x won't be the answer to every question. Any organization built on a "we always use the same tech stack regardless of the problem" is likely to run into big problems in the long term.
Tim Fox
Jan 22, 2016, 8:39:12 AM1/22/16
to ve...@googlegroups.com
On 22/01/16 13:05, J Guedouar wrote:
Thank you Tim for your comments,
I am just playing now the evil advocate :)
But for the support, what happens if a company has a problem with Vertx ? They should rely on this community forum ? If yes then its a risk...
Most of JavaEE vendors have a professional support ( Redhat, Oracle ) and this is big point for many big companies.
Also Vertx is a totally new concept with his event loop, most of Java developers have to change their knowledge then.
You said: the best developers does not follow the standards, this is not very true and this is a personal point of view, you have to come at Devoxx and you will see that most of best presenters are Java/JavaEE defenders...
Having spoken about Vert.x twice at Devoxx personally, and having
seen the Vert.x presentation that the other team members did this
year, I would have to disagree with you ;)
Devoxx has always been a very progressive conference - sure you have the "old guard" pushing the JavaEE stuff there too, but imho it's the more interesting new developments which usually provide the best presentations :)
Devoxx has always been a very progressive conference - sure you have the "old guard" pushing the JavaEE stuff there too, but imho it's the more interesting new developments which usually provide the best presentations :)
Le vendredi 22 janvier 2016 13:32:51 UTC+1, Mark Little a écrit :
On 22 Jan 2016, at 12:31, Tim Fox <timv...@gmail.com> wrote:
Well I think it’s more accurate to say you had an important hand in creating JBossMessaging and HornetQ, as you were the project(s) lead, and wrote significant chunks of the code while you held that position. However, let’s give the whole team a bit of credit where it’s due :)
Fair enough. I didn't mean to imply I single handedly wrote it!
But when I left I was by far the largest contributor and it seems I'm still one of the biggest contributors even though I haven't contributed for over 5 years ;)
Agreed. That’s what I meant by “significant chunks”. :)
https://github.com/hornetq/hornetq/graphs/contributors
But that aside, the point I was trying to make was that the Vert.x event bus is very different from JMS and I'm saying that as someone who has worked deeply with both.
+1
--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/241c0849-a495-4527-bf38-1dd09205cf1d%40googlegroups.com.
Julien Viet
Jan 22, 2016, 8:40:42 AM1/22/16
to ve...@googlegroups.com
I believe one of the compelling aspect of Vert.x over Java EE, is reactive programming (which is not really new and a reinvent of the past)
Java EE does not provide an end-to-end reactive programming model and perhaps it will never.
My point is standards are good but when they don’t evolve anymore (or take years to) then using a standard is a weakness and not asset anymore.
--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/241c0849-a495-4527-bf38-1dd09205cf1d%40googlegroups.com.
Jez P
Jan 22, 2016, 9:02:33 AM1/22/16
to vert.x
Re my comment above, I wasn't present at one where you spoke Tim (I was at Devoxx UK 2013, 14 and 15) - no offence was intended.
John Clingan
Jan 22, 2016, 9:23:07 AM1/22/16
to ve...@googlegroups.com
On Jan 22, 2016, at 5:40 AM, Julien Viet <jul...@julienviet.com> wrote:I believe one of the compelling aspect of Vert.x over Java EE, is reactive programming (which is not really new and a reinvent of the past)
+1.
Java EE does not provide an end-to-end reactive programming model and perhaps it will never.
Having been the Java EE PM at Sun/Oracle for 7 years until recently, i can say that we never really discussed end-to-end reactive programming model. Yeah, it has some async and non-blocking APIs, but there is not an end-to-end reactive model being planned. The JAX-RS expert group has been looking at reactive extensions to the client API, but again, that’s not an end-to-end Java EE platform model. It would be easier to start over than to retrofit end-to-end reactive into Java EE. Hey, that’s kinda what vert.x did ;-)
My point is standards are good but when they don’t evolve anymore (or take years to) then using a standard is a weakness and not asset anymore.
HTTP, ECMAScript, and HTML have been very slow moving ;-) The more ubiquitous something becomes, the slower it moves because many major use cases have been implemented and arguably need time to settle, vendors need to implement the specs, the risk of change is greater, and the new stuff needs to align neatly with what already exists. Java 8 Lambdas/Streams and Modules are examples of the latter.
I really do think Julien (and some others) have nailed it though - reactive vs non-reactive is probably the most obvious technical differentiator.
As for commercial support, that’s what I am being tasked to look into as a product manager. Feel free to contact me since data points are critical.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/27CF96CD-CBB5-4412-BFA2-827F9CA8B898%40julienviet.com.
John Clingan
Jan 22, 2016, 9:24:58 AM1/22/16
to ve...@googlegroups.com
On Jan 22, 2016, at 6:23 AM, John Clingan <jcli...@redhat.com> wrote:
On Jan 22, 2016, at 5:40 AM, Julien Viet <jul...@julienviet.com> wrote:I believe one of the compelling aspect of Vert.x over Java EE, is reactive programming (which is not really new and a reinvent of the past)+1.Java EE does not provide an end-to-end reactive programming model and perhaps it will never.Having been the Java EE PM at Sun/Oracle for 7 years until recently, i can say that we never really discussed end-to-end reactive programming model. Yeah, it has some async and non-blocking APIs, but there is not an end-to-end reactive model being planned. The JAX-RS expert group has been looking at reactive extensions to the client API, but again, that’s not an end-to-end Java EE platform model. It would be easier to start over than to retrofit end-to-end reactive into Java EE. Hey, that’s kinda what vert.x did ;-)
Oh, to back this up a bit a bit, check out the recent thread on using JPA with vert.x. It’s not straightforward by any means.
<SNIP/>
J Guedouar
Jan 22, 2016, 7:09:57 PM1/22/16
to vert.x
Also please I still wanted to know if there is a professional support for vertx ?
What happens if there is a problem on a PRODUCTION site ?
Julien Viet
Jan 22, 2016, 7:19:13 PM1/22/16
to ve...@googlegroups.com
as far as I know, the only form of support you can get as of today is on this forum.
the community provides usually a good support, given that enough information is provided, this list (http://vertx.io/whos_using/) shows a list of companies using Vert.x in production and that have been happy enough with Vert.x and its community to let us publish their logo/name on this page.
often a reproducer is asked, specially when it might be a Vert.x bug : a minimal project that exhibit the problem so it can be reproduced easily which increased the chance of fixing the bug.
--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/f0b7ab2c-64dc-40bf-bb93-d768aee2e3d5%40googlegroups.com.
John Clingan
Jan 22, 2016, 7:39:28 PM1/22/16
to ve...@googlegroups.com
As I replied earlier, this is something that we are looking into. Julien is correct in that the best place for supports today is the forum. If a supported product is something that you are interested in, contact me offline.
jul...@julienviet.com
Jan 26, 2016, 6:27:44 AM1/26/16
to vert.x
on testing:
Vert.x can trivially be embedded for running test in any JUnit test.
For EE stuff you often need to use Arquillian which adds tons of complexity and overhead for doing simple testing.
J Guedouar
Jan 26, 2016, 6:56:22 AM1/26/16
to vert.x
This is true but it depends the goal of your tests: unit, integration, functional.
Unit tests are usually light but I have to admit that vertx can make integration tests very light.
Unit tests are usually light but I have to admit that vertx can make integration tests very light.
Mumuney Abdlquadri
Jan 26, 2016, 9:05:59 AM1/26/16
to ve...@googlegroups.com
The best feature of Vert.x is simplicity, you can't beat that. You can read the Docs in the morning and have a working app in the afternoon.
The EventBus is simple just JSON, can you say that of JMS.
Simple threading model. About 5years ago we started building this product where transactions were critical. We needed to get the threading right. With JavaEE you can try with a lot of hardwork. But with Vert.x you know where you are at 'the same thread'. This is the best gift to the Java world.
Couple this with the clustered data-structures you get for almost free.
All of a sudden a humble Java developer can actually say my app is horizontally scalable across multiple nodes. This is the real deal.
However, since you want to have a microservice architecture, you do not necessarily have to chose between JavaEE7 or VertX, you can use Vertx for some part and JavaEE for others. You can also mix them Vert.x is just a jar file.
You might want to do this to benefit from all the above and True Async Network Operations, True Async Filesystem Operations, etc.
--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/43f277d3-864d-4474-8d7e-6ae4bb14e287%40googlegroups.com.
qsys
Jan 30, 2016, 3:59:37 AM1/30/16
to vert.x
Op vrijdag 22 januari 2016 14:05:42 UTC+1 schreef J Guedouar:
Thank you Tim for your comments,I am just playing now the evil advocate :)
But for the support, what happens if a company has a problem with Vertx ? They should rely on this community forum ? If yes then its a risk...
Really? If you have problems with JavaEE-stuff, you can hire an overpayed consultant who will not really solve your problem, because in that case, you will not need him again (https://vimeo.com/77199361).
In the case of vertx, you get help, for free, and your problem gets solved, or at least nicely explained why it doesn't work.
In the case of vertx, you get help, for free, and your problem gets solved, or at least nicely explained why it doesn't work.
Most of JavaEE vendors have a professional support ( Redhat, Oracle ) and this is big point for many big companies.
Well yeah... professional support, been there, didn't like most them. There are exceptions, though...
Also Vertx is a totally new concept with his event loop, most of Java developers have to change their knowledge then.
... and that's a good point! Really, if it's node.js, event loops are cool. If it's vert.x, it's hard for devs?
No, seriously, the more devs know, the more they know how the solve a particular problem nicely. You can't solve every problem the same way, so having a few good devs is worth much more than a bunch of code-monkeys. I know, most companies prefer the code-monkey strategy for hiring, but in the end, they pay much more. That's their problem...
You said: the best developers does not follow the standards, this is not very true and this is a personal point of view, you have to come at Devoxx and you will see that most of best presenters are Java/JavaEE defenders...
Hmm, I have been to Devoxx a few years now, and honestly, I don't agree on that statement. There are, of course Java/JavaEE defenders, but certainly not a lot of them defend on JavaEE. But of course, it depends on which talks you choose. The best presenters, though, do defend Java in the sense that they 'learn attendees how to use Java properly', and that's in many cases not how it's done in companies, which just use Spring/Hibernate and such, because, well, Spring/Hibernate is what they use.
vert.x follows many of the ideas which these 'best presenters' propose to do.
qsys
Jan 30, 2016, 4:00:28 AM1/30/16
to vert.x
... you ask this lot of people, and you will get real help. That's my experience.
Op zaterdag 23 januari 2016 01:09:57 UTC+1 schreef J Guedouar:
Op zaterdag 23 januari 2016 01:09:57 UTC+1 schreef J Guedouar:
qsys
Jan 30, 2016, 4:30:17 AM1/30/16
to vert.x
Well, a little story. Not about JavaEE and vert.x, but Spring and vert.x, from my work.
I wasn't allowed to use vert.x for a long time: the company I work for during my day job uses Spring/Hibernate in a Tomcat container as the only truth. Than I had permission to use it as a proof of concept and it should be approved by some committee when the POC was over. That's about 1,5 years ago. I still tell them it's a proof of concept, but that's a strategic move :). Anyway, vert.x in production for more than 1 year, it integrates with the legacy application via the eventbus (vert.x embedded in the legacy application). All new features are programmed in verticles these days, which is known as 'the new application' by the users. The users love the new application: it's resilient and performant. We're moving to vert.x 3.x, and while doing that, I'm reorganizing everything.
My collegues started to wonder how I could be so productive, why our application is so fast en why it hardly ever crashes: verticles can crash, very occasionally, but I can restart them in less than a minute - I'd love to have a kind of erlang 'let it crash'-filosophy, but I miss real 'supervisers' in vert.x. Anyway, verticles crashing doesn't mean your application goes down: some functionality is not usable for a short time, and only if(!) something goes wrong. Otherwise, upgrading: deploy a new verticle, and bring down the old version. No downtime - another thing my colleagues hardly can believe it's so simple. And I don't need help of any overcharging consultant of so-called 'professional', whenever necessary.
Now, the fun stuff: one of my colleagues had to program an pure server-side application, and it involved multithreading/messaging between jobs a lot. Now, one of the things I learned at Devoxx "everyone says you can not get concurrency right if you haven't read Brian Goetz' book... I read Brian Goetz' book and now I know I never can get concurrency right' (Venkat Subramanium, 2 years ago @Devoxx university sessions, I forgot which one). That colleague worked a few months on that application, and it always had some issues, and it was slow. Concurrency is hard. He asked me how I would do it, and now done by using vert.x, although he isn't really allowed to do so: simpler code, less code (this is important) and a faster and very resilient application.
You might wonder why he can do it in a 'non-standard, non-approved' technology... well, because it's a way to get the job done for a non-genius developer. If someone sais he can't do it like that, he just asks them 'how should I do it, than?', with a 'please show me the code that will work'. So far, nobody seems to have the courage to do so. So it's running, in productin, resilient en performant, and with very low memory overhead: got from >3GB heap, with memory issues from time to time when running the Spring-Tomcat self-programmed threading application, down to <1GB heap (and we can probably run the application in about 0.5GB, if we would really tweak it).
Although the technology we are using is still not approved by the 'committee', last week, I got the news that they would like to hire some new people to rewrite our legacy application in 'the new technology'. We're going bottom-up. It can't be, and isn't ignored any more.
My point being: it's not about 'what can be done'. You can do everything in brainfuck as well. A real genius can do everything in any language or technology. It's more about how it can be done. In that case, vert.x wins hands down in many cases, imho. I'm not using vert.x for everything, but it surely solves a lot of unnecessary architectural problems in many cases. It doesn't hide complexity, it removes it. That's an amazingly huge win. Devs can reason about their code again. There will be other technologies a well (and there are a few already) which are very optimized for real 'modular' design. However, I don't know of any JavaEE- or Spring-based solution that has the potential of vert.x and alike.
best regards, qsys
Op woensdag 20 januari 2016 16:33:57 UTC+1 schreef J Guedouar:
I wasn't allowed to use vert.x for a long time: the company I work for during my day job uses Spring/Hibernate in a Tomcat container as the only truth. Than I had permission to use it as a proof of concept and it should be approved by some committee when the POC was over. That's about 1,5 years ago. I still tell them it's a proof of concept, but that's a strategic move :). Anyway, vert.x in production for more than 1 year, it integrates with the legacy application via the eventbus (vert.x embedded in the legacy application). All new features are programmed in verticles these days, which is known as 'the new application' by the users. The users love the new application: it's resilient and performant. We're moving to vert.x 3.x, and while doing that, I'm reorganizing everything.
My collegues started to wonder how I could be so productive, why our application is so fast en why it hardly ever crashes: verticles can crash, very occasionally, but I can restart them in less than a minute - I'd love to have a kind of erlang 'let it crash'-filosophy, but I miss real 'supervisers' in vert.x. Anyway, verticles crashing doesn't mean your application goes down: some functionality is not usable for a short time, and only if(!) something goes wrong. Otherwise, upgrading: deploy a new verticle, and bring down the old version. No downtime - another thing my colleagues hardly can believe it's so simple. And I don't need help of any overcharging consultant of so-called 'professional', whenever necessary.
Now, the fun stuff: one of my colleagues had to program an pure server-side application, and it involved multithreading/messaging between jobs a lot. Now, one of the things I learned at Devoxx "everyone says you can not get concurrency right if you haven't read Brian Goetz' book... I read Brian Goetz' book and now I know I never can get concurrency right' (Venkat Subramanium, 2 years ago @Devoxx university sessions, I forgot which one). That colleague worked a few months on that application, and it always had some issues, and it was slow. Concurrency is hard. He asked me how I would do it, and now done by using vert.x, although he isn't really allowed to do so: simpler code, less code (this is important) and a faster and very resilient application.
You might wonder why he can do it in a 'non-standard, non-approved' technology... well, because it's a way to get the job done for a non-genius developer. If someone sais he can't do it like that, he just asks them 'how should I do it, than?', with a 'please show me the code that will work'. So far, nobody seems to have the courage to do so. So it's running, in productin, resilient en performant, and with very low memory overhead: got from >3GB heap, with memory issues from time to time when running the Spring-Tomcat self-programmed threading application, down to <1GB heap (and we can probably run the application in about 0.5GB, if we would really tweak it).
Although the technology we are using is still not approved by the 'committee', last week, I got the news that they would like to hire some new people to rewrite our legacy application in 'the new technology'. We're going bottom-up. It can't be, and isn't ignored any more.
My point being: it's not about 'what can be done'. You can do everything in brainfuck as well. A real genius can do everything in any language or technology. It's more about how it can be done. In that case, vert.x wins hands down in many cases, imho. I'm not using vert.x for everything, but it surely solves a lot of unnecessary architectural problems in many cases. It doesn't hide complexity, it removes it. That's an amazingly huge win. Devs can reason about their code again. There will be other technologies a well (and there are a few already) which are very optimized for real 'modular' design. However, I don't know of any JavaEE- or Spring-based solution that has the potential of vert.x and alike.
best regards, qsys
Op woensdag 20 januari 2016 16:33:57 UTC+1 schreef J Guedouar:
qsys
Jan 30, 2016, 5:09:19 AM1/30/16
to vert.x
Non-limited list of advantages:
1. Higher productivity of the dev
2. Higher resilience of the application
3. Higher performance of the application
4. Much less need for expensive consultants
5. More technology-independent and interop with (almost) whatever you like
6. Design flexibility
7. ...
Biggest disadvantage: you need people that can think and reason:
1. devs: they can't just 'generate code' or 'copy-past from stackoverflow' ;).
2. architects and analysts: they have flexibility, and in my experience, some (or even many) of them don't like that at all, since they don't know how to design something simple - it makes them feel superfluous, and they are actually to some extend ;).
1. Higher productivity of the dev
2. Higher resilience of the application
3. Higher performance of the application
4. Much less need for expensive consultants
5. More technology-independent and interop with (almost) whatever you like
6. Design flexibility
7. ...
Biggest disadvantage: you need people that can think and reason:
1. devs: they can't just 'generate code' or 'copy-past from stackoverflow' ;).
2. architects and analysts: they have flexibility, and in my experience, some (or even many) of them don't like that at all, since they don't know how to design something simple - it makes them feel superfluous, and they are actually to some extend ;).
qsys
Op woensdag 20 januari 2016 16:33:57 UTC+1 schreef J Guedouar:
John Clingan
Jan 30, 2016, 1:49:16 PM1/30/16
to ve...@googlegroups.com
"I'm not using vert.x for everything ..."
So I have to ask: What do you use vert.x for, what do you not use it for, and what do you use in its place?
-------- Original message --------
From: qsys <kurt...@gmail.com>
Date: 01/30/2016 1:30 AM (GMT-08:00)
To: "vert.x" <ve...@googlegroups.com>
Subject: [vertx:32393] Re: vertx vs Java EE 7
Well, a little story. Not about JavaEE and vert.x, but Spring and vert.x, from my work.
I wasn't allowed to use vert.x for a long time: the company I work for during my day job uses Spring/Hibernate in a Tomcat container as the only truth. Than I had permission to use it as a proof of concept and it should be approved by some committee when the POC was over. That's about 1,5 years ago. I still tell them it's a proof of concept, but that's a strategic move :). Anyway, vert.x in production for more than 1 year, it integrates with the legacy application via the eventbus (vert.x embedded in the legacy application). All new features are programmed in verticles these days, which is known as 'the new application' by the users. The users love the new application: it's resilient and performant. We're moving to vert.x 3.x, and while doing that, I'm reorganizing everything.
My collegues started to wonder how I could be so productive, why our application is so fast en why it hardly ever crashes: verticles can crash, very occasionally, but I can restart them in less than a minute - I'd love to have a kind of erlang 'let it crash'-filosophy, but I miss real 'supervisers' in vert.x. Anyway, verticles crashing doesn't mean your application goes down: some functionality is not usable for a short time, and only if(!) something goes wrong. Otherwise, upgrading: deploy a new verticle, and bring down the old version. No downtime - another thing my colleagues hardly can believe it's so simple. And I don't need help of any overcharging consultant of so-called 'professional', whenever necessary.
Now, the fun stuff: one of my colleagues had to program an pure server-side application, and it involved multithreading/messaging between jobs a lot. Now, one of the things I learned at Devoxx "everyone says you can not get concurrency right if you haven't read Brian Goetz' book... I read Brian Goetz' book and now I know I never can get concurrency right' (Venkat Subramanium, 2 years ago @Devoxx university sessions, I forgot which one). That colleague worked a few months on that application, and it always had some issues, and it was slow. Concurrency is hard. He asked me how I would do it, and now done by using vert.x, although he isn't really allowed to do so: simpler code, less code (this is important) and a faster and very resilient application.
You might wonder why he can do it in a 'non-standard, non-approved' technology... well, because it's a way to get the job done for a non-genius developer. If someone sais he can't do it like that, he just asks them 'how should I do it, than?', with a 'please show me the code that will work'. So far, nobody seems to have the courage to do so. So it's running, in productin, resilient en performant, and with very low memory overhead: got from >3GB heap, with memory issues from time to time when running the Spring-Tomcat self-programmed threading application, down to <1GB heap (and we can probably run the application in about 0.5GB, if we would really tweak it).
Although the technology we are using is still not approved by the 'committee', last week, I got the news that they would like to hire some new people to rewrite our legacy application in 'the new technology'. We're going bottom-up. It can't be, and isn't ignored any more.
My point being: it's not about 'what can be done'. You can do everything in brainfuck as well. A real genius can do everything in any language or technology. It's more about how it can be done. In that case, vert.x wins hands down in many cases, imho. I'm not using vert.x for everything, but it surely solves a lot of unnecessary architectural problems in many cases. It doesn't hide complexity, it removes it. That's an amazingly huge win. Devs can reason about their code again. There will be other technologies a well (and there are a few already) which are very optimized for real 'modular' design. However, I don't know of any JavaEE- or Spring-based solution that has the potential of vert.x and alike.
I wasn't allowed to use vert.x for a long time: the company I work for during my day job uses Spring/Hibernate in a Tomcat container as the only truth. Than I had permission to use it as a proof of concept and it should be approved by some committee when the POC was over. That's about 1,5 years ago. I still tell them it's a proof of concept, but that's a strategic move :). Anyway, vert.x in production for more than 1 year, it integrates with the legacy application via the eventbus (vert.x embedded in the legacy application). All new features are programmed in verticles these days, which is known as 'the new application' by the users. The users love the new application: it's resilient and performant. We're moving to vert.x 3.x, and while doing that, I'm reorganizing everything.
My collegues started to wonder how I could be so productive, why our application is so fast en why it hardly ever crashes: verticles can crash, very occasionally, but I can restart them in less than a minute - I'd love to have a kind of erlang 'let it crash'-filosophy, but I miss real 'supervisers' in vert.x. Anyway, verticles crashing doesn't mean your application goes down: some functionality is not usable for a short time, and only if(!) something goes wrong. Otherwise, upgrading: deploy a new verticle, and bring down the old version. No downtime - another thing my colleagues hardly can believe it's so simple. And I don't need help of any overcharging consultant of so-called 'professional', whenever necessary.
Now, the fun stuff: one of my colleagues had to program an pure server-side application, and it involved multithreading/messaging between jobs a lot. Now, one of the things I learned at Devoxx "everyone says you can not get concurrency right if you haven't read Brian Goetz' book... I read Brian Goetz' book and now I know I never can get concurrency right' (Venkat Subramanium, 2 years ago @Devoxx university sessions, I forgot which one). That colleague worked a few months on that application, and it always had some issues, and it was slow. Concurrency is hard. He asked me how I would do it, and now done by using vert.x, although he isn't really allowed to do so: simpler code, less code (this is important) and a faster and very resilient application.
You might wonder why he can do it in a 'non-standard, non-approved' technology... well, because it's a way to get the job done for a non-genius developer. If someone sais he can't do it like that, he just asks them 'how should I do it, than?', with a 'please show me the code that will work'. So far, nobody seems to have the courage to do so. So it's running, in productin, resilient en performant, and with very low memory overhead: got from >3GB heap, with memory issues from time to time when running the Spring-Tomcat self-programmed threading application, down to <1GB heap (and we can probably run the application in about 0.5GB, if we would really tweak it).
Although the technology we are using is still not approved by the 'committee', last week, I got the news that they would like to hire some new people to rewrite our legacy application in 'the new technology'. We're going bottom-up. It can't be, and isn't ignored any more.
My point being: it's not about 'what can be done'. You can do everything in brainfuck as well. A real genius can do everything in any language or technology. It's more about how it can be done. In that case, vert.x wins hands down in many cases, imho. I'm not using vert.x for everything, but it surely solves a lot of unnecessary architectural problems in many cases. It doesn't hide complexity, it removes it. That's an amazingly huge win. Devs can reason about their code again. There will be other technologies a well (and there are a few already) which are very optimized for real 'modular' design. However, I don't know of any JavaEE- or Spring-based solution that has the potential of vert.x and alike.
best regards, qsys
Hello,
As I have to start soon a new project, we will test a new type of architecture: the micro services.
We have to choose between Java EE 7 and Vertx.
I wanted to know what are the advantages using Vertx over JavaEE7, as far as I know I will compare this like:
vertx: ( micro server )
verticle ( modules ) non-blocking full async framework using an EventBus to exchange data between verticles.
We need to use modules/extensions in order to use DI, JDBC, security, SMTP, ....
Also there is no JPA like extension on vertx, writing SQL queries by hand is a little... deprecated...
JavaEE7: ( we can also use micro server like wildfly-swarm )
Non blocking - Async can be done via:
REST with @Async and @Suspended annotations ( Jersey 2 supports it )
@Resource(name = "DefaultManagedExecutorService")
ManagedExecutorService executor
We can use JMS for the EventBus.
We can add RxJava for parallel calls.
No need to use extensions because JavaEE stack already include REST, DI, SMTP, JMS, ...
Here we can find a good exemple of JavaEE 7 + RxJava:
http://www.lordofthejars.com/2014/07/rxjava-java8-java-ee-7-arquillian-bliss.html
Also is it possible for vetx verticles to talk each other on the event bus on different locations ?
Example:
10.254.151.5 verticle 1
194.165.154.5 verticle 2
verticle 1 sends message on eventbus, verticle 2 can catch it ?
So in conclusion, I wanted to know what is the advantage using vertx over JavaEE for microservices when a Java Developer is on the story. ( Suppose we don't care about polyglot )
Thank you !
--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/281e0896-5a50-4560-baf4-e622c38ce73e%40googlegroups.com.
qsys
Jan 30, 2016, 2:40:30 PM1/30/16
to vert.x
Hey,
That's a matter of design choices. I don't mind discussing that, let's say, on IRC or something, but to answer as shortly as possible: I do follow the C4 architecture more and more (or rather, some slight variation of it). It all depends on scope and scale. According to the C4 model:
- Containers: verticles, independent deployable artifacts.
- Components: can be everything, but these days, but having 'non-blocking OS-level threading' in mind:
- clojure core.async channels
- pulsar/quasar (parallel universe) fibers, channels, or actors. I like the latter a lot for their hot swapping and fault tolerance capacity.
Inside a verticle (C4 container), I used to have a small Spring 'container' in many cases - to align myself somewhat with company rules - and I still have, whenever it suits my needs. However, I use these Spring containers less and less. Just plain evolution...
I know vert.x has quasar-fibers in vertx-sync, which is great, but a verticle is another scale than the 'component'-level. The granularity is very different... Having a verticle for about each public class or functionality, gives too much anarchy in the system. It makes it harder to handle, manage and reason about. Having a clear distinction between 'containers' and 'components', makes many things clearer. If each container has only one component, than you have a lot of containers which are actually the same as components, and the design becomes too scattered, with loads of 'services' dangling around, unmanaged - that's how it eventually evolves very often.
It's a matter of choosing the right technology for the right job, and about design choices. I'm looking for the best choices for both :).
greetz, qsys
Op zaterdag 30 januari 2016 19:49:16 UTC+1 schreef John Clingan:
That's a matter of design choices. I don't mind discussing that, let's say, on IRC or something, but to answer as shortly as possible: I do follow the C4 architecture more and more (or rather, some slight variation of it). It all depends on scope and scale. According to the C4 model:
- Containers: verticles, independent deployable artifacts.
- Components: can be everything, but these days, but having 'non-blocking OS-level threading' in mind:
- clojure core.async channels
- pulsar/quasar (parallel universe) fibers, channels, or actors. I like the latter a lot for their hot swapping and fault tolerance capacity.
Inside a verticle (C4 container), I used to have a small Spring 'container' in many cases - to align myself somewhat with company rules - and I still have, whenever it suits my needs. However, I use these Spring containers less and less. Just plain evolution...
I know vert.x has quasar-fibers in vertx-sync, which is great, but a verticle is another scale than the 'component'-level. The granularity is very different... Having a verticle for about each public class or functionality, gives too much anarchy in the system. It makes it harder to handle, manage and reason about. Having a clear distinction between 'containers' and 'components', makes many things clearer. If each container has only one component, than you have a lot of containers which are actually the same as components, and the design becomes too scattered, with loads of 'services' dangling around, unmanaged - that's how it eventually evolves very often.
It's a matter of choosing the right technology for the right job, and about design choices. I'm looking for the best choices for both :).
greetz, qsys
Op zaterdag 30 januari 2016 19:49:16 UTC+1 schreef John Clingan:
John Clingan
Jan 30, 2016, 4:52:40 PM1/30/16
to ve...@googlegroups.com
I’m on IRC occasionally in the vert.x channel (pacific time zone) so would like to chat about this a bit at some point. I used to be the Java EE and GlassFish product manager @ Sun and Oracle (and a pretty fun project called Project Avatar), and now I am doing some PM work at Red Hat around alternative platform architectures, like Vert.x, Node, and WildFly Swarm (think of Java EE 7 as runnable jars). This leads to the intent of my question - to understand how and when folks like yourself decide which is the best approach. Some have greenfield environments where they can start from scratch. Others, like yourself do not because of existing corporate standards and guidelines.
I am very interested in the design choices of when you choose one platform over the other. We are at a point in time where consolidation of interest in a couple of platforms is gone, and the growth of interest in more platform choices is becoming more interesting for companies. Typically, the larger the organization the harder the change, but there are vertical industries and outlier companies that break the mold. The more data points I have, the better approach to productization we can deliver.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/5c0d0812-c4e0-451c-94d1-efbeb387e43b%40googlegroups.com.
J Guedouar
Jan 31, 2016, 4:12:05 AM1/31/16
to vert.x
Hi
I like this topic but your experience is based on Spring and not JavaEE.
I dont like Spring because it just adds complexity ( specific container, config, ... ), you can do everything with JavaEE 7 with less code and configuration.
Thank you for sharing us your experience, again I wanted to have feedbacks from users who use it in production.
qsys
Jan 31, 2016, 5:37:24 AM1/31/16
to vert.x
True, JavaEE is different than Spring when it comes to (convention over) config and such. But it is still somewhat the same philosophy. It's been a while since I used JavaEE, mainly because there are alternatives which suit my needs better. It's just, there are no silver bullets...
and technologies change fast. I don't feel like JavaEE is capable of
coping with this, and to me, JavaEE is about doing things the JavaEE way
only. Technologies like vert.x give me way more freedom (besides simplicity, productivity, ...), even in what functionality of the technology I want - vert.x is a real modular toolkit. Some people don't
like that freedom, because freedom means making choices. Making choices
can be very hard.
So, if you would like to know the difference, not only in what it can do, but also in how to do things: do some applications in both, and see which one fits your needs the best in which context.
good luck, and please share your experiences as well,
qsys
Op zondag 31 januari 2016 10:12:05 UTC+1 schreef J Guedouar:
So, if you would like to know the difference, not only in what it can do, but also in how to do things: do some applications in both, and see which one fits your needs the best in which context.
good luck, and please share your experiences as well,
qsys
Op zondag 31 januari 2016 10:12:05 UTC+1 schreef J Guedouar:
Tim Fox
Jan 31, 2016, 10:54:48 AM1/31/16
to ve...@googlegroups.com
On 31/01/16 10:37, qsys wrote:
True, JavaEE is different than Spring when it comes to (convention over) config and such. But it is still somewhat the same philosophy. It's been a while since I used JavaEE, mainly because there are alternatives which suit my needs better. It's just, there are no silver bullets... and technologies change fast. I don't feel like JavaEE is capable of coping with this, and to me, JavaEE is about doing things the JavaEE way only. Technologies like vert.x give me way more freedom (besides simplicity, productivity, ...), even in what functionality of the technology I want - vert.x is a real modular toolkit. Some people don't like that freedom, because freedom means making choices. Making choices can be very hard.
+1 This is a key point.
JavaEE is an opinionated framework/platform, Vert.x is an unopinonated toolkit.
We don't say "this is how you write an application" but we do give you the bits you need to _enable_ you to write an application how you like.
Of course this means developers need to think for themselves and not just "fill in the blanks", but that's a good thing - do you really want the kind of developers who don't understand architectural issues on your team anyway?
More here: http://www.infoq.com/articles/vertx-3-tim-fox
JavaEE is an opinionated framework/platform, Vert.x is an unopinonated toolkit.
We don't say "this is how you write an application" but we do give you the bits you need to _enable_ you to write an application how you like.
Of course this means developers need to think for themselves and not just "fill in the blanks", but that's a good thing - do you really want the kind of developers who don't understand architectural issues on your team anyway?
More here: http://www.infoq.com/articles/vertx-3-tim-fox
So, if you would like to know the difference, not only in what it can do, but also in how to do things: do some applications in both, and see which one fits your needs the best in which context.
good luck, and please share your experiences as well,
qsys
Op zondag 31 januari 2016 10:12:05 UTC+1 schreef J Guedouar:HiI like this topic but your experience is based on Spring and not JavaEE.
I dont like Spring because it just adds complexity ( specific container, config, ... ), you can do everything with JavaEE 7 with less code and configuration.
Thank you for sharing us your experience, again I wanted to have feedbacks from users who use it in production.
--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/f175dab0-bacf-4934-a437-142ba14f72ea%40googlegroups.com.
Tim Fox
Jan 31, 2016, 10:58:39 AM1/31/16
to ve...@googlegroups.com
On 30/01/16 21:52, John Clingan wrote:
I’m on IRC occasionally in the vert.x channel (pacific time zone) so would like to chat about this a bit at some point. I used to be the Java EE and GlassFish product manager @ Sun and Oracle (and a pretty fun project called Project Avatar), and now I am doing some PM work at Red Hat around alternative platform architectures, like Vert.x, Node, and WildFly Swarm (think of Java EE 7 as runnable jars). This leads to the intent of my question - to understand how and when folks like yourself decide which is the best approach. Some have greenfield environments where they can start from scratch. Others, like yourself do not because of existing corporate standards and guidelines.
I am very interested in the design choices of when you choose one platform over the other. We are at a point in time where consolidation of interest in a couple of platforms is gone, and the growth of interest in more platform choices is becoming more interesting for companies. Typically, the larger the organization the harder the change,
True, but I've also found that some of the earliest adopters of
Vert.x are actually some of the largest companies. Large, successful
companies tend to have smart architecture departments who know that
they constantly need to adapt to remain competitive... that's why
they're successful!
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/F4BCE16C-A246-4105-A511-7D7E6D6DEB67%40redhat.com.
qsys
Jan 31, 2016, 12:12:16 PM1/31/16
to vert.x
:)
You'd be surprised how many CIO's, architects, and other decision makers want 100 code-monkeys instead of 20 'real' devs.
You'd be surprised how many CIO's, architects, and other decision makers want 100 code-monkeys instead of 20 'real' devs.
qsys
Jan 31, 2016, 12:14:24 PM1/31/16
to vert.x
I'm in CET, so that might be a fun... although, that's 9 hours difference? Well, it might work. I'm quite often online on vert.x channel as well, also in the evenings (local time here :) )...
greetz, qsys
Op zaterdag 30 januari 2016 22:52:40 UTC+1 schreef John Clingan:
greetz, qsys
Op zaterdag 30 januari 2016 22:52:40 UTC+1 schreef John Clingan:
Jez P
Jan 31, 2016, 1:27:52 PM1/31/16
to vert.x
I really wouldn't, having seen it more than once at first hand :)
Message has been deleted
J Guedouar
Feb 8, 2016, 5:02:27 AM2/8/16
to vert.x
Hi guys,
Just to let you know that I will finally use Vertx for our new application, so we will give a try and see how it goes.
In fact Vertx uses the new features of Java8 but he does with a clean API and the implementation is easier.
I also liked the different integration examples with key frameworks on JavaEE ( like Jersey, HK2, ... ).
So in fact it does not go far away from "standards" as its not really a framework but a toolkit and I think this is really great as there is always a chance to "integrate" with the technologies used in any company.
I suppose we cannot use the EJB 3 with vertx but I can stay with HK2 for DI, it works perfectly.
Thanks for the discussion !
Just to let you know that I will finally use Vertx for our new application, so we will give a try and see how it goes.
In fact Vertx uses the new features of Java8 but he does with a clean API and the implementation is easier.
I also liked the different integration examples with key frameworks on JavaEE ( like Jersey, HK2, ... ).
So in fact it does not go far away from "standards" as its not really a framework but a toolkit and I think this is really great as there is always a chance to "integrate" with the technologies used in any company.
I suppose we cannot use the EJB 3 with vertx but I can stay with HK2 for DI, it works perfectly.
Thanks for the discussion !
Arik Bron
Feb 8, 2016, 9:13:44 AM2/8/16
to vert.x
Please do post an update when you finish your POC phase :) It's interesting to know what other conclusions you will reach as I am dealing with the same dilemma at the moment - vert.x vs Node.js vs JEE + app server.
Klausen Schaefersinho
Feb 9, 2016, 5:12:33 PM2/9/16
to vert.x
Hi Arik,
I can just tell you from my personal experience. I moved a project from Tomcat to Vertx and had
a) huge performance gains (10x)
b) much less and more maintainable code
The performance are in particular visible when serving static content, so I had no need for an NGINX in front or so. I also tried node.js, which was also quite fast. However, I would have needed to integrate and external event bus/ message queue. Vertx ships already one, so my deployment is super easy. Just distribute some fat-jars and thats all. Last but not least I found it a little cumbersome to maintain the backend JS code. At least in Eclipse the JS tool is by far not as powerfull as the Java Tools. So refactoring etc was really a pain.
Best,
klaus
Reply all
Reply to author
Forward
0 new messages