We use an "enterprise" app which deploys Hazelcast. Every minor version upgrade is a pain, because the vendor has to become involved.
Any chance Hazelcast.org could deploy a hazelcast-api.jar on which the legacy app could depend at compile-time, leaving us free to deploy the compatible version of our choice for runtime use?
Thanks, Robin.
Robin,
Currently it's not possible we at Hazelcast have this requirement in mind for future hazelcast versions (maybe in Hazelcast 4).
Let me know if you have an questions.
Related
I would like to know the following.
We are using node version 6 and an upgrade to node 12 or 14 is easier said than done as it may demand a re-write of our code in our case.
That said I would like to know the disadvantage of continuing with node6 for significant amount of time in the future? I know node 6 is not supported but what would that mean for a production application which is running for several years? Thanks.
Let's assume your production application is running perfectly fine till, so there is no need to change anything (Here we are focusing on business logic). But apart from that, there are certain things we may focus on while talking about maintaining the production projects like adding new features, improving the performance, and many more.
Let's focus on the above two points
if we want to add new functionality, we have to stick with the older version of nodejs. So libraries which we are using should be also running on nodejs version 6 or lower which will be problematic for developers.
improving the performance
Let's look out the key improvements done in nodejs after version 6
Heap size & dump improvements
Native modules N-API improvements
Improved startup performance, TLS, and security
Performance improvements with V8 Engine v6.6
and many more
These are just the system improvements, apart from these there are function improvements like promises, async/await, ES6, diagnosis, and monitoring
So if we are updating slowly to new stable versions it will help both developers to maintain and getting high performance
Note that, node version 8 is coming to an end and after 2020, there'll be no support for it including any security patches.
Considering your case, I wouldn't recommend jumping 8 major versions and upgrading to version 14.
Instead go one version up, see how things go; then continue doing the same until you get to a LTS version.
I have a few questions regarding the integration of the two tools. Not technical questions and how to setup( i will have my fun with that later ) but more on the course of the project and the direction, seeing that JanusGraph is still very young.
I am starting a new project and already decided to use Cassandra for storage and using a graph on top sounds very appealing to me.
A couple of things that i would like to know in advance before i take that road.
JanusGraph is very young and it picks up from where Titan left about a year or so ago. There is gap there but the fact that is part of the Linux Foundation and all the big players are going to support it sounds promising. Is it safe to assume at this point that JanusGraph is here to stay? Would it be safe to depend on Janus as a startup project? And follow development of course and be up to date as much as possible.
Cassandra. Titan/JanusGraph integrates with Cassandra 2.1.9 using the thrift api which will be deprecated eventually in Cassandra 4. I know that work is being done at the moment to make janus work with Cassandra 3 and eventually work with CQL as well. Is it safe to start with existing janus and Cassandra 2.1.9 and deal with the migration later on? Will it be a huge task for a startup to handle?
Production ready JanusGraph.(This question relates to any kind of software in it's early stages and whether it's safe for a start up to use). As i understand it, it will take some time for JanusGraph to be production ready and catch up with the rest of the tools it integrates with( although work is being done as we speak:)). Again would it be safe to start using Janus at this point and follow development and finally migrate to a production ready version? What is the overall roadmap for JanusGraph?
My concern in general is whether the combination of the tools is a safe choice for a start up. The whole stack is already new to us and we are excited to try and learn but we will hit a migration period pretty quickly. Is it something that you would do/recommend? Is it a suicide?
Please share your thoughts and keep in mind that it doesn't have to be about the stack i am talking about. It could be any startup company dealing with any kind of software in its early stages.
Cheers
Full disclosure, I'm a developer for JanusGraph on Compose.
It's as safe as any other OSS software project with a large amount of backers. Everyone could jump on some new toy tomorrow, but I doubt it. Companies are putting money into it and the development community is very active.
There is a CQL backend for Janus that's compatible with the Thrift data model. Migration to CQL should be simple and pretty painless when 0.2.0 is released.
I know there are already people using Titan for production applications. With JanusGraph being forked from Titan, I think it's pretty reasonable to start in with JanusGraph from everything I've seen. As far as a roadmap, I'd check out the JanusGraph mailing list (dev/users) and see what's going on and what's being talked about.
Disclosure: I am one of the co-founders of the JanusGraph project; I am also seeking out and adding production users to our GitHub repo and website, so I may be slightly biased. :)
Regarding your questions:
Is it safe to use?
The project is young, but it is built on a foundation of Titan, a very popular graph database that's been around since 2012 and has already been running in production. We have contributors from a number of well-known companies, and several companies are building their business-critical applications directly on JanusGraph, e.g.,
GRAKN.AI is building their knowledge graph on JanusGraph
IBM's Compose.io has built a managed JanusGraph service
Uber is already running JanusGraph in production (having previously run Titan)
several other companies run JanusGraph as a core part of their production environment
We are also starting to identify companies who will provide consulting services around JanusGraph in case someone needs production-level support for their own self-managed deployments.
So as you can see, there is significant interest in and support for this project.
Cassandra upgrade
#pantalohnes answered this question; I won't repeat it here.
Production readiness
As I linked above (GitHub repo and website), we already have production users of JanusGraph which you can find there. Those are just the companies that are publicly willing to lend their name/logo to the project; I'm sure there are more. Also, Titan has been running in many production environments for several years; JanusGraph is a more up-to-date version of Titan, despite the low version number.
I am also speaking with other companies who are planning to migrate to JanusGraph soon; look for announcements via the #JanusGraph Twitter handle to learn about more production deployments.
What is the difference between the LTS version and the stable version of node.js ?
What version should we use on production ?
It depends where you are using node.js in your apps and how sensitive are they.
LTS (Long Term Support, currently v6.11.2) - as was mentioned in the comment, will have support and maintenance for at least 18months. So its better to use this one in Production for node.js as a back-end service.
Stable (currently v8.3.0) - will have support for approximately 8months, with features/updates released more often. This version will be ok for Production if you're using node.js for fron-end services (dependency management etc.). Will work for node.js on back-end as well, if you have ability to easily update your apps without interrupting the environment.
The reason of 2 type node.js versions:
As node.js team described when they announced this feature is that 2 different types of node.js versions will meet your node.js needs. Basically, if you have a complex node.js app and you want stability, then stay on LTS. If you are able to update your app often, or you use node.js only for the fron-end tools, then use Stable. The philosophy is to push new features, performance updates, bug fixes etc. in a quick manner, so companies/developers who wants the 'on the edge' technology and loves node.js, will be able easily use it and expect updates every 2weeks.
In My organisation we are planning to use Cassandra and these days we are running some experimental tests against Custom Configuraiton to check the better and stable verison of Cassandra. And we are using DataStax drivers.
We are running tests, INSERT into and Select * from CQL statements in very tight loop with higher load like 10K qps.
So any one has any experience on which Cassandra version is better and stable and which drivers shall be used?
Thanks in advance.
You cannot go wrong with the latest 2.0 release (2.0.9). You can get that version from either the Apache Cassandra project or DataStax. The Apache Cassandra download page also has links for the latest release candidates (RC5 is the latest) of 2.1, but those are still in development, so consider that before installing them.
As for the driver, there are drivers available for more than a dozen languages. Chances are that you probably know or use one of them. There is no one driver (at least that I am aware of) that significantly out-performs all of the others. So pick the driver for the language that either:
You have the most thorough knowledge of.
Complies with the usage standards of your team.
For instance, you could make an argument for using Java. After all, Cassandra is written in Java and all of the examples on the original DataStax Academy are done with the Java CQL Driver. But that argument loses ground quickly if you have never done Java before. Or if your team is a .Net shop, and there's nobody else who understands Java. InfoWorld's Andrew Oliver put it best when he wrote:
The lesson to be learned here is: Don't solve a simple problem with a
completely unfamiliar technology and apply it to use cases it isn't
especially appropriate for.
Again, you cannot go wrong with using a "DataStax Supported Driver" from their downloads page.
“You should not deploy a Cassandra version X.Y.Z to production where Z <= 5.”
Source:
https://engineering.eventbrite.com/what-version-of-cassandra-should-i-run/
Hence go with 2.0.x . Currently its 2.0.10
Is the latest mongodb native driver mature enough to use with for instance GridFS in a production environment or as specification in a large project?
Referring to http://mongodb.github.com/node-mongodb-native
I would like to consider the rapid changing conventions, as opposed to the maturity of the technology. In short, is it safe to select a version as specification for a high profile production environment?
My limited experience with the technology does not allow me to determine if it would be safe to use in a locked down specification scenario, or even version lock down as per long term support aka Ubuntu, where fix/security patches are OK as opposed to version changes.
Yes. This driver is mature enough to use in production. It is being used in many high profile Node.js deployments already and supports a feature set on par with existing MongoDB drivers. It is also put through the same testing as other MongoDB drivers and performs sufficiently well.
On the MongoDB side there should not be any concern about rapidly changing conventions. The API has shown stability over the past few releases and hasn't introduced any breaking changes through many releases.
Are you really sure that you want to use young technology in the kind of setting you are describing? It requires a lot of maturity for a project to start doing long term support of older versions.
Also in the open source world you rarely see the project itself providing any kind of long term support. Instead you have companies like Canonical and RedHat backporting patches to their specific versions of i.e. MySQL. 10Gen is the company behind MongoDB and mongodb-native and they would be the right ones to ask about long term support.
My experience with mongodb-native is that is a very rapidly improving project and you really need to keep up with what is going on. I would not like to support anything where the mongodb-native version is set in stone for the next n years.
Having said that MongoDB, Node.JS, and mongodb-native are certainly production ready if you are prepared to stay abreast with their rapid development.