To some degree that’s true. Less engineers definitely can speed things up if they get autonomy.
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.
Right. Has Google ever produced a profitable product outside of ads and G Suite? YouTube likely isn't profitable, but even if it were, they bought it.
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.
That’s revenue. They don’t disclose profit because it isn’t profitable. No amount of revenue is good or impressive if you can’t figure out how to spend less than you make.
adding more engineers makes development go more slowly -- does that work in reverse??
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¢."
More employees doesn't automatically mean more productivity/launches/success. Downsizing can be an effective tool to get back on the right track (if done correctly, of course).
Reorgs like this happen all the time at Google -- they didn't downsize Cloud, they found two parts of the business doing the same thing and merged them - so some people were redundant there.
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).
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.
Microsoft is pushing Azure hard. Not to disclose specifics but there are cases where deals with Microsoft for unrelated things are reliant on the company adopting/moving parts of their work to Azure, with huge amounts of free credits for the first year as a sweetener. It's not in writing on contracts but it's very much a requirement.
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.
I know a company that got a very, very, very sweetheart deal with GCP on a tens of million dollar contract. They have a huge sales team with a monsterous entertainment budget to land "traditional" companies.
If you have a CIO/CTO title at a "traditional" fortune 500 there are a busload of cloud sales people waiting to take you out to the finest steak houses and gentlemen's clubs as often as you please. Along with all expenses paid trips to Jackson hole, Aspen or any other upper crust resort city for company trainings and seminars.
Translation, both Microsoft and Google have train cars full of money to light on fire in the short term to subsidize long term contracts and integrations. It'll be interesting to see who is number 2 in three and then five years.
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"?
The cloud provider market seems too competitive for them to be getting huge markups; if there was a 50% margin on storage, why wouldn't Microsoft or whomever just knock 20% off and undercut all of their competitors thereby making them the obvious choice?
All three are totally dependent on cloud services to power revenue growth in the forseeable future. Amazon's retail efforts aren't where the big exciting growth for investors is, it's all AWS. Windows/Office has been stagnant for a long time, or even in decline. MSFT price only took off once Azure took off. And as for Google, well, what exactly are they doing that's new other than GCP? They've got nothing that can absorb growth at their scale.
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.
> They have a huge sales team with a monsterous entertainment budget to land "traditional" companies.
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".
I completely agree but that is how it all works. I think if the IRS wanted to crack down on this, the US economy would grind to a halt. (I never see people paying taxes on these gifts.)
I wish gcp and aws would take some notes (or make some acquisitions) to get close to Azure Devops... It has been a natural - dare I say pleasant - exercise to move some really rancid 15-year old legacy .net sql server/stored procedure nightmare applications to the cloud and get them into modern devops pipelines. That would not even be a project I would contemplate with aws or gcp. It's actually on par cost-wise in a lot of cases with running it on-prem which is a rare thing to say about the cloud.
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.
Azure Batch let's you use pre-emptible VMs for at least a couple of years now. I used it on a compute-intensive AI project a while back - it worked quite well, and was cost efficient relative to normal VM pricing.
The things are so different, you should really look both up. DevOps is essentially an entire suite for developers, from git repos, ticket boards, ci/cd pipelines, knowledge management and hell even a little package management sprinkled in. Brilliant tool.
A lot of the Microsoft Azure stuff is simply because companies do large volume deals with Microsoft for Windows/Office/Sharepoint and Azure becomes a piggyback. "Well we are paying Microsoft millions of dollars anyway, why not use their cloud too?".
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.
> A lot of the Microsoft Azure stuff is simply because companies do large volume deals with Microsoft for Windows/Office/Sharepoint and Azure becomes a piggyback. "Well we are paying Microsoft millions of dollars anyway, why not use their cloud too?
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.
> weird horizontally-expanding OG-Xbox blades user interface
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 don't like Amazon's, though the incremental spread of their redesigns is helping. GCP's is okay. But Azure's is straight-up bad. And you're right--I can't for the life of me figure out why they did that.
I have been told, too, that the team that made it is very pleased with it. "Why" comes to mind.
> Powershell Core is not, however, a good experience on a Linux machine
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.
> from the inconsistent and weird horizontally-expanding OG-Xbox blades user interface
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.
These comments make me sad as i work there, at ibm and in the cloud business. But i have to agree with you. It's looking pretty bad from the inside. higher management seems incompetent in making the pieces (like redhat, softlayer, the paas) into an efficient, large machine. But that doesn't make our work less interesting in our smaller teams.
Trust me, I know. I don't dunk on IBM Cloud gratuitously; I was an employee at IBM Cloud (not in IBM Cloud, one of the product offerings) for five months last year. It took the entirety of that five months to get a VMware cluster up and running and the very generous help of a customer-facing consulting team that took pity on us to make it actually work. There are the pieces to make a completely adequate experience--by which I mean "drives me less crazy than Azure"--but I don't see any path forward towards achieving it under the current management.
Azure is fine, but I don't see a lot of efficiencies between Azure, VSTS and O365. They're all pretty separate. AWS is still the best and it's perfectly fine to use one cloud provider and a different productivity suite.
> it's perfectly fine to use one cloud provider and a different productivity suite
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.
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.
Personal experience. Or how else do you expect to be proven such a sweeping statement?
Can you link any sources that azure ranks worse in quantitative measures?
Your wording "especially in networking" strongly implies that Azure was worst on several counts, but especially so on networking - but that is not the case, they were only worse on networking.
- 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
Personal experience of around 3 years of solid usage, spanning many Azure services, with complex systems running in production for several clients.
> 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.
Agreed. Witnessed first hand a large enterprise company was given free Azure credits in the millions. The executives loved it, until it was time to start paying.... Then they freaked out. Unfortunately for them, they had no centralized mechanism for control to reign in applications, so of course everyone said their application was critical. Part of the ever-failing multi/hybrid cloud approach.
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_
Not the Google Cloud but Firebase is by far the nicest experience I ever had with a "hosting" provider. It is a bit expensive but I think this proves that there are many low hanging fruits to gather out there.
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.
Firebase is fantastic. There is also a steady drumbeat of continual improvements going on in Firebase that keeps making it better and better.
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.
Oh definitely. Also, I like their SDK. It's even easier to keep all the app data in Firebase than dealing with native solutions. All the stuff about imperfections of the world like slow connections and so no is taken care of.
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.
I'm pretty happy with Firebase compared to other platforms I used. At this point I'm using all major components including hosting, firestore, cloud storage, cloud functions, etc.
I wrote up a whole design document of how we designed our app a few months back:
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.
Yes, they suggest using something like Algola for text search.
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.
The extensions/plugins are kind of cool in that they build in a bunch pre-existing functionality like automatic thumbnail generation for uploaded images.
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.
> 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'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).
As much as I always thought the app engine development model was pretty sweet, it seems like it just wasn't that compelling in the marketplace. You look at the biggest sites built on appengine and while there's some good stuff there it is not exactly mind blowing. If the development model were really that much more productive you'd expect there to be more there.
I'm sure you're right, but they already had a parallel service (App Engine flexible environment) that did what all the other providers did. I don't see why they had to destroy the standard environment.
It's not like they have a shortage of developers to work on it.
I've built the early version of our platform atop Firebase and I agree, it's a great acquisition by Google.
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.
I love the idea of Firebase but the thing keeping me off it is the pricing. It's like regular cloud pricing on steroids. Comparing Firebase pricing to say a $5 droplet from DigitalOcean:
- 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.
Oh definitely, I am hoping to see serious competitors so that the prices go down. I also wish for an open-source alternative where we can spin it on our own server.
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.
Are you equating one droplet with no redundancy or scalability to Firebase's services? Also, will postgres sustain 500 transactions/sec for a month to reach 1.3B. Sounds like serious stretch to me.
I still don't understand why companies like Microsoft and Google hire folks from Oracle to run a cloud business. Oracle is the only player that can't do anything on the cloud; even IBM has a better game.
Oracle Cloud is apparently not that bad, but it has no mindshare.
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.
I tried spinning up some free Oracle cloud instances (you get 2!) but it was "out of capacity" (at least in that instance shape?) in sydney region... not an experience I've had with any other cloud provider.
I hope part of their plan is fixing their documentation. Their documentation is crap and they can't win if they don't fix it. Apparently GCP technical writers have not been tasked with creating task/goal oriented documents. For grins, look up how to create a load balancer. You'll find 5 different articles. There won't be one containing the specific instructions you're looking for. The whole thing needs to be torn out by the roots and recreated around achieving specific results. They are unlikely to do this, so they are unlikely to catch up let alone win.
It’s so abundantly clear that most documentation writers at google have NEVER used their own products in production (nor do they ever intend to).
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!”
Granted I've not used a ton of AWS services because all of this was in context of grad school research, but I've found this with a lot of the AWS documentation I've come across. Things like documentation for general API being inconsistent with language specific library docs, or function signature is different than what docs indicate. I had issues with others, but for reference this was largely with MTurk JS bindings to the api.
FWIW I’ve also worked with mturk and find that to be an unfair comparison point because it basically a vestigial organ that nobody in academia actually even uses correctly.
I have no idea how much mturk makes, my guess is not a ton and its mostly in a maintenance mode? Would explain the state of the documentation. Not sure I see how researchers improper utilization of crowdsourcing is a reason for the API documentation to be inaccurate (and I don't think even updated after I emailed while I was still using the docs).
Honestly most techdoc writers have never really used their products in production. You are lucky if they have built their own test and sample apps.
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.
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.
Target Pools. Worst LB UX ever. Requires a daemon to run locally on your instance so that the instance routes traffic to a service to itself if it's part of the pool. If the service is down (say.... for maintenance), then all local traffic dies unless you stop the agent. It's a real mess.
When I first tried using GCP I was trying to do something fairly simple. Every page in the documentation would give some high level overview and then link to another page. Eventually I ended up back where I started and never found the answer. So frustrating.
I think a good start would be building a reputation for decent support and longevity, but surprisingly they seem to be going in exactly the opposite direction.
The bulk of the customers generating the $40 billion per year for AWS do not care enough about bandwidth (transfer) costs for it to change the market completely. While it may be in the top ten as a consideration on cost, it's nowhere near the top.
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.
if a cloud provider out of the big 3 adds hard limit budget (taking down the service) so I don't have to worry about getting a 100k bill if I fuck up and not turn off some service before I go to a 2 month vacation, they can take all my money.
This is clearly not a recommended process. GCP probably does not want a user to check the box and not understand the consequences given how severe they could be.
124 comments
[ 3.1 ms ] story [ 147 ms ] threadThe 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.
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.
0: https://azure.microsoft.com/en-au/pricing/spot/
Cute strategy if they are indeed a rebrand.
https://azure.microsoft.com/en-us/blog/announcing-the-previe...
https://azure.microsoft.com/en-us/pricing/spot/
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_
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.
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
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 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.