…we assembled a map of the ecosystem to help guide practitioners, vendors, investors, media, or anyone who’s simply interested in following the space…

icroservices architecture has reached a tipping point where its broad adoption is now pretty much guaranteed. According to a survey by NGINX, nearly a third of companies have deployed microservices in production, and another third are either using microservices in development or considering them. Furthermore, there is fairly even distribution of microservices adoption across small (36%), medium (50%), and large companies (44%), indicating that the approach has merit regardless of how many developers you have in your organization.

However, developing microservices is not always easy, and not necessarily a panacea or silver bullet versus monolithic architectures. While limiting the function of a program to a specific task may reduce the absolute lines of code, it may introduce other challenges related to testing, team coordination, and distributed computing complexity.

The good news is that there is an abundance of tools and frameworks to support microservices adoption and mitigate these challenges, with new solutions emerging continuously. Understanding the relationships within and among this ecosystem of software tools, frameworks, and vendors can be daunting, so we assembled a map of the ecosystem to help guide practitioners, vendors, investors, media, or anyone who’s simply interested in following the space. There are other efforts to do this, most notably Sequoia Capital’s excellent microservices ecosystem map of the broader market, which also covers general data center, network management, and operating systems. Our goal was to create an ecosystem map that is more focused on microservices specialists, and less overweight on the data center side of the space.

Microservices Ecosystem Transit Map

Approach and Methodology

To illustrate the various dynamics of the ecosystem, we used a transit map (or subway map) paradigm that covers four “districts” corresponding to the microservices life cycle: development, deployment, management, and discovery (via public directories, not service instance registries). Each of these districts has one or more “category lines” with multiple “vendor stations”.

Each vendor station may span multiple category lines, and it is noted whether a vendor provides any products under open source licenses (O), made any acquisitions (A), or is a public company (P). Strategic relationships, projects, and subsidiaries are indicated with “bus lines”. In an effort to be less verbose, we list vendor names instead of individual products, which can be found in the details below.

How to read the map in this zoomed area:

• Nanoscale.io has a solution that is both a Microservices Builder and provides Serverless/FaaS Computing.

• Microsoft has an offering for API Management, Serverless Computing, and Containers. It is a public company, and at least one of these offerings is via an acquisition.

• Google has an offering for API Management and Serverless Computing. It also has a relationship with an open source project Container Orchestration project called Kubernetes.

Category lines are defined in more detail below, where we describe both inclusion and, more importantly, exclusion criteria in an effort to maintain focus on microservices-specific tools that drive productivity. The map notes “airport codes” to related ecosystems; groups of vendors who may have functional overlap, but not necessarily focus specifically on the microservices approach.

Observations

• An unmarked “downtown core” district emerged at the center of the map, where larger vendors congregate across multiple category lines and convergence is taking place.

• There is a plethora of open source container, orchestration, and deployment frameworks, enabling the growth of serverless microservice and function-as-a-service (FaaS) cloud offerings

• This will likely result in serverless FaaS and microservice cloud offerings becoming commoditized, like PaaS and IaaS before them. Current pricing behavior already signals a race to bottom, with heavy pressure from both heavyweights like AWS Lambda and emerging vendors like Nanoscale.io offering generous plans.

• Many large vendors entered the ecosystem via the API management category, through both organic efforts (eg. Oracle, IBM, AWS) and acquisitions (eg. RedHat+3Scale, Tibco+Mashery, Microsoft+Apiphany).

• The ecosystem is likely to experience continued convergence in the downtown core, as larger vendors seek to expand their lifecycle coverage into developer productivity categories such as microservice builders and mockup tools.

• There is potential for more strategic relationships between complementary solutions, as we saw recently with the AWS and VMWare announcement. This would be particularly interesting and useful in the development district, where mockup tools flow naturally into microservice builders from a life cycle perspective, but remain distinct offerings today.

• Larger vendors in related ecosystems, such as PaaS, ESB, and APM, who are looking to build their microservices credibility, will also drive convergence.

• More adoption of container-based microservices and FaaS will increase the need for container-specific logging and analytics features in the monitoring category and related APM ecosystem.

• Container-native security is an emerging category within the ecosystem that we did not cover. Security would most likely reside within the management district, adjacent to monitoring, which also takes place at runtime, and where there is some overlap with governance and security features of API management solutions.

Microservices Ecosystem Transit Map Details (Back/Cover)

Details and Category Notes

District: Development

Category Line: Specification and Mockups

Related Ecosystem(s): Application lifecycle management (ALM)

Category Notes: Includes widely adopted web service specification standards. Includes solutions that provide a user interface (UI) for developers or business users to declaratively define API endpoints and generate standards-based specifications and/or code stubs. Excludes command line (CLI) developer toolkits that only generate documentation (eg. Slate, Snowboard, etc.) or source code renderers (eg. Drakov, API-Mock, etc.). Excludes ALM solutions (eg. IBM Rational, SmartBear ALMComplete).

Vendor Stations:

• WSDL

• WADL

• API Blueprint / Apiary

• Swagger (acquired) / SmartBear SwaggerHub

• RAML / Mulesoft** AnyPoint API Designer

• Reslet* Studio

• Mockable.io

—————————

District: Development

Category Line: Microservice Builder

Related Ecosystem(s): Integrated Development Environments (IDEs), Backend-as-a-Service (BaaS)

Criteria Notes: Includes vendors who provide an abstracted approach to define the business logic of a microservice and corresponding API specifications, via a graphical user interface console to increase productivity. May include a domain-specific scripting language (DSL) for defining custom business logic. Some are downloadable frameworks, others provide cloud hosting, and some offer both options. Excludes solutions that only provide a command-line interface (CLI) or only execute containerized code (eg. Iron.io, IBM OpenWhisk). Excludes general integrated development environments (IDEs such as Eclipse, Microsoft Visual Studio, etc.). Excludes mobile and backend-as-a-service solutions (BaaS) that are monolithic app builders or have prescribed API routes and specifications (eg. RedHat Mobile Application Platform, Kony Mobile Fabric, Kinvey, etc.) .

Vendor Stations:

• Fabric8

• Apigility/Zend

• GalaticFog

• Restlet* API Spark

• LSQ*

• Dreamfactory*

• Nanoscale.io*

• Mulesoft* AnyPoint Studio

• CA* Live API Creator

• Tibco* Mashery (acquired)

—————————

District: Deployment

Category Line: Containers and Orchestration

Related Ecosystem(s): Continuous Integration and Continuous Deployment tools. Operating system platforms that are optimized for microservices execution.

Criteria Notes: Includes container and container orchestration solutions (eg. Kubernetes, Docker). Includes container management and deployment solutions (eg. Rancher, Containership). Excludes general-purpose continuous improvement (CI) and continuous deployment (CD) devops toolkits (eg. Puppet, Ansible, Vagrant, etc.). Excludes Linux kernel operating systems (eg. CoreOS, DC/OS, RancherOS, etc.) and general cloud platforms (eg. CloudFoundry, OpenStack, etc.).

Vendor Stations:

• Apcera

• Kontena

• Containership

• Serverless

• Wavefront

• VMWare vSphere Integrated Containers (VIC)

• Vamp*

• Marathon (Mesosphere)

• Rancher

• Docker and Docker Swarm (acquired Tutum)

• Microsoft** Windows Containers, Azure Container Service

• Kubernetes (Google)

• Oracle** StackEngine (acquired)

• RedHat* OpenShift Origin

—————————

District: Deployment

Category Line: Serverless and Function-as-a-Service (FaaS) Computing

Related Ecosystem(s): Platform-as-a-Service (PaaS), Infrastructure-as-a-Service (IaaS)

Criteria Notes: Includes vendors that offer cloud hosted microservice or FaaS execution on-demand platforms, either via containers and/or native scripting, with auto-scaled resources, and billing on a granular usage basis. Excludes PaaS solutions that are primarily designed to run “always-on” monolithic applications (eg. CenturyLink AppFog, Mulesoft Cloudhub, etc.). Excludes general-purpose IaaS and managed hosting providers (eg. Rackspace, IBM Softlayer).

Vendor Stations:

• PubNub Blocks

• Joyent Manta Functions (acquired by Samsung)

• Hook.io

• Webtask

• Iron.io

• LSQ*

• Dreamfactory*

• Nanoscale.io*

• Microsoft** Azure Service Fabric

• Amazon Web Services* Lambda

• Google* Cloud Functions

• IBM* Bluemix OpenWhisk

• Oracle** Cloud Container Service

• Tyk*

• SAP* Hana Cloud

• WSO2* App Cloud

—————————

District: Management

Category Line: API Management

Related Ecosystem(s): Enterprise Service Bus (ESB), Integration Platforms-as-a-Service (iPaaS)

Criteria Notes: Includes vendors that offer API management solutions via graphical user interface consoles, several of whom are now adding abstracted microservice builder capabilities. Excludes middleware and integration-focused (IPaaS) vendors (eg. Snaplogic, CloudElements, Dell Boomi). Excludes ESB solutions (eg. IBM WebSphere, Mule ESB, SoftwareAG WebMethods), most of whom have corresponding API management solutions from the same vendor.

Vendor Stations:

• Akana

• Axway API Management (acquired Vordel)

• WSO2* API Manager

• SAP* API Management

• Tibco Mashery (acquired)

• CA* API Management (acquired Layer7)

• RedHat* 3Scale (acquired)

• Tyk*

• Oracle** API Management

• Mulesoft** API Manager

• IBM* API Connect

• Google Apigee (acquired)

• Amazon Web Services* API Gateway

• Microsoft* Azure API Management (acquired Apiphany)

• Mashape* Kong

• APinf*

—————————

District: Management

Category Line: Monitoring

Related Ecosystem(s): Application performance management (APM)

Criteria Notes: Includes vendors that offer container-focused monitoring solutions either via a graphical interface or by providing webhooks for a microservice to invoke. Excludes general IT operations monitoring (eg. DataDog, Zabbix) and network monitoring tools (eg. Nagios, Zenoss). Excludes logging-focused solutions (eg. Splunk, Sumo). Excludes time series databases (TSDBs, like Graphite and InfluxDB). Excludes APM solutions that focus on performance management (eg. Dynatrace, AppDynamics, and NewRelic).

Vendor Stations:

• Sysdig Cloud

• Runscope

• Dataloop.io

• Datawire.io

• Prometheus

• cAdvisor (by Google)

• Vamp/Magnetic.io*

—————————

District: Discovery

Note: This name of this district refers to discovery of APIs and microservices via public directories, not service registries and service instance discovery, which are typically functions that load balancers or proxy servers perform.

Category Line: Public Directory and Marketplace

Related Ecosystem(s): Public source code repository hosting (CRH)

Criteria Notes: Includes public API directories (eg. ProgrammableWeb, APIs.io), and marketplaces (eg. Mashape, APinf). Excludes public source code repository hosts (eg. GitHub, Microsoft Codeplex, etc.).

Vendor Stations:

• APIHound

• APIs.io

• ProgammableWeb (acquired by MuleSoft)

• API Harmony (an IBM project)

• APIinf*

• Mashape*

—————————

* Vendor is on one other category line
** Vendor is on two other category lines

Errata and Feedback

The Microservices Ecosystem Transit Map is far from perfect. It undoubtedly contains errors, omissions, and miss-categorizations. Therefore, we will continue to update the map and detail content periodically, and welcome any feedback or suggestions for improvement. If proposing to add a vendor to the map, please specify the company, product, url, and evidence (screenshot, documentation, etc.) that it meets the selection criteria for the proposed category. You can reach us via DM on Twitter (@nanoscaleio) or by sending an email to “info” at nanoscale.io