Are you using Fission? We would love to hear

[vishal-biyani]

Hey folks,

We would love to hear if you are using Fission! We would like to know:

1. How are you using Fission
2. What else would you like to see ion Fission?
3. If you are ok to share, please mention the name of the company/organization using Fission. We will include it in the "Users of Fission" list in README!
4. Feel free to get in touch with us on Fission Slack

[PraveenGNair]

Hey @vishal-biyani We are accessing fission, so that we can use in our jvm environment But found that fission-java-core module is still in SNAPSHOT version, and that cannot be used as per company policies. Is there any ETA for a release version ?

[vishal-biyani]

Hey, @PraveenGNair Thanks for reaching out. We will prioritize this in an upcoming release.

[vishal-biyani]

Hey @PraveenGNair Can you please raise a separate issue for this?

[ajoslin103]

I am trying to get Fission into our organization, and I feel the best way will be to re-implement code I've already got running inside other docker containers. Then the group that makes those decisions will be able to measure one solution directly against the other. But it looks like RMQ triggers are NYI ?

Update: @viveksinghggits has answered me on #1478

As far as making a case for Fission goes, I'd be welcome of any arguments with metrics comparing it with plain Docker container deployments.

My primary point will be the ease of adoption amongst our current development team, many of whom seem to be having trouble wrapping their code in Docker containers.

I'll be presenting Fission as a tool to lower the barrier of entry, and reduce the 'cost of ownership' of our K8s installation. We have one one guy maintaining all the pods and managing all the rollouts. I'd like to present Fission as a simpler and more controllable way to deploy code. So any arguments for F reducing the 'cost of ownership' of K8s would be nice also.

[vishal-biyani]

Hi @ajoslin103 Thanks for the details and for trying to use Fission. Do you have any specific features/areas in mind that you see missing in Fission from your adoption POV?

[ajoslin103]

I've been mostly a consumer of serverless products via Heroku. I've been kinda mis-using them by deploying entire SPA frontends and backends rather than functions.

At the office we have finally got a fairly solid Kubernetes installation over an OpenStack architecture and my continual push, push, push, for modern devOps is starting to gain some ground.

My first modern implementation for them, after years of SPAs, was a matched semi-micro frontend & backend (using minimal installs of Aurelia & Adonis) to let customers drive a communication, via RMQ & a VPN, to a python adaptor that used the database to control an ssh process to drive some remote hardware.

I took point on the need and designed that project as a set of 5 async processes talking with each other statelessly - using our new infrastructure as architecture and terminating on our just born GrayLog server. It's been a resounding success.

I've got my eyes on our next need, and it will be about twice as complex and I would dearly like to drag the other dev's into a Fission future with me. They are overworked so I have a good chance -- but I'll need RMQ triggers if I'm going to succeed.

I have two weeks to lay out how I want the multiple intertwined processes to work, and to convince our infrastructure overlord that I must have Fission in our production cloud.

My plan is to install Fission into our dev cloud and build the product on top of that so that I must have the Fission in our production cloud to bring the project live.

I've got Fission running on my Mac, but can't get it running on Centos 7.7 yet (using minikube) which is what I have for a template-able instance in our dev cloud (I've requested C8) -- there is an Ubuntu template as well - but U and I don't mix well :(

I want the minikube based install on C to standardize non-productions installs -- it absolutely flew thru the install on my Mac, and hopefully will on any Windows dev who wants a local install. There's 4 more Mac devs and 6 more Windows devs as potential local installs.

It all will hinge on RMQ triggers, as I've finally got the 2 primary senior devs hooked on them. Do you think there's a chance of RMQ triggers being in a release in a couple of weeks?

After that I'd absolutely love to integrate Fission into our non-existent testing architecture -- serverless as a testing infrastructure could work for us, as I can't get any traction on CI/CD here...

Cheers, and huge thanks for Fission !! I've been waiting for the tipping point where I could start using it -- that's there for my own dev, now I need it to be accepted into our clouds.

[vishal-biyani]

Hi, @ajoslin103 Thanks - this is super helpful. Some comments/asks:

1. We will prioritize the RabbitMQ integration and make it available in May.
2. Can you please file an issue about CentOS 7.7 issue if it is related to Fission
3. In other areas - we have done some work and we will update blog posts in the coming month.

[ajoslin103]

-1- PERFECTO!! -- see also #1565
-2- will do
-3- looking forward to it!

I'll update this issue if I have more info not related to the C7 issue

[ajoslin103]

My infrastructure guy just let me know that he is starting the install of Fission into our Lab cluster -- so I won't have to fight to get it added to our stack !!

Excellent !!

I hope to be ready to try out the RMQ support as soon as it's available and we install the upgrade/patch

Nice !!

[slayerjain]

I currently lead the data and platforms team at Fareye. We're using Fission as an alternative to AWS Lambda to write various glue logic and webhooks. We've recently started experimenting with fission for more high throughput/critical use cases which would be difficult to model as a pod (unless the application architecture was rewritten). ref #1628

[toonsevrin]

The problem I have with fission is that it messes with our GitOps workflow.

Ideally we should be able to provide Fission some Git credentials and let it pull the source code itself, instead of having us push it to fission (or requiring us to expose the source on a public http url).

[chenjr0719]

Hi there, I'm Jacob from Cinnamon AI. I would like to share how our company uses Fission to help us build the product.

Before I start, I would like to introduce my company a bit more. We are a Japanese company (though I'm from Taiwan 😂 ) that focuses on AI technology to help our client improve their daily works by providing an AI Document Reader to automate the data extraction from unstructured documents. We have more than 70 AI researchers to build state-of-art AI technology. And the duty of my team is, build the platform to use all AI components and serving to our clients.

So, how Fission helps my team? The main usage of Fission is, we build the AI components as the FaaS function. In other words, we build the model serving functions. And thanks to Fission's features, we can make any AI components into a micro-service and provide the interface in HTTP, or even use the message queue to trigger our AI components.
Besides this, we have some more complicated use cases that need to build the pipeline which involves multiple AI components. Although the fission-workflows is no more available now, I use the Message Queue Trigger to implement the pipeline concept. I just make sure the current function's output topic is the input topic for the next function, then Fission will help us run all the components as the pipeline.
Since the Fission is built on top of Kubernetes, we can easily scale our components to run on multiple GPU nodes, to utilize more powerful computing resources without pain. And also we don't have to worried about the vendor-lock problem even our client requests us to install the on-premise system.

Currently, I'm heavily rely on the MQT, and thanks for the KEDA integration, that is a very nice feature that I'm pretty much enjoying it. Though I think we can make it better:

1. The better error handling. The current implementation only puts the message to the error topic but without the error response from the function itself. To better handle the errors, I think we should also put the error response to the error message so we can have another function to help us handle errors.
2. The retry mechanism. The current implementation only retries when the function is not available (more specifically, when the response is empty). However, for those 500 errors, we might still want to retry.
   Actually, I already have some implement related to two features on my own fork. And maybe we can contribute back to the Fission community.

I think that's all I can share with you guys. I appreciate the whole community building this great project. Let's see what else that I can contribute to the community, cheers. 😉

[info2000]

Hi, I'm using Fission only as cronjob and workflows with rabbitmq

Initially, 3 years ago, we thought on fission to serve our micro-code http request, but with 6 big bare metal servers, and 3 years later is impossible to serve 300 request per second on a cluster with 6 machines 256gb ram and 48 cores

What else would you like to see ion Fission?
had a better performance for production systems, deliver 300 micro requests per second don't should be a 3 years issue

[endersonmenezes]

Hi, I'm Enderson Menezes. SRE on the Stone Infrastructure team, and we are starting a Fission POC.

[lionello]

I'm experimenting with Fission and comparing it to OpenFunction, Knative-Eventing, and OpenFaaS.

[KevinClair]

I'm experimenting with Fission and comparing it to OpenFunction, Knative-Eventing, and OpenFaaS.

Me too, any progress do you have?

[ajoslin103]

There is a Doc over here

#1663 (comment)

[sjk7524068]

Yes, I'm working for a company from china, we are using fission as one part of our production servers. First of all, to fission,I have to say, definitely a good product it is. It plays a good job on concepts, resources management, and some low frequency requests. but we are considering a replacement now. it's really annoying when handling multiple concurrency requests, crashing down for no reason and too hard to track the logs, even for InfluxDB. and maybe some bad events mechanism could be add on MQT. Anyway, I'll keep following all the latest features. My love and respect.

[mersl]

The problem I have with fission is that it messes with our GitOps workflow.

Ideally we should be able to provide Fission some Git credentials and let it pull the source code itself, instead of having us push it to fission (or requiring us to expose the source on a public http url).

I managed the same requirement by pushing the relevant resources (incl. source code) into a oci image on our (internal) registry while the git pipeline run and deploy all resources with a gitops from the oci image (using fluxci). So data stays internal and protected as there are imagePull secrets required to pull the oci image

[chenjinxuan]

第1663章 （评论）

请问下。是fission 函数在大并发请求时性能有问题是吗？你现在是更换了吗，