Ask HN: What happened when Amazon moved into your business?
Without going too much into my own product. I have recently found out after watching the AWS conference that I am now directly competing against an Amazon product... I am looking for stories of how your company reacted and maybe the successes or failures...
84 コメント
Don't despair. Despite common perception, most AWS products are half-baked and clunky. (I don't have much experience with other Amazon products.) A while ago when GCP appeared in the scene, the team I was in performed a series of tests to evaluate it. In all our tests, GCP came out ahead of AWS. On top of that, their documentation and UI was better and prices were lower. That's part of how Google managed to get a foothold in the cloud services space.
AWS premium support doesn't help much when you are fighting fire because the first line support staff is clueless. It will take you days to reach a person who can actually help you.
IMHO, if you are offering a standalone product, you can always do better than Amazon (AWS). Whether you can beat them depends on variables other than the quality of your product.
AWS premium support doesn't help much when you are fighting fire because the first line support staff is clueless. It will take you days to reach a person who can actually help you.
IMHO, if you are offering a standalone product, you can always do better than Amazon (AWS). Whether you can beat them depends on variables other than the quality of your product.
I worked for a company that was in 50K/ month spend in AWS there is basically 0 service. Now I work for a company with serious monthly spend in millions we pretty much can get access to competent eng. immediately.
And the worst of both world. Work for a company that spent tens of millions on their own datacenters only to get neither half of the services nor half the quality.
It's all about who your TAM is. A good TAM will have your back from the jump. A bad one...not so much.
Small things about AWS suggest it's a load of different products held together by duct tape.
Case in point - I was fixing an issue today, so had iam/s3/ec2 open. They have different favicons. I had the situation we all know where I had 40 different tabs open whilst trying to work out what was going on, thought I didn't have an AWS tab so opened another one purely because the iam favicon is completely different to the rest.
I know it sounds silly, but it is indicative of the entire thing - their ECR doesn't support going back in the browser for one. I'd run to GCloud, but unfortunately the company i'm contracting at won't move.
Case in point - I was fixing an issue today, so had iam/s3/ec2 open. They have different favicons. I had the situation we all know where I had 40 different tabs open whilst trying to work out what was going on, thought I didn't have an AWS tab so opened another one purely because the iam favicon is completely different to the rest.
I know it sounds silly, but it is indicative of the entire thing - their ECR doesn't support going back in the browser for one. I'd run to GCloud, but unfortunately the company i'm contracting at won't move.
> because the iam favicon is completely different to the rest
I can easily imagine this being a deliberate decision to make it easier for someone who uses AWS a lot to click the right tab when they have 40 tabs open.
I agree with the point that GCP feels like it has better docs and API than AWS.
I can easily imagine this being a deliberate decision to make it easier for someone who uses AWS a lot to click the right tab when they have 40 tabs open.
I agree with the point that GCP feels like it has better docs and API than AWS.
When Amazon launched their Cloudwatch reports, I saw a definite downward trend in S3stat signups, and even lost several customers since their thing duplicated most of my functionality at the time.
It took a couple years to recover. Mostly through improving my product, but also from people realizing that Cloudwatch is kinda a pain to use and doesn't give the best reports.
Better still, Amazon never iterates on things, so their product today is the same one they introduced half a dozen years ago.
S3stat is doing better than ever today.
It took a couple years to recover. Mostly through improving my product, but also from people realizing that Cloudwatch is kinda a pain to use and doesn't give the best reports.
Better still, Amazon never iterates on things, so their product today is the same one they introduced half a dozen years ago.
S3stat is doing better than ever today.
im getting NET::ERR_CERT_AUTHORITY_INVALID
NET::ERR_CERT_AUTHORITY_INVALID Subject: www.s3stat.com
NET::ERR_CERT_AUTHORITY_INVALID Subject: www.s3stat.com
I think most readers here would enjoy the book, "Small Giants"[0]. I also like the concept of, "1,000 True Fans"[1]. I'm aiming for both my self, personally.
[0]: http://www.smallgiantsbook.com/ [1]: http://kk.org/thetechnium/1000-true-fans/
[0]: http://www.smallgiantsbook.com/ [1]: http://kk.org/thetechnium/1000-true-fans/
We have a product in analytics space and our target customer audience was companies that want to develop an analytics solution on top of AWS. We're not actually a direct competitor to AWS but it turns out to be that way.
At first, we thought that it's a win-win-win situation for AWS, AWS customers to use our product and us because I know a lot of AWS customers who try to build in-house solution on AWS and then switched to either third-party solution or another cloud provider since they couldn't design the right system for high data volume on AWS. It's mainly because data engineers are one of the most expensive engineers and there're not enough sophisticated data engineers in the market. We provided (this was the promise) the right (scalable, cheap enough and flexible) solution from day 1 so that they don't have to build a data engineering team.
It didn't work because AWS advertises its products as dead-easy to maintain and easy to start working with. Let's take Redshift as an example; it's easy to create a Redshift cluster with 3 clicks but that doesn't make you experienced in distributed systems. Often the companies start using Redshift and as their data grows the price gets expensive exponentially. They hire data engineers at that point and try to switch to another solution or try to make it scalable but switching to a completely different architecture (our solution) is also not easy at this point because of switching costs. Essentially our product became a competitor of AWS from customer's perspective even though we're complementary.
Even though we have customers and a profitable company I don't think that we could find the product market fit with that product so now we're pivoting to something else and the new target is more niche.
At first, we thought that it's a win-win-win situation for AWS, AWS customers to use our product and us because I know a lot of AWS customers who try to build in-house solution on AWS and then switched to either third-party solution or another cloud provider since they couldn't design the right system for high data volume on AWS. It's mainly because data engineers are one of the most expensive engineers and there're not enough sophisticated data engineers in the market. We provided (this was the promise) the right (scalable, cheap enough and flexible) solution from day 1 so that they don't have to build a data engineering team.
It didn't work because AWS advertises its products as dead-easy to maintain and easy to start working with. Let's take Redshift as an example; it's easy to create a Redshift cluster with 3 clicks but that doesn't make you experienced in distributed systems. Often the companies start using Redshift and as their data grows the price gets expensive exponentially. They hire data engineers at that point and try to switch to another solution or try to make it scalable but switching to a completely different architecture (our solution) is also not easy at this point because of switching costs. Essentially our product became a competitor of AWS from customer's perspective even though we're complementary.
Even though we have customers and a profitable company I don't think that we could find the product market fit with that product so now we're pivoting to something else and the new target is more niche.
Amazon entered our business (B2B) not too long ago. Not yet in our country, but we were watching closely. They tried to go very large from the very beginning while we had started from zero 8 years ago and still are a small company.
We are still here, doing well and growing. Amazon just recently announced the shutdown of their service.
Steady yet healthy growth and happy customers won‘t let them kill you overnight.
We are still here, doing well and growing. Amazon just recently announced the shutdown of their service.
Steady yet healthy growth and happy customers won‘t let them kill you overnight.
I think you'd enjoy the book, "Small Gaints"
You are right, I think I would.
Ordered it just now – not on Amazon ;)
Haha! Good call. I actually almost sent you an Amazon link to it but thought that too ironic ;-)
You should check out RedisLabs and read about their story. I'm not affiliated, but I always thought it was amazing how successful they are given that AWS has redis ElastiCache.
Every company I know of that this happened to, and I know of at least five personally and others via 2nd hand, disappeared within six months.
One of them went on to start a new company and was acquired by Facebook for a whole lot of money.
But overall the outlook isn't great, and here's why. Amazon is great at the "80% solution". If you're already in AWS, and they have something that does most of what you want, it's way easier to use that than try and integrate with someone else.
So if what you're doing is only in AWS and isn't significantly better than what they offer, the news isn't good.
I'm sorry this happened to you. :(
One of them went on to start a new company and was acquired by Facebook for a whole lot of money.
But overall the outlook isn't great, and here's why. Amazon is great at the "80% solution". If you're already in AWS, and they have something that does most of what you want, it's way easier to use that than try and integrate with someone else.
So if what you're doing is only in AWS and isn't significantly better than what they offer, the news isn't good.
I'm sorry this happened to you. :(
It's the old "No one ever got fired for buying IBM". Why would I choose a slightly better product from an unknown company? If it was the wrong decision it calls my competence into question. If I choose AWS and it was the wrong solution, no one will bat an eye because they would have made the same choice.
I don't think it's just that.
I have complete freedom to use any cloud solution in my organization, but I almost always choose AWS. Mostly it's a seal of basic quality. I know it had documentation, I know it has uptime, and I know it has packages for any environment I want to use it in.
I've had mixed experiences with less established SaaS, and mixed experiences means more dev time on average.
I have complete freedom to use any cloud solution in my organization, but I almost always choose AWS. Mostly it's a seal of basic quality. I know it had documentation, I know it has uptime, and I know it has packages for any environment I want to use it in.
I've had mixed experiences with less established SaaS, and mixed experiences means more dev time on average.
If the unknown company is offering everything you just listed, will the unknown company be considered?
Not OP, but unknown companies are unkown quantities. They might be better than AWS, but they also might just be worse.
It is the very known-ness of AWS that gives it the 'seal of basic quality'. To compete, the unknown company would probably need a reputation for excellence. Note that it takes a reputation excellence to beat AWS not because AWS is excellent, but to ensure that even if the reputation is off by a little, the company still isn't shite. (there is also the bonus of excellence on its own being an enticing reason to swap)
It is the very known-ness of AWS that gives it the 'seal of basic quality'. To compete, the unknown company would probably need a reputation for excellence. Note that it takes a reputation excellence to beat AWS not because AWS is excellent, but to ensure that even if the reputation is off by a little, the company still isn't shite. (there is also the bonus of excellence on its own being an enticing reason to swap)
If it was just “as good as” AWS, then no it wouldn’t be considered - easier to just expand the usage of the existing product.
If it is materially better, then yes, but the barrier to entry for setting it up, signing yet another SaaS contract, etc. is high. Most likely would still go with AWS unless there was a really good reason not to.
If it is materially better, then yes, but the barrier to entry for setting it up, signing yet another SaaS contract, etc. is high. Most likely would still go with AWS unless there was a really good reason not to.
An unknown company by definition is unable to offer what they just listed, namely, that they know and trust that all of that really is there at the quality they expect.
It may claim these things and might actually have them, but any company or sysadmin must spend significant time, effort and thus cost to investigate and verify if that really is true, at least until they have established a solid reputation and aren't an unknown company anymore. And there should be some reason to spend this cost in reviewing and considering them if more established options are available; if other factors are equal, then the more widely used service is better for various reasons, so if they aren't promising some nontrivial improvement over AWS, why bother?
It may claim these things and might actually have them, but any company or sysadmin must spend significant time, effort and thus cost to investigate and verify if that really is true, at least until they have established a solid reputation and aren't an unknown company anymore. And there should be some reason to spend this cost in reviewing and considering them if more established options are available; if other factors are equal, then the more widely used service is better for various reasons, so if they aren't promising some nontrivial improvement over AWS, why bother?
No. The things I listed are reasons I am hesitant to work with a company I am unfamiliar with.
To be considered you have to have everything listed, and be clearly better than AWS. Better shouldn't be defined as cheaper, but by a higher quality product. It's hard to define that without knowing exactly what service you provide.
To be considered you have to have everything listed, and be clearly better than AWS. Better shouldn't be defined as cheaper, but by a higher quality product. It's hard to define that without knowing exactly what service you provide.
If the company does offer all that, how are they still unknown?
You'd have to weigh or SWOT your decision, using a better product from an unknown company that might offer more or from a trusted company (AWS) that offers less. Especially if, the unknown company is offering something the trusted company isn't
The thing about "nobody ever gets fired for buying IBM" is that going with an unknown alternative is a risk to you personally and most of the benefits go to the company. When you over-spend on a well-known brand, the company suffers the costs and they barely even notice. The only time they care is if something goes wrong, and then they want to know why you chose an unknown brand.
I figure the correct way is that you build for "the cloud" aka someone else's computer. This means that don't use their proprietary offerings to do so unless absolutely necessary.
If you don't use their proprietary offerings, you lose most of the benefit of going to the cloud over being on prem.
If all you're doing is hosting a bunch of VMs on the cloud, what's the point?
Yes, be mindful as a developer I do take a few common sense steps...
1. ElastiCache uses the Memcached protocol so you're really not tying yourself to anything.
2. Lambda - think the "ports and adapters" pattern. Treat your Lambda function as a controller and keep all of your business logic separate.
3. Logging - all of our logging that goes to CloudWatch goes through Serilog. We can switch out the sink easily enough to anything.
4. Simple Queueing System - don't have calls to SQS all over your code, have it in one central module (in our case a Nuget package).
5. Autoscaling - have a shutdown method and wrap the calls that check when your instance is being shut down as events.
6. AWS KMS - We use Hashicorp's Vault and use AWS as a "backend".
7. Cognito - authentication. It's just Middleware for .Net Core that creates a principal before every request. It would be quite easy to add another piece of middleware.
If all you're doing is hosting a bunch of VMs on the cloud, what's the point?
Yes, be mindful as a developer I do take a few common sense steps...
1. ElastiCache uses the Memcached protocol so you're really not tying yourself to anything.
2. Lambda - think the "ports and adapters" pattern. Treat your Lambda function as a controller and keep all of your business logic separate.
3. Logging - all of our logging that goes to CloudWatch goes through Serilog. We can switch out the sink easily enough to anything.
4. Simple Queueing System - don't have calls to SQS all over your code, have it in one central module (in our case a Nuget package).
5. Autoscaling - have a shutdown method and wrap the calls that check when your instance is being shut down as events.
6. AWS KMS - We use Hashicorp's Vault and use AWS as a "backend".
7. Cognito - authentication. It's just Middleware for .Net Core that creates a principal before every request. It would be quite easy to add another piece of middleware.
Say something went wrong, and the company is questioning why you went for an unknown brand. My answer to that would be they offered more value than the trusted brand, also I would have notified necessary stakeholders before making that decision of using services provided by the unknown brand.
Or you could save yourself the risk and all the hassle, and just go with the well-known brand. It's not necessarily what you should do, but it is what often happens.
> My answer to that would be they offered more value than the trusted brand
So much value that things went wrong and now you're explaining yourself.
So much value that things went wrong and now you're explaining yourself.
And if that unknown small company goes out of business, then what?
I've been on both sides of that equation - the vendor and the client. When I was working for the vendor, the only way that we were able to secure our biggest deal was to put our entire software stack in escrow -both the proprietary development platform and the system we built for them on top of it. *
As the client, part of the contract was that they had to put their code in escrow.
In both cases, the client was large enough to negotiate those terms. What if you aren't large enough to force those terms?
* That worked out well for me. When the company I worked for went belly up, the client that enforced those terms hired me to complete their system since they had the right to the source code and I was the only person on the planet that was available that knew how both the C based development platform and their implementation worked well enough to complete it.
I've been on both sides of that equation - the vendor and the client. When I was working for the vendor, the only way that we were able to secure our biggest deal was to put our entire software stack in escrow -both the proprietary development platform and the system we built for them on top of it. *
As the client, part of the contract was that they had to put their code in escrow.
In both cases, the client was large enough to negotiate those terms. What if you aren't large enough to force those terms?
* That worked out well for me. When the company I worked for went belly up, the client that enforced those terms hired me to complete their system since they had the right to the source code and I was the only person on the planet that was available that knew how both the C based development platform and their implementation worked well enough to complete it.
I work for Booking.com. Amazon entered the hotel reservation business in early 2015 with Amazon Destinations, and then inexplicably shut it down a few months later[1].
At the time there was the expectation that they'd drop commissions to the floor and compete on ultra-thin margins, and there's certainly a lot of room for that in the travel industry.
But they didn't, and then just left within a few months. Weird.
1. https://techcrunch.com/2015/10/14/amazon-shuts-down-its-hote...
At the time there was the expectation that they'd drop commissions to the floor and compete on ultra-thin margins, and there's certainly a lot of room for that in the travel industry.
But they didn't, and then just left within a few months. Weird.
1. https://techcrunch.com/2015/10/14/amazon-shuts-down-its-hote...
Similar situation with Amazon Tickets, they threw money at it, then abruptly stopped. I imagine they do this a lot in a lot of industries to see what sticks.
Don't forget about Amazon Local Register, a common theme among all these failed and summarily canned offerings is Amazon was going up against an industry where the core business was relationship based between vendors and venues/businesses, with small margins after everything is said and done.
Amazon seems not to want to eat its lunch forever outside its artificial book subsidies. If a product isn't net positive within 2 years, its off to the chopping block.
Amazon seems not to want to eat its lunch forever outside its artificial book subsidies. If a product isn't net positive within 2 years, its off to the chopping block.
Pretty sure they did a lot of market research before calling shutting down, most companies make decisions that's align with their goal/aim.
So you're thought is that the market research they had three months prior to shutting down was significantly different than what they had three months later? I'm pretty sure you're not pretty sure of anything here.
But what about the research before creating Amazon Destinations?
Plenty of famous ones also don't, as evidenced by google's umpteen different messaging apps.
I work for an competitor to an AWS product. We've grown rapidly over the past ~7 years in a generally competitive (lots of startups, some really old tough incumbent companies). Without revealing too much on our end, here's some lessons learned:
* AWS is bad at customer service, even for their large or premium customers. If you position yourself, and _seriously_ invest in making your company's culture rooted in exceptional customer service, that's a foothold.
* Don't compete on price. This is hard for most tech startups, as pricing is a very difficult thing to do properly, but resist the urge to drop price to compete. You'll never have the scale, the supply chain masterminds, or the financial modeling to compete with AWS on price, so position yourself as a premium or luxury offering and don't be afraid to price accordingly. If you do the first step properly (a deeply rooted culture of service) you'll be able to justify the price.
* AWS has great uptime, but often the actual operating performance of their service isn't that great, especially when you push the products beyond the 80% use case. They know that for the majority of their customer base, best-in-class performance isn't actually business critical (despite how flashy it sounds). However, there is absolutely a market for people who truly need best in class performance, or product flexibility, or some other best-in-class trait (latency, interaction design, etc.). Find who these people are, and optimize for that ruthlessly. This focus, in combination with the culture of exceptional service and positioning your brand as a premium provider, puts you into a completely different market space than AWS.
* AWS is bad at customer service, even for their large or premium customers. If you position yourself, and _seriously_ invest in making your company's culture rooted in exceptional customer service, that's a foothold.
* Don't compete on price. This is hard for most tech startups, as pricing is a very difficult thing to do properly, but resist the urge to drop price to compete. You'll never have the scale, the supply chain masterminds, or the financial modeling to compete with AWS on price, so position yourself as a premium or luxury offering and don't be afraid to price accordingly. If you do the first step properly (a deeply rooted culture of service) you'll be able to justify the price.
* AWS has great uptime, but often the actual operating performance of their service isn't that great, especially when you push the products beyond the 80% use case. They know that for the majority of their customer base, best-in-class performance isn't actually business critical (despite how flashy it sounds). However, there is absolutely a market for people who truly need best in class performance, or product flexibility, or some other best-in-class trait (latency, interaction design, etc.). Find who these people are, and optimize for that ruthlessly. This focus, in combination with the culture of exceptional service and positioning your brand as a premium provider, puts you into a completely different market space than AWS.
Really? I’ve had better customer experience with AWS than Azure or GCE... Even their SDK devs are responsive, I raised a bug for the SDK for their queues and went to bed, woke up and they had published a new SDK with the fix after 7 hours of raising the ticket...
There is a lot to dislike about AWS but from my experience customer server isn’t one of them...
There is a lot to dislike about AWS but from my experience customer server isn’t one of them...
> better customer experience with AWS than Azure or GCE
Yeah, they're all awful. A comparison might show one is better than another, but it's all a wash when you look at actually good customer service.
A good host has a phone number, you ring it, somebody answers and then they fix your problem, without pinging you around a call centre. You're in and out within 20 minutes.
For AWS (and their class) you submit a ticket and in 4-48 hours, you twiddle your thumbs while the cheapest labour available to Amazon wakes up on the other side of the planet to investigate your problem (also known as walking you through a script).
AWS-sized hosts have advantages but I put a lot of weight in scaling things back to the RackSpace, Linode and Hetzner size operations. They put so much more effort into their human interaction.
Yeah, they're all awful. A comparison might show one is better than another, but it's all a wash when you look at actually good customer service.
A good host has a phone number, you ring it, somebody answers and then they fix your problem, without pinging you around a call centre. You're in and out within 20 minutes.
For AWS (and their class) you submit a ticket and in 4-48 hours, you twiddle your thumbs while the cheapest labour available to Amazon wakes up on the other side of the planet to investigate your problem (also known as walking you through a script).
AWS-sized hosts have advantages but I put a lot of weight in scaling things back to the RackSpace, Linode and Hetzner size operations. They put so much more effort into their human interaction.
I have to say that these days the people on the other side of the planet are getting really good.
As mentioned in another comment, I had an Indian woman answer a non-trivial support ticket and she really was excellent.
She had a breath of knowledge about SQL & SQL Server that I'd hire on the spot.
As mentioned in another comment, I had an Indian woman answer a non-trivial support ticket and she really was excellent.
She had a breath of knowledge about SQL & SQL Server that I'd hire on the spot.
True their support has been quite helpful and pretty amazing. A dev reached out to me days after the issue was resolved for feedback and advice, and it wasn't a cookie cutter template. He actually wrote a 300 word letter to me, including asking for my feedback on a new feature they were working on.
I couldn't believe a company as big as AWS would seek out opinion of some guy just posting on their forum.
I couldn't believe a company as big as AWS would seek out opinion of some guy just posting on their forum.
What was your experience like on Azure and GCE?
Azure had me on the phone within minutes of filing critical issues. Their engineering department provided updates all night.
Amazon issue resolution could be summarized as "won't fix" or "someday/maybe". Their API inconsistencies might be considered a poor developer experience [0].
It's great you like AWS. I do too for some use cases! I disagree their customer service is "better" though.
[0] http://apievangelist.com/2017/01/05/what-i-learned-crafting-...
Azure had me on the phone within minutes of filing critical issues. Their engineering department provided updates all night.
Amazon issue resolution could be summarized as "won't fix" or "someday/maybe". Their API inconsistencies might be considered a poor developer experience [0].
It's great you like AWS. I do too for some use cases! I disagree their customer service is "better" though.
[0] http://apievangelist.com/2017/01/05/what-i-learned-crafting-...
To be honest, all of this depends heavily on the support level and company size as well.
While we had gold support at GCP (initial free offering), we were using one of their beta APIs that wasn't working properly — and within minutes we were talking to one of their Zurich SREs who was top notch and filed an issue that was resolved within a day.
When we scaled down to developer support (and even with a 5 digit infrastructure spend per month), we got delegated to an outsourced first-level support team somewhere in Asia with a complex problem and couldn't get through to anyone who didn't ask the equivalent of "have you tried turning it on and off again?", even after several tries. Eventually we gave up on using IAP completely due to severe bugs. Guess we'll upgrade again soon despite the cost, since the difference was night and day.
Just as a finishing line, the support experience at AWS was always equally mediocre, even in business support.
While we had gold support at GCP (initial free offering), we were using one of their beta APIs that wasn't working properly — and within minutes we were talking to one of their Zurich SREs who was top notch and filed an issue that was resolved within a day.
When we scaled down to developer support (and even with a 5 digit infrastructure spend per month), we got delegated to an outsourced first-level support team somewhere in Asia with a complex problem and couldn't get through to anyone who didn't ask the equivalent of "have you tried turning it on and off again?", even after several tries. Eventually we gave up on using IAP completely due to severe bugs. Guess we'll upgrade again soon despite the cost, since the difference was night and day.
Just as a finishing line, the support experience at AWS was always equally mediocre, even in business support.
Ah their API is far more consistent than Azure. Azure has the worst API of all. But their services are much faster than AWS.
Aws is much more consistent if you know how to use one API then learning a new feature is simple because it’s more or less the same thing (only basing this on .NET and JavaScript SDKs)
Been on Aws for... 6 years now. I was an Azure insider for like 5 years till they discontinued the program and use it for contract work.
GCE I don’t have a lot of experience in but just try to Ensure I know what’s going on incase we need to switch one day or I move to new job.
Aws is much more consistent if you know how to use one API then learning a new feature is simple because it’s more or less the same thing (only basing this on .NET and JavaScript SDKs)
Been on Aws for... 6 years now. I was an Azure insider for like 5 years till they discontinued the program and use it for contract work.
GCE I don’t have a lot of experience in but just try to Ensure I know what’s going on incase we need to switch one day or I move to new job.
We had an instance crash (first time), once we were bestowed the honor of submitting a ticket after an hours of downtime (to which the clock only started an hour after the instance went offline, we were able to solve the issue ourselves, and closed the ticket an hour after submitting it... to which a couple of days later we received a response asking about the issue.
Ah I had that experience on Azure. With aws we have paid support so when we have issues and raise critical tickets they respond in ~20m but azure. When they were still doing sql server as a service I lost access to my database. Support told me there was no problem. The azure insiders forum said others were having issues. The support wouldn’t even acknowledge I couldn’t access the database. 2 days later I finally got access again randomly. I never got a response to why this happened. I’m just Glad this was a non production application for some contract work but they ended up wanting to go aws over the experience.
I Guess at the end of the day we all experience different levels of support from all these providers.
I Guess at the end of the day we all experience different levels of support from all these providers.
I got some support from Azure a few months ago asking about DTU spikes, more of a shot in the dark than hoping for a good answer, but got an extremely good, knowledgeable woman go through it with me within a day. We only spend a few thousand a year at the moment.
I may hate their admin interface, but their support was top notch in my experience.
I may hate their admin interface, but their support was top notch in my experience.
I dunno, that sounds pretty good honestly. The only info I have on AWS's service is testimonials, so I don't have anything concrete.
The industry we obsessively study/studied was hospitality, where service is literally the differentiator between the "pretty good" and the "absolute best in the world," and we've been pretty meticulous about iterating and building upon our service ecosystem (it's way beyond just one team at this point) like one might do with a software product. Most of our customers, from the small ones in the early days to the huge internet juggernauts we've had the privilege to work with use us as the standard to which all other vendors are measured, sometimes quite literally in a very odd way. So, I don't know if we got lucky with some stinker incumbents, or we stumbled on to something completely different, but we've got a good system in place that's built a pretty solid competitive moat.
I guess if folks on the thread are still reading and interested in replicating this at their startups, my advice is: study elite hospitality and restaurants, not tech. I'm very rarely impressed with the service ecosystem in the tech world, though it happens, but I can learn something massive every day from hospitality.
The industry we obsessively study/studied was hospitality, where service is literally the differentiator between the "pretty good" and the "absolute best in the world," and we've been pretty meticulous about iterating and building upon our service ecosystem (it's way beyond just one team at this point) like one might do with a software product. Most of our customers, from the small ones in the early days to the huge internet juggernauts we've had the privilege to work with use us as the standard to which all other vendors are measured, sometimes quite literally in a very odd way. So, I don't know if we got lucky with some stinker incumbents, or we stumbled on to something completely different, but we've got a good system in place that's built a pretty solid competitive moat.
I guess if folks on the thread are still reading and interested in replicating this at their startups, my advice is: study elite hospitality and restaurants, not tech. I'm very rarely impressed with the service ecosystem in the tech world, though it happens, but I can learn something massive every day from hospitality.
Somewhat of a counterpoint, though with a huge caveat because I was just a grunt:
I used to work at Etsy, and Amazon launched a competing product in 2015. Cue the frenzy about Etsy's imminent doom. Hasn't happened yet.
Etsy's gone through troubles, obviously, but while I was there at least the general feeling/consensus was that Shopify is by far a bigger threat than Amazon. It's incredibly unclear, at best, whether Amazon has siphoned off any appreciable part of Etsy's market.
Different products and spaces, obviously, but just a reminder that Amazon doesn't get it right 100% of the time (see also: fire phone).
Also worth noting that SES hasn't put Mailgun/etc. out of business completely (though that's a bit of a stretch of a comparison, I'll admit).
I used to work at Etsy, and Amazon launched a competing product in 2015. Cue the frenzy about Etsy's imminent doom. Hasn't happened yet.
Etsy's gone through troubles, obviously, but while I was there at least the general feeling/consensus was that Shopify is by far a bigger threat than Amazon. It's incredibly unclear, at best, whether Amazon has siphoned off any appreciable part of Etsy's market.
Different products and spaces, obviously, but just a reminder that Amazon doesn't get it right 100% of the time (see also: fire phone).
Also worth noting that SES hasn't put Mailgun/etc. out of business completely (though that's a bit of a stretch of a comparison, I'll admit).
Etsy's biggest threat seems to be themselves really (which pushes people to things like Shopify).
Also not surprised that Amazon hasn't made much of a dent for them: Amazon site isn't all that good for actual browsing and tries to diminish seller identity.
Also not surprised that Amazon hasn't made much of a dent for them: Amazon site isn't all that good for actual browsing and tries to diminish seller identity.
I wasnt the owner of the business but I worked for an "email infrastructure" company (think Sendgrid but not US based). When amazon launched its SES offer, things started to get pretty grim.
- Their infrastructure was better (stable)
- Their price was much, much lower (pricing)
- They are Amazon and they're global. (company image & trustworthiness)
Going to meetups and developer conferences people would always ask "why not use SES haha it's a no brainer" Pricing yourself in between Mailchimp and SES was a good fight and ultimately it did help convert a lot of "Mailchimp" affectionados.
Luckily getting emails delivered in the inbox of your customers is a bit like dark-magic - there are a lot of factors that a regular joe wouldn't consider, and because email marketing is still one of the best channels with the highest ROI ever - companies really care about setting up their email campaigns with companies that know all of the tricks and rules to optimize campaigns and ensure maximum open and ctr rates. Another thing: Data protection laws in US and EU are different, the company had the advantage of having datacenters exclusively for EU customers (where more rigid rules were applied) and then all the others...
The business focused on creating frictionless experience with stellar customer support (24/7) and also worked a lot on its dev-first marketing approach (im talking about developer experience, plugins, wrappers, integrations etc). One of the advantages of owning your own infrastructure and whole stack is that you can build and configure your product to fit every client's need. Something that Amazon has never managed to deliver out of the box - especially because email is a tool used by developers and marketers at the same time. It's really hard to make marketers happy!
The business is still around today, I learned a lot but I ultimately moved on because like I told my friends "email isn't sexy" Email is painful, email is great.
- Their infrastructure was better (stable)
- Their price was much, much lower (pricing)
- They are Amazon and they're global. (company image & trustworthiness)
Going to meetups and developer conferences people would always ask "why not use SES haha it's a no brainer" Pricing yourself in between Mailchimp and SES was a good fight and ultimately it did help convert a lot of "Mailchimp" affectionados.
Luckily getting emails delivered in the inbox of your customers is a bit like dark-magic - there are a lot of factors that a regular joe wouldn't consider, and because email marketing is still one of the best channels with the highest ROI ever - companies really care about setting up their email campaigns with companies that know all of the tricks and rules to optimize campaigns and ensure maximum open and ctr rates. Another thing: Data protection laws in US and EU are different, the company had the advantage of having datacenters exclusively for EU customers (where more rigid rules were applied) and then all the others...
The business focused on creating frictionless experience with stellar customer support (24/7) and also worked a lot on its dev-first marketing approach (im talking about developer experience, plugins, wrappers, integrations etc). One of the advantages of owning your own infrastructure and whole stack is that you can build and configure your product to fit every client's need. Something that Amazon has never managed to deliver out of the box - especially because email is a tool used by developers and marketers at the same time. It's really hard to make marketers happy!
The business is still around today, I learned a lot but I ultimately moved on because like I told my friends "email isn't sexy" Email is painful, email is great.
This is a great example of excellent product strategy, these are all points AWS are unlikely to compete on. Great to hear that they’re still in business
I worked as a strategy guy in the same space as AWS. In my opinion, you don't. You look at what they are doing in the market, and you decide how you fit in around them, there is typically a pretty decent business there, AWS is a great for wake building, developer first is key. :)
I consult or have consulted multiple tech startups that suddenly found themselves competing against an AWS service like CloudWatch, Glue, Sagemaker, and so on.
In every one of those cases, nothing bad happened. Here's why:
- These AWS products are more like single-purpose utilities than complete solutions. They cover just the basic use cases. If your competing product is also single-purpose then yes, you should be worried. But if you're selling a platform, suite, or an enterprise product (like the companies I work with), then you're probably fine.
- These products are meant to plug into a developer's workflow, like one piece of a larger puzzle. That means requiring technical expertise. If your product is used by both practitioners and managers then you're fine.
- AWS tools are for AWS users. Does your product support Google Cloud and/or Azure?
- AWS products are provided "as is." Most users will have little to no input into the product roadmap and have little hope for getting their feature requests fulfilled. As a (presumably) smaller company, your agility and ability to implement customer feedback is an advantage.
There's more to say on this but the tl;dr is don't worry. For every utility product AWS offers, there are dozens of alternative solutions that are thriving.
Edit to clarify my statement and to reconcile with the other stories where companies were pushed out of the market by AWS: If you're selling infrastructure such as email servers, data storage of any kind, etc, then yes you should be worried if AWS moves in. Doesn't mean AWS will win by default (see: Snowflake vs Redshift), but the amount of resources Amazon puts behind those things is significantly greater than their add-on solutions. With that said, even a company the size of Amazon can't grab an entire market immediately; there's plenty of business to be won by both sides if you play things right... That's what makes it fun!
In every one of those cases, nothing bad happened. Here's why:
- These AWS products are more like single-purpose utilities than complete solutions. They cover just the basic use cases. If your competing product is also single-purpose then yes, you should be worried. But if you're selling a platform, suite, or an enterprise product (like the companies I work with), then you're probably fine.
- These products are meant to plug into a developer's workflow, like one piece of a larger puzzle. That means requiring technical expertise. If your product is used by both practitioners and managers then you're fine.
- AWS tools are for AWS users. Does your product support Google Cloud and/or Azure?
- AWS products are provided "as is." Most users will have little to no input into the product roadmap and have little hope for getting their feature requests fulfilled. As a (presumably) smaller company, your agility and ability to implement customer feedback is an advantage.
There's more to say on this but the tl;dr is don't worry. For every utility product AWS offers, there are dozens of alternative solutions that are thriving.
Edit to clarify my statement and to reconcile with the other stories where companies were pushed out of the market by AWS: If you're selling infrastructure such as email servers, data storage of any kind, etc, then yes you should be worried if AWS moves in. Doesn't mean AWS will win by default (see: Snowflake vs Redshift), but the amount of resources Amazon puts behind those things is significantly greater than their add-on solutions. With that said, even a company the size of Amazon can't grab an entire market immediately; there's plenty of business to be won by both sides if you play things right... That's what makes it fun!
To support your argument, cloudwatch is not a product.
It's just a bunch of API to retrieve AWS metrics. It is integrated into third party products that do amazing things with it and other sources.
It's just a bunch of API to retrieve AWS metrics. It is integrated into third party products that do amazing things with it and other sources.
tech_man7(1)
I've never been hit by it personally, but I know two people from different companies that found themselves in the same situation.
The first went through the stages of grief, and "acceptance" meant shutting down. The second company had the option to pivot and focus on a specific feature that AWS lacked, but the company decided against that plan. According to my friend over there, management is still in denial over the severity of the threat. He's looking for other work, and so are most of his co-workers.
Unfortunately, this is not good news. On the plus side, you're cognisant of what you're facing, which means you can start looking for ways to pivot. Failing that, you can decide to bail before things become critical.
I'm really sorry to hear you're in this situation. For what it's worth, you're in good company.
The first went through the stages of grief, and "acceptance" meant shutting down. The second company had the option to pivot and focus on a specific feature that AWS lacked, but the company decided against that plan. According to my friend over there, management is still in denial over the severity of the threat. He's looking for other work, and so are most of his co-workers.
Unfortunately, this is not good news. On the plus side, you're cognisant of what you're facing, which means you can start looking for ways to pivot. Failing that, you can decide to bail before things become critical.
I'm really sorry to hear you're in this situation. For what it's worth, you're in good company.
It's a different business, but Instacart recently had to deal with Amazon offering home grocery delivery. According to [0] it's working out because every other grocery chain realized they needed same-day home delivery in order to not get killed by Amazon, and they mostly went with Instacart.
By analogy, your strategy could be to provide the service for every other cloud provider. They watched the AWS conference too, and don't want to be left behind on any features.
[0] https://www.forbes.com/sites/bizcarson/2017/11/08/amazon-who...
By analogy, your strategy could be to provide the service for every other cloud provider. They watched the AWS conference too, and don't want to be left behind on any features.
[0] https://www.forbes.com/sites/bizcarson/2017/11/08/amazon-who...
I have mixed feelings when reading these stories. I believe that a lot of competition and innovation is needed in our industry and whenever I see a service throw in the towel because of AWS, I cant help but feel that my future is threatened.
From my perspective, it's the smaller companies that pose the biggest threat to AWS/Amazon because they are able to satisfy their customer's needs far better and faster.
From my perspective, it's the smaller companies that pose the biggest threat to AWS/Amazon because they are able to satisfy their customer's needs far better and faster.
I remember in the first decade of this century and everyone was afraid of Wal Mart killing small business (and in some ways it did)- but now look at Wal-Mart...
I don't like Amazon on a philosophical basis- the same reason I don't like Wal-Mart, and Amazon is just the Wal-Mart of everything. Hopefully someone comes to their senses and breaks up companies who are able to use profits from various subsidiaries to undercut competitors in others.
I don't like Amazon on a philosophical basis- the same reason I don't like Wal-Mart, and Amazon is just the Wal-Mart of everything. Hopefully someone comes to their senses and breaks up companies who are able to use profits from various subsidiaries to undercut competitors in others.
There’s really only one AWS product you wouldn’t want to compete with, and that’s EC2 (and possibly S3). Mostly every other AWS product you can build a better or more niche alternative at a higher price point and still get business.
I admittedly haven't looked into this as in depth as I would like to, but I recall being surprised by Digital Ocean's "Droplets" (similar to Amazon EC2) being far cheaper[0]
[0]: https://www.digitalocean.com/pricing/
[0]: https://www.digitalocean.com/pricing/
DigitalOcean is not comparable to EC2 unless you are literally-literally only using compute. The second you want a network that is private to you or any sort of hosted solutions for stuff like SQL databases, DigitalOcean folds.
I use AWS despite the (moderate, and with reserved instances largely nonexistent) premium on compute because of everything else that's right there.
I use AWS despite the (moderate, and with reserved instances largely nonexistent) premium on compute because of everything else that's right there.
Yeah, I'm not clear on that either. I know you can set up servers with different IPs on DO to talk with each other and from there "privacy" is a matter of configuration. Seems like UFW would be a tool to use for that.
But I am not a "network specialist" and I've never even looked at AWS so there's bound to be lot I don't know in this arena.
But I am not a "network specialist" and I've never even looked at AWS so there's bound to be lot I don't know in this arena.
In my experience non-cloud networks run by professionals rarely use compute-side firewalls in general, and VPC is a powerful analogue for this. AWS VPC and security groups expose the entirety of your network configuration in a single location with easy ways to visualize it and manipulate it. They are also a lot easier for someone who is not a network specialist to correctly work with; "only allow network access over port X from machines tagged with security group A" is trivial (using an additional layer atop VPC's lower-level subnet/route table/gateway primitives).
I don't remember the last time I configured a compute-side firewall, whether in a cloud environment, a physical network environment, or in my home (my router does VLANs and allows rules between them).
I don't remember the last time I configured a compute-side firewall, whether in a cloud environment, a physical network environment, or in my home (my router does VLANs and allows rules between them).
> The second you want a network that is private to you or any sort of hosted solutions for stuff like SQL databases, DigitalOcean folds.
Can you explain what you mean by this?
Can you explain what you mean by this?
EC2 has VPC, a software-defined networking solution with route tables, subnetting, ACLs, the nice abstraction of security groups, and (importantly) the ability to peer separate VPCs, across multiple accounts.
DigitalOcean does not have VPC; they've had a backplane of "private network IPs" isolated merely to all DigitalOcean customers. This month they instead changed their underlying system behavior (WTF) to isolate their private IPs to your account. So they also just broke that for their customers. On top of that--can you firewall/segment off that private network to certain machines? Nah. Can you talk to other customers' machines over this private network. Nah. It's a bad, partial solution for limited use cases.
AWS also has a managed solution for MariaDB, MySQL, Oracle, Postgres, and MS SQL. DigitalOcean has an emoji shrug.
DigitalOcean does not have VPC; they've had a backplane of "private network IPs" isolated merely to all DigitalOcean customers. This month they instead changed their underlying system behavior (WTF) to isolate their private IPs to your account. So they also just broke that for their customers. On top of that--can you firewall/segment off that private network to certain machines? Nah. Can you talk to other customers' machines over this private network. Nah. It's a bad, partial solution for limited use cases.
AWS also has a managed solution for MariaDB, MySQL, Oracle, Postgres, and MS SQL. DigitalOcean has an emoji shrug.
AWS launched mobile analytics a few years back: https://aws.amazon.com/mobileanalytics/. I've literally never heard of a customer even considering it, despite the fact that their free tier could accommodate 99% of companies. If you're not selling a commodity, don't be too worried unless AWS considers it a core part of their strategy.
This question could be much wider in scope than AWS, so I'm surprised we don't have a wider variety of responses that touch upon everyday B2C ... bookstores (vs the original Amazon), shoe stores (vs zappos), home services (vs Amazon's task rabbit like service) etc. (Yes, I know this is hackernews!)
For my contribution, we're working on something where we expect AMZN to go far deeper into in the not so distant future: furniture. We're "safe" now because AMZN doesn't let you touch, feel and smell their offerings. That clearly could change if they continue to expand their physical retail footprint.
AMZN's impact on us: TBD. We think they may disappoint a lot of consumers. We focus on vintage and artisan furniture to cater to those that will want more variety and character.
https://attic.city
For my contribution, we're working on something where we expect AMZN to go far deeper into in the not so distant future: furniture. We're "safe" now because AMZN doesn't let you touch, feel and smell their offerings. That clearly could change if they continue to expand their physical retail footprint.
AMZN's impact on us: TBD. We think they may disappoint a lot of consumers. We focus on vintage and artisan furniture to cater to those that will want more variety and character.
https://attic.city
[deleted]
AMZN in IKEA space, that would be an interesting battle.
If you stay on your toes and keep growing they will buy you. Then they will slowly chip away at it until they can delete it and replace it. CreateSpace vs KindleDirect being a prime example.
Direct to China sales increased, without clear guidance to consumers on the resulting decrease in shipping times and actual support. I can't tell yet the market effect. That is, if end buyers like the lower prices enough to offset the lower level of support, refunds, tech support, etc.
Chinese sellers actively avoid personalized support, refunds and compensation. But they sell at much lower initial pricing. It's hard to tell, for now, what the buyers value.
Chinese sellers actively avoid personalized support, refunds and compensation. But they sell at much lower initial pricing. It's hard to tell, for now, what the buyers value.
We have a personal experience to share. Posting from a throwaway account for obvious reasons. We have a product in aws marketplace with decent traction. We have also gone jointly with aws for some big opportunities in government space. They have started thier own competing product in the same space and started sabotaging our joint opportunities with large customers. AWS marketplace is a big idea engine for them to identify profitable opportunities and copy the products ruthlessly. Our stomach twiches as they copy every one of our features including the UI.
It is unfair for startups but i guess that is business. I think dropbox moved away from them for right reasons.
Think twice before listing your products in aws marketplace. You will be thier next victim if you become profitable. AWS for startups is the biggest joke of our time.
It is unfair for startups but i guess that is business. I think dropbox moved away from them for right reasons.
Think twice before listing your products in aws marketplace. You will be thier next victim if you become profitable. AWS for startups is the biggest joke of our time.
I've heard stories of this happening on the retail side. They monitor what products third parties are selling well, then start selling it directly themselves.
Does Amazon use tenant metrics in order to set product strategy (decide which AWS customers to attack)?
I don't have a personal story, but I wrote an article about AWS competing with its own customers a while back: https://www.inc.com/sonya-mann/aws-startups-conflict.html
...and I've heard rumors off-the-record that I wish I could share right now. It's a serious concern for anyone making devtools.
...and I've heard rumors off-the-record that I wish I could share right now. It's a serious concern for anyone making devtools.