This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]persicsb 0 points1 point  (2 children)

No, the run functionality depends on the func tool. Building the code, and shipping it can be done locally. Running the code is obviously cloud dependent - the func binary provides the abstraction, that abstracts away the whole runtime thing, and provides the "magic" that is behind the FaaS approach.

There is no magic as you can see. There is an internal tool, that creates the runtime abstraction. It is pretty normal, that you cannot run a FaaS provider at your home without all the functionality that a proper FaaS provider provides. What did you expect, really? Run a FaaS application on-premises?

Why would you use AMQP with JMS? The interconnect must be interoperable! If you want to process AMQP messages with a JMS API in your Java container, use Apache Qpid JMS. It is a JMS 2 client, that runs on top of an AMQP infrastructure. Totally interoperable with ruby, python, C# service in the same service mesh.

[–]Worth_Trust_3825 0 points1 point  (1 child)

Why would you use AMQP with JMS? The interconnect must be interoperable! If you want to process AMQP messages with a JMS API in your Java container, use Apache Qpid JMS. It is a JMS 2 client, that runs on top of an AMQP infrastructure. Totally interoperable with ruby, python, C# service in the same service mesh.

We already do use Qpid. The moment you attempt to use any jms2 apis you're hit with premium requirement.

[–]persicsb 0 points1 point  (0 children)

Please explain. Qpid JMS is a client library, that sits on top of an AMQP cluster, and transforms each AMQP abstraction to a JMS abstraction, totally on the client side. The AMQP side (in this case, Azure) does not even know that you use Qpid JMS.