Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am involved in the design of a service that uses Spring Cloud and Apache Camel. I was taken aback today when a colleague asked (maybe advocating would be a better term) whether we really need Apache Camel. From his perspective, most of the downstream systems we talk to are REST-based and therefore, no integration framework should be needed. If my recollection is correct, he also implied that Microservices and Integration Frameworks are incompatible.
I started passionately suggesting that Spring Cloud helps solve a deployment/ops issue while Integration frameworks solve integration issues and that they have orthogonal requirements.
Here are some of the protocols the system will be using to communicate:
REST
SOAP
AMQP
Azure SDK
AWS SDK (S3, SimpleBD, etc.)
Dropbox SDK
Paypal SDK
Braintree SDK
Caching (Memcached, EhCache)
Async (VM, Direct-VM, SEDA, SEDA-VM)
Facebook
Twitter
FTP
SMTP
File IO
SOLR/Elesticsearch
Quartz
Unknown protocols: as we integrate in customers environment we need to integrate with their systems. The communication protocols are yet unknown.
The following statement by Martin Fowler and James Lewis seems to suggest that ESB and Microservices are incompatible: "We can't resist mentioning Jim Webber's statement that ESB stands for "Egregious Spaghetti Box". Now, how far do you think this statement applies to an integration framework such as Apache Camel?
And more generally, does my colleague have a point? Does this mean that integration patterns have no place in microservices?
Apache Camel is not really an ESB (unless you want it to be), but rather a language/framework to connect "stuff" in a message oriented fashion.
If you feel you can use a concise syntax and flexible swiss army knife to connect "stuff" in your microsservices, sure - use Apache Camel. If you rather solve your integration code in other ways, do so.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
My plan is about making React application talk to set of gRPC micro-services deployed on Kubernetes (with Istio and Envoy). But after few implementation tries with different libraries such as grpc-gateway, grpc-web,... it seems like those libraries is not completely support gRPC. Each library lacks of some features which are "standards" in traditional XML/JSON over HTTP.
The points of my question are:
Is gRPC truly ready for production?
Do you have any recommendations for implementing micro-services in Go with gRPC to talk to web client.
You should use grpc-web if you are using Istio, as Istio will automatically handle proxying your http/1 requests into the http/2 requests that your grpc service understands.
gRPC is ready for production and is used by many corporations.
My recommendation is to keep your code in a monorepo, use Bazel as your build system, and Istio as your service mesh.
The monorepo approach allows you to avoid one of the most painful aspects of dealing with gRPC / protobufs - the sharing of the proto files across language / client / service boundaries. (There are Bazel rules which create libraries from your proto files in various languages). The JavaScript rules are Beta quality as of November 2019 but they are quickly maturing.
Since you are already using Istio as your gRPC proxy you can take advantage of its other features, allowing you to move tracing, authentication, service discovery and other concerns out of your application code, so you can focus on business logic.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
Is it possible to deploy a react-redux application to the cloud foundry environment of the SAP Cloud Platform and is it a supported way of the new SAP Cloud Application Programming Model ?
I cannot find any official resources on that so far.
Sure you can do it. You can build a CAP backend app (with a HANA db for example), add an HTML5 frontend app with any framework you like (React, Angular, Vue, etc...) and glue it all together with the App Router, for dispatching your calls.
Here explained step-by-step how to do this:
https://blogs.sap.com/2020/09/01/how-to-build-end-to-end-custom-applications-in-cloud-foundry/?update=updated
To answer your first question, Yes It should be possible to deploy a react-redux based JavaScript application on SAP CF. You can use the static buildback for on cloud foundry. You can check the documentation here.
To answer your second question, I am not completely sure about that, But you can use CAP to generate your database and OData services, and consume them in your application. Additionaly you can check SAP fundamental react
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
We are using Spring Integration to read from a database, transform into XML, and then place messages onto a topic for an external system. Would there be any reasons to favour Camel for this use case? Also, in general, what advantages, if any, does Camel have over Spring Integration?
A related question: for development using Spring projects such as Batch, Data and XD, how seamless would it be to use Camel with these technologies, in comparison to Spring Integration.
Thanks
Here are a few links that discuss Spring Integration vs Camel.
http://java.dzone.com/articles/light-weight-open-source
http://www.javacodebook.com/2013/07/24/spring-integration-vs-apache-camel/
When to use Spring Integration vs. Camel?
Note that Camel uses Spring for configuration and can easily integrate with other Spring projects such as Batch, http://camel.apache.org/springbatch.html, XD and others.
Nothing requires you to go with a pure Spring stack though many choose to do so. I find Camel a much more pleasant choice than SI in my day to day work.
I don't want to start one more holly war regarding Spring Integration vs Apache Camel, but I'd say: it's up to you, which one to choose for development.
As you noticed Batch, Data and XD, and, of course, Integration, all are projects of Spring.
And what is interest XD is written on Spring Integration and the last one is main tool to extend the XD Runtime.
So, I won't mind that you can write some adapter for Camel in the XD, but will it make sense, if you can just concentrate on your business task with existing abilities from XD via Integration and Spring at all?..
Anyway Spring Integration is a part of Spring IO platform. And you should agree with me, that one Camel can't replace entire platform.
You can find some links to what other people have blogged/written about Apache Camel vs competitors at
http://camel.apache.org/articles
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I'm interested in Mule ESB but I dont understand the licence, could someone explan me the CPAL licence in simple words?
We have a commercial porduct (JavaEE web application) that neads to be integrated with solutions that are hosting in the cliens environment. For example a clienat has a SAP instalation or any other source of data and want to integrate it with our java web application. We woud like to Mule to achive this functionality, does the CPAL licence allow this?
Our application and Mule could be hosting on our internal machinery or at the clients, both ways are possible.
First: I do not know anything about law.
That said, the CPAL license is based on Mozilla Public License, which is less strict than GPL and you can mix license rather freely as long as the code stays open.
CPAL introduces a concept, that if you run your application with CPAL code in it (Mule for instance), as a "Cloud" service, then you will have to give out the code as well. Simply put, if you alter the Mule source code and host it as a cloud service, you will have to give out your modifications.
I really recommend you to talk to a lawyer in your area (which knows the local laws and immaterial laws etc). However, I do know about a few companies that "bundles" Mule CE with commercial products without concern for license issues in a way very similar to your situation.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm going to deploy my application on one of them,
and have no idea which is better.
Amazon's Cloud services, at this time, are much more general and flexible, while Google App Engine essentially fits some specific classes of applications that can live within its specific limitations (those limitations are being gradually relaxed, as GAE adds features and allows you to pay to exceed certain quotas, but that does not mean GAE will become a completely general-purpose platform the way Amazon's services are).
If your app can live within GAE's limitations, then GAE presents advantages: free up to a certain quota, almost no system configuration / administration overhead, etc. But if you need total flexibility -- for example, if you want to code part of your apps in C or C++, and that's just one of many examples -- then GAE is not suitable, while Amazon (for a price, in both money and sysadm overhead) can accomodate you.
If you've already written your app, and just want to deploy it, I'd have to say AWS is your best bet. AWS is a platform (or rather, EC2 is), and deploying an existing app is easy. App Engine, on the other hand, provides an entire development environment, at a much higher level of abstraction, which has significant advantages when it comes to scaling, but requires you to have written your app to work on it.
Now how about Free Amazon EC2 for a year to do a better comparision. Check this out.
http://www.buzzingup.com/2010/10/amazon-announces-free-cloud-services-for-new-developers/
No one is king in this field because both amazon and google have their own pros and cons. for the finally decision you have to study deep about both or you have to analyze what you required for you apps.
no doubt aws is old in this field and they have lot of good quality stuff but remember google is fast growing in cloud computing.
personally aws is easy to use and training and support is easily available on the other side google is his early stage and bit complex interface for newbie
so you can learn from you requirement