Google Plots Course to Overtake Cloud Rivals
wsj.com
wsj.com
It's essentially an API to access a streamlined database, file hosting, access provider and so on. Everything integrated and can talk to each other.
Not long ago I got fed up with endless tools and configuration in the LAMP/MEAN/MERN or whatever the latest trend is to put data somewhere and read it, so I got into native iOS development and I am loving it.
On the client-side, I have only two UI frameworks to deal with(UIKit and SwiftUI). On the backend side, I only deal with Firebase. You can do everything with those.
Honestly, I don't know why not all providers are essentially like Firebase. Surely for some scenarios, a custom solution would be needed but it strikes me as Firebase being the place that provides the structure and you plug your custom software to it.
That's why I am under the impression that at the end the gold rush for the cloud, the result would be something like Firebase.
What I would love though, if an open source self hostable Firebase alternative.
Even when Firebase is using other GCP products under the hood (e.g. Firebase Storage is Cloud Storage and Firebase Functions are Cloud Functions) they often provide a better developer experience that makes things flow smoother. For example, having a Firebase Function running on a schedule is a just an added line in your functions config whereas running a Cloud Function on a schedule requires setting up a Cloud Scheduler Job and linking everything together with PubSub.
My only issue so far is that cloud functions respond very slowly if they are not used for a while. The first time takes 2-3 seconds, thereafter it's in the milliseconds.
But other than that, it's such a nice experience.
I wrote up a whole design document of how we designed our app a few months back:
https://getpolarized.io/2019/01/03/building-cloud-sync-on-go...
I think the biggest thing I miss is having some sort of full-text search support for the JSON storage. I'm used to having Elasticearch so this was a big of a headache.
One of the nice things is that you can use some of the easier things in Firebase but also dive down and use more lower level components in Google Cloud when necessary.
For example, I might need a more complex caching CDN for our server-side rendered pages and I might end up deploying that next.
I definitely hope Google stays competitive here as it will make my job a lot easier.
Yesterday, I was galavanting their marketplace for apps that you can use in your GCP and I like the idea a lot. I think they are doing something similar for Firebase and call it "Firebase Extensions".
I think this can also be another gold rush. I was hoping to find Cryptocurrency exchange ticker dataset(but there were only at low resolution). I think Salesforce has such a marketplace where developers write apps for automating things, enable things, sell data and so on. Would be nice to have a standardized API marketplace.
So much potential there. Easy to start with and a lot of depth if you want to dive deeper.
There's definitely a ton of 3rd party plugins / innovation that could happen here much the way Intercom, etc was able to build on top of other people's data.
What's funny is Google Cloud is going in the opposite direction. They've pretty much destroyed the standard App Engine in the upgrade to Python 3. With the latest updates they've been moving towards becoming just another provider of dumb boxes where you do everything yourself. I'm expecting the standard App Engine to be deprecated at some point soon as they push everyone to the flexible environment (which is pretty much what you can get at any cloud provider).
It's not like they have a shortage of developers to work on it.
Saying Firebase is the new C-panel is like saying Uber is the new O’Reilly Auto Parts.
Integrated authentication, deployment, database and file-serving.
I do have concerns about being closely tied to Firebase (mainly for cost reasons down the road - just eyeballing the pricing, it seems things can escalate very quickly). I agree that an open-source hosting alternative would be amazing (though that would obviously chip away at some of the "plug-and-play" benefits).
From a technical perspective, though it's fantastic.
- Bandwidth egress uses Google's standard pricing, which is hilariously uncompetitive (~0.12$/GB vs. ~0.01$/GB) and totally inappropriate for anything bandwidth-intensive like image hosting.
- $5/month will get you 2.7M writes, 8.3M reads or 25M deletes on Firebase while Postgres running on a DigitalOcean droplet should be able to handle at least ~500 transactions a second, or ~1.3B per month.
- A GB-month of RAM costs $6.48 on Firebase and is included as part of the $5 droplet from DO.
- A month of CPU time costs $25.92 on Firebase and is included as part of the $5 droplet from DO.
So a $5 DO droplet will give you 1GB-month, 1 CPU-month, 1.3B write transactions and 1TB of bandwidth.
For those same resources you'd pay $6.48 for RAM, $25.92 for CPU time, $2332 for 1.3B writes, and $120 for bandwidth, for a total of $2484.40, or 497x more. Even if you just look at the CPU and RAM, it's 6x more expensive.
I can imagine this being great for a pet project where you might only use a few minutes of CPU time each month but for any kind of scale, the resource costs just seem crazy.
That said, even at these prices, it is quite useful. I think If you need that many writes for cheap, it's probably part of your core product and you can concentrate on building a custom solution for that and take advantage of the rest of the product for the more mundane tasks of your business, like user access management for example.
Besides, If you think about it, 1.3 billion writes are about two writes per every person in USA and EU combined. There are usually a lot of things that you can do to optimize and reduce writes and make each write worthwhile.
I'm not sure how they can hope to become the number 2 cloud provider when pitted against that. Say what you want about Microsoft but they are in a really good position to take large chunks of the enterprise cloud market, and that's where the money is.
Is there any indicator that these credits are actually "lighting train cars full of money on fire", as opposed to "selling product with a small instead of a huge markup"?
If you look at the costs of the big 3 tech firm cloud solutions relative to what you can get from smaller providers, it's an enormous markup. None of them are going to compete with each other on price because that'd void the point of doing cloud to begin with. Plus tech firms hate competing on price. It signals to the market that you've run out of innovations.
This is the disillusionment I experienced in the B2B industry. Nobody cares about your products, they just care about getting free stuff from you. When people are buying something for a company, the money they're spending isn't theirs... but they're the one that gets free sports tickets or free dinners or whatever. It almost feels like stealing to me, but it's "business as usual".
Azure is growing pretty damn fast. One thing they don't have over AWS however is the scale of cheap resources. If you're using public cloud properly, you should be leveraging spot instances wherever possible - and in that case, azure doesn't really have a solution here. GCP preemptible instances are closer. You can spin up a rediculous amount of machines for pennies on the dollar at 2am in us-east and I see no such solution in Azure.
So all-in-all it seems that a good chunk of Azure's growth is proprietary migrations and thus they don't have to focus too hard on being cost competitive at the hardware level.
Cute strategy if they are indeed a rebrand.
https://azure.microsoft.com/en-us/blog/announcing-the-previe...
Google could solve this by fixing Linux on the desktop, or essentially making as many parts of ChromeOS open as possible. With Windows 10's bloatware, Microsoft has made many missteps – a Google Linux that looks and works like a Mac, and has native G Suite as well as meaningful GCP integrations would be an Azure-killing app. Unfortunately chances seem very slim that Google will ever have the imagination to do something like this.
It's not just about licensing fees - it's also practicality. That, and Azure is actually really good (relative to the other major players, GCP and AWS).
If you're a Microsoft-shop, you use Active Directory. Naturally, Azure Active Directory (AAD) works well with your existing on-prem AD deployment, so with very little effort, your employees get SSO for your shiny new cloud services.
This doesn't match my experience at all, from the inconsistent and weird horizontally-expanding OG-Xbox blades user interface to thrown-over-the-wall API libraries[0] to Azure AD being a complete waste of time and effort if you don't want them owning your entire directory (I'm sorry, I have to pay for Office or separate API access to manage users through Okta?) to real fun stuff like servers not recording restart or shutdown events in their audit logs if they were under load.
In fairness, I will say one nice thing about Azure: their CLI tools, under Powershell, are pretty good. I was impressed. Powershell Core is not, however, a good experience on a Linux machine, and while WSL2 is a lot better it's still not replacing my normal day-job workflow.
But it's been over a year since I had to use the comprehensively bad clusterfuck that is Azure, and honestly I'm still pretty mad about the experience. Azure is the one cloud provider that a company can't pay me enough money to work with. Well, one of two; there's also IBM Cloud, which, whoa-nope.
[0] - https://github.com/AzureAD/azure-activedirectory-library-for...
God do I hate this. I've given up hope that I'll get used to it at this point. I have yet to even figure out how it's supposed to help me, let alone find a way that it actually does. It's so very weird to seemingly no purpose. And someone had to put in a ton of effort to make it that way!
... but then I kinda hate all of the big 3 cloud web UIs.
I have been told, too, that the team that made it is very pleased with it. "Why" comes to mind.
Or on a Mac.
There is the Azure CLI, but it is pretty limited on what it can do. Both GCP and AWS have good command line tools (AWS can be awkward sometimes). GCP will even give you a CLI right there on the web console so you can run CLI commands even if you don't have them locally installed in whatever system you are coming from.
Assuming the provider won't break in mysterious ways, or that Azure won't return a 400 error for no discernible reason, you are better off doing whatever you can do from Terraform. And then you have a repeatable environment and won't have to remember Azure quirks every single day.
API responses are inconsistent, it has the slowest VM spin up time of the big three(also inconsistent). It has lots of confusing names for instances (and a shit ton of them), weird limitations on SKUs.
Anecdote: I almost threw my keyboard away once I figured out why the instances I had deployed suddenty lost network connectivity. I had added a load balancer pointing to them. Really. That's all it was. Once I did so, all traffic started flowing through the load balancer. What kind of design is that? And AFAIK you can only add one. That may differ between Basic or Standard load balancer SKUs, I don't remember, don't care.
On either GCP or AWS, one can attach as many load balancers they want, nothing else is affected, only traffic flowing through them.
That's just one example. Next time you try attaching some premium disk SKU to some non premium VM SKU (or is it vice-versa?) and a Premium/Standard Storage Account and the Azure API yells at you, you'll understand. The storage account has SKUs too. Premium cannot have blob storage. Or is it the standard that can't? Meh, I don't care. You have to keep track of all of this. Which may or may not be clear in the documentation.
Simple things like health checks terminating scale set instances automatically are not there. Heck, until some point in time you couldn't even terminate specific instances in a scale set. They have improved that.
You have to do a bunch of work to "generalize" instances for use in Azure. In true Azure fashion, the disk has to be a VHD (not VHDX). Image can only be up to 1023GB in size. Sizes must be aligned to 1MB. And probably more stuff.
At the end of the day, things will eventually work. Just budget between 3x to 5x extra development time versus AWS or GCP.
I'm going to have to pull you up on consistency here - I find the blade UI very consistent (with a few exceptions, such as Function Apps). I always know where the toolbar will be, where header info will be, where the details will be etc.
The same cannot be said for AWS, where I sometimes wonder if the UI for each service has been created by separate teams in complete isolation.
Aside from consistency, I really like Azure's blade UI, but I recognise that it seems to be quite polarising. Also, if it was a few years ago you used it, you'd have a different experience now (I recall when the blade UI was first introduced, it had a lot of performance issues and weird UI glitches; it's performant and stable now).
> thrown-over-the-wall API libraries
I somewhat agree here, and I've fallen victim to this myself on occasion.
> Powershell Core is not, however, a good experience on a Linux machine
As much as I like the Windows and Azure ecosystems, I'm not a fan of Powershell's verbose syntax at all. I much prefer bash for scripting tasks, which works in the "Git Bash" tool you get with Git for Windows, as well as WSL. WSL is pretty amazing actually, but WSL2 can't come quick enough!
> the comprehensively bad clusterfuck that is Azure
I've been using numerous Azure services pretty solidly for ~3-4 years now, and I haven't encountered issues like those you mentioned. Their support is excellent too, although I've only used it a few times.
I work with AWS and GCP from time to time too (depends on what clients want), but Azure would be my first choice every time.
I fear for Red Hat.
Yes, but this is just the same with Azure as it is with AWS.
> I don't see a lot of efficiencies between Azure, VSTS and O365
Efficiencies are certainly there for Microsoft at least, since all these services are hosted on Azure behind the scenes.
From the user side, yes, Azure, Azure DevOps, O365, Exchange etc each has its own admin portal/web app. But TBH I think this makes a lot of sense, and results in a better user experience, since each web app can be specialised, instead of having to fit everything into a single UI.
Azure DevOps has good integrations with Azure though, such as AAD for users and permissions, service connections, Azure-specific CI/CD tasks etc.
> AWS is still the best
Citation needed, and by what measure?
Do you have something to back that up? From almost everything I've heard, and most of the quantitative measures I've seen, they are strictly worse than AWS and GCP. As mentioned above, they are 2nd only due to their strong existing connections to enterprise.
Especially in networking, Azure is orders of magnitude worse.
- On CPU performance, Azure absolutely smashed it! - For storage read and write, Azure came second behind AWS - For TPC-C perf/$ all 4 providers had similar pricing for similar tiers. Note that Cockroach labs say this only takes into account on-demand pricing, so reserved instance pricing may differ
> they are 2nd only due to their strong existing connections to enterprise
Those connections sure help, but only really for Microsoft-shops. As I mentioned, if you're already using AD, SMB file servers etc, then it makes a lot of sense since they have 1st-class support for these in the cloud.
Chromium OS is already a thing; what change do you want?
> in a container
> a nice developer environment
Golly, the things you'd read on the Internet...
Genuinely interested but not getting anything of what you said.
Well, apparently not. I don't think that "this time in a container" is a good fix for the problem.
I haven't seen a breakdown where they split out office 365, active directory, etc vs their pure cloud offerings.
I wish they would use those resources in improving the platform itself. Azure may be nice for the decision makers, but as an engineer, _it is infuriating_
This is how I imagine their meetings to discuss this goes:
“Users leave our documentation pages in under 15 seconds! Our documentation is so clear and efficient! For some reason their hardware analytics show that the device falls 20 meters and shuts down afterwards, but that is surely an unrelated event!”
And if they spend a lot of time poring over our documentation, well, that just means our user engagement is through the roof!
So the solution is having the engineers building the service write the documentation right? Wrong. They also don't know what assumptions a real customer makes and how they would use it. Quite likely they too don't understand real external production use.
Writing technical documentation is hard.
So true. Good documentation can make or break a platform. I think a big part of the success of C++ is that Stroustrup is an excellent writer. A lot of the posts I have seen from Linus were also very well written. In the 90s Apple had documentation that seemed written by people who actually knew how to develop software. Nowadays it feels less so.
A bit of humbleness would have gone a long way to them securing a large enterprise contract.
They hire from Oracle because Oracle is really, really good at selling to the 'enterprise' i.e. the sorts of non-tech firms where non-tech executives make tech spending decisions. They often expect to be lavished with attention and sometimes perks (see Jackson Hole discussions above) in order to agree to a platform buy. Oracle's skill at selling into that environment is pretty legendary.
Perhaps they are too popular? /s
They have already built a reputation for being capricious with support and sloppy with documentation.
Re-doing a reputation is even harder than building one.
All Google would do by slashing transfer pricing is lure a lot of low value customers - and worse - to their shores and harm their service in the process.
It's a benefit to the cloud majors to keep transfer costs artificially high, which is why none of them have pulled the trigger on that competitive angle. It helps keep various types of low value + high abuse risk customers out and of course the transfer pricing is a profit center. Google isn't eager / desperate to saturate its services with terrible customers any more than the other large providers.
The next logical step is to hire fire people until you reach the optimal number, in some kind of binary search approach.
At my company there are a lot of people talking about work, doing planning, scheduling and whatever. They don’t contribute much but also hold the engineers up with constant information requests.
At this point product managers fight for their ideas to be implemented so that they can get promoted, even if it's an inferiour solution.
This article is far too credulous and feels like it was planted by a Google marketing person worried about customers being scared off by the downsizing news and by Google's culture of whimsical product creation/destruction in general.
Sure. That's why we see so many blog links on HN with titles like "I scaled my startup from $0 to $883 million with no employees in six days and only spent 49¢."
They could've just let those employees go, but they are giving them time to find a new role (and paying them the whole time they're not working).
Disclaimer: Am a Google employee.
Btw, the "finding a new role" is easily within Google. One of the "cloud" teams that was defragged was in my office, and some of those people were people I've worked with over the years. Local management are trying to make sure they have places to land on other teams in the office.
Yes, they can look for new jobs externally, but this is how Google deals with cleaning up teams from time-to-time. Luckily Google is still hiring, and people moving to new teams tends to work out without much fuss.
Outside Google, I've seen the same behavior. A friend that worked at waffle.io got a similar 3-6 month transition window (find a new job internally or externally). They ended up staying at Broadcom, so it's a good way for companies to retain talent in a tight labor market.