What is our primary use case?
We are a fintech company located in Argentina, and most of our use cases are related to transferring money from one account to another and doing the orchestration with financial institutions.
It is also used for the orchestration of all the documents for onboarding. We have electronic onboarding where you give some information about yourself, and then you take a selfie and provide photos of the front and back of your document. We have to orchestrate all this information in order to validate it with a third-party bureau of data. When we receive an okay from the bureau, we know that you are an active customer, and we can give you an account.
In terms of deployment, it is a public cloud. We have Amazon Web Services running inside a Kubernetes cluster.
How has it helped my organization?
We are a startup with less than 200 people. We first started doing orchestration using code, but after two sprints or about a month and a half, it became very clear that we are just generating spaghetti code. No one could understand the code after one month because it had difficult logic based on what an engineer thought would be a good idea, such as creating a new branch of decision, and if it wasn't very well documented, you wouldn't understand what was going on. Another drawback of having such a code was that we couldn't make the business understand what was going on there. So, it was very difficult to do things faster. That's why we decided to look for an orchestration tool, and we decided on Camunda as a solution. The way we could orchestrate everything was transformative. We went from having to code to drawing our processes. As of today, Camunda is used for every process here.
It is very good as a universal process orchestrator for complex business processes. We are using it for microservices, not for a human process. We had thousands of processes happening per hour, and the tool was able to capture the data for this throughput. The thing that wasn't aligned was the pricing structure. Camunda On-Premises is more designed for a human process where you have to have some kind of manual processing. We had a lot of back and forth with the commercial team because of the price of the licensing due to the volume that we had to process. That's because every time we wanted to send $1, we had to start a new process or several processes. This was a drawback, but in terms of the project, the product was very good and robust. Process heatmaps show the process steps that are hanging or taking significantly longer. You can go there and see the values and debug those. So, it was very useful for not only orchestrating what we have but also in understanding where we have made a mistake with a production process.
When it comes to integration, because we are a startup, we don't have any legacy systems, but we use it to connect with the legacy systems of the general payment system in Argentina. It was very instrumental for this use case. We had our own logic for how to connect and how to do the interface inside our microservices, and we used Camunda to verify the correct logic and sequence of calling different microservices, getting the response, and handling the response.
The dashboards are helpful in making the business understand what we are talking about and what can we do in certain situations, such as, if the money doesn't arrive at its destination. We had the drawings, and we used them to ask, "For the arrow here, what should we do?" We were able to have the conversation in a clear way. If we had just the code, it would have been very difficult. To have the conversation with the business, we would have had to create a drawing on a whiteboard and hope that this drawing is exactly what is happening in the code.
It freed up the time of our technical leaders working on this part of the system. By using Camunda, we could have the application process design, and we could quickly deploy the system to production and have the product early on the market. That was our biggest gain. We didn't have engineers struggling to orchestrate microservices.
What is most valuable?
The BPMN diagram is valuable. For our use case of transferring money from one account to another, the connections have to be done in the traditional financial ways. There are a lot of unexpected errors and a lot of instability with this kind of system, and we are using Camunda in order to have clear flows. With BPMN, I can show a flow to my business partner, and the business team can easily understand what's going on. The technical team can understand what the implementation is, and we can model different errors and the process for recovering from these errors. For example, it is very common that you make a transaction, but you don't have a response from a bank. You sent the money, but the bank didn't confirm this. Such errors have to be handled because it may mean that you have to do a reverse transaction. We are able to solve a lot of orchestration problems by using Camunda. Most of them are related to payments or sending and receiving money.
The feature where you can have dynamic tables with values and actions inside the BPMN is very good when you don't have all the possible responses. We may think that the payment system is very robust, but it is not. Sometimes, we receive an error code that we weren't expecting, and this kind of solution helped a lot with that.
What needs improvement?
Camunda has licensing per process. There should be a different kind of licensing so that a company with thousands of microservices doesn't have to pay per process. It would be very useful for us. Their current licensing is very difficult for us to maintain. When you have a lot of processes running, it becomes very expensive very quickly.
It has a Postgres database at the backend, and it is very difficult to scale if you increase the number of processes running. We did hit some barriers. We were able to overcome them, but it was a problem. Camunda has another product called Camunda Cloud, which supposedly doesn't have the same scalability problems, but we are not using Camunda Cloud because the set of features is smaller than Camunda On-Premises. So, its scalability can be improved. Because it has a single database, it is more difficult to scale if you have a huge success.
We use our deployment pipeline to deploy the BPMN process. We have a continuous deployment system where when you finish your development, you are able to deploy the BPMN file as well. Sometimes, when the engineers are deploying several BPMN processes in parallel, we receive an error for Camunda, and we are unable to do the deployment. It is a very specific issue, but we have found that automatic BPMN process deployments sometimes fail in Camunda. When we try to deploy several at once, the system isn't strong or robust enough. So, there is room for improvement.
Buyer's Guide
Camunda
April 2024
Learn what your peers think about Camunda. Get advice and tips from experienced pros sharing their opinions. Updated: April 2024.
768,886 professionals have used our research since 2012.
For how long have I used the solution?
I have been using this solution since October of 2020.
What do I think about the stability of the solution?
In general, its stability is very good.
What do I think about the scalability of the solution?
Scalability is something that we have been worried about because everything that runs in Camunda is run using Postgres. It is very difficult to scale when the number of processes increases. Because Camunda uses Postgres, we had scalability challenges. We had to do a lot of fine-tuning in the Postgres database to support increased processes.
The main problem with scalability is related to the database. That's why they created Camunda Cloud, which is Zeebe. They know they have this dependency on Postgres, which is hurting its ability to scale up.
How are customer service and support?
Their tech support is very good, but it also depends on which support team you get. You can get someone who doesn't understand the whole thing.
They have been very supportive from the beginning. I believe that they didn't have our type of use case before where a fintech company is using Camunda for its microservices. We could see the same people who were committing the code in the open-source version providing the support to us. It couldn't get better than that.
I would rate them a nine out of ten. Sometimes, we had a junior engineer, and it took a lot of back and forth communication to have the answers, but in general, we have had a very good support experience.
How would you rate customer service and support?
Which solution did I use previously and why did I switch?
How was the initial setup?
It is kind of straightforward. We have everything configured as infrastructure as a code. So, we got the best practices from Camunda, and we wrote our deployment instructions for Camunda's deployment as code by using Terraform. We did that on our side, but it would be very good if we can get it from them, but I understand that each client probably wanted to have their own method of deployment.
Camunda's deployment was easy, but fine-tuning the Postgres that we had as the backend database wasn't easy.
After the deployment, it took us two to three months to wrap our minds around how to use it correctly. After that, it was a matter of creating templates that our team would be able to leverage and start using more and more. It isn't a very difficult product to understand. It has its quirks, and that's the part that you have to learn and has a steep learning curve, but when we did our due diligence, Camunda seemed to be more mature and straightforward than its competitors. I value it very highly.
What about the implementation team?
Everything was done in-house. I built a very knowledgeable technical team. We had DevOps, and we had frontend and backend engineers. We had a complete team dedicated to making the startup grow. There were two to three people doing the work for a few weeks, and we have been able to make everything work.
It is easy to maintain, with the exception of the database. For the Camunda instance, for example, it is very easy to maintain the licenses. It is easy to attach a license to the container, and we are good to go, but we also have to take care of the database. We have grown so fast, and in order to not have a huge Postgres database, we have to delete some of the instances, such as instances from a day earlier. We are deleting the processing history because the database couldn't handle all the data that was passing through it. Maintenance-wise, that's what I remember the team complaining about.
What was our ROI?
We have definitely seen an ROI. We are using it for all critical processes in the company. The dashboard and the BPMN part have been instrumental to our success.
What's my experience with pricing, setup cost, and licensing?
It is good for a startup. When we started, its price was fair, but the way we are using it to orchestrate microservices makes it expensive. When you are growing as a company, you would have more microservices, and you would have more users. There is an exponential effect when you are growing in terms of the number of conditions, processes, and users because they bill you per process. So, the price was increasing very quickly for us, and it was very difficult.
The commercial team has been trying to find a way to have different licensing, and it seems that we have found a way. We're starting a conversation with them, but so far, our experience is that when you grow as a company, the cost increases very fast. It has been difficult for us. However, our use case was related to microservices, but that might not be the case with other use cases.
We purchased a license directly from Camunda. It was the first time that we were working with a process orchestration system, and the features or aspects of the paid license that appealed to us included support and dashboards. Having a dashboard helped us to understand which processes are failing and where they are failing. They have heat maps that show the paths that are more used in our process. It has been very useful to understand how things work in general, and then you can go and do a deep dive and select a specific process and debug it. You understand why it was failing. It has been very valuable for the engineers in understanding what's going on and how to fix a bug.
If you want to debug a process and also understand what's going on in different instances that are failing, the features in the paid version are very valuable.
The paid license features are instrumental for us. Because of the price increase, we are looking at alternatives. We are looking at just an open-source solution, but we really don't want to do that because we're going to lose a lot of features. The dashboard, heat maps, and visual administrative interface are not available in the open-source solution.
Which other solutions did I evaluate?
We did a little bit of research. We looked at Zeebe, which is their own. We also did research on jBPM, but it didn't have all the features.
We were trying to solve a problem in our startup, and we just started to look for solutions. We didn't have a broad benchmark. We were looking for something that could work, and Camunda was fit for our needs. We couldn’t find anything that had the stability or robustness that we were looking for. So, we went ahead with Camunda.
What other advice do I have?
I would advise comparing it with Camunda Cloud or Zeebe. If your use case allows you, go with Camunda Cloud because, this way, you can leverage this new system that has fewer scalability problems. It is not a straightforward recommendation because at least until last year, the set of features in Camunda Cloud wasn't the same as Camunda On-Premises. That's why we didn't use Camunda Cloud.
We didn't use any third-party connectors. We used Camunda and then we used just the HTTP connector to orchestrate our microservices. We didn't do a direct connection from Camunda to any outside or third-party system. With Camunda, we only wanted to orchestrate our microservices, which can then connect to third-party or other systems. We wanted to keep our architecture clean, and this piece of software was used to orchestrate microservices, which was great.
Camunda provides an interface where business users can create, update, and execute complex workflows, but we didn't use this feature. No one from the business side used it for creating their own processes or modifying anything. I used it only for microservices. Being able to have a diagram and being able to have a business discussion by using the diagram as a reference was good. It was very interesting because we could have all the teams and all the specialists on the same page, but I didn't have anyone from the business side or operation side directly using or connecting with Camunda.
It hasn't reduced the cost to design and implement critical processes. That's because we weren't using any other tool previously. So, I don't have a comparison. It also didn't have any effect on our TCO. We are a cloud company. We have a very modern infrastructure where everything is on Amazon. The team is very used to getting docker systems and running complex systems inside of Kubernetes. We haven't had any trouble running it.
I would rate this solution an eight out of ten.
Which deployment model are you using for this solution?
Public Cloud
Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.