Having worked at both places for ~4 years each, I would say Amazon is much more of a product company, and a platform is really a collection of compelling products.
Amazon really puts customers first. Their platform and organization are made up of small teams that own services with well-defined interfaces, accountable for customer metrics. All profits are reinvested, so resources and perks are scarce, efficiency matters, and management is tight. The platform emerged because internal teams thought of their infrastructure services as products with customers.
Google really puts ideas (or technology) first; it aims to hire the smartest people and rewards them for launching new things and solving complex problems rather than optimizing UX or making customers happy. Resources are ample and management is loose, so individual contributors can try new things with greater leisure. It's been compared to grad school. But simplifying customer experience is less of a priority, so the internal infrastructure was notoriously complex and hard to use. They're now learning to prioritize customers, but it's hard to change culture.
Of course, both companies are huge and diverse and evolving, so you'll find plenty of variance.
App Engine wasn't evidence of Google being a product company, nor does it exemplify the company's strategy. It was a grassroots project that for years didn't receive much leadership support, but was still allowed to launch and grow.
App engine is the biggest enigma. On paper it is a near perfect cloud experience. It has a huge range of services covering the needs of most web applications: task queues, caching, RDBMS, storage, monitoring, logging, a fantastic dashboard; the list goes on and the scope of GCP and GAE in general is truly massive. At first glance the documentation is exhaustive, support quick, and you get the feeling that the product has the full backing of Google with many hundreds of engineers continually improving and iterating.
Yet then you get into the trenches of it and (IMO) you realize the sum of its parts is much less then the value of the individual pieces. You feel the pain of the documentation writers who had to transcribe examples and helper libraries to ten languages, "beta" features that have been out for years, "examples coming soon" in README's that are two years old.
Want to use python3? That's cool, use the flexible environment. But it doesn't support taskqueues or many other features.
Need websockets? Thats cool, we kinda have this socket API and similar for some languages and environments. It doesn't really work in the flexible environment though sorry :X.
All our python examples are in framework X, that's sufficient for everyone using framework Y, right?
Don't get me wrong, my company uses GAE and its benefits outweigh the costs for us. But there is a very real "Googliness" to the failings of the platform. The shear breadth and requirements of "fixing" and iterating on GAE must not be a very fun project to work on.
"Their platform and organization are made up of small teams that own services with well-defined interfaces, accountable for customer metrics."
You are using the terminology of products and platforms with the exact opposite meaning of the article's author.
Those "services with well-defined interfaces" become a platform others can use to build their own products. Similarly with the e-commerce and fulfillment infrastructure third party sellers can use. And maybe the transportation infrastructure in the future.
I also think you vastly underestimate the quality of Google's UX. Type any thing you can think of into one simple box, and you get surprisingly useful auto-completions, relevant spelling corrections, and almost always find the answer to the question you had when you started typing. There are any number of complex back end services working in parallel to resolve your query, with results gathered, ranked, merged, and rendered in a fraction of a second. Pretty hard to beat that user experience.
This is how the author defines product focus, emphasis on combining many components internally to provide an outstanding end user experience, without necessarily making the components available to be used by others to create their own user experience for their customers.
Amazon gives each team independence. Therefore it is virtually impossible to insist on consistency between what different teams do. Each team makes sense on its own, but the whole can be very, very confusing.
Google has a process that results in much greater internal consistency. It may not be a great UX, but it is consistent. Inside and out.
For small systems, Amazon is going to give a better UX. But for a complex system, I prefer what Google will produce.
> App Engine wasn't evidence of Google being a product company, nor does it exemplify the company's strategy. It was a grassroots project that for years didn't receive much leadership support, but was still allowed to launch and grow.
App Engine was a precursor that came 5 years too early.
Great point on simplifying the UI being a priority. This takes a lot of coordination and willingness to say "We will drop features A, B and C to make the overall experience easier." This is ultimately both an organizational and cultural issue. Some companies optimize on centralization (historically Apple) while others have a more decentralized "empower the individual" ethos. This article from the same source highlights how Apple's centralized org is core to it's view of product integration. https://stratechery.com/2016/apples-organizational-crossroad...
When dealing with a platform, this user experience coordination becomes much more important. (Think the old Apple ecosystem versus all the crap that came pre-installed on the Wintel systems)
AWS has fallen flat in the past with cross-service initiatives. Tagging and IAM keys come to mind. I haven't personally used Google much but from what I hear their stuff is a bit more cohesive..
This new Org stuff might be a recent exception though; I haven't read through it all and tested it to know. Hopefully.
This is changing - I got a call from Google Cloud sales/support today. I am just using the GCP for prototyping so I have spent maybe $50 on it so far. Looks like they're stepping up their gane and really trying to be helpful and willing to listen to customers.
I think Ben (who I generally think is right on) in this post misapprehends the effectiveness of generalized data for machine learning services and thus the effectiveness of this approach in Google’s strategy here. Perhaps the slide makers in Mountain View have the same misapprehension.
1 - Prediction API - you provide your own data there, so no data advantage from Google there.
2 - Cloud Natural Language API - the effectiveness really depends on what type of text you want to understand. If Google’s training data includes information about my type of text application great, but if it doesn’t then what? How do I know that?
3 - Cloud Vision API - likewise. Can I subset the training set? Provide my own examples? If they subset, can I inspect the examples?
4 - Translation API seems like the exception here, mainly because the odds are that customers of translation service are unlikely to have collected language pairs and this collection is more highly specialized. But it’s unclear that this one API would be the deciding factor for many companies choosing which cloud vendor to use.
ML services as a differentiator have yet to be proven out. I am highly suspect. Yes, some big general data sets will be better on some applications than others, but an enterprises’ own data about their problem will always be better than a huge, general data set. And if you’re using your own data anyway, you’re going to care about all the platformy things Amazon has already been winning with.
Barring proprietary breakthroughs in unsupervised learning, I don’t believe that this strategy as outlined will work in practice.
I don't think Google is marketing their Cloud NLP/Vision APIs for big enterprise customers that have very specific needs. Those APIs are meant for people that have common needs ( = want to identify which items or people are on a photo, understand queries in commonly used languages, etc.)
If you have specific needs, then you can use TensorFlow running on the app engine (as they will soon be providing hosted and GPU-accelerated instances), which at worst makes it equal to Amazon offering... but something tells me the vast majority of Google Cloud customers will be satisfied with pre-trained models that can be applied on a very large swath of problems.
I think you've really pointed out a very important flaw in that as developers and startups we don't have terabytes of training data.
However, I'm not sure who's in the leading edge here while Microsoft seems to suggest as the leader, but in the end machine learning, deep learning will be commoditized with enough training already baked in.
ex. Need your web app translated flawlessly into Farsi? Just drop in farsi.js to your </head> and etc.
> Amazon’s AWS strategy sprang from the same approach that made the company successful in the first place
I'd argue that Amazon isn't a successful company, they are a popular company with a few large successes surrounded by decaying and decrepit failures that won't die. But then again I'm biased.
As far as Amazon's AWS strategy, I can't comment (I worked in the retail business side). But I can comment on a relatively small aspect of management that I witnessed. At one point in time I had a very strong need for PostGIS, and I lamented on an internal email list about AWS not having a Postgres version of RDS. I received an email directly from Raju Gulabani, VP of databases in AWS. He scheduled an appointment with me, him, and two product managers. He asked me pointed questions about why I wanted Postgres over the other options, how I would be using it, what extensions I wanted, and what features were important to me. He thanked me for my time, and less than a year later it was released to the public.
In the retail business side, I never had more than 2 minutes at a time with someone at the director level, and not once had I spoken to someone at the VP level. Literally zero communication from the bottom up, everything was top down. Whether AWS had already been working on it or not I don't know, but they definitely took the time to hear my case, and when it was released it was almost perfectly as I had asked for. And that, IMO is waaaay more important than anything regarding the size of a team or whatever the fluff pieces have attributed.
> I'd argue that Amazon isn't a successful company, they are a popular company with a few large successes surrounded by decaying and decrepit failures that won't die. But then again I'm biased.
Couldn't you say the same thing about Google, or Microsoft? I think the point of 'success' is that your big wins outweigh your failures as determined by your revenue. Is it not?
Creating the largest retailer in the world and the largest cloud services platform in the world seem like two pretty big wins. Either one on its own would be an extremely successful company IMO.
There's always the simpler explanation to why Google is getting traction:
- Price/performance is better in some/many cases for VMs
- It's easy(ier?) to use
- Clear technical advantage with some of their other services e.g. Load balancers
- Customers prefer when there are multiple companies competing for their business
I get that there are long-term strategies that involve the likes of container services. But just the fact that they are better in some areas will help them get traction. Plus they have a fantastic brand name.
Frankly I still like the Heroku model the best. Do one thing and do it well. Have third-party plugins handle the other things. It fits the "cloud" vision better, than consolidating all your functionality with one provider. That seems like a regression. I just wish Heroku was cheaper at scale. I don't understand why it's not. It seems like they could reduce prices and still remain profitable, while increasing their visibility greatly.
The article mentioned kubernetes multiple times and I think it's providers like Heroku that actually stand the most to gain there. With kubernetes in theory they should no longer have to make you choose between providers, and be able to run on spot instances of whatever provider is cheapest at the time. You just choose your max latency at certain geo areas and a budget to balance by, some AI to help you determine the tradeoffs, and it does the rest. If Heroku isn't working toward that then there has to be someone doing so soon. If not it seems like there's a pretty big opportunity there.
>> Microsoft did the same with its Win32 API. Yes, this meant that Windows was by design a worse platform in terms of the end user experience than, say, Mac OS ...
I want to try out Google, but they need to make it easier to try it out. I have petabytes of data in S3 that I would need to move first (at least some of it).
`Transfer data to your Cloud Storage buckets from Amazon Simple Storage Service (S3), HTTP/HTTPS servers or other buckets. You can schedule once-off or daily transfers, and you can filter files based on name prefix and when they were changed.`
> Yes, this meant that Windows was by design a worse platform in terms of the end user experience than, say, Mac OS, but it was far more powerful and extensible, an approach that paid off with millions of line of business apps that even today keep Windows at the center of business.
Is there any validity to this? I don't do much OS-level programming, but is the Win32 API really that much more powerful and extensible?
To give one example: Windows Explorer has been extensible since Windows 95. That was 21 years ago. Dropbox has to pull nasty hacks to integrate with the macOS Finder [1]. That's now.
> Is there any validity to this? I don't do much OS-level programming, but is the Win32 API really that much more powerful and extensible?
I certainly don't think so (although there are some nice things about the Windows kernel, if one comes from a VMS background), and it's certainly not the reason for the success of Windows. Remember that MS-DOS beat Mac OS; Windows 1 beat Mac OS; Windows 3.1 beat Mac OS; Windows 95 beat Mac OS. None of those was technically any good whatsoever, and only one of those had a UI that was worth shaking a stick at.
The reasons for the success of Windows are non-technical: Bill Gates's mother served on a charity board with the chairman of IBM; business bought IBM computers because no-one ever got fired for buying IBM; IBM clones were cheaper than Macs; IBM clones were more extensible and hackable than Macs; Unix workstation vendors thought they could keep milking their cash cows; Microsoft engaged in noncompetitive behaviour; random chance.
I would like to try out google cloud due to its lower costs, but don't trust them with my data--partially perception I know. Also Amazon has never failed me over the last 15 years I've been doing business with them, so I'll probably continue despite the clunkiness of their products.
I'm not sure if Google's commercial products are as bad as their consumer-facing offerings, but if we can't get someone on the phone when a support issue arises then we'd never consider using them for any cloud services.
Depending on how you use the services the AWS free tier is actually worth less than GCP's $300 free-trial credit: https://cloud.google.com/free-trial/
I will give Amazon that theirs extends out to a year, but summing up the costs of everything included in the free tier if you use all of it, I think it may still come out to less than $300 (or the equivalents on GCP would, anyway). For example, running an f1-micro for a year will cost you a bit under $60. If you add in another for Google Cloud SQL you're up to a total of about $150 over the course of a year. What they offer you in S3 is basically free (<$2 over the course of a year).
It's possible the other services are a better deal than compute and storage, if you have a use for them, but the GCP free trial lets you allocate that $300 however you like. You can scale up more in that 60 days than you can within the AWS free tier. To me, personally, this strikes me as more valuable if I'm trying to sketch out a new product — I'd rather not try to figure out how to fit inside the AWS free tier resource envelope and instead understand how my costs are scaling with the resources I'm using while not being on the hook for those costs (up to the $300 size of the credit, obviously) for the first couple months. Especially to absorb things like shaking out automation -- go ahead, spin up a GKE cluster, scale it out to 5x the size you currently need, run some quick load tests, and then scale it back down 30 minutes later (and only pay for that 30 minutes).
Full ack. I don't understand why GCE doesn't have the same offer there. Their free trial is too short to really test it. If you're a developer and experimenting with cloud offers on side projects, AWS is often free. That way a lot of people have some experience using AWS. I'm sure the free trial pays off well for Amazon.
If Google released an IDE with tight integration to Google Cloud like Azure + Visual Studio, that's a potential killer app that lowers the perceived switching cost.
If you told me to use Azure two years ago I would've laughed you out of the room. But here I am in 2016, using Azure, using ASP.net + IIS on Visual Studio. that's some powerful shit and currently AWS has cost leadership and perceived switching cost as their edge.
By introducing a layer of learning curve, you lock in your customers but eventually the other guys will race to lower that curve.
Those Azure gains only exist within a small space. Once you step outside the C# ASP.net sphere, their picture is no where near as rosy. Much of their offerings are minimal products for checkbox comparison sake.
When the answer to your tech problem is not ASP.net/SQL Server, you are going to find their services much more difficult to put up with compared to the competition.
Before someone jumps in with ".Net is huge in the X space" thing: There has been double digit growth of close to a decade now of platforms that don't run .Net. That ecosphere was a giant. Now it isn't.
I haven't used Azure, so I'm a bit confused. Do you mean something with different capabilities than Google Cloud Tools for Visual Studio? https://cloud.google.com/visual-studio/
What are the killer features of that tight integration for you? I use VS but run on other platforms with a fairly simple git push. Does VS have some other features beyond deployment that integrate directly with Azure?
Google Cloud UI is vastly superior to AWS. It's clear to me AWS didn't put a lot of effort into their interface, Google console is nice too in order to quickly experiment with the platform. On the other hand, it seems to me that AWS is still cheaper than GCloud right now.
I disagree with the central thesis of this article that Google is a product company rather than a platform company. I think that's wrong because throughout its history Google has asked itself "what if we had this?" first, and built the products around that later. Essentially the company believes that products will naturally emerge if you hire tens of thousands of engineers and deploy an unholy number of computers. I said this before on this site: Google's core product is dirt-cheap computing. Everything else follows from that.
[+] [-] seregine|9 years ago|reply
Amazon really puts customers first. Their platform and organization are made up of small teams that own services with well-defined interfaces, accountable for customer metrics. All profits are reinvested, so resources and perks are scarce, efficiency matters, and management is tight. The platform emerged because internal teams thought of their infrastructure services as products with customers.
Google really puts ideas (or technology) first; it aims to hire the smartest people and rewards them for launching new things and solving complex problems rather than optimizing UX or making customers happy. Resources are ample and management is loose, so individual contributors can try new things with greater leisure. It's been compared to grad school. But simplifying customer experience is less of a priority, so the internal infrastructure was notoriously complex and hard to use. They're now learning to prioritize customers, but it's hard to change culture.
Of course, both companies are huge and diverse and evolving, so you'll find plenty of variance.
App Engine wasn't evidence of Google being a product company, nor does it exemplify the company's strategy. It was a grassroots project that for years didn't receive much leadership support, but was still allowed to launch and grow.
[+] [-] ben_jones|9 years ago|reply
Yet then you get into the trenches of it and (IMO) you realize the sum of its parts is much less then the value of the individual pieces. You feel the pain of the documentation writers who had to transcribe examples and helper libraries to ten languages, "beta" features that have been out for years, "examples coming soon" in README's that are two years old.
Want to use python3? That's cool, use the flexible environment. But it doesn't support taskqueues or many other features.
Need websockets? Thats cool, we kinda have this socket API and similar for some languages and environments. It doesn't really work in the flexible environment though sorry :X.
All our python examples are in framework X, that's sufficient for everyone using framework Y, right?
Don't get me wrong, my company uses GAE and its benefits outweigh the costs for us. But there is a very real "Googliness" to the failings of the platform. The shear breadth and requirements of "fixing" and iterating on GAE must not be a very fun project to work on.
[+] [-] jimbokun|9 years ago|reply
You are using the terminology of products and platforms with the exact opposite meaning of the article's author.
Those "services with well-defined interfaces" become a platform others can use to build their own products. Similarly with the e-commerce and fulfillment infrastructure third party sellers can use. And maybe the transportation infrastructure in the future.
I also think you vastly underestimate the quality of Google's UX. Type any thing you can think of into one simple box, and you get surprisingly useful auto-completions, relevant spelling corrections, and almost always find the answer to the question you had when you started typing. There are any number of complex back end services working in parallel to resolve your query, with results gathered, ranked, merged, and rendered in a fraction of a second. Pretty hard to beat that user experience.
This is how the author defines product focus, emphasis on combining many components internally to provide an outstanding end user experience, without necessarily making the components available to be used by others to create their own user experience for their customers.
[+] [-] btilly|9 years ago|reply
Amazon gives each team independence. Therefore it is virtually impossible to insist on consistency between what different teams do. Each team makes sense on its own, but the whole can be very, very confusing.
Google has a process that results in much greater internal consistency. It may not be a great UX, but it is consistent. Inside and out.
For small systems, Amazon is going to give a better UX. But for a complex system, I prefer what Google will produce.
[+] [-] user5994461|9 years ago|reply
App Engine was a precursor that came 5 years too early.
The hype about serverless is only starting now.
[+] [-] mathattack|9 years ago|reply
When dealing with a platform, this user experience coordination becomes much more important. (Think the old Apple ecosystem versus all the crap that came pre-installed on the Wintel systems)
[+] [-] findjashua|9 years ago|reply
as someone who's dabbled a bit w both, I found GCP UI/UX to be far simpler than dealing w AWS
[+] [-] Rapzid|9 years ago|reply
This new Org stuff might be a recent exception though; I haven't read through it all and tested it to know. Hopefully.
[+] [-] mdani|9 years ago|reply
[+] [-] olimashi|9 years ago|reply
1 - Prediction API - you provide your own data there, so no data advantage from Google there.
2 - Cloud Natural Language API - the effectiveness really depends on what type of text you want to understand. If Google’s training data includes information about my type of text application great, but if it doesn’t then what? How do I know that?
3 - Cloud Vision API - likewise. Can I subset the training set? Provide my own examples? If they subset, can I inspect the examples?
4 - Translation API seems like the exception here, mainly because the odds are that customers of translation service are unlikely to have collected language pairs and this collection is more highly specialized. But it’s unclear that this one API would be the deciding factor for many companies choosing which cloud vendor to use.
ML services as a differentiator have yet to be proven out. I am highly suspect. Yes, some big general data sets will be better on some applications than others, but an enterprises’ own data about their problem will always be better than a huge, general data set. And if you’re using your own data anyway, you’re going to care about all the platformy things Amazon has already been winning with.
Barring proprietary breakthroughs in unsupervised learning, I don’t believe that this strategy as outlined will work in practice.
[+] [-] halflings|9 years ago|reply
If you have specific needs, then you can use TensorFlow running on the app engine (as they will soon be providing hosted and GPU-accelerated instances), which at worst makes it equal to Amazon offering... but something tells me the vast majority of Google Cloud customers will be satisfied with pre-trained models that can be applied on a very large swath of problems.
[+] [-] brilliantcode|9 years ago|reply
However, I'm not sure who's in the leading edge here while Microsoft seems to suggest as the leader, but in the end machine learning, deep learning will be commoditized with enough training already baked in.
ex. Need your web app translated flawlessly into Farsi? Just drop in farsi.js to your </head> and etc.
[+] [-] darksaints|9 years ago|reply
I'd argue that Amazon isn't a successful company, they are a popular company with a few large successes surrounded by decaying and decrepit failures that won't die. But then again I'm biased.
As far as Amazon's AWS strategy, I can't comment (I worked in the retail business side). But I can comment on a relatively small aspect of management that I witnessed. At one point in time I had a very strong need for PostGIS, and I lamented on an internal email list about AWS not having a Postgres version of RDS. I received an email directly from Raju Gulabani, VP of databases in AWS. He scheduled an appointment with me, him, and two product managers. He asked me pointed questions about why I wanted Postgres over the other options, how I would be using it, what extensions I wanted, and what features were important to me. He thanked me for my time, and less than a year later it was released to the public.
In the retail business side, I never had more than 2 minutes at a time with someone at the director level, and not once had I spoken to someone at the VP level. Literally zero communication from the bottom up, everything was top down. Whether AWS had already been working on it or not I don't know, but they definitely took the time to hear my case, and when it was released it was almost perfectly as I had asked for. And that, IMO is waaaay more important than anything regarding the size of a team or whatever the fluff pieces have attributed.
[+] [-] darawk|9 years ago|reply
Couldn't you say the same thing about Google, or Microsoft? I think the point of 'success' is that your big wins outweigh your failures as determined by your revenue. Is it not?
Creating the largest retailer in the world and the largest cloud services platform in the world seem like two pretty big wins. Either one on its own would be an extremely successful company IMO.
[+] [-] origami777|9 years ago|reply
- Price/performance is better in some/many cases for VMs
- It's easy(ier?) to use
- Clear technical advantage with some of their other services e.g. Load balancers
- Customers prefer when there are multiple companies competing for their business
I get that there are long-term strategies that involve the likes of container services. But just the fact that they are better in some areas will help them get traction. Plus they have a fantastic brand name.
[+] [-] daxfohl|9 years ago|reply
[+] [-] daxfohl|9 years ago|reply
[+] [-] jacques_chester|9 years ago|reply
"Do one thing and do it well" is underselling Heroku.
PaaSes have to do a lot of things and do them well.
[+] [-] wangii|9 years ago|reply
The author loses his creditability since here.
[+] [-] ap22213|9 years ago|reply
[+] [-] mvitorino|9 years ago|reply
`Transfer data to your Cloud Storage buckets from Amazon Simple Storage Service (S3), HTTP/HTTPS servers or other buckets. You can schedule once-off or daily transfers, and you can filter files based on name prefix and when they were changed.`
https://cloud.google.com/storage/transfer/
[+] [-] cobookman|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] daxfohl|9 years ago|reply
Is there any validity to this? I don't do much OS-level programming, but is the Win32 API really that much more powerful and extensible?
[+] [-] brassic|9 years ago|reply
[1]: https://news.ycombinator.com/item?id=12463338
[+] [-] zeveb|9 years ago|reply
I certainly don't think so (although there are some nice things about the Windows kernel, if one comes from a VMS background), and it's certainly not the reason for the success of Windows. Remember that MS-DOS beat Mac OS; Windows 1 beat Mac OS; Windows 3.1 beat Mac OS; Windows 95 beat Mac OS. None of those was technically any good whatsoever, and only one of those had a UI that was worth shaking a stick at.
The reasons for the success of Windows are non-technical: Bill Gates's mother served on a charity board with the chairman of IBM; business bought IBM computers because no-one ever got fired for buying IBM; IBM clones were cheaper than Macs; IBM clones were more extensible and hackable than Macs; Unix workstation vendors thought they could keep milking their cash cows; Microsoft engaged in noncompetitive behaviour; random chance.
[+] [-] mixmastamyk|9 years ago|reply
[+] [-] naner|9 years ago|reply
[+] [-] dxxvi|9 years ago|reply
[+] [-] jsolson|9 years ago|reply
I will give Amazon that theirs extends out to a year, but summing up the costs of everything included in the free tier if you use all of it, I think it may still come out to less than $300 (or the equivalents on GCP would, anyway). For example, running an f1-micro for a year will cost you a bit under $60. If you add in another for Google Cloud SQL you're up to a total of about $150 over the course of a year. What they offer you in S3 is basically free (<$2 over the course of a year).
It's possible the other services are a better deal than compute and storage, if you have a use for them, but the GCP free trial lets you allocate that $300 however you like. You can scale up more in that 60 days than you can within the AWS free tier. To me, personally, this strikes me as more valuable if I'm trying to sketch out a new product — I'd rather not try to figure out how to fit inside the AWS free tier resource envelope and instead understand how my costs are scaling with the resources I'm using while not being on the hook for those costs (up to the $300 size of the credit, obviously) for the first couple months. Especially to absorb things like shaking out automation -- go ahead, spin up a GKE cluster, scale it out to 5x the size you currently need, run some quick load tests, and then scale it back down 30 minutes later (and only pay for that 30 minutes).
(affiliation: I'm an engineer on Compute Engine)
[+] [-] dx034|9 years ago|reply
[+] [-] perseusprime11|9 years ago|reply
[+] [-] thiyags|9 years ago|reply
[+] [-] sorenbs|9 years ago|reply
[+] [-] NicoJuicy|9 years ago|reply
[+] [-] brilliantcode|9 years ago|reply
If you told me to use Azure two years ago I would've laughed you out of the room. But here I am in 2016, using Azure, using ASP.net + IIS on Visual Studio. that's some powerful shit and currently AWS has cost leadership and perceived switching cost as their edge.
By introducing a layer of learning curve, you lock in your customers but eventually the other guys will race to lower that curve.
[+] [-] lmickh|9 years ago|reply
When the answer to your tech problem is not ASP.net/SQL Server, you are going to find their services much more difficult to put up with compared to the competition.
Before someone jumps in with ".Net is huge in the X space" thing: There has been double digit growth of close to a decade now of platforms that don't run .Net. That ecosphere was a giant. Now it isn't.
[+] [-] trautlein|9 years ago|reply
[1]: http://thenextweb.com/dd/2016/07/14/amazon-buys-cloud9-aws/
[+] [-] jpatokal|9 years ago|reply
https://cloudplatform.googleblog.com/2016/10/introducing-Goo...
[+] [-] CobrastanJorji|9 years ago|reply
[+] [-] daxfohl|9 years ago|reply
[+] [-] solatic|9 years ago|reply
[+] [-] aikah|9 years ago|reply
Google Cloud UI is vastly superior to AWS. It's clear to me AWS didn't put a lot of effort into their interface, Google console is nice too in order to quickly experiment with the platform. On the other hand, it seems to me that AWS is still cheaper than GCloud right now.
[+] [-] bduerst|9 years ago|reply
How so?
I thought this was brought up just a week ago saying GCloud is consistently cheaper:
https://news.ycombinator.com/item?id=12993021
[+] [-] hueving|9 years ago|reply
[+] [-] pbreit|9 years ago|reply
[+] [-] honkhonkpants|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] lasermike026|9 years ago|reply
To be serious this is a catastrophic failure. We can not deprive people of there freedom because of a glitch. This system doesn't have fail safes.
[+] [-] wyldfire|9 years ago|reply