There’s a difference between consumer stuff and enterprise stuff with contracts. Grown up services like GSuite, AppEngine, etc have been alive and well for many years and aren’t going anywhere.
It makes sense to do risk assessment and avoidance where there is value. General emotional stuff isn’t productive.
Building your entire business on AWS Lambda, for example, is a risk you need to understand. In the past, I worked on a team that chose to put a critical business process on a IBM POWER/Aix platform... in our case we went through the options, identified risks/opportunities for standardizing a long lived process on a sole source platform, and made a decision. It was a decision that served us for about a decade before we moved on, so it was very successful.
--
Upgrading to Java11 will indeed be a big change, but Java8, with memcache etc, is still very much supported.
I don’t think it’s a tired argument: Google is much more likely to cut bait than Amazon.
If my cloud provider said, “hey we released a half baked service and we’re deprecating it” at least that would give a solid reason to fix some obvious technical debt. Otherwise you may just be band-aiding technical debt for years.
Anecdotally, I’m thinking of ElasticSearch Service around 2017. We were pushing almost a terabyte an hour into ESS.
We ended up tacking on SearchGuard, ElastiAlert, some SSO proxy, and about 3-4 other products, when what we wanted was X-Pack.
It took a lot of toil before we convinced the org to go permit a migration off of ESS.
Large enterprises are complicated beasts, and they value stability a lot. Even removing a single feature might cause dozens of teams to drop everything in order to go and fix the mess that someone else made. Why risk it? Especially if the alternative is someone who will wait to release a feature until it’s more than half baked and support it for a decade or more?
I think purging some of the lower quality services from a catalog of over 175 (AWS) services would be a net positive, because orgs wouldnt come along and build on top of sore ice that may not be as extensible as you need it two quarters from now.
It makes the AWS dashboard a bit more cluttered, but if you use one of AWS’ half-baked services you know it will be around for as long as you want. Maybe you outgrow it; that’s fine. You can opt to move off, but AWS won’t force your hand.
There’s a ton of value in that stability. Your MySQL server running on EC2 still works today if you haven’t migrated to RDS. And if you migrate to RDS, you can be confident that it will be around until well after you’ve moved to your next job.
Ironically, this is related to Golang’s strong 1.X backwards compatibility guarantee. Knowing that what works today will work tomorrow has tremendous value. You don’t have to wake up and migrate everything from vendor to modules. You can build on ECS today and have confidence ECS will be around tomorrow.
Granted, you offered a nuanced reply for someone building something on these clouds. However, when you're dealing with enterprise that are directly competing with the main cloud providers on other verticals, they are not being lazy or annoying, they are being careful, and not without a reason, and avoid using their competitor's cloud infrastructure.
Some of our clients have no problems using these cloud providers. Others wouldn't go through them because that would leak information.
If I'm not mistaken, Google used to buy datacenters in stealth mode, under different companies created for that purpose, to avoid getting on Microsoft's radar and keeping how successful search was from them.
We use GCP, for context.
I believe, Google for a long time (and still does?) thought their infrastructure was the secret sauce, and that might have impeded them from competing with AWS in the early years (despite having all the pieces in place already)?
This matters to us because we're building our machine learning platform[0] and we want flexibility as opposed to using their machine learning products, because each considers themselves "the only cloud". Therefore, we're compelled to do "multi-cloud"[sigh], because we want to be able to train models on X, deploy on Y, and have data on Z.
It's funny to watch, though, as if I recall correctly, there was an article on one of these companies where saying "multi-cloud" was blasphematory.
- [0]: https://iko.ai
For me, it's because Amazon killing their failed phone, their failed Yahoo Answers clone, their failed search engine, or their failed paypal clone says nothing about their commitment to their phenomenally successful $45 billion / year business with high margins and 29% growth.
Google Cloud is a $14 billion / year business growing at 45% / year. It is a smaller business than AWS, sure. But not by an order of magnitude. It's basically 3.5 years behind Amazon on the growth curve. Were you afraid in 2017 that AWS would be killed due to being too small a business?
I'd be really interested in this quote and its context. At AWS, things are always iterated upon and tested. But there's an incredible emphasis on two-way door decisions. Basically, don't make big decisions that can't be reversed if things go poorly. And once you've released something customer-facing (especially something as important as a new AWS service), you're locked in for the foreseeable future.
There are still CloudHSM v1 HSMs running out there in the wild. CloudHSM v2 was released in 2017. And CloudHSM v1 hasn't been available since at least 2019.
There are still EC2 instances running in EC2 classic--that is, EC2 before VPC was introduced.
> "Failure comes part and parcel with invention," Bezos wrote in his 2013 letter to shareholders. "It's not optional. We ... believe in failing early and iterating until we get it right." Three years later, he added, "Amazon is the best place in the world to fail."
Or:
> “As a company grows, everything needs to scale, including the size of your failed experiments. If the size of your failures isn’t growing, you’re not going to be inventing at a size that can actually move the needle,”
Now, I'm sure that doesn't apply to AWS, and your culture is totally different. You're an enterprise product with real contracts, real commitments, and making real money. You're not the Groupon clone, online pharmacy or whatever that grocery service *Amazon killed today* was.
But if we're accepting that Amazon's general trigger-happiness when it comes to failed consumer products doesn't extend to AWS, why does Google Cloud not get the same treatment?
What a scam. Has amazon EVER raised the price of an AWS service?
Old, lazy, and annoying? Come now.
https://www.courtlistener.com/recap/gov.uscourts.wawd.294664...
The entire filing makes it clear that they were given considerable time and refused to moderate content which violated the terms of service which they had agreed to follow:
https://cdn.arstechnica.net/wp-content/uploads/2021/01/gov.u...
In a span of seven weeks, on a platform with 8 million users, Amazon found 100 examples of objectionable content.
How many examples of objectionable content do you think I can find on Reddit, Twitter, or Facebook right now?
It's not a question of whether Parler had offensive content on its site. It's a question of Amazon holding Parler to terms that they don't hold anyone else to, including Parler rivals. Parler had moderation tools, were moderating content, and had a clear Terms of Service that outlined the type of content that was not allowed.
Let us travel back in time to 2009. It's three years after Twitter was founded. How robust and effective do you think the Twitter moderation was back at that time?
Even today, in 2021, Twitter is absolutely FULL of illegal content and hate speech. When do you think Amazon will eject Twitter from AWS? Should be any minute now. Any minute.
This is why I suggested reading the filings: Parler is not unique for having user-hosted content but, unlike Twitter and Facebook, refusing to accept responsibility for managing it – those services are far from perfect but they don’t try to pretend volunteer moderation is enough, either.
If you read the filing note that the 100 examples were a representative sample and additional examples were provided.
The key point to look at is this:
“On January 8 and 9, AWS also spoke with Parler executives about its content moderation policies, processes, and tools, and emphasized that Parler’s current approach failed to address Parler’s duty to promptly identify and remove content that threatened or encouraged violence. Id. In response, Parler outlined additional, reactive steps that would rely almost exclusively on ‘volunteers.’”
That’s after having months to develop a serious plan, and after an insurrection involving many users of their service. Beyond the obvious violations of their contract, at that point AWS would reasonably worry that not enforcing their ToS could invite legal claims that their continued non-enforcement constituted support. The direct costs of that and indirect risk to other contracts – imagine, for example, Congress prohibiting federal IT procurements from any company connected to the coup attempt — are much greater than Parler’s rounding-error portion of AWS’ customer base.
* Google Maps API increasing prices by 1400%+
* GKE price increasing from free to ~$73/month per cluster
Can you go into more detail? Not saying you’re wrong of course, but your experience is massively contra to my own, and like I said, we have production on there with little to no issues.
If you have a problem with anything, it's clearly your fault and you're doing it wrong. /s
It’s hard to overstate how important this level of close support is for an enterprise that is literally betting the farm on a cloud provider. The idea of counting on Google’s historical level of support is an absolute non-starter for us.
They've never tried to deeply understand our use cases or business at all. Hopefully they turn this around but IMO, Google is absolutely horrible at B2B, they're just not currently set up to do it correctly.
In the large enterprise migrations I've worked on the past 2 years, I haven't heard a Google employee or partner say, "you're doing it wrong." Sometimes there is a response along the lines of, "we don't recommend doing it that way for the following specific reasons. For your consideration, here are alternatives we recommend for your use case. We've filed your use case as a feature request with product."
Additionally, I've seen issues which block a migration to GCP get escalated and fixed quickly. Issues which in ~2015 might have garnered a, "you're doing it wrong" response.
I've noticed a real shift in attitude and execution. There is genuine empathy and an attempt to understand how enterprise customers run their workloads in the cloud, multi-cloud and hybrid-cloud.
I know of only 2 colleagues who've looked at GCP. Both are medium-large financial institutions. Both said they had very little human-to-human contact with Google representatives. In one case they chose AWS instead; the other is still evaluating GCP.
It's interesting that other posts in the thread are complimentary about the quality of the GCP products. I can believe that; Google has built its fair share of impressive technology. But I see no evidence of an enterprise supplier I could trust: one that would be there to help out when the world went belly up. Given that, it doesn't matter how good their products are.
I'd actually like to see GCP being successful. As well as bringing some competition and diversity to the market, it would give Google a more honest and above-board revenue stream than ads. I don't see that happening though, at least not without a change in leadership.
What!! So I paid $50 for one month for support, and got a full on support expert who'd bill (at least in my world) $250+/hr. Honestly, the support cost was maybe even LOWER, and I'd just signed up for support to submit my ticket.
Google does not care. You GSuite calendar is not accessible on google home devices etc etc despite TONS of requests from paying customers. That same calendar integrates easily with ALEXA from amazon. Huh? Someone is paying attention, and it's not google.
I do like project based permission / approach in GCP. I like a lot of other things there too. But I've had stuff running for years on AWS without issue - so the trust with AWS keeping things going mostly is there.
I think the answer to this question depends on a multitude of factors. For example, nowadays you can use container technologies to create images of your software, which will run on any bit of infrastructure that supports them, be it AWS, GCP, Azure, or even your on-prem servers with something like Rancher or even Docker Swarm running on it. However, creating software like that needs some special thought put into it, this site covering some of those aspects: https://12factor.net/
And while this will make your code more reproducible and migrating between different clouds more easy (or even running on multiple clouds simultaneously), it'll do so at the expense of making development slower and a bit harder for you. For some, this will be worth it, while for others it'll be less so. There are definitely valid criticisms of container technologies and some of the aspects they don't handle all that well yet (Kubernetes being overcomplicated for some projects, whereas Docker Swarm isn't "trendy" or in active development, then there's managing storage and needing to work with either network file systems, or distributed file systems, or even using bind mounts even though they're considered bad practices, then there's routing and the complexity of service meshes etc.).
Of course, there are also people who really don't want to think about infrastructure that much and just want their apps to run in a semi-managed manner, like Heroku does, or perhaps just want to use one of the cloud vendors' managed database or messaging system offerings. Not everyone has a large amount of resources to invest in engineering and running infrastructure.
Some links that will hopefully explain it better than I can:
* https://www.lastweekinaws.com/blog/multi-cloud-is-the-worst-...
* https://www.infoworld.com/article/3428682/your-multicloud-st...