Maybe it’s just me but I’m not getting if those senior engineers are just observing those meetings or whether they are expected to contribute or even take major action points upon themselves.
In other words, if there is a set of engineers without access to those meetings, do they simply get the news from those senior engineers or are they actually in teams led by these senior people?
In my book a cloud provider is a provider where you can spin up VMs at scale, offers multiple geographic regions across the world, offers managed complementary services such as S3, CDN, GLB, IAM, Managed Databases, backup & restore, FaaS, container registry, managed K8s or another container orchestration platform, PoPs around the world.
Hetzner has an S3 compatible offering, a VPS offering and that's it. Their core business is renting physical servers. And I see lately they offer a load balancing service.
You know, we used to have a single tech company providing essentially an entire tech stack to its customers. Its core enterprise pricing provided a platform with impressive compute capabilities, high redundancy, global support, strong backward compatibility and the backing of a company providing consulting and an ecosystem made of a lot of other software products. That company is still alive and well, although that product is probably less appealing now to new customers.
I'm talking about IBM mainframes.
Eventually, as the Internet (networking) and open source technologies (like Git and Linux) become more and more widespread, people realized they could build their services by combining products from different vendors (not to mention FOSS). I'm talking about the 1990s-2000s.
Now, after 20-30 years, we're thinking that the same company must provide the entire tech stack or lose relevancy as a provider.
To be clear, AWS and mainframes are pretty different from a technical standpoint, but I do wonder if we're kinda repeating the same cycle over and over. Asking the same company to provide everything and then build stuff with different products, to then find a new company which can provide everything and so on.
It's one thing to say that a lot of AWS/Azure/Google users take advantage of many managed services.
But saying something is not a cloud provider because they don't provide a specific SaaS is kinda weird, especially if you read the NIST definition of cloud computing or when you consider that not every AWS user is using more than a handful of services (does that make AWS a cloud provider only for more "advanced" users?).
Sure, smaller cloud providers don't usually have all those services, but this doesn't mean they are not cloud providers. They cannot attract users who are more familiar with specific managed services, but they can probably satisfy the needs of other users who are more than happy with a smaller feature set.
Also, limiting yourself to a smaller portion of AWS/Azure/GCP services can facilitate migrations to other cloud platforms (think AWS -> Azure or viceversa), because you're less tied to specific proprietary tooling.
> because they don't provide a specific SaaS is kinda weird
I think for most business stakeholders it's not about the number of services but rather the coverage of business-critical needs. When you have access to Azure Entra, you know that you can cover 90%+ of your auth needs with that service. If you have access to AWS S3, you know that your various storage needs would be possible to cover with that. If a managed Postgres is available, you know that most of the IT systems you run would be able to take advantage of that. You look at Azure their IAM/audit/observability offerings and it's the same.
When you look at Hetzner as a business stakeholder, all you see are bare servers and and one object storage service that you are not sure of how battle-tested it is. And then you start thinking: "okay, I will need to run k8s or some other workload orchestration approach, my IT systems need Postgres/MySQL/SQL Server etc, I need auth, I need audit, I will need to build, operate, maintain all of that in-house". I am not saying that this is a wrong path for everyone, but Hetzner essentially leaves you no choice. And many business stakeholders who have been operating their own own-prem infra or colocated or rented IaaS plus a large dev team for decades and have since switched to one of the hyperscalers and reduced their dev/IT headcount - may not want to go back to the old model.
> limiting yourself to a smaller portion of AWS/Azure/GCP services can facilitate migrations to other cloud platforms.
Yes, which is why you insist (where possible/reasonable) on Postgres-compatible DBMS offerings, IdP solutions based on OIDC, observability on OpenTelemetry.
> Sure, smaller cloud providers don't usually have all those services, but this doesn't mean they are not cloud providers
Yes, it could mean that they are not cloud providers.
> but they can probably satisfy the needs of other users who are more than happy with a smaller feature set
Please see the linked article. This is essentially "users who are happy to build some of the furniture themselves".
I agree that there is a difference between "wood" and "furniture".
Although maybe a more apt comparison is IKEA vs another furniture store.
With IKEA you have a relatively basic "style". You'd be hard to pressed a 1800 style table, for example, but if you are a student or someone who just wants to live in a new place, it's a pretty solid store to go. However, they give you the pieces (not just basic wood, already pre-made pieces) and you have to put them together.
Other furnitures have a lot more choices in terms of styles and they allow you to just buy stuff without any DIY needed.
Different offerings in the same space (no one in IKEA is asking you to cut wood and make your own chair legs or whatever), both valid.
Furniture metaphores aside, what I'm saying is that there is a subset of users which is completely fine with those services, which are still provided in a self-service, pay-per-use way without the need to have admin rights over the entire platform. That's a cloud provider. A more limited one, sure, but it can still be a cloud provider.
And when it comes to business stakeholders, coverage is important, but so are other concerns, including the ability to move out when needed (which still requires some sensible technical choice, because if you go "all in" you're complicating your exit strategy), or even concerns like the ones mentioned in the OP.
Obviously, each company has its own risk aversion and its own decision making process, and so far market share heavily favors the Big Three even outside of the US, but this doesn't mean alternative options should be dismissed as "not cloud providers" just because they don't provide all those services.
>Does anyone know what the typical tool cost is for a factory worker?
It's probably lower. Apart from safety gear like helmets and gloves, everything else is most likely reused across shifts or shared across workers simultaneously (think industrial machines).
I don't have a lot of payment experience, but AFAIK actual payment systems work in an append-only fashion, which makes concurrency management easier since you're just adding a new row with (timestamp, from, to, value, currency, status) or something similar. However, how can you efficiently check for overdrafts in this model? You'd have to periodically sum up transactions to find the sender's balance and compare it to a known threshold.
Is this how things are usually done in your business domain?
> Is this how things are usually done in your business domain?
I don't know about "usually" and I cannot explain details. But many banks are migrating from batch-based mainframes to real-time systems. Maybe that answers your question about "efficiently".
> how can you efficiently check for overdrafts in this model?
You already laid the groundwork for this to be done efficiently: "actual payment systems work in an append-only fashion"
If you can't alter the past, it's trivial to maintain your rolling sums to compare against. Each new transaction through the system only needs to mutate the source and destination balances of that individual transaction.
If you know everyone's balance as of 10 seconds ago, you don't need to consider any of the 5 million transactions that happened before 10 seconds ago.
(If your system allowed you to alter the past and edit arbitrary transactions in the past, you could never trust your rolling sums, and you'd be back to summing up everything for every operation.)
At the beginning of time, all your accounts will have their starting value.
When the first transaction (from,to,value) happens, you will do one overdraft check, and if it's good, you will do 1 addition and 1 subtraction, and two of the accounts will have a new value.
On the millionth transaction, you will do one overdraft check, and if it's good, you will do 1 addition and 1 subtraction, and two of the accounts will have a new value.
At no point will you need to do more than one check & one add & one sub per arriving transaction.
(The append-only is what allows this: the next state is only ever a single, cheap step from the current state. But if someone insists upon mutating history, the current state is no longer valid because it no longer represents the history that led up to it, so it cannot be used to generate the next state - you need to throw it all away and regenerate the current/next states, starting from 0 and replaying every transaction again.
Ok so basically you have a Transactions table as well as a separate Accounts table which stores balances, and every time Alices wishes to pay Bob, a (database) transaction appends an entry to the Transaction table and updates balance in Accounts only if the sender’s balance is ok? Something like a “INSERT INTO…SELECT”?
Your bank statement has the event (A deposit or withdrawal) with details, and to one side the bank will say, your balance after this event can be calculated to be $FOO
The balance isn't a part of the event, it's a calculation based on the (cached) balance known from the previous event.
Further, your bank statements are (typically) for the calendar month, or whatever. They start with the balance bought forward from the previous statement (a snapshot)
$150 will build you a 7" with a reasonably long flying time, a bit more and you can do some pretty impressive things. You still need a controller but those can be had for cheap as well. The main issue would be hiding it for pickup until after the event.
You’re talking about bargain bin analog FPV drones? Most people can’t operate them and even for an experienced operator it’s far from the best tool for the job of filming armed thugs..I mean ICE..
You’d need a digital system with a gimbal, and the DJI O4 Pro alone will run you $200+. For dual lenses with different zoom levels and feed switching it’s getting pretty expensive very fast.
FPV is a skill you can learn though and for filming armed thugs I actually can't think of a better tool because it allows you to fly the drone out of LOS so you can do it from a relatively safe position while still getting footage that matters.
For extra protection you could even abandon the drone and record the video directly on your headset.
Technically true I guess, but learning to fly a recent DJI drone takes about ten minutes. You're not so much flying it, as telling it what you want and letting it fly itself. And the controller has a built-in tutorial with a simulator.
True, but DJI drones are comparably well behaved (and boring) compared to a homebrew FPV. Even there you have various stabilization modes, including alt-hold, pos-hold and so on. In full acro mode they're a handful, that's for sure, but you don't have to fly like that, just fly in stabilized until you get the hang of that and want to live more dangerously.
You don't have to fly in acro mode lol. The common hobbyist drone firmwares have full support for even things like autonomous GPS missions. You also don't need expensive gimbal stabilized cameras; you're not making a cinematic film, so you can just hot glue a 360 camera to the bottom and deal with the slight oscillations.
If it’s just “sign up any time you want and go”, yes, it can go that way.
If it’s “join that waiting list” or “book a call” (for KYC purposes or whatever), you have a buffer.
If user count is more or less constant (most internal websites, for example), it’s probably not an issue.
And so on.
reply