Microservices Ecosystem Transit Map

Microservices 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.

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 on the original blog post.

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 on the original blog post, 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.

For more details on vendor product names, category inclusion and exclusion criteria, and how to leave us feedback on the map, please continue reading the original blog post at: https://www.nanoscale.io/ecosystem