Nextgrid

I guess the question is how will it be enforced and what would the penalties be for reporting inaccurate or outdated data?

Companies do not understand "must" unless it's accompanied by a proven threat of sanctions that outweighs the profits made by breaching the regulation. The GDPR is a good example of plenty of "musts" and theoretical fines but lax enforcement means it's always more profitable to breach it than comply.

With the low cost & power of modern microcontrollers, instead of having the dongle act purely for licensing purposes you could offload some of your "secret sauce" to it (I assume your software does a lot of calculations with some hardcoded, industry-specific constants). This makes it somewhat crack-proof because cracking it would involve replicating your secret sauce - at which point they may as well just make and sell their own software instead of distributing cracks.

Muting notifications and deleting do not have to be correlated (unless you send something offensive enough to prompt someone to delete immediately).

Muting notifications means "I don't need this thing to interrupt me". Deleting means "I don't need to use this thing ever".

Those are very different and separate things - I have plenty of apps that I use regularly and yet they do not have notifications enabled because there would be no value from that.

The salaries may be high in absolute terms, but they’re still low in relative terms - compared to what jumping ship would give you when you have a resume full of buzzwords.

None of the autoscaling solutions presented in the post address the database issue either.

I agree that in general the database is always going to be your bottleneck and autoscaling appservers is generally bullshit.

But let’s assume your DB is fine and you do actually need to scale appservers beyond what your provisioned capacity can allow, you can trivially spin up VMs at AWS or your provider of choice, Wireguard to your “VPC” at your bare-metal provider (or just SSH tunnel the ports) and run your appserver binary/container/etc on it.

Hell in a pinch you can do the above with your dev laptop and serve traffic from it. It will work and your customers won’t even be able to tell.

Java or C# is a nice middle ground. But even in python you can enforce said separation - one module can only import from itself, libraries or any other module’s “services” object, and must export its functions in its own “services” object.

This behavior is self-inflicted by a decade of low pay and lack of significant raises to reward seniority.

The most effective way to increase income for a developer is to join a place, rack up as many buzzwords as possible and leave after 2-3 years, using those buzzwords to secure a higher-paying role somewhere else. Rinse and repeat until you get a management position where you can use politics to increase your income instead.

If you want guys that use boring tech to drive the business forward you have to pay them upfront the money they’d otherwise make playing the above game. It still makes sense (an engineering playground is anything but cheap) but good luck getting an employer to pay anything above “market rate”.

You don’t need to buy them, you can get them from AWS for that period only. Doesn’t mean your whole stack needs to be on AWS.

Out of interest how do you get the authority to make those decisions and have the existing developers continue working productively after this?

To me it seems like microservices (or cloud, or whatever) is often overused for career/buzzword reasons. The engineers pushing for it aren't asking for your advice, they want to build an engineering playground - denying them the opportunity is unlikely to suddenly make them productive at driving the business forward with a simple stack when their original idea was to play with shiny tech instead.

The only way I see out of this is to have management buy-in to get the microservices and their developers out the door, replaced by more competent people.

WoL is reliable when waking from sleep/suspend. I have yet to see consumer HW that can do it from poweroff. But if suspend is fine, all you have to do is configure your firmware to turn on after power loss (so you always boot into your OS) and in your OS enable WoL and configure suspend on inactivity as you wish. It should be reliable and failures would default to "on", not off.

Which is why you should not be going to AWS to begin with when there are plenty of providers who will give you orders of magnitude more performance for this price.

(of course, say goodbye to resume points and your cloud provider conference invite. Question is, what are you trying to do? Are you building a business, or a resume?)

That's often the case yes. In a monolith a developer disgruntled about the situation can clean up the mess in a weekend, test it and push it through. No chance of that happening in microservices - you'd run out of weekend just opening PRs in the dozens of repos and dealing with all the nitpicking and turf wars.

Grug actually covers this in his essay:

> note, this good engineering advice but bad career advice: "yes" is magic word for more shiney rock and put in charge of large tribe of developer

Microservices definitely contribute to having a "large tribe of developer" to manage.

You can get the separation benefits of microservices in a compiled language with modules that only communicate over well-defined interfaces, constraining each team within their own module without having to introduce a network call between each operation.

Would love to see what those guys do against a device including actual KB/mouse/etc chips and simulating inputs to those chips' analog input lines.

From the host machine it's undetectable - it looks like a real KB/mouse because it is a real KB-mouse, no different from an actual real one with a robot arm moving it and pressing keys.

While those guys are weeding out the poor remote workers limited to off-the-shelf KVM devices that are just trying to enjoy their miserable bullshit job a bit more, actual attackers with more resources (including the DPRK they fear so much) are busy pwning them.

Good post in general but some caveats:

1) His user numbers are off by an order of magnitude at least, as other comments have mentioned. Even a VM/VPS should handle more, and a modern bare-metal server will do way more than the quoted numbers.

2) Autoscaling is a solution to the self-inflicted problem of insanely-high cloud prices, which cloud providers love because implementing it requires more reliance on proprietary vendor-specific APIs. The actual solution is a handful of modern bare-metal servers at strategic locations which allow you to cover your worst-case expected load while being cheaper than the lowest expected load on a cloud. Upside: lower prices & complexity. Downside: say goodbye to your AWS ReInvent invite.

3) Microservices. Apparently redeploying stateless appservers is a problem (despite the autoscaling part doing exactly this in response to load spikes which he's fine with), and his solution is to introduce 100x the management overhead and points of failure? The argument about scaling separate features differently doesn't make sense either - unless your code is literally so big it can't all fit in one server, there is no problem having every server be able to serve all types of requests, and as a bonus you no longer have to predict the expected load on a per-feature basis. A monolith's individual features can still talk to separate databases just fine.

A Flex PCB connecting the OCP2 connector would allow to put the converter board behind the NIC board, allowing the NIC board to be exposed to the aluminum case to use the case itself as a heatsink (would need a split case so the NIC board can be screwed to one side of the case, pressing the main chip against it via a thermal pad).

As a stop-gap, I'd see if there was any way to get airflow into the case - I'd expect even a tiny fan would do much more than those two large heatsinks stuck onto the case (since the case itself has no thermal connection to the chip heatsink).

Neat, but the thermal design is absolutely terrible. Sticking that heatsink inside the aluminum case without any air circulation is awful.

> This is the product that Apple and Google were unable to build

It's not they're unable to build it, it's that their businesses are built on "engagement" and wasting human time. A bot "engaging" with the ads and wasting its time would signal the end of their business model.

Would there be any advantage in using Yocto if you only ever have one target (x86 in my case)? Been happily using Buildroot but wondering just how greener the grass is on the other side.

Why not? Docker is effectively free on Linux. You only get the performance hit on macOS and Windows (since it runs the containers in a hidden Linux VM).

My point is that you can go very far and solve real-world problems with the basic primitives alone.

While I’m sure there are legitimate uses for the services you mentioned, I’ve also witnessed plenty of engineering playgrounds where complexity was a feature and services were used for the sake of it rather than due to a specific need.

If you’re going to go multi-region and take the latency hit may as well go multi-provider no?

Multi-region within the same provider won’t shield you against unknown shared dependencies on a single point of failure (AWS console auth still relies on credentials being checked in a single region if I remember right).

And yes fully agreed that maintaining consistency between active-active regions (whether cloud or bare-metal) is super hard and not worth it for most deployments. Active-standby with point-in-time-recovery and an acceptable data loss window is much easier - when one region is confirmed down, someone throws a switch and the standby becomes active.

> no sane provider is willing to cover your losses

Agreed, but thats why all those who justify the 10-90x premium of the cloud over bare-metal are full of it - that premium is not actually worth it.

> it's not a secret this is not happening

Maybe for you it’s not a secret? Literally every thread tries to justify cloud reliability and their resulting markups. Well if it’s that reliable they’d put their money where their mouth is.

> I could go on with the list of services currently used by the people that pay to push buttons

I too can build an engineering playground where every ingress byte traverses as many AWS services as I can find. But if you're building a business application, how many of these do you actually need?

Once you have the basic primitives you can fill in the gaps yourself if needed. But in the list you provided, Pub/Sub, CDN and GLB is already covered actually.

I'm sure in due time other services will be covered if there's enough demand, but to claim there is no EU alternative while the basics (app server + DB + S3, aka the most difficult to scale/operate yourself) are covered is a bit misleading I think.

It would also help not taxing those incomes at 60%.

Every time I look at a permanent role in Europe, if I didn't already close the tab based on the offered salary, I plug the number into a take-home calculator and then I close the tab for sure.

Unfortunately my landlord does not agree and wants his payment in actual money, and so do a lot of services we rely on to live.

80k net is 6.6k. If you're getting 80k (which is the very upper end of the range) it's likely you are in Paris, where you're gonna give at least 2k of that on rent for a shitty damp place, and double that for something decent.

Trust me I would love to quit consulting and be able to have a chill permanent job that can afford me a good flat and lifestyle. I'm still searching. Spain situation is very similar last time I ran the numbers.

Definitely no fucking way I'm helping anyone build a cloud provider (a cash cow considering the margins in there) for such pay. If I want to sell my soul to the devil, the one across the pond is gonna give me twice as many bucks for it.

Offer just half of the typical AWS cloud bill and you'll magically have lots of candidates! But greed often doesn't let companies pay any more than "market rate" even if it means paying twice that to AWS or a vendor instead.

Availability ain't worth shit unless the compensation for missing said availability is anywhere near the business losses caused by it. "Credit on your bill" doesn't count (and you're not even likely to get that since they can just lie on their status page and pretend everything is fine).

Cloud is convenient but don't expect any kind of availability you can actually rely on. If you actually need that, you're gonna have to go multi-cloud or self-managed bare-metal at multiple providers anyway.

> no european cloud operator able to offer what AWS/GCP/Azure offer

I guess we must be living on different planets. I have recently deployed a Django application for a client of mine on Scaleway (due to an existing partnership we preferred using them over other infrastructure). Scaleway right now (you can signup and check it out) offers:

* container registry - build an push your containers there

* ECS/Fargate equivalent - tell it to run N instances of your aforementioned container

* Managed Postgres & Redis with failover/replication

* VPC - put your managed DBs and containers there so they can talk over a private network

* S3-compatible object storage

What more do you need exactly? That's essentially all I would use from the incumbent cloud providers anyway.