Attila Fulop

I've been using both Bugsnag and Sentry for years and I would recommend both of them and as Tom Maiaroto mentioned "they are roughly the same". Bugzilla is a different kind of animal, that is more of an issue tracker like Jira or Redmine.

Despite what Tom Maiaroto wrote, we're using these tools more for the backend and less for the frontend, so I am going to give a brief insight into how we use them in our Telemetry stack for monitoring the backend.

Sentry and Bugsnag are advertising themselves as Application Monitoring, but their definite focus is on Error Monitoring. This is what they originally were made for and this is were they shine.

A typical confusion is that we think they are mutually replaceable with APM tools like NewRelic's or Datadog's APM. Albeit both are doing very similar things, there are several significant differences:

• NewRelic/Datadog APMs are sampling exceptions, so you don't have a "complete catalog" of your errors
• Sentry and Bugsnag are collecting very detailed data (stack trace, HTTP request, user, device, host, etc) of each exception, thus you'll exactly know when, where, how many times and to whom those errors have happened.

The focus of those APMs is broader and can give you a much bigger picture like distributed tracing, logs, processes on the hosts at the given moment just to name a few. But they are not designed to give you a laser focus on each specific error.

So the bottom line is that they are complementing each other.

Sentry is more affordable especially if you have more than 5 users. I personally prefer Bugsnag because of the cleaner UI. But at the end of the day, they're both very valuable and lovely gadgets in our toolbox and help us a lot being on top of our systems

First of all, Java can give you definitely better speed, especially at scale. One benefit is that you can tune it for a better response time, and another one is when you'll have millions of requests per day it'll save you some infrastructure cost.

But.. will you have millions of requests a day? How much does it matter if the API response time is 10ms or 50ms?

Rewriting an existing project is a huge deal. It can take years(!), especially if the team hasn't done such a thing yet and especially if the tech stack gets completely replaced.

So I argue against rewrite in the first place. There are two older articles on the topic, but their arguments are both valid as of today: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.jjinux.com/2008/05/joel-on-software-never-rewrite-from.html

What I'd suggest instead is to learn refactoring strategies. Even if you have some routine with refactoring it is worth reading Fowler's refactoring book: https://book-programming.com/refactoring-books/

What I would do with a "frameworkless" PHP codebase is: - Add a framework (I would also go with Laravel, but Symfony or Phalcon would also do the job) - Isolate the existing codebase in a folder if possible without any actual changes - Route the requests through the framework (with a catch-all route) and forward the request to the existing codebase - Take a simple component/page to start with and replace the DB calls using Laravel's DB layer - Doing this "experiment", you'll have a strategy that you can apply to other components - Do the refactoring for views, controllers, etc, step by step - In case you have APIs and other kinds of components apply different strategies - Keep deploying as frequent as possible - Apply the learnings on the run and do pivots if needed

There are many more details to this, but it exceeds the scope of this answer.

About Java: last year I was part of, actually sparking the rewrite of an existing API from Symfony to Java using Spring Boot/JHipster. The bottom line is that it was a bad idea.

We had a separate PM, an Engineering Manager, and a set of developers both Java and PHP, one of the developers highly experienced with the JHipster stack. We've got the support of the CEO, and despite his strong worries, the Head of Software gave it a green light too. After 20 months the old PHP system is still running and - of course - it has more features than the Java one, because life didn't stop, business demanded new features in the live system.

Java and the whole ecosystem are very different, so even if you have people with battlefield experience with it, the complete rewrite is extremely risky.

In my opinion, it's less of a technical than a business decision. I would sit down with the person(s) paying the bill for the refactoring. I would phrase the following questions and elaborate the answer together with them: - What is the problem we want to solve? (maintainability? speed? lack of people understanding the system? security?) - Is the system legacy only technically or also in the meaning "it no longer fits the business' reality"? - What are the expected outcomes of the refactoring? - What is the budget for the new/refactored system? - What is the timeframe allowed for the refactoring/rewrite? - How does the rewrite compare to refactoring, in terms of time, money, and complexity? - What happens with the development of new features during refactoring? - What resources will be assigned to the refactoring project?

Chef is a definite no-go for me. I learned it the hard way (ie. got a few tasks in a prod system) and it took quite a lot to grasp it on an acceptable level. Ansible in turn is much more straightforward and much easier to test.

Bugsnag is one of my favorite tools. I must admit that I can't compare with the other two variants, because I only have experience with Sentry and Bugsnag. Both are fine, but I lean towards Bugsnag. With the help of Bugsnag I'm able to see quite clearly what went wrong, and it shows the affected users (and in my case even the tenant as we're operating a multi-tenant application).

Regarding Logstash: I've been using Bugsnag as a complementary tool with Logging + APM platforms like NewRelic or Datadog. What I mean is, go for Logstash if that's the log monitoring tool you like, but Bugsnag and Logstash are not interchangeable, and it perfectly makes sense to use both.

If there is a way to connect to Redis via UNIX sockets instead of TCP then it worth it to switch over. We had a busy e-commerce site with heavy Redis usage and we saw a 4-5x(!) performance improvement during testing situations with a high number of concurrent requests.

I know that the probability these days is rather low to have such a scenario where you have Redis and the app on the same host (and thus the ability to connect over UNIX sockets). But if that's the case, it's definitely worth it.

Disclaimer: I am a PHP developer.

Both can do the job, but I suggest .NET, here's why:

• .NET has first-hand support for Microservices Architecture
• PHP typically needs to have 2 containers running per service (fpm and nginx)
• C# performs better due to being a compiled language
• .NET has a better performing architecture since it doesn't need to boot the framework at every request*
• C# supports threads whereas PHP threads support is limited

*: In case you would still go with PHP, I suggest Swoole optionally with Laravel Octane. This is yet an unconventional PHP setup, but they've been around for a while to be mature enough. This is the structure you'll need for a good microservices setup in PHP. Also, .net, nodejs and Java apps are running like that.

How many services do you plan to have? What orchestration tooling do you plan to use? Are you going to use services written in different languages?

I have hands on production experience both with New Relic and Datadog. I personally prefer Datadog over NewRelic because of the UI, the Documentation and the overall user/developer experience.

NewRelic however, can do basically the same things as Datadog can, and some of the features like alerting have been present in NewRelic for longer than in Datadog. The cool thing about NewRelic is their last-summer-updated pricing: you no longer pay per host but after data you send towards New Relic. This can be a huge cost saver depending on your particular setup

https://docs.newrelic.com/docs/accounts/accounts-billing/new-relic-one-pricing-billing/new-relic-one-pricing-billing

I'd go for Datadog, but given you have lots of containers I would also make a cost calculation. If the price difference is significant and there's a budget constraint NewRelic might be the better choice.

In order to answer the question, could you please tell me how you handle multi-tenancy in the application at the moment?

Anytime we had such cases it turned out the SQL queries within the (PHP) application needed to be improved.