#3scale

Red Hat Buys 3Scale for API Management

Red Hat has announced a definitive agreement to add API management to its portfolio by acquiring 3Scale. The acquisition adds an important piece to Red Hat’s strategy to build a complete stack for cloud, microservice and other enterprise applications.

The Platform Vision of API Giants – Kin Lane (3scale)

[google-drive-embed url=”https://drive.google.com/file/d/0Bz0MfE0pk4lGam5yMDBvaUN6d28/preview?usp=drivesdk” title=”the-platform-vision-of-api-giants.pdf” icon=”https://ssl.gstatic.com/docs/doclist/images/icon_12_pdf_list.png” width=”100%” height=”600″ style=”embed”]

3scale Launches No-Cost APIcast Cloud API Gateway Service; Making It Easier For Customers To Launch And Manage APIs Quickly And Efficiently

San Francisco, CA (PRWEB) December 10, 2014

3scale, the leading API management platform, today announced the launch of APIcast, a cloud-hosted API gateway (or proxy) that makes it fast and simple to launch an API via 3scale’s API management platform. 3scale APIcast reduces the time to get an API up and running to only a few clicks, and without the need to modify backend code or deploy API gateway proxy software or hardware internally. The service is free and supports up to 50,000 API transactions per day.

“3scale’s overall objective is to make it easier and cheaper to launch and operate an API”, said Steve Willmott, CEO at 3scale. “Helping to grow the API Web is at the heart of everything we do and the APIcast cloud-hosted gateway helps make that happen by making APIs even easier to launch and run.”

The new hosted-gateway service makes it possible to run lower volume production APIs without any local code deployment at all. This means simple configuration for customers and faster time to go live with their APIs, while delivering the same rich API management feature set 3scale provides. APIcast is a perfect solution for small to medium volume APIs and/or customers who want to get a managed API running quickly.

For higher volume APIs, 3scale already offers industry-leading performance through self- hosted NGINX or Varnish gateways, software plugins and existing CDN Integrations. Now customers can select one method, or deploy both and seamlessly move their APIs between different modes, giving them total control of API delivery. The service is also relevant to enterprise situations that require quick, solid staging and testing facilities,

To sign up for 3scale APIcast, please visit http://www.3scale.net/apicast/. Current customers can find the new option on their 3scale dashboard.

About 3scale 3scale provides a comprehensive API management platform that lets API providers easily package, distribute, manage and monetize APIs through a SaaS API infrastructure that is flexible, secure and Web scalable. The platform enables the distribution of a company’s data, content or services to multiple devices or mobile/Web applications, as well as the ability to easily productize APIs. Since 2009 more than 450 APIs are powered by 3scale. Customers span the Fortune 500, government, academia, and startups. 3scale customers include Coldwell Banker, Johnson Controls, SITA, Transport For London (TFL), UC Berkeley, Wine.com among others. The company also powers APItools for API consumers and APIs.io, the worlds first open source API search engine. For more information visit http://www.3scale.net

New Post has been published on http://cloudifica.com/3scale-launches-no-cost-apicast-cloud-api-gateway-service-making-it-easier-for-customers-to-launch-and-manage-apis-quickly-and-efficiently/

Después de encontrarnos en San Francisco el pasado mes de octubre en un evento organizado por un VC, le pedimos a Steve Willmott, CEO de 3scale, si nos podía explicar su experiencia en el viaje emprendedor desde Barcelona a alzar 5 millones de dólares de VCs en EEUU. En diciembre pudimos encontrar un hueco y le hicimos la siguiente video entrevista. Le agradecemos su generosidad y amabilidad.

Esta es la primera entrega de entrevistas que vamos a hacer a emprendedores de éxito surgidos en nuestro ecosistema y que están triunfando en Silicon Valley. En nuestro objetivo de ofrecer recursos para incrementar las posibilidades de éxito de las startups en EEUU, que mejores consejos que los de alguien que ya lo ha conseguido! Abajo la video entrevista. Gracias Steve!

Entrevista a Steve Willmott - Parte 1:

I constantly stumble upon discussions about SOA vs API, about what’s the “better” model or which one will replace the other. I want to summarise my thoughts in this post.

  Definitions

There are many definitions of APIs out there. At its most basic form an API “specifies how software components should interact with each other” (see Wikipedia). In the API Strategy Guide, the authors define an “API is a way for two computer applications to talk to each other over a network (predominantly the Internet) using a common language that they both understand.”

A more recent and very appropriate definition is given in 3scale’s ebook Winning in the API Economy where the authors refer to a Web API as (I prefer the term Network API as it does not necessarily need to use Web technologies):

An interface to a software component that can be invoked at a distance over a communications network using standards based technologies.

Find some more thoughts on APIs in my post about the purpose of an API strategy.

    There are also plenty of definitions for service-oriented architectures (SOA). The one I prefer is from the OpenGroup, which says that:

SOA is an architectural style that supports service-orientation.

Service-orientation is a way of thinking in terms of services and service-based development and the outcomes of services.

A service is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit, provide weather data, consolidate drilling reports), is self-contained, may be composed of other services, and is a “black box” to consumers of the service.

  Essentially, SOA achieves a breakout from thinking in applications but thinking in more fine-grained functions (i.e., services), where applications can be composed of various such services. This has some inherent benefits such as higher flexibility, agility, re-usability and simpler integration. In fact, ServiceOrientation.com lists a whole range of additional benefits such as loose coupling, abstraction, autonomy, statelessness, discoverability, composability, or interoperability.

You can download the following poster which gives a lot of details regarding these benefits.

        (Source: http://serviceorientation.com/)

The core building blocks of a SOA are very similar and recurring:

Service consumers

Service providers

Service descriptions

Service implementations

Service directories

Discovery mechanisms

  A service provider holds a service implementation but only describes the interface to it and how to use it via the service description. The provider would use a discovery mechanism to find a service directory and register the service description there.

A service consumer would also use a discover mechanism to find a service directory and then the relevant service in there, which based on the description fits the requirements of the consumer. Using this description enables the consumer to invoke the service directly from the service provider.

  This is the theory and it sounds good. The reality is often a bit less simple. I have practical experience specifically with Jini, which is (a quite old) SOA originally designed and implemented by Sun Microsystems. Now it goes under the name of River under the Apache umbrella. It is outdated and probably not used much nowadays. Probably a more current SOA is SORCER with which I have no experience. Using Jini I implemented an Open Management System, which combined different types of multimedia content from different sources and allowed to playback the content based on the capabilities of distributed and mobile devices. That worked alright. It was a prototype. I am sure I would have run into scalability and inconsistency problems fairly soon. The service directory is clearly a single-point-of-failure as well as a bottleneck and if you have several you will run into all classic network problems (such as the CAP theorem).

Jini abstracts an additional level over remote method invocation (RMI) which can be quite heavyweight, not really straightforward to implement and you need proprietary libraries for all supported devices or operating systems.

SOA is often used in combination with enterprise service bus (ESB), which should help to publish, use and orchestrate services within a company. This can eventually also get out of hand as depicted in the figure below.

(Source: Agigee's APIs inside the Enterprise)

  All in all SOA (or Jini as one concrete instantiation) increases flexibility and agility but still was complex to implement and maintain.

  SOA is APIs

In SOA we are using interfaces to invoke the various services. So, we could argue -- also based on the definitions given above -- that APIs inherently are a part of every service oriented architecture solution.

The notion of API changed over time from simply a technical expression to a paradigm. Today we use the term API to express opening up company assets to external developers. In essence this is still true to the original usage, namely encapsulating complex data or algorithms in a black box to which the API is the key to access.

  APIs are SOA

If we look at APIs today the same six core building blocks of SOA as mentioned above exist in some shape or form. Most of these work alright, and the popularity and explosion of public API registrations (see “API adoption – we are still in the early days”) is evidence enough. However, especially two areas require substantial improvement: service directories and discovery mechanisms. There are some API directories available such as ProgrammableWeb, APIhub, or Mashape. As a developer you have to human-read them, find them, read the developer documentation, (often sign up), and then implement the APIs. An automatic or machine-based approach would be useful. Especially because this space of public APIs is getting more and more convoluted and confusing.

Two recent developments in the API Economy clearly show that this weakness has been identified and is worked on:

RAML is the RESTful API Modelling Language that facilitates reuse, API description based on patterns, and increase of discoverability.

API Commons is an initiative that aims to come up with simple and transparent mechanisms for the copyright free sharing of APIs. This should result in collaborative design of API specifications, interfaces and data models, which should allow sharing best-practices and increase re-usability.

    Conclusions

The API / SOA duality is interesting, overlapping, and mutually supportive. I don’t think there is a SOA or API relation. I think it is more about the core building blocks of the early SOA and how the lessons learned can be transferred into modern API-based architectures.

What we currently subsume under the API Economy is an evolution of SOA including a much deeper integration between business and API strategy. With APIs the potential barrier between business and technology has been lowered even more, which facilitates this strategy integration.

API description and discovery will be the main challenges for the near future in the API Economy.

     Further resources

Just today I attended a Webinar by MuleSoft about SOA and Legacy Modernisation.

Apigee also held a webinar earlier about SOA and APIs. Find slides and video embedded below.

We'll be at The Next Web from this wednesday, in Amsterdam, together with people from 3scale, with whom we worked for our API management.