RapidAPI nabs $25M led by Microsoft as its API marketplace cracks 10K APIs and 1M users

Source: Microsoft more

APIs — the lightweight programming interfaces used by developers to integrate other applications with theirs, or to help their apps integrate with others — have become an essential building block of our software-powered world, with a majority of organizations building and working with them and, by some estimates, upwards of 50,000 of them in circulation today.

Those numbers and popularity, however, can lead to a lot of fragmentation and disorganization in terms of discoverability. Now, one of the startups that’s building a marketplace to help fix these problems has raised funding to capitalise on the opportunity.

RapidAPI, which developers use to search for, pay and connect to public APIs, has closed a Series B round of $25 million.

CEO and co-founder Iddo Gino said in an interview that the startup plans to use the funding to continue both expanding the size of its marketplace and the kinds of tools that it provides to developers to engage with it.

Up first will be a new product aimed at developer groups, appropriately titled RapidAPI for Teams, which will help them not only manage their use of public APIs but also organise and use their own internal APIs and microservices. (The product will be free for up to five developers and charged at $10 per user per month thereafter for unlimited calls, Gino said.)

The funding comes at a time of decent growth for the startup. The company now counts 10,000 APIs in its marketplace, which it estimates covers 33% of all publicly available APIs globally (leaving lots of room still to grow); with developers using RapidAPI now standing at 1 million, who now collectively make 500 billion API calls each month from a wide variety of companies big and small, including Microsoft, SendGrid, Nexmo, Telesign, Google, Skyscanner  and Crunchbase (TC’s cousin).

Customers, meanwhile, include some of API providers along with other enterprises, including Cisco, Hyatt, SAP, Delta, and Reddit .

In addition to that we have 20,000 more APIs that are either stale (not used, mostly private) or are used by just one user in private mode so we don’t consider them in our count.

The stats RapidAPI is putting out today are all up on numbers it revealed to me last year, when I wrote about the startup’s Series A. (Then, it had 8,000 APIs, 500,000 developers and 400 billion calls.)

It now also has some 50 employees spread out between San Francisco, Tel Aviv and Ukraine.

The Series B — which brings the total raised by RapidAPI to around $38 million — is being led by M12, the VC arm of Microsoft, with DNS Capital and previous investors Andreessen Horowitz and Green Bay Capital also participating.

Microsoft’s involvement is strategic and notable: the company has long been building itself as the go-to platform for all things developer, a strategy that goes back years but more recently has extended to its big investment in its Azure cloud platform, as well as its acquisition of code repository GitHub, among many other moves. You can easily see how well something like RapidAPI could complement those existing tools.

“Responding to the torrid growth of the API economy, RapidAPI is changing the way businesses scale with APIs and microservices,” said Mony Hassid, General Manager and Managing Director at M12, in a statement. “We are excited about the potential for RapidAPI to enhance developers’ productivity, streamline duplicative work, and assist to combine API contracts.” Hassid also has now joined RapidAPIs board of directors.

From what we understand, Microsoft wasn’t the only strategic company that was eyeing an investment in RapidAPI in this round. But Iddo Gino, the company’s young founder, said in an interview that the terms of this deal were very clear and the company is very free to pursue partnerships with others, including Microsoft competitors.

Competitors are top of mind for RapidAPI in another regard, too. As you would imagine, the popularity of API usage — which extends not just to software but a number of hardware devices and IoT devices that the software powers — has led to a number of companies that are all going after the same business.

Companies like Zapier and IFTTT (also backed by Andreessen) provide directories of apps that can be connected together; and ProgrammableWeb also has offered a longstanding API directory, although Gino argues that it incorporates less of the tools that RapidAPI offers. He noted that he sees Manifold, which is a much larger cloud services marketplace, a more direct competitor.

The proliferation of tools for developers, and more specifically those aimed at helping developers work with APIs, will inevitably lead to more consolidation, with bigger fish swallowing up some of the minnows, or the minnows coming together for a stronger proposition to the market. RapidAPI has already been a beneficiary of that trend: it acquired Mashape in 2017, leading to a nice bump in its user numbers. And there could be more of that to come.

While RapidAPI has focused up to now on public APIs, the turn with teams to private APIs will open the door to a whole new set of services and use cases that speak to another kind of growth for the company. Citing a survey by Ping Identity, RapidAPI notes that 25% of companies typically use more than 1,000 internal APIs or microservices, while another 35% have 400–1,000 internal APIs. API days are here again, it seems.


RapidAPI nabs M led by Microsoft as its API marketplace cracks 10K APIs and 1M users

Microsoft makes a push for service mesh interoperability

Source: Microsoft more

Services meshes. They are the hot new thing in the cloud native computing world. At Kubecon, the bi-annual festival of all things cloud native, Microsoft today announced that it is teaming up with a number of companies in this space to create a generic service mesh interface. This will make it easier for developers to adopt the concept without locking them into a specific technology.

In a world where the number of network endpoints continues to increase as developers launch new micro-services, containers and other systems at a rapid clip, they are making the network smarter again by handling encryption, traffic management and other functions so that the actual applications don’t have to worry about that. With a number of competing service mesh technologies, though, including the likes of Istio and Linkerd, developers currently have to chose which one of these to support.

“I’m really thrilled to see that we were able to pull together a pretty broad consortium of folks from across the industry to help us drive some interoperability in the service mesh space,” Gabe Monroy, Microsoft’s lead product manager for containers and the former CTO of Deis, told me. “This is obviously hot technology — and for good reasons. The cloud-native ecosystem is driving the need for smarter networks and smarter pipes and service mesh technology provides answers.”

The partners here include Buoyant, HashiCorp, Solo.io, Red Hat, AspenMesh, Weaveworks, Docker, Rancher, Pivotal, Kinvolk and VMWare. That’s a pretty broad coalition, though it notably doesn’t include cloud heavyweights like Google, the company behind Istio, and AWS.

“In a rapidly evolving ecosystem, having a set of common standards is critical to preserving the best possible end-user experience,” said Idit Levine, founder and CEO of Solo.io. “This was the vision behind SuperGloo – to create an abstraction layer for consistency across different meshes, which led us to the release of Service Mesh Hub last week. We are excited to see service mesh adoption evolve into an industry level initiative with the SMI specification.”

For the time being, the interoperability features focus on traffic policy, telemetry and traffic management. Monroy argues that these are the most pressing problems right now. He also stressed that this common interface still allows the different service mesh tools to innovate and that developers can always work directly with their APIs when needed. He also stressed that the Service Mesh Interface (SMI), as this new specification is called, does not provide any of its own implementations of these features. It only defines a common set of APIs.

Currently, the most well-known service mesh is probably Istio, which Google, IBM and Lyft launched about two years ago. SMI may just bring a bit more competition to this market since it will allow developers to bet on the overall idea of a service mesh instead of a specific implementation.

In addition to SMI, Microsoft also today announced a couple of other updates around its cloud-native and Kubernetes services. It announced the first alpha of the Helm 3 package manager, for example, as well as the 1.0 release of its Kubernetes extension for Visual Studio Code and the general availability of its AKS virtual nodes, using the open source Virtual Kubelet project.

 


Microsoft makes a push for service mesh interoperability

Microsoft makes a push for service mesh interoperability

Source: Tech News – Enterprise

Services meshes. They are the hot new thing in the cloud native computing world. At Kubecon, the bi-annual festival of all things cloud native, Microsoft today announced that it is teaming up with a number of companies in this space to create a generic service mesh interface. This will make it easier for developers to adopt the concept without locking them into a specific technology.

In a world where the number of network endpoints continues to increase as developers launch new micro-services, containers and other systems at a rapid clip, they are making the network smarter again by handling encryption, traffic management and other functions so that the actual applications don’t have to worry about that. With a number of competing service mesh technologies, though, including the likes of Istio and Linkerd, developers currently have to chose which one of these to support.

“I’m really thrilled to see that we were able to pull together a pretty broad consortium of folks from across the industry to help us drive some interoperability in the service mesh space,” Gabe Monroy, Microsoft’s lead product manager for containers and the former CTO of Deis, told me. “This is obviously hot technology — and for good reasons. The cloud-native ecosystem is driving the need for smarter networks and smarter pipes and service mesh technology provides answers.”

The partners here include Buoyant, HashiCorp, Solo.io, Red Hat, AspenMesh, Weaveworks, Docker, Rancher, Pivotal, Kinvolk and VMWare. That’s a pretty broad coalition, though it notably doesn’t include cloud heavyweights like Google, the company behind Istio, and AWS.

“In a rapidly evolving ecosystem, having a set of common standards is critical to preserving the best possible end-user experience,” said Idit Levine, founder and CEO of Solo.io. “This was the vision behind SuperGloo – to create an abstraction layer for consistency across different meshes, which led us to the release of Service Mesh Hub last week. We are excited to see service mesh adoption evolve into an industry level initiative with the SMI specification.”

For the time being, the interoperability features focus on traffic policy, telemetry and traffic management. Monroy argues that these are the most pressing problems right now. He also stressed that this common interface still allows the different service mesh tools to innovate and that developers can always work directly with their APIs when needed. He also stressed that the Service Mesh Interface (SMI), as this new specification is called, does not provide any of its own implementations of these features. It only defines a common set of APIs.

Currently, the most well-known service mesh is probably Istio, which Google, IBM and Lyft launched about two years ago. SMI may just bring a bit more competition to this market since it will allow developers to bet on the overall idea of a service mesh instead of a specific implementation.

In addition to SMI, Microsoft also today announced a couple of other updates around its cloud-native and Kubernetes services. It announced the first alpha of the Helm 3 package manager, for example, as well as the 1.0 release of its Kubernetes extension for Visual Studio Code and the general availability of its AKS virtual nodes, using the open source Virtual Kubelet project.

 


Microsoft makes a push for service mesh interoperability

Solo.io wants to bring order to service meshes with centralized management hub

Source: Tech News – Enterprise

As containers and microservices have proliferated, a new kind of tool called the service mesh has developed to help manage and understand interactions between services. While Kubernetes has emerged as the clear container orchestration tool of choice, there is much less certainty in the service mesh market. Solo.io announced a new open source tool called Service Mesh Hub today, designed to help companies manage multiple service meshes in a single interface.

It is early days for the service mesh concept, but there are already multiple offerings including Istio, Linkerd (pronounced Linker-Dee) and Convoy. While the market sorts itself it out, it requires a new set of tools, a management layer, so that developers and operations can monitor and understand what’s happening inside the various service meshes they are running.

Idit Levine, founder and CEO at Solo, say she formed the company because she saw an opportunity to develop a set of tooling for a nascent market. Since founding the company in 2017, it has developed several open source tools to fill that service mesh tool vacuum.

Levine says that she recognized that companies would be using multiple service meshes for multiple situations and that not every company would have the technical capabilities to manage this. That is where the idea for the Service Mesh Hub was born.

It’s a centralized place for companies to add the different service mesh tools they are using, understand the interactions happening within the mesh and add extensions to each one from a kind of extension app store. Solo wants to make adding these tools a simple matter of pointing and clicking. While it obviously still requires a certain level of knowledge about how these tools work, it removes some of the complexity around managing them.

Solo.io Service Mesh Hub

Solo.io Service Mesh Hub. Screenshot: Solo.io

“The reason we created this is because we believe service mesh is something big, and we want people to use it, and we feel it’s hard to adopt right now. We believe by creating that kind of framework or platform, it will make it easier for people to actually use it,” Levine told TechCrunch.

The vision is that eventually companies will be able to add extensions to the store for free, or even at some point for a fee, and it is through these paid extensions that the company will be able to make money. She recognized that some companies will be creating extensions for internal use only, and in those cases, they can add them to the hub and mark them as private and only that company can see them.

For every abstraction it seems, there is a new set of problems to solve. The service mesh is a response to the problem of managing multiple services. It solves three key issues, according to Levine. It allows a company to route the microservices, have visibility into them to see logs and metrics of the mesh and to provide security to manage which services can talk to each other.

Levine’s company is a response to the issues that have developed around understanding and managing the service meshes themselves. She says she doesn’t worry about a big company coming in and undermining her mission because she says that they are too focused on their own tools to create a set of uber-management tool like these (but that doesn’t mean the company wouldn’t be an attractive acquisition target).

So far, the company has taken over $13 million in funding, according to Crunchbase data.


Solo.io wants to bring order to service meshes with centralized management hub