Amazon API Gateway vs. Drools

Experienced a lack of available programming languages while working on a minor project. I had to halt the project and wait for it to be added later. It took ages and had a hit on our productivity. It has a centralized management system which helps and an easy interface which helps to manage multiple tasks in case of large-scale operations and projects.

Incentivized

As an open source rule engine and product suite, Drools is well suited for the small and middle scale business to manage and integrate the rules to build the rule-driven system which can process the business-critical data and events to produce the automated decision. It is better to use Drools in the well-secured environment (back-end behind the DMZ), not putting it on the customer-facing front or exposing it directly the to public where may bring direct security risk in the enterprise environment. Drools still needs a lot hardening on the security side.

Incentivized

• API Gateway integrates well with AWS Lambda. This allows us to build a web server in the language and framework of our choice, deploy it as a Lambda function, and expose it through API Gateway.
• API Gateway manages API keys. Building rate limiting and request quota features are not trivial (or interesting).
• API Gateway's pricing can be very attractive for services that are accessed infrequently.

Incentivized

• Writing rules with business focus
• Rules evolution and maintenance
• separate business logic from program code

Incentivized

• Client certificates are troublesome when trying to attach them to API GW stages.
• Debugging across several services can be difficult when API GW is integrated with Route 53 and another service like Lambda or EC2/ELB.
• Creating internal/private APIs, particularly with custom domains, can be unintuitive.

Incentivized

• Fusion doesn't support persistence of working memory, which brings some extra high availability risk to our business.
• Guvnor still has a lot room to be implemented, it is not so user-friendly for non-technical people, so a lot of business users complain it is hard to master.
• Rule execution server doesn't even have JMX implemented, hard to be monitored.
• Drools is still lacking support for key Web services standards.

Incentivized

It is a great product very reliable and stable for connecting various aws services like we connected with lambda function and it is working very well, never faced any issue after the setup. It also saves out lots of money as well as time after we implemented the automatic ec2 server recovery system

Incentivized

We always had a great experience with the AWS support team. They were always on time and very dependable. It was a good partnership while we worked to resolve our issues.

Incentivized

When we tested Azure API Management at the time, it had serious connectivity issues, it was very unstable, and it needed to do a lot using the command line. Comparing with the AWS solution, which was more mature, and the fact that we have services in use on AWS, we ended up choosing to continue using AWS products. This so as not to run the risk of increasing latency in accesses, and of some functionality not working, due to being developed yet.

Incentivized

I did not participate in drools choice. I can only compare drools with the previous situation which was using nothing.

Incentivized

• ROI is negative, you need either to hire them to work with you or spend days/weeks to figure out issues.
• For some of the projects in the end it is not worth it, it is just a "buzz" to use serverless but not practical.
• Service is easy to set up authorization and it is easy to manage.

Incentivized

• The IT department quickly adopted Drools as it is a very good java-based rule engine, which saves a lot of time to meet the project timeline and balanced our business requirements.
• Recently we start considering the OpenRules, which may be more business user-friendly.

Incentivized