Readit NewsDeleted Comment
Off the top of my mind I'd go with privacy policies: maybe their typical vagueness is exploited to the extreme, and rather than pointless legal mumbo-jumbo, they're actually a legal cornerstone of some extensive surveillance program. Hmm...
There are in between solutions. Renting bare metal instead of renting virtual machines can be quite nice. I've done that via Hetzner some years ago. You pay just about the same but you get a lot more performance for the same money. This is great if you actually need that performance.
People obsess about hardware but there's also the software side to consider. For smaller companies, operations/devops people are usually more expensive than the resources they manage. The cost to optimize is that cost. The hosting cost usually is a rounding error on the staffing cost. And on top of that the amount of responsibilities increases as soon as you own the hardware. You need to service it, monitor it, replace it when it fails, make sure those fans don't get jammed by dust puppies, deal with outages when they happen, etc. All the stuff that you pay cloud providers to do for you now becomes your problem. And it has a non zero cost.
The right mindset for hosting cost is to think of it in FTEs (full time employee cost for a year). If it's below 1 (most startups until they are well into scale up territory), you are doing great. Most of the optimizations you are going to get are going to cost you in actual FTEs spent doing that work. 1 FTE pays for quite a bit of hosting. Think 10K per month in AWS cost. A good ops person/developer is more expensive than that. My company runs at about 1K per month (GCP and misc managed services). It would be the wrong thing to optimize for us. It's not worth spending any amount of time on for me. I literally have more valuable things to do.
This flips when you start getting into the multiple FTEs per month in cost for just the hosting. At that point you probably have additional cost measured in 5-10 FTE in staffing anyway to babysit all of that. So now you can talk about trading off some hosting FTEs for modest amount of extra staffing FTEs and make net gains.
It's typically going to cost significantly less; it can make a lot of sense for small companies, especially.
I thought we couldn't reach a lower point than what happened with social networks, but here we are.
We need strong laws about this.
However much the code is hidden and obfuscated, some parts of the source code are going to be looked upon.
For a binary, none, ever, except in the extremely rare case that someone disassembles and analyzes one version of it.
The fact that open-source doesn't coincide with security doesn't mean that it isn't beneficial to security.
The vast majority of apps are probably used by a handful of people. If any external app with heavier traffic wanted to use AppX, we should architect it accordingly.
Here is the full proposal:
https://docs.google.com/document/d/e/2PACX-1vT5i_J8Kq2VEcyqd...
You think you know who's responsible for it; just ask him
You'll have a hard time at changing things without knowing the background of the situation.
I realized that in the microservices world this kind of duplication could be acceptable; are those apps meant to be microservices?
---
I disagree with the "data alone isn't valuable" paragraphs of your proposal; I was actually going to tell you to keep in mind DBMS, besides APIs: they're specifically built to provide data to many parties, efficiently and safely.
One concern of allowing APIs might be that it might be demanding for an app, it could require adjustments and fine-tuning. Allowing direct access to a DBMS would largely avoid any such problem. You might well not even need any read replica, if you don't have an enormous load of requests (but you might prefer to make them, for redundancy and decoupling).
Even some derived data could be handled by stored queries, although your team might not enjoy dabbling with sql too much.
> This architecture was designed to achieve loose coupling, high availability, and independent deployability. These remain valuable goals that any proposed changes should preserve.
Were you explicitly told that these were the goals?
If so, it sounds a lot like microservices; data duplication and very strong decoupling is encouraged, and it could be hard to convince your colleagues.
> Our current approach draws inspiration from event sourcing,
Are you sure? A core aspect of data sourcing is storing all the events, and deriving the current state from them. It might be just an event-driven architecture.
---
I agree with most of your document, anyhow, although it might be hard to convince the others, if they're all-in into microservices.
Off the top of my mind I'd go with privacy policies: maybe their typical vagueness is exploited to the extreme, and rather than pointless legal mumbo-jumbo, they're actually a legal cornerstone of some extensive surveillance program. Hmm...