re: Who's going to write us a post on alternatives to mongoose ? VIEW POST

re: That was a mere remark with no intent to be hostile; regardless. Again, you are defining a schema, a structure. Something which is probably bette...

I think we reached a point in the discussion, that is pointless to continue.


You are basically saying: kick all people out of companies, no matter how log they have worked with the company, because they are not able/willing to learn another database. Not the most social part.

Also you seem to never have worked for companies that came from other sectors to web/IT where the old politics also apply to new sectors. And these companies may not have a dedicated DevOps team.

First: Coding is not my Job. Completly relying on a hosted service by one vendor is stupidly dangerous. There are reasons why projects like Istio are comming up to have multicloud solutions. And sorry to say this there the way to go is Kubernetes. I would never use any dedicated vendor product, just because you do not know what will happen.

Maybe it is a different use case in germany, but we are stuck with legacy code, legacy system and lots of lots compliences that even state the servers have to be on german soil for certain things.
But i know this as well from other western europe countries and companies in the us.

We surely have reached that point.

I am not saying that. And I never said that "kick them if they are not willing to learn another database." I am saying that it's a sign of a good developer to learn something new and apply it. If you think that you are going to have one skill set and apply it everywhere without learning anything new, then... I am not sure what to say. Now, before you misconstrue that and think that you need to be on your toes and learn everything to be good.

Also you seem to have never...

I have worked with a lot of companies in a lot of different sectors; food, education, marketing, sales, ops, logistics and I am yet to see this level of dystopia you mention. Maybe it's because the new heads of these companies are doing their jobs right and keeping things where they belong.

Completely replying on a hosted...

Umm. What? You do realize that and a lot of other applications you use on a daily basis (Netflix, for example) are deployed almost exclusively on AWS.

Your argument of "the way to go is..." is a classic example of how when someone is comfortable with one technology, they use that regardless of anything happening for every single project.

As far as Istio is concerned: there is a reason why AWS has faired for such a long time.

I don't understand why your entire argument chain shifted from database technologies to a cloud provider.

Ok let's get back to why it might be useful do define models:

The database needs protections from it's foremost enemy: the developer
If you have some basic layered structure of data you force the developer to think instead of just vomiting data in your database.
If you have at least partial structured data you also have a bullshit filter of what comes into a database.
If you have structured data you can be shure that for example an idex of a field exists. There is a reason why you can set indexes in mongo.

Schema and Data Modeling is part of MongoDB, heck it is even in the documentation:

You could now come again with the argument why not use PG, simple less options querying the unstructured Data within you possible model.
A Mongo Cluster is also working way more reliant as soon as it comes to cross region scale, even if you use a managed service like RDS

You brought up the point it is easier with using DaaS and then brought up some strange views using mono cloud SaaS.
Why not use single Vendor cloud?

How nice that you choose Netflix, roughly one year ago AWS East Us crashed and was down, half in the US Netflix, Github and some other service have not been available for over 6 hours.
Gues what, Netflix moved to Multicloud and uses Google Cloud as well, because of this.

Also cloud platforms, regardless of form factor or delivery method, are not all interoperable with each other or with legacy systems. There is often an assumption that all will play and talk nicely together and push and pull data easily; this is not the case. Therefore, the ability to mix and choose between offerings in a multi-cloud environment

You cannot easily move your infrastructure to annother provider. The question might be why would i? You do not know exactly what is on layer below, there might come changes that you did not antacipate. Or simply a matter of cost.

Additional you have advantages like lower lateny, higher security.

Most of the bigger companies, are or currently moving to multicloud enviroment.

I drop out of this discussion now, because in my opinion the view of this discussion is only in seeking to find flaws.

code of conduct - report abuse