Re: So, they're throwing in the towel on OCI?
Yes that one is.
They build a new one from scratch afterwards.
47 publicly visible posts • joined 19 Dec 2020
It's the other taking off life support. It can breath on it's own. OCI makes money.
This is more about giving the database some love and also the logical consequence of their effort to shrink OCI into smaller and smaller dedicated regions.
It's more practical (for customers) to add racks in other hyperscalers than faff about with interconnects that could fail (and logging, telemetry, IAM, admin, security etc.) This is where multicloud is putting a piece of one cloud into another.
The overwhelming trend in this market is that customers migrate from on-premise to cloud or create new workloads in the cloud.
Cloud to cloud migration is trivial.
Microsoft's call for delay is especially wrong headed. Customers who move to Azure now due to licensing are extremely unlikely to migrate again if the licensing rules become fairer later. They (and cloud competitors) will have been harmed forever if the licensing is anticompetitive now.
Delaying is more important than winning (but both are large stakes).
It's not generous and it's not rare.
Oracle added years of extended support for 11g and 12c. They did it to give customers time to upgrade.
Ending mainline support in May with on-premise versions (on supported hardware platforms) not available until next year was clearly not tenable.
Support is 22.5% per annum. They were always going to extend, announcing it later would have just caused more trouble for customers.
Microsoft know and are best positioned to assess unfair behaviour because they tried to do it to Google and failed. And they're succeeded in doing it to others more than everyone else in the industry put together.
People switch out Bing for Google, I haven't seen someone using Bing on a device where it wasn't default in about 15 years. I have seen people using Bing to open Google because they didn't know about changing the default.
Microsoft tried to squeeze out Google and failed. Google would have made more money if they hadn't been bid up in the auction for the Apple default.
I don't know the details of competition law and whether it was legal or not.
I mostly use duckduckgo.
It was an bad idea, poorly executed.
BMW were paying for a seat heater for everyone, improving economies of scale and trying to use subscriptions to fund it.
It was a new jarring way of paying, it messed with various purchase taxes, lease, BIK, running costs and it was immediately both expensive and painfully expensive to customers. It also cut dealers out of the sales cycle and effected the 2nd hand market.
It was the the wrong feature to sell to customers who had never asked for it and didnt like it, at the wrong price, using the wrong model. Of course it failed.
Deleted files, trying to fix a sync issue between primary and backup database...
Could be lots of causes. The one that jumps out is that logs build up if the standby falls being or becomes unavailable. Then the primary starts to fill up. Then someone who doesn't know what a database is deletes the log files to stop it running out of space.
They're evaporating the water to cool the data center. It's far more efficient than dry cooling (and the capital costs are less). It lets the air-conditioners run at lower condensing temperatures.
As with many environmental decisions there are tradeoffs. Most engineers would see this as standard.
In time they'll fund reclamation projects that will give back more water locally than they take out.
Cloud DCs are almost always more efficient than the on-premise DCs they replace. So big headline figures of growth/usage aren't necessarily always a bad thing.
Making a bucket private is really simple, it's default.
Adding more complexity and additional controls doesn't actually make it easier, though it can help with compliance tasks like verifying that buckets are still private.
The problem is that connecting to a public bucket is far easier. When security is hard, people work around it.
It's not an easy fix but it's not wildly difficult either, it's just that AWS aren't on the hook for your mistakes (when implementing their broken process) and customers have low standards.
There'd probably be home customer demand for fixed pricing in the way that a PPA gets and an innovative electricity supplier could package deals that way but there'd still be variability (in aggregate and locally) and switching during low prices.
Bit barns use power 24/7 so their profile is that bit more stable.
PPAs fund extra capacity (or they should be doing that) which is good, but they're a financial instrument that shifts the cost of variability and security of supply onto the rest of the market.
Status page is mostly marketing. If they were really serious about it being usable it would be a lot more usable.
They host their status page on their own infrastructure. Hence it breaks whenever there's a really big outage. If your first architectural decision is that compromised then it sets a low bar for trust. They'd never let a spokesperson say that of course.
The M5 generation was launched in November 2017. The next generation of Intel was August 2021. That was long by Intel standards. And supply was constrained so it's not in every region and AWS aren't pushing people to upgrade, if everyone wanted to they couldn't.
Not many customers upgrade quickly, especially if they have reserved instances already.
A lot of that kit will be running for longer simply because it didn't go obsolete as quickly as usual.
Supply chain issues. Running for longer does Intel a favour right now, when it normally wouldn't.
At the rate they're growing they probably use all the new chips they can get for new capacity and would have had capacity issues if they'd switched off older kit at the rate originally planned.
It's an easy way to get Red Hat command line syntax and package management for Windows users.
This is great for learners as tutorials are sometimes specific to Red Hat/CentOS and lots of people don't want to learn how to use Red Hat and Ubuntu.
Good news, it's another route for new users into Linux.
When you withhold tips, you are also stealing from the customers who left the tip.
It's not just a contractual matter between the employer and the worker.
If I leave a tip for some reason, it was hard earned money being handed over because it is mine to do with as I see fit. It's no business of the employer to get in the way and whether the employee/contractor consents is irrelevant.
We'd see less of these abusive practices if we recognised them for what they are.
The old procurement has requirements 3-4 years old at this point, and it was controversial right from the start. A lot has changed and part of the justification for junking it was the fact that it's out of date.
JEDI was a dumpster fire, they should have gone for a clean slate. Starting off by trying to do basically the same thing was always going to just end up with more of the same.
It's procurement masochism.
The problem is the creative corporate structures designed to book revenue and expenses in high tax regimes so there are token profits (to limit outrage and allow then to say they pay some tax).
Then the low tax areas book particularly high profits.
Amazon pay exactly as much tax in Britain as they want to be seen to.
Their contract with delivery companies prevents/severely limits them from offering collection discounts.
Same with all the middlemen. Hotels.com have a price promise with the customer and it's backed up by their contract with the hotel. Otherwise everyone would browse on the middleman platform and then go direct. Then the middlemen wouldn't have a business model. You can still do that but the hotel isn't allowed offer you a cheaper price ( unless you're a regular and you can call them to negotiate a discount).
I agree, let them increase fees. Increasing fees would make them uncompetitive and people would just order direct from restaurants.
Restaurants higher margins would allow them to run cheaper takeaway menus, as many do or did.
Customers would pay the same, restaurants would get the same. Delivery services would get the same, if they were used.
But if it's 20% of a £50 order plus a £2.50 delivery charge, customers now have choice of paying £12.50 for delivery or picking it up themselves. Given a choice a lot of people would choose to keep their money. So the NYC proposal is very customer friendly, shame it didn't go far enough.
Funnily enough another benefit of removing restaurant delivery fees would be that far more restaurants would use those services. So more choice for customers, new customers for restaurants and more business (at lower margins) for delivery services.
Revoke credentials from August 31, presumably when mitigation started.
Tell users on 9 September to start the process of revoking credentials.
Not especially fast when the mitigation could have alerted someone with a zero day.
At least the really sensitive data probably wasn't in Container Services to begin with.
Hard limits are a big no with production.
They're only relevant for sandboxes and PoCs.
For their own billing purposes the different clouds will cut you off if you start spending too much. A sensible approach would be to set a spending limit for new accounts with some level of configurability.
e.g. accounts start with a $50/month limit. Like the way credit cards start with a low credit limit.