“When looking at exploiting them from the web, if you let “imagineers” run away with what they “might” want, you’ll fail. You have to start with exposing the transaction and database as a set of core services based on the first application that will use them. Define your API structure to allow for growth and further exploitation. That’s what we successfully did for NatWest. The project rolled out on the internal IP network, and a year later, to the public via the Internet.” Original source: API’s and Mainframes
As for Oracle, the enterprise software vendor wants to use Apiary’s technology set to make its existing API Integration Cloud more robust. Oracle’s API product focuses primarily on services that help companies monetize and analyze APIs. Apiary provides more of a front-end platform for designing, creating and governing APIs. From Natalie Gagliordi f at ZDnet
- $8.55M in funding, over three rounds
- Founded April, 2011.
Apigee was acquired, by Google, last year for $625m. Of course, they were public with (let’s hazard a guess) many, many more customers and revenue: $92.03m in FY2016, to be exact.
Back in September 2015, Carl Lehmann at 451 Research said they had 33 employees (up from 22 in Dec 2014) and estimated their revenue at $2-3m. Carl says, now, it’s “likely below $5m in annual revenue.”
What Apiary does
Apiary’s promise is to be quick and easy when it comes to managing the full life-cycle of API design. As their CEO, Jakub Nesetril, put it when I interviewed him in 2015:
It all starts with that first meeting when you’re thinking about building an API and you’re either kind of, you know, you’re inside meeting room ideating on a white board and then taking a photo of it and sending it to a co-worker, or summarizing it down into an email and sending it down to somebody else, saying hey, I just thought would could build something like this. That white board should be. And, if you do that it becomes, you know, we do a lot to try to make it super simple. We have a language that is like really, really simple for developers to write and we can write down a quick API in five minutes. It’s marked down, it’s like very organic, it’s very simple for developers.
What it creates for you, is creates this kind of common space, common language kind of when you talk about it that’s machine readable, human writable so it’s super simple but it’s also machine writable, and machine readable. The important aspect of it is that we take your white board, we take your … we build a language that we have API blue prints. It’s a… We take that API blueprint and we immediately create a API prototype, the moment you hit your first button. So, from day one when you’ve proposed your first API idea, your first resource you know, your first data structure. You have an API that’s sitting out there on the internet, somebody can query it and guess what, if they decide that the API is broken, that they would like to have a different resource, they would like to change the of a certain data structure, they would like add to it, whatever. They can go in, edit that out, click the save button and boom the API prototype is updated immediately.
Load in some enterprise governance and access controls, and you have something nice and useful. See him explaining more in this 2013 InfoQ interview.
Carl at 451 summarized the meat of what they do back in that 2015 report:
Apiary structures its API lifecycle management platform into five phases. The design phase includes the means to ensure API design consistency using a style guide, a collaborative editor and an approval process. The prototype phase includes productivity capabilities such as auto-generated code and a feedback loop for quality assurance. The implementation phase enables agile-inspired and test-driven development practices, helps deploy server code, and provides for framework integration. The delivery phase includes tools for automated documentation, offers code samples, guides the release of final client code, and offers SDKs. The feedback phase includes debugging, support and usage metrics.
The Money – grabbing part of the $3bn pie
Forrester threw out some API management market-sizing back in June of 2015 (there’s likely something more up-to-date behind their paywall):
We predict US companies alone will spend nearly $3 billion on API management over the next five years. Annual spend will quadruple by the end of the decade, from $140 million in 2014 to $660 million in 2020. International sales will take the global market over the billion dollar mark.
With Oracle’s foot-print in all of enterprise applications and IT (they own Java and share much of the JEE market with IBM), there’s likely some genuine synergies to be had. That is, Oracle could be in a position to boost Apiary sales way above what the tiny company could do on its own.
To be clear, as pointed out above, Apiary doesn’t do all that Apigee does. Apiary is just for the development/design time part of APIs, also providing documentation.
That’s helpful for sure, but I’d guess most of Forrester’s $3bn estimation is likely in actually running and managing APIs. And, in fact, it’s probably more realistic to put Apiary in the development tools/ALM TAM, which is probably in the low, single digit billions. That said, I’m guessing Forrester would put Apiary in their API management bucket; after all, it has “API” in it!
“So anyone who is producing food that ends up in our grocery stores, we’re working with them to get the data from their labels and the packaging information to come right into the database for us,” Pamela Stark Reed, deputy administrator for Nutrition, Food Safety and Quality, said on Information Management month.
The database has actually existed for over a century, Reed said. But before starting the initiative, it only had about 8,000 entries. Since opening it up to manufacturer submission, ARS has received 80,000 new items, a 1000 percent increase.
And on future plans:
The goal for the database is to eventually expand to 1,000,000 items. Reed said ARS anticipates getting store brand and international food items into the database soon. Some items from chain restaurants may follow.
Because of this, the agency is looking into cloud services to increase its storage capacity.
Just imagine, globally, how many data sets like that there are. Throw in the workflow to injest and cleanup the data, and change it, plus APIs to access it, and you have an almost endless amount of projects for software eating.
A report I wrote on Intigua is up now. Here’s the 451 Take for y’all now:
Intigua has always been a company with a difficult marketing proposition, having started off as a packaging and deployment balm for systems management agents. While there is certainly utility to ‘managing the managers,’ a broader positioning and purpose was clearly needed. Intigua’s new positioning as an enabler of cloud management APIs looks encouraging, and if the company can extend into ‘orchestration’ as a consequence, it can start addressing one of the major gaps of large enterprises that are ‘going cloud.’ It’s nice that all of those cloud-native companies can manage tens of applications with their devops and cloud approaches – but how will the large companies of the world manage the tens of thousands of applications they’re beset with?
In talking with some folks who’ve been dealing with so-called “APIs” at the infrastructure stack…there’s a lot of work to do to make the management layer APIs behave like one would expect. Because WS-*.
Intigua bought re-print rights to the last piece I wrote on them, so you can read it for free on their site.
Client can read the full report, and try a trial if you’re not signed up with us yet.
I spoke with the folks at Contentful recently. They have an interesting smoothie of API management and CMS that looks hopeful to people like me who remember “mashups.”
Anyhow, as always, the full report is available for clients, but here’s the 451 Take:
As companies seek to become ‘digital enterprises,’ many are faced with the challenge of omni-channel marketing and content distribution: delivering content to Web browsers, mobile and tablet browsers, and even in-car systems, for example. While dreams of ‘mashups’ in the past sought to deliver programmer-friendly ways of accessing cleaned, tidy data over standard Web protocols, that technology doesn’t seem to have rolled out to the market beyond early prototypes popular at conferences – after all, who says ‘mashup’ any more? Contentful is bringing an interesting, RESTful, public cloud API approach to content management. The company’s challenge will be to out-innovate larger competitors that have much to lose in the small content management market.
You can also apply to get trial access (why not?) to read this report and more of what we have tucked away behind the paywall.
How could I have broken anything? All I did was change a comment.
“I am not a lawyer, but from a developer perspective, the idea of copyrighted APIs does nothing but introduce friction and uncertainty into the very integration efforts the developers use APIs to accomplish,” said Jeffrey Hammond, a vice president at Forrester Research. “Devs will now need to worry about the potential for API lock-in via copyright, as alternative suppliers can’t produce like-for-like substitutions without risk. I don’t see how this is good for developers as it amps up the fear, uncertainty, and doubt about using third-party services.”
Donnie has a detailed piece as well, along with this example:
This is going to create a lot of difficulty for everyone reimplementing S3 APIs, for example, such as OpenStack and others, with the exception of Eucalyptus because of its Amazon partnership.
Secondly, when evaluating new IT hardware and software assets for potential adoption, you need to institute a much stronger requirement for programmability and open APIs. Complete automation of your infrastructure requires programmatic access, and it’s simply insufficient to only have control via graphical interfaces. This isn’t just about provisioning and configuration support via such APIs, you also need to ensure that vendors are providing reliable APIs to get sufficiently detailed status. A core tenet of DevOps is the ability to measure the state of your infrastructure for future improvement and this really needs to be automated programmatically. Ideally these APIs for automation and measurement are simple, easy to adopt, and accessible to people who aren’t full-time software engineers. Thus, beware of complex, language-specific APIs, and strongly lean towards vendors using simple HTTP or REST APIs and standard, easily parsable data formats like JSON.