Pure economics. In Minneapolis the railroad demanded a crash wall to separate the light rail trains from their trains. It runs 1 mile and somehow cost nearly $100 million. This is a 5x increase from the original estimate but still $20 million for a 1 mile wall is a heck of a lot of money
Here's an example. One of my friends works for a manufacturing company. He attended a protest. The next day ICE called his employer and he was informed that if he attended another protest he would be fired. All this b/c he had a small company logo on his jacket.
The ability to en-mass record, lookup and intimidate citizens is unprecedented and while I have no hard proof that this is due to Palantir, it sure smells like it
ICE employees working to “injure, oppress, threaten, or intimidate any person in any State, Territory, Commonwealth, Possession, or District in the free exercise or enjoyment of any right or privilege secured to him by the Constitution or laws of the United States, or because of his having so exercised the same”, such as exercise of 1st Amendment rights, is itself super-illegal (not just “outside their authority” but a federal criminal violation of the KKK Act), whether or not the employer’s response to the resulting pressure is also illegal.
SimpleCov in ruby has 2 metrics, line coverage and branch coverage. If you really want to be strict, get to 100% branch coverage. This really helps you flesh out all the various scenarios
Seems like a great opportunity to curtail betting. You want to leach money out of people, well you have to leave yourself open to let the pros do it to you.
My first startup we had to support IE 7 for a bit and then IE 8 until like 2017… I thought I had it bad then. I’m so glad I didn’t have to fight any older version
My friend owns a metal stamping company. One of the things they make are the heat dissipation fins for radiators. That portion of their business has grown 20x in the last few years.
The entrenched interests would fight tooth and nail against this but I think that the drive towards simplifying billing and pricing is a generally good thing.
That being said, in my view, one of the fundamental problems with healthcare is that outside of truly elective procedures like cosmetic plastic surgery and lasik, it's nearly impossible to have free market economics function.
- There are HUGE information asymmetries between doctors and patients
- Judging performance of doctors is very challenge. Reviews are terribly inaccurate, data can be better but has big problems, and even other doctors aren't good judges of doctors outside their specialty.
- Right now at least, price discovery is nonexistent so you can't price shop and compete on price vs quality
- Insurance means that consumers of healthcare are not actually footing the bill so they have no incentive to price shop. And most healthcare procedures are completely unaffordable so there's no way we can do without insurance
- and finally it's really hard to make an economic decision that is literally life and death. Am I going to forgo a $100k surgery if it means I'll die? There's no choice there
All of these things lead me to the conclusion that healthcare is fundamentally incompatible with classic free market economics, and some form of single payer is the only solution to avoid us bankrupting our country spending on healthcare
One of my favorite things when I was here was seeing an Amazon Prime logo on the saddlebag of a donkey. That struck me as a very weird collision of old and new worlds
Microservices make sense from a technical perspective in startups if:
- You need to use a different language than your core application. E.g. we build Rails apps but need to use R for a data pipeline and 100% could not build this in ruby.
- You have 1 service that has vastly different scaling requirements that the rest of your stack. Then splitting that part off into it's own service can help
- You have a portion of your data set that has vastly different security and lifecycle requirements. E.g. you're getting healthcare data from medicare.
Outside of those, and maybe a few other edge cases, I see basically no reason why a small startup should ever choose microservices... you're just setting yourself up for more work for little to no gain.
Splitting off a few services from an application is not the same as using microservices. With microservices you split off basically everything that would be a module in a normal application.
I think that really depends on your definition. But I will also contend that even splitting your system into 2 or 3 services if it's not for strong reasons will 100% slow you down and cause long term headaches.
One project that I helped design had to split out a segment of the system b/c the data was eligibility records coming from health plans. This data had very different security and lifecycle requirements (e.g. we have to keep it for 7 or 10 years). Splitting out this service simplified some parts but any time we need to cross the boundary between the 2 services, the work takes probably twice as long as it would if it were in a single service. I don't think it was the wrong decision, but it the service definitely did not come for free
> But I will also contend that even splitting your system into 2 or 3 services if it's not for strong reasons will 100% slow you down and cause long term headaches.
Even tiny backends usually have, from the start, a database server, some web server / proxy to handle incoming requests and load balance or cache them, and then something running your actual code that requests are passed on to. That's so normal that we don't even think of them as separate services anymore, but they are.
Splitting off a few larger parts because they are self contained, have their own Ops characteristics and might be usable by other projects on their own, vs creating a service for every single entity in your domain modal (or whatever), that's quite a difference.
We have an auth service, a database service for raster geo data, a generic task runner. Those are services. They all have their own pretty unique architecture and stand on their own, they are used by but are separate from the project that they were made for.
Different services for customers, for orders, for invoices, for items in the shop, for items on an order, for promotions, that's microservices. They all look very similar and belong to the application.
In addition to having 1 service with vastly different scaling requirements, having 1 service with vastly different availability requirements may make sense to separate as well.
If you need to keep the lights or maintain an SLA and can do so by separating a concern, it can really reduce risk and increase speed when deploying new features on "less important" components.
