Not much. 15 years ago was 2010. Gas stations in 2025 are very similar to Gas stations from 2010. I doubt they will be too different in 2040. May be a few more EV chargers.
The ones they build here in Norway has changed somewhat from 2010. For one, mainly EV chargers, with just a few, if any, pumps.
Mostly sells food and soft drinks, so hot dogs, fresh sandwiches, baked goods, with much more seating area so you can sit and eat while your car charges.
Has almost no car-related stuff, just one or two small sections of blinker fluid, wunder-baum and such.
And looking at the current trend, there will be far fewer of them, mainly located at strategic positions. The small, local gas stations will go away.
I remember reading this piece of news some time ago[0]: “People may not know – BP sells coffee. We sold 150 million cups of coffee last year,” Bernard Looney said in an interview in August (2020), referring to beverage kiosks attached to the company’s fuel stations. “This is a very strong business. It’s a growth business.”
I remember I was impressed by this. The only country I drink gas-station-coffee is Finland (because where else can you find coffee in the middle of nowhere?). So right after I read that article, and the first time I saw a BP gas station I got a coffee. It was 'cheap' and I assume EUR per mg of caffeine was 'ok', but the quality/flavor.. omfg. Also, volcanic hot, so thanks but no thanks.
With the hot-dogs, fries, pizzas, snacks, milk, cereal, alcohol (in some countries), they remind me of "The Profit" with Marcus Lemonis, where he is trying to use each square-inch from a retail store to sell stuff.
In the statoil petrol stations in Norway you can buy a mug and get free drinks thereafter at all petrol stations for the season. This is very popular with dirtbag kayakers, climbers etc. It was there that I discovered the weinermelange option on the machine which is apparently a cleaning mode that selects every option for your drink so you get a mix of coffee, hot choc, sugar and whatever else. Unforgettable.
Today, every gas station is self-serve, and often you can pay by card at the pump.
50 years ago, plenty of gas stations still had attendants. One guy would fill the tank (possibly with 'leaded'), another might give your windshield a quick wipe. You could ask for them to check your oil, too.
That’s definitely an innovation that creates convenience but does it really change the commercial function of the station much? You are still essentially transacting for fuel, which is what gas stations have done for decades. My guess is while a lot of stations provide that ability out of customer demand, but the owners would probably rather the customer come in and buy the over priced soda and Doritos along with the gas purchase. I don’t think owner-operators make hardly anything on the fuel sales.
With my comment I was thinking more along the lines of overall footprint of the station and what products are being sold. I think self-service pushed the ability for stations to service more pumps and with a person anchored to a register inside instead of outside attending to the pumps, it allowed the ability of stations to expand to more a mini-mart concept easily where more profitable products (to the station owner) are sold.
EV charging might help bring people into the food, but i suspect you don’t “turn tables” fast enough to make EV charging beneficial enough to bringing enough people inside to warrant devoting a lot of space to that activity.
Gas stations often used to be car service stations as well. We have a few local ones with 3-4 car work garages attached but they are always closed now and used for storage.
> North America has stuck to minimum of 1 staff at all times. No staff = closed.
Not true at all at least in California. I regularly fill at unattended stations late at night past midnight. The credit card operated pumps are operable 24/7.
Years ago we were traveling in remote areas of Nevada and running out of gas around 2am, desperately trying to find a gas station (this is before mobile phones, so couldn't just look things up, although maybe even today might be too remote for signal). Finally rolled into a small village with a gas station but everything was dark, so we thought we'll take a nap there until whenever they open. But I noticed the pump light was on, so I gave it a try. Yes, it worked!
I agree that they probably would benefit more from food sales off EV charging on a per vehicle basis, but they would need to turn over the chargers to new customers much quicker than what happens now for that to really benefit them.
Hydrogen seems like going backwards into the future. For personal transport it surely is a dead end, there are no significant upsides to offset the large downsides compared to BEVs.
Perhaps it can work well for certain commercial niches, time will tell.
Here in Norway we just have had a handful of hydrogen stations, and of those two went out of business.
Meanwhile almost all new cars here are BEV, even out in many rural areas BEVs are 50% of new sales.
A local store can relatively easily and cheaply install a supercharger. Installing a hydrogen pump is presumably much more expensive as it requires more space and more complex equipment. And it needs refilling by truck, while electricty just flows.
And while EV chargers or cars can catch fire during charging, hydrogen can explode violently[1][2] when mixed with air (the one in Norway registered as an earthquake 30 km, 20 miles, away).
As I said perhaps it will find some niche uses, but widescale adoptation seems very unlikely to me.
Echoing the comment below, I guess one obvious thing is that we are a team at ClickHouse and an official first-party product on top. That translates into:
- We're flexible on top of any ClickHouse instance, you can use virtually any schema in ClickHouse and things will still work. Custom schemas are pretty important for either tuned high performance or once you're at a scale like Anthropic. This makes it also incredibly easy to get started (especially if you already have data in ClickHouse).
- The above also means you don't need to buy into OTel. I love OTel but some companies choose to use Vector, Cribl, S3, a custom writing script, etc for good reasons. All of that is supported natively due to the various ClickHouse integrations, and naturally means you can use ClickStack/HyperDX in that scenario as well.
- We also have some cool tools around wrangling telemetry at scale, from Event Deltas (high cardinality correlation between slow spans and normal spans to root cause issues) to Event Patterns (clustering similar logs or spans together automatically with ML) - all of these help users dive into their data in easier ways than just searching & charting.
- We also have session replay capability - to truly unify everything from click to infra metrics.
We're built to work at the 100PB+ scale we run internally here for monitoring ClickHouse Cloud, but flexible enough to pin point specific user issues that get brought up once in a support case in an end-to-end manner.
There's probably a lot more I'm missing. Ultimately from a product philosophy standpoint, we aren't big believers in the "3 pillars" concept, which tends to manifest as 3 silos/tabs for "logs", "metrics", "traces" (this isn't just Signoz - but across the industry). I'm a big believer that we're building tools to unify and centralize signals/clues in one place and giving the right datapoint at the right time to the engineer. During an incident I just think about what's the next clue I can get to root cause an issue, not if I'm in the logging product or the tracing product.
So, seems like the direction you are going is trying to enable ingestion to different ClickHouse instances (Cloud/BYOC/Self hosted) and then use HyperDX as the query & visualization layer on top.
I think, fundamental difference we have at SigNoz on how we approach this is that we want to solve for observability and the fact that we use ClickHouse today is just a point in time fact. In future, we are open to use any other datastore which may be more performant for observability. We can also use different databases to augment different use cases in observability.
>Ultimately from a product philosophy standpoint, we aren't big believers in the "3 pillars" concept, which tends to manifest as 3 silos/tabs for "logs", "metrics", "traces" (this isn't just SigNoz - but across the industry).
I am not too sure on how this works in practice, do you expect people to write metrics and logs query in the same explorer. From our experience, the query writing experience is very different for logs and metrics and you need different defaults to make the query writing UX easier for users.
"An individual human being who wants to log in can be represented by multiple Users in Tesseral, each of which belongs to exactly one Organization."
This will be extremely confusing. You should simplify it and just keep the concept of User as we usually do. A user should have access to 1 or more organizations. That's it. You should rethink this otherwise it will be too confusing.
But isn't this kind of like saying your logins to Blizzard and Activision should actually be the same underlying user? Doesn't make sense, and becomes an authz nightmare, imo.
Depends on which model will be more beneficial to your customers and also be profitable to you at the same time. You can learn from companies like PostHog that stopped offering paid self hosted managed solution. Either you use their Open Core version yourself OR you pay for their cloud hosting. This article will hopefully help:
Let me add to your statement. It is hard to keep call center workers bribe-proof WHEN they are paid peanuts AND they are working for a company that is in an extremely high risk business of managing crypto.
correct, but what's the alternative? they're paid peanuts because it's not exactly the kind of job you ever pay out the wazoo for. the only thing that comes to mind if I'm Brian Armstrong is going all in on AI bots that can get to 90% of the way there (maybe 95%) and then have domestic based humans that are paid more with (presumably) a less probability of being bribed. but realistically, the only way to stop something like this is going 100% AI bots but then that comes at the expense of customer satisfaction, and also bots that are exploitable through prompt manipulation.
alternatively limit the roles and what the offshore people are able to do, but then any escalation means domestic people, which brings us back to "well at that point just use AI to automate easy tasks"
Normally payment should follow the amount of power/responsibility. If you pay someone peanuts but they have root access to prod, then you should pay more or restrict their credentials. Same applies to being able to access PII.
Small set of privileged employees who work from the home office and are compensated to match. If an issue requires their attention, it takes time to resolve. But it's resolved securely. In essence, what Google does.
Alternative is the banking model. Low-cost customer service massively empowered and just eat the costs of breaches as they come.
What Google does is “don’t resolve shit”. When I was a Google Fi customer paying $60-80/mo, so more than the vast majority of Google users, their customer support was completely useless (but at least polite, I’ll give them that). They did take their sweet time, kept promising to call me back after each fruitless call I initiated but didn’t, so you’re right about “it takes time to resolve” I guess.
My multiple banks’ customer service is meh but they do resolve problems and as far as I can tell, haven’t leaked any of my stuff yet in decades. That you think “what Google does” is better than “the banking model” is amusing.
Oh totally. I’m just defining the poles of the spectrums. Someone has to eat the cost, whether it be in friction and inconvenience or reimbursing fraud.
From a high level yes, but we are taking a very different route. They're very deep into usage-based billing and high throughput events, whereas we're more for early stage founders and "pricing in a box"
Depends on the type of person you are. Are you ok with uncertainty of not having projects in pipeline all the time ? Are you ok to go a few months without work while other months being intense with strict deadlines ? Do you like to work with multiple clients with different needs etc ? Can you switch context quickly ?
The answer to these questions will help you determine what should be your next thing. But just fyi, freelancing doesn't mean there are no deadlines. In fact, quite the opposite. However, you do have the option of being selective (if you get to that point) and that can be a good thing.
Yeah, I'd love having some intense months with breaks in between, that and the ability to negotiate on deadlines or say no is why I even thought of doing freelancing.
Issue I had with deadlines is that management would set them and refuse to engage with engineers on how unrealistic they are.
Seconded. This corner of the programming world is a deep dark and scary place for people who haven't had solid industry experience. It'd be hugely helpful to have a barebones starting point to begin learning best practices.
You probably already know this but I will say it anyway. These cloud services like AWS are not succeeding in enterprise because they have outdated hardware. They succeed because in enterprise, CIOs and CTOs want something that is known, has a brand and everyone else uses it. It's like the old adage of "No one got fired for using IBM". Now it is "No one gets fired for hosting with AWS no matter how ridiculous the cost and corresponding feature is".
But consider the counterfactual: Non-realized customers because AWS certified solutions architect(tm) software couldn't deliver the price/perf they would have needed.
At $work this is a very real problem because a software system was built on api gateway, lambdas, sqs and a whole bunch of other moving pieces (serverless! scalable! easy compliance!) that combined resulted in way too much latency to meet a client's goal.
> Let me give you a concrete example. I recently heard from a competitor, let’s call them ACME Bookmarking Co., who are looking to leave the bookmarking game and sell their website.
While ACME has much more traffic than I do, I learned they only have half the daily active users. This was reassuring, because the hard part of scaling a bookmarking site is dealing with people saving stuff.
We both had the same number of employees. They have an intern working on the project part time, while I dither around and travel the world giving talks. Say half a full-time employee for each of us.
We have similar revenue per active user. I gross $12,000 a month, they gross $5,000.
But where the projects differ radically is cost. ACME hosts their service on AWS, and at one point they were paying $23,000 (!!) in monthly fees. Through titanic effort, they have been able to reduce that to $9,000 a month.
I pay just over a thousand dollars a month for hosting, using my own equipment. That figure includes the amortized cost of my hardware, and sodas from the vending machine at the colo.
So while I consider bookmarking a profitable business, to them it's a $4,000/month money pit. I'm living large off the same income stream that is driving them to sell their user data to marketers and get the hell out of the game.
The point is that assumptions about complexity will anchor your expectations, and limit what you're willing to try. If you think a 'real' website has to live in the cloud and run across a dozen machines, a whole range of otherwise viable projects will seem unprofitable.
Similarly, if you think you need a many-layered CMS and extensive custom javascript for an online publishing venture, the range of things you will try becomes very constricted.
Rather than trying to make your overbuilt projects look simple, ask yourself if they can't just be simple.
> No one gets fired for hosting with AWS no matter how ridiculous the cost and corresponding feature is
Actually, AWS is so expensive, hosting everything we ran on Hetzner there would have simply depleted our funding, and the company would not exist anymore.
reply