The 'API marketplace' and 'API economy' narratives are largely pushed by companies who make API proxies: Mashape, Mulesoft, etc. (EDIT: not Mashable, they're unrelated)
I've yet to hear true success stories in this space; to me it just seems like wishful thinking (on part of the marketplace and on part of API developers) about a second app boom; notably, in the hype cycle, the API boom has largely been superseded by the Chatbot boom, which is functionally very similar, although the gatekeepers are different.
That is not to say you can't make money this way. Perhaps it's useful for hobbyist-level projects, or cut-from-the-same-cloth wrapper APIs that hardly offer anything unique but at least one sucker signs up anyway -- the same as with apps, really. Is this actually a thriving market?
There was a subthread on HN not too long ago from a guy who quit his day job to scale ipinfo.io, which sells an API subscription product for geoIP lookups. He's doing fairly well.
So I think there is a market for services like this, especially since API Gateway takes away a lot of the kinds of scaling headaches the creator talks about in the linked post.
We've been using the Azure API Management on my team for well over a year now on a couple projects. Though monetizing it is still just a goal, it's been pretty useful just for the features auth, logging, CORS, and some routing issues.
I can see how this market has a BS feel to it (and have noticed this too lately), but at least the general concept of "API" leaves a lot of room for interpretation... perhaps much more functionality can be exposed via an API on such a marketplace than could ever be offered by an "app", etc.
My impression is that it's not a big thing yet because many of the tools really don't support monetization any too well right now (I'd be interested in hearing counter-examples). That said, once the tooling catches up, it will be interesting to see if it actually takes off or not.
Yeah, it's a huge huge market for sure. It's why pretty much every Web APP provides an API to integrate with. They don't do it because it's worthless :)
API Marketplace might help discovery. Not sure about that though.
Need a US bank account to sell [1]. Not quite as restrictive as devpay's requirement for a US legal entity, but still a hassle. I think I'll stick with a free AMI and stripe/quaderno for payments/VAT for license keys to unlock premium features.
There are companies like World First[0] who work with Amazon resellers to repatriate funds for people who sell through Amazon. They set up a virtual bank account for the resellers. I think they would enable this type of business.
Despite all the complaints and open letters about Amazon's horrible work culture and bad organization, they seemed to be building great products at an amazing pace. I read somewhere that AWS deployed 1000 new features to production every week. Whatever they're doing, it seems to be working. My only complaint is that most of their UI interfaces feel like Web 1.0
Amazon's store frontend interfaces are A/B tested. Their backend stuff for developers---not so much.
The look and feel of the Amazon store looks 'web 1.0' because it has high information density, and less white space. Current web fashion is to have minimalist design with lots of white space, but that fashion not UX.
As a UX example, Amazon's store follows pretty standard practices---tables for tabular data, cards for related items that will be skimmed, vertical scrolling to support long item lists without changing the layout on browser resolution, consistent sizing/spacing/coloring for headers, control locality so clicking a button changes information near by it.
It does all of the things you'd expect a regular web app to do, but sprays it over a long-form page instead of burying it in tabs increasing scroll distance via whitespace.
Where Amazon fails is niches. Their interface is generalist, so they don't have great UX for buying clothes, or buying groceries (albeit no one really has a great interface for that).
Minimalist design is not even remotely about fashion. At least not as applied to UX and conversion flow. It's about intuition vs cognition. Amazon is blind to how extraordinarily bad their UI is probably because they are putting too much value into A/B testing and/or leadership has a belief that "everything at once" is some how more helpful to users then a directed flow.
A/B testing is a very useful tool for a very constrained problem of comparing two or more alternatives of the same thing. It cannot tell you which overall UX approach is more effective. Good minimalist design is about creating user flow which often consists of multiple simple steps. Each step avoiding cognitive overload by maintaining a context and limiting the current scope.
Actually these multiple steps happen on complex pages too. The difference is that on complex pages the user gets no help from the UX to accomplish their goal. It needn't be fashionable, it needs to be functional not in the theoretical sense, but in the actual sense accounting for real user behavior.
Amazon and people who mistakenly believe that "information density" is necessarily good, often not true, and that a "lot of words" == "information density" which is also often not true fail to realize that following a link or scrolling a pages is actually less difficult then visually searching a cluttered information scape.
Even users who do not become frustrated by the UI will 'pre-filter' it once they figure out how to do the one thing they want. This has the effect of making most of the interface invisible to then from that point on. It's like driving to work, they will tune out all the visual noise around them after the first few trips. So at best the information density has no value because it is ignored, and at worst, it's adding a heavy friction to conversion.
It's bad, pre design 101 bad. Amazon only gets away with it because they already won the market long ago.
„...because it has high information density...“ +1!! If you look at the Sellercentral backend (for sellers on Amazon) it is breathtaking what kind of Analytics, inventory reports, etc you can generate.
Would love to have this kind of level of information in an external (own) ecommerce-shop/system.
> buying groceries (albeit no one really has a great interface for that).
VR Grocery Store please. Let me walk around the store in my home and let me browse the grocery aisles. Make the VR experience 'live' by using the in-store security cameras to construct the VR environment and in-store data like real-time inventory counts.
Which makes me certainly wonder about what assumptions I am making about the general computing public that are obviously false. I assume that Amazon's pages are probably some of the most optimized and A/B tested in the world. If their interfaces feel sooo Web 1.0, I can only imagine it is like that because of extensive and exhaustive testing and metrics analysis. What lessons can this teach to the rest of us, who don't have the infrastructure or user-base to do the kind of testing that they do?
>What lessons can this teach to the rest of us, who don't have the infrastructure or user-base to do the kind of testing that they do?
Probably a lot. I've worked with embarrassingly bad looking websites that were making millions of dollars in revenue, only to see it drop off a cliff after a "modern" redesign. The truth is that the general public sees a much different thing as they browse the web than we do. Things like legibility, simplicity, and speed are far more important than advanced features.
A couple years ago, my employer redesigned their credit card page from a slightly cluttered, clunky design to a cleaner, more modern version. Nothing fancy, certainly nothing heavy, just your typical Web 1.0 -> 2.0 CSS adjustment.
Payments plummeted by 5-10%. Didn't understand it. Reverted the change, and still have Web 1.0 UI to this day.
I think Amazon.com is heavily tested, not so sure about AWS. I'm happy that it's Web 1.0 (i.e. fast), but it often seems as new functions were just added to existing design. Some pages might need reorganization/redesign to make them a bit less complicated to use.
The problem is that people often associate a redesign with switching to SPA. Which I really hope they won't do.
Fast? I guess the initial render for everything on the AWS console is fast and the new landing page is much nicer to look at, but many of the APIs take forever and all of the product specific pages still have a Web 1.0 UI.
Then we're talking about different pages. The ones that load forever are not Web 1.0 for me. Web 1.0 is pure HTML with little JavaScript. They load fast. What takes forever are the new, fancy JS pages, which are probably Web 3.0 (or where ever we are now).
It's still faster than most SPAs, just very complicated.
I think you're falling into the hole of thinking the web interface is the business. I don't shop at Amazon because I like their website, I do it because Prime allows me reliable free 2-day shipping, because camelcamelcamel provides an accurate price history, because I believe in the customer service, and because I can usually find what I'm looking for.
Now they opened a warehouse nearby I can order something in the morning and have it in the afternoon.
Amazon is a logistics company with a web frontend, that frontend isn't nearly the most important part of their business. Their recommendations are awful, their site is clunky and difficult (try to, say, price compare the per-battery price on CR123A batteries for a frustrating afternoon) and doesn't do classes or categories well at all.
The point I'm trying to make is they've got a lot going for them that isn't their website and most of that is why they're popular.
AWS is a very specific business unit within the company and from my friends that work there seems to have a very different culture than Amazon (retail) proper.
Yes their dev/release cycles are quite impressive.
That makes Web 1.0 sound bad. AWS seems to be using Angular and is full of UI quirks and bugs that would have been impossible without JS. HTML forms work predictably, reliably, and with a high degree of affordance.
You could say this about a lot of businesses; AAA game companies, supermarkets etc all can have horrible work culture. But when you are spending millions, and can hire as many people as you want, and work them hard, results will come.
Slightly away from topic, but my new burn is "this is so web 2.0." Because that was like 10 years ago. Personally, I think AWS feels pretty "now" with UX only a developer could love (said as a sometime developer).
I'd rather they had a better work culture and deployed less than "1000 new features every week", in the same way I don't care for cheap sneakers made in sweatshops.
People get into abusive contracts and stay with them for all shorts of reasons.
Most abused spouses are not literally helpless either. They are physically able to go to the police, break the relationship, fight back, etc, but human needs and psychology are not black and white.
And of course just because they decided to "put up with it" or the extra compensation makes it justified for them, doesn't mean the abuse isn't there.
If someone gives a huge tip, it doesn't mean it's OK for them to mistreat the waiter. It just makes them more of a jerk.
Does Amazon have contracts that tie people to their jobs? Can't people simply leave at will?
> Most abused spouses are not literally helpless either.
This is a good comparison actually. Many people continue to work for an employer long after the good times have passed, because they feel loyalty towards them or don't want to admit to making a poor decision in the past, or there is social stigma against leaving.
That said... Amazon is well reknowned for having poor workplace practices, so anyone joining them today should be going in with their eyes wide open, and stigma against leaving Amazon ought to be widely lowered.
Im actually not sure how this interacts with visas -- can visa employees freely leave without having to leave the country as well?
It's anecdata, but when I interviewed with Amazon, not a single person born in the US interviewed me. (Which seems suspicious, that none of 7 people were from the US.)
I've suspected that tech companies use visas to permit such toxic practices because foreign workers don't have the same negotiating position.
All metaphors are a stretch. If they were absolutely analogous to the original there wouldn't be metaphors in the first place.
Something doesn't have to be of equal value or importance to the thing its a metaphor for, just to convey the mechanics of the thing. It doesn't even have to convey the full thing, just the part the metaphor is intended for.
In other words, one can use e.g. the Cold War as a metaphor for some office turf situation, even if the Cold War has millions of victims in proxy wars and could potentially have meant the end of the world, whereas office politics are much more inconsequential.
Much of their features come out from requests of existing customers; they know that ~someone~ cares about it, because someone who is already giving them money has asked for it. As they add those, other people will also use it, as needed. They expand the feature set for anyone evaluating them, as well as help lock in existing customers.
The API gateway seems quite expensive to me. I guess it has its use cases and mine doesn't fit into it.
I run a free API www.macvendors.com that handles around 225 million requests per month. It's super simple and has no authentiction or anything, but I'm also able to run it on a $20/m VPS. Looks like API gateway would be $750+data. Bummer because the ecosystem around it looks great. You certainly pay for it though!
It's a steal for mediocre organizations where traditional development of even a simple proxy to some other AWS service would be a couple months' planning and launch late with show-stopping bugs, eating a couple man-months total before reaching stability and ultimately serving only a few thousand requests before getting shelved.
In circumstances like these, I've estimated per-request costs of systems at tens of dollars.
you should definitely look at Kong[1] - they have an opensource API Management tool. They do have their own commercial product Mashape[2] whose pricing is $250 plus 20% of the API Revenue[3] and they have one more option called Gelato[4] that provides Kong Integration
From a load perspective, if the request pattern is even, 225 million req/month are only about 85 req/s (assuming ~730hrs/mo). Any $5/mo VPS running even a very heavy and suboptimal web framework can handle that.
It's likely more spikey than that (i.e., peak/off-peak times), but certain server-to-server loads have a very consistent load pattern. (For example, at Userify[1] - SSH key management -- servers check for updates every 90 seconds or so or 10 seconds for premium plans or self hosted, so the load pattern is literally a flat line.. extremely predictable. We'll probably switch over clients that can handle it to websockets and maybe hashed etags and cut that load pattern into oblivion, but for now it works and is simple/auditable code/extremely reliable, which is a very important factor in our case.)
To GP's point, spiraling costs are definitely a factor with most of Amazon's services such as DynamoDB and especially Lambda... they are sometimes an effective use of devtime, especially in the beginning of a project (and when dealing with a mature platform like DynamoDB and maybe not so much Lambda), but you have to carefully consider the cost factor as you scale. For example, Lambda is often literally several orders of magnitude[2] more expensive than an equivalent ELB. (i.e., it can be more than 100x more expensive.. for small scale or maintenance tasks, that may not matter.. for a heavy/core service, it definitely matters!) So, as they taught us in AWS SA, design for cost: use the more advanced services when it makes sense, but optimize across all axes, not just devtime.
hmm interesting. I guess I haven't really thought of this from cost point of view. It is nice knowing that I can have a Flask endpoint up on AWS Lambda + API Gateway that can scale using only my credit card. That peace of mind, once you write a code you won't have to worry about scaling seems like a pretty good deal and should carry a premium.
I'd be happy to have 85req/s hopefully by then I'd be charging lot of money.
Exactly - and don't forget about things like Elastic Beanstalk as you grow. Those automate even the setup of things like the ELB/ALB etc, trading a higher fixed monthly cost for a lower cost per transaction. Still, if your business model supports it and if it ain't broke, just leave it where it is... AWS does give you many good choices.
Handling the spikes is the tricky part. People apparently like to run cron jobs on the hour so a few times a day I need to handle up to around 1200 req/s
Just made sure it was fast enough to handle it. I have benchmarked it and it should be able to do close to 2250 req/sec. After that I'll have to drop a load balancer in front I guess.
It used to run in PHP/redis but when the load got too high I rewrote the server in GO. No database needed as the server downloads and loads the files in memory.
Teams targeting this capability ought to consider how much specific information Amazon would be able to derive: utilization and revenue growth rates. We've seen platform providers crowd out existing solutions on their platforms when a particular product becomes popular -- Twitter, and their treatment of developers on it's platform, is a classic example.
Through the lens of Twitter, AWS seems to be creating for itself the opportunity to benefit from this sort of third-party R&D on a massive scale.
On the other hand, on Amazon scale you cat probably get pretty good idea about trending API services by just looking at the AWS DNS statistics (and/or some network level metrics) and Amazon Alexa stats.
"Accountant as a service. Free. Works worldwide. Select in which country you want to create your company: ..." would be a great value proposition for AWS startups ;) "We don't sell your data", it says, "we... only... use it internally."
I use Mashape for monetizing an API. They have great customer service, but it seems like their marketplace hasn't gotten a lot of love in the last few years. Instead they seem to be focused on other things, like Kong.
I do however, think my customers prefer monthly plans instead of a strict per usage billing. It also helps me predict growth in advance.
And why wouldn't they? It clearly hasn't stopped sellers. Amazon has them do all the market research on their dime. Amazon then gets all the data to decide what to launch next to improve their margins, and they get paid for the privilege.
I can't say I blame them, but I can't say it does much for my trust in them either.
I think this is a great opportunity for back-end developers who lack full-stack skills or don't have a front-end sidekick to produce valuable software.
Unfortunately, just like the app store, you would still suffer from discovery issues so the developer must also think about upping their marketing game.
Very excited about this new development from Amazon though!
> Unfortunately, just like the app store, you would still suffer from discovery issues
To some degree certainly quite likely, but personally I don't think it'd be as pronounced in such b2b / dev2dev contexts as it would be on today's b2c app stores, to the (hard to quantify/guesstimate) degree that users in the former more carefully scrutinize more offerings and contrast them with their actual requirements.
I highly recommend visiting 21.co. They develop for some time technology to easily charge/collect/pay bitcoin on every HTTP request in the 21 Marketplace.
They have cool (afaik opensource) technology using standard HTTP Response 402 "Payment Required" - yeah, there is such thing :)
I think this is a great new addition to AWS. Amazon's pace of releasing new things is just astounding.
As an API provider I'm pretty excited to find out how this works and whether the AWS marketplace is really ready for 3rd party services.
Having tried mashape a couple of months ago I like the idea but found their implementation a bit cumbersome and confusing. I hope Amazon's approach will be simpler.
The "per request" model is seriously limiting. I work in the mobile app machine learning/analytics space and per Monthly Active User makes a lot more sense for that market.
Or use 3scale or WSO2?
I understand, pricing point of view, amazon will be 10 times or more cheaper. But level of effort required and limited features set, you have to decide what you are trying to do with your time & skills.
Excuse my ignorance, can you tell me an example of a what kind of API would someone sell and someone else buy and why? I just don't understand what is the business model here. Thanks.
AWS itself is a great example: Most Amazon Web Services (e.g. S3, EC2) can be controlled and accessed via APIs, and Amazon charges for that API access. Here's a more concrete example --- the pricing page for Amazon DynamoDB:
Would be interesting if they enabled integration with Ethereum for API monetizing. But that is probably unlikely as they would go against their own payment platform.
What are the advantages of using AWS over selling the API yourself? I can think of a few:
* AWS handles the billing software for you.
* AWS markets to enterprise companies who already have billing integrated and pay a lot of money. So less hassle collecting payment, and less resistance to charging lots.
* You get the AWS brand associated with your API, so people may be more likely to trust it.
The main reason I can think of is, if you make an API that you think will handle 100/s but the product takes off and you end up with 1,000,000/s, you don't have to do anything.
The idea should be that you don't have to reinvent how to authenticate users (client developer and end user), apply different quotas, charge money, detect abuse, log any of that, nor a number of other things that are common to all APIs.
Not sure how much of that does Amazon accomplish, nor to what success.
I don't know Amazon's solution, but an API Gateway in general helps you abstract public and private APIs from each other. You can change your internal processes without affecting your external APIs, in addition to not having to build authorization, monitoring, etc. into every API separately.
Assuming an AWS hosted service would save both the buyer and seller the egress charges, that's probably the killer use case. Captive gardens like to grow.
The uptake on this will be dependent on how comfortable developers feel about building completely off AWS's infra.
I'm optimistic about such an approach -- a lot of infra effort (maintaining servers & service/marketing) is expended innumerable times across all SaaS services/APIs.
I believe convenience may be a huge argument for a lot of ppl. Paying to new provider takes a lot of resources, while using yet another AWS like api is easier.
sounds like this will put the nail in mashape's coffin. not sure why this is downvoted, mashape's marketplace has been dead for quite some time, there are no buyers.
I've yet to hear true success stories in this space; to me it just seems like wishful thinking (on part of the marketplace and on part of API developers) about a second app boom; notably, in the hype cycle, the API boom has largely been superseded by the Chatbot boom, which is functionally very similar, although the gatekeepers are different.
That is not to say you can't make money this way. Perhaps it's useful for hobbyist-level projects, or cut-from-the-same-cloth wrapper APIs that hardly offer anything unique but at least one sucker signs up anyway -- the same as with apps, really. Is this actually a thriving market?