* 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.
There is a lot to dislike about AWS but from my experience customer server isn’t one of them...
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-...
I Guess at the end of the day we all experience different levels of support from all these providers.
I may hate their admin interface, but their support was top notch in my experience.
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.
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.
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.
I couldn't believe a company as big as AWS would seek out opinion of some guy just posting on their forum.
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.
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.
- 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.
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...
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. :(
So much value that things went wrong and now you're explaining yourself.
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.
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 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.
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?
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.
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 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.
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...
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.
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.
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.
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.
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 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).
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.
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.
I use AWS despite the (moderate, and with reserved instances largely nonexistent) premium on compute because of everything else that's right there.
Can you explain what you mean by this?
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.
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.
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).
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.
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.
NET::ERR_CERT_AUTHORITY_INVALID Subject: www.s3stat.com
[0]: http://www.smallgiantsbook.com/ [1]: http://kk.org/thetechnium/1000-true-fans/
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!
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.
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.
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.
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.
...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.
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 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.