SpaceX has never met any milestone that Elon has ever set.
Never on time, but always eventually.
Readit Newsrockemsockem commented on Economics of Orbital vs. Terrestrial Data Centers andrewmccalip.com/space-d... · Posted by u/flinner
Dead Comment
rockemsockem commented on Roomba maker goes bankrupt, Chinese owner emerges news.bloomberglaw.com/ban... · Posted by u/nreece
I was so angry at this.
I want Amazon and Google to be broken up, but not in this category or along with these lines. This wasn't going to create some household appliance monopoly. Amazon has plenty of competition, and Roomba was already behind the curve.
Now America is out of this market category. A category we invented. This felt like our last toehold in consumer robotics.
Maybe one day you'll realize the contradictions in this post and think about how you cheered for things that led to this.
I doubt it though
rockemsockem commented on You want microservices, but do you need them? docker.com/blog/do-you-re... · Posted by u/tsenturk
It has other advantages.
Operationally, it is very nice to be able to update one discrete function on its own in a patch cycle. You can try to persuade yourself you will pull it off with a modular monolith but the physical isolation of separate services provides guarantees that no amount of testing / review / good intentions can.
However, it's equally an argument for SOA as it is for microservices.
There are some other benefits like having different release cycles for core infrastructure that must never go down vs a service that greatly benefits from a fast pace of iteration.
Literally one function per service though is certainly overkill though unless you're pretty small and trying to avoid managing any servers for your application.
rockemsockem commented on You want microservices, but do you need them? docker.com/blog/do-you-re... · Posted by u/tsenturk
You can still horizontally scale a monolith and distribute requests equally or route certain requests to certain instances; the only downside is that those instances would technically waste a few hundred MBs of RAM holding code for endpoints they will never serve; however RAM is cheap compared to the labor cost of a microservices environment.
For those numbers, yeah you should absolutely do that. But you might want to host your database on different machines than your application because the numbers will likely differ by much more than a few hundred MBs.
rockemsockem commented on You want microservices, but do you need them? docker.com/blog/do-you-re... · Posted by u/tsenturk
Another case I’ve seen is to separate a specific part of the system which has regulatory or compliance requirements that might be challenging to support for the rest of the larger system, eg HIPAA compliance, PCI compliance, etc.
(To clarify, I’m not disagreeing with you!)
Good point, I was primarily thinking of engineering reasons, but alas there are indeed other concerns.
rockemsockem commented on You want microservices, but do you need them? docker.com/blog/do-you-re... · Posted by u/tsenturk
Many developers started their career during the ZIRP era where none of the typical constraints of "engineering" (cost control, etc) actually applied and complexity & high cloud bills were seen as a good thing, so no wonder.
Splitting up responsibilities into separate services should in fact primarily be done to reduce costs.
rockemsockem commented on You want microservices, but do you need them? docker.com/blog/do-you-re... · Posted by u/tsenturk
At this point, I'm convinced that too many people simply haven't built software in a way that isn't super Kubernetes-ified, so they don't know that it's possible. This is the field where developers think 32 GB of RAM isn't enough in their laptop, when we went to the moon with like... 4K. There is no historical or cultural memory in software anymore, so people graduate not understanding that you can actually handle 10,000 connections per second now on a five-year-old server.
There is in fact software that consumes large amounts of resources for fundamental reasons that saves real dollars when it is split into different units for the purpose of scaling those units independently. Most of that software is not primarily dealing with the number of connections it has.
rockemsockem commented on You want microservices, but do you need them? docker.com/blog/do-you-re... · Posted by u/tsenturk
That's the most nonsensical reason to adopt microservices imo.
Consider this: every API call (or function call) in your application has different scaling requirements. Every LOC in your application has different scaling requirements. What difference does it make whether you scale it all "together" as a monolith or separately? One step further, I'd argue it's better to scale everything together because the total breathing room available to any one function experiencing unusual load is higher than if you deployed everything separately. Not to mention intra- and inter-process comm being much cheaper than network calls.
The "correct" reasons for going microservices are exclusively human -- walling off too much complexity for one person or one team to grapple with. Some hypothetical big brain alien species would draw the line between microservices at completely different levels of complexity.
What are you talking about.
When people talk about scaling requirements they are not referring to minutiae like "this function needs X CPU per request and this other function needs Y CPU per request", they are talking about whether particular endpoints are primarily constrained by different things (i.e. CPU vs memory vs disk). This is important because if I need to scale up machines for one endpoint that requires X CPU but the same service has another endpoint requiring Y memory whereas my original service only needs Z memory and Y is significantly larger than Z then suddenly you have to pay a bunch of extra money to scale up your CPU-bound endpoint because you are co-hosting it with a memory-bound endpoint.
If all your endpoints just do some different logic and all hit a few redis endpoints, run a few postgres queries, and assemble results then keep them all together!!!
EDIT: my original post even included the phrase "significantly different" to describe when you should split a service!!! It's like you decided to have an argument with someone else you've met in your life, but directed it at me
Amazon helped dismantle the entertainment industry. Full stop.
It doesn't mean Amazon's home appliance and home automation product lines or platforms are harming competition. There is robust competition in this sector.
Amazon offers "free" entertainment, subsidizes the cost of series that rival HBO's Game of Thrones production costs using unrelated business units, market those movies and shows for free in the Amazon app, on their website, emblazoned on their delivery vehicles and on every item of packaging. Other companies have to pay hundreds of millions to match this. There is eyeball opportunity cost for consumers, and Amazon is flooding the zone with their free wares. This is a markedly unfair advantage.
Amazon moves US union jobs overseas and trains up low cost crews in Eastern Europe. They buy up once successful studios on the cheap because they all tried to catch up with the stupid steaming game.
Theatrical box office receipts are the biggest revenue driver for studios by a wide margin. Individually, studios could have countered Netflix and Disney by pulling licensing. Amazon in the mix threatened this, because they had existing content licenses and also controlled home media releases. The studios felt cornered by tech giants basically salting the earth. They had to give up healthy Box Office proceeds and exclusivity to chase streaming and defend their access to eyeballs as best they could.
You've heard of Disney eating the mid market film? Amazon ate everything. It left no oxygen in the fish bowl.
Amazon's entertainment business needs to be spun off.
All of that can be true and completely unrelated to Roomba. Nothing should have prevented their purchase of iRobot. That was insanity.
Prevent them from buying their competitors, for sure, but don't kid yourself into thinking that there are many neat ways to parcel these companies up into neat little independent business units. There is at best a very small number of ways to do this and the government will not get it right, just look at their most recent attempt with Google to strip out Chrome of all things.
Just to be clear on my stance,I agree that blocking the irobot deal was absurd. Context matters in a big way, clearly they were struggling and were basically alone in the market as an American company.
I think you also need to apply that context to Google and Amazon and consider whether the government would do so wisely.