agsandrew - Fotolia

Get started Bring yourself up to speed with our introductory content.

Amid microservices boom, smart pipes emerge

In part two of a two-part series about the tradeoffs between smart endpoints and smart pipes in microservices, experts describe the value of smart pipes.

This is part two of a two-part series about the tradeoffs between smart endpoints and smart pipes. This article focuses on using smart pipes. Read part one here.

One of the leading proponents of using smart pipes to build next-generation services has been network technology company F5 Networks with its Software Defined Application Services (SDAS) architecture. This approach uses programmable application services -- like availability, application acceleration, security, identity management and access control -- that reside in the data path between users and applications (or APIs). Because they are in the data path and are deployed on a full-proxy software platform, they can intercept, inspect and modify both inbound requests and outbound responses.

Being programmable means that SDAS can be instructed to route messages for services based on message-level elements as well as device, network and user attributes. Like API management tools that provide metering of APIs, SDAS can extract API keys, enforce quotas and rate limits on usage and provide identity and access control for the API. SDAS can be used to implement API façades, help transition users to new API versions and secure messages.

Lori MacVittie, a principal technical evangelist at F5 Networks, said, "SDAS are not necessarily directly comparable with API or enterprise service bus (ESB) gateways in that they are not specifically designed for those purposes and thus do not include the full complement of capabilities associated with those solutions." But their programmable nature means they are able to take on some of the functions of these solutions like message routing, security and access control. Message transformation associated with ESB gateways is possible with SDAS, for example, but not necessarily recommended, especially when messages require significant fluency with a variety of extensible markup language or other messaging standards.

MacVittie recommends that organizations considering a smart pipes approach like SDAS should start by understanding how it will be included in the application architecture.

Like ESB gateways, SDAS can act as a translation point within the message flow. In the case of SDAS, this can be used to transition from one protocol to another, like HTTP/2 or SPDY to HTTP/1. This allows ESB gateways and API management services to effectively support emerging application protocols on clients without requiring extensive modification to the gateway or service. MacVittie recommends that organizations considering a smart pipes approach like SDAS should start by understanding how it will be included in the application architecture, which gives developers the opportunity to influence and direct the smart pipe's behavior based on application-specific information in early phases of the software development lifecycle.

Mixing networking and business value

The move toward smart pipes could prove to be of growing importance for companies in which business domains are intertwined with the ability to provision and manage network components such as Internet service providers, cloud service providers and telephone companies. Virtualization and runtime programmability of not only server platforms but now the network interconnections between them are bringing to reality the long sought-after dream of rapid service provisioning without the traditional delays associated with physical network equipment racking, cabling and configuration.

John Diamond, a principle solutions architect at smart pipe software vendor Entuity, said that it makes sense to have API-based integration of network-monitoring facilities into a flow-through architecture. It will likely be considered necessary in the near future. He continued, "This style of integration allows previously autonomous software systems to be brought together as flexible components of the larger management environment, providing tangible increased efficiencies along with a rapidly adjustable collection of custom capabilities."

Finding the right balance

Teams need to implement a consistent policy environment across APIs, microservices and back-end service components. The pipe or fabric must intelligently connect or scale solution components so that it is more than just the network. Enterprise architects need to understand that microservices, API management ESBs and networking control components don't work in a vacuum. Architects must identify the best places for command and control interfaces between these tools.

For example, an enterprise running a cloud platform as a service (PaaS) stack such as Cloud Foundry, Spring Boot or Apache Stratos will find the particular PaaS stack influences the decisions about what application containers should be spun up or how they are connected. Other organizations might find that the network layer or router and load-balancing infrastructure play a bigger role in guiding the decision.

Chris Haddad, vice president of platform evangelism at open source software company WS02, indicated that the network is important to many clients. Architects need to be able to establish a connectivity point, which means defining the network connectivity. "It is important to [have] a clean implementation between the components that are published in the PaaS, scaling out the microservices and connecting the services together," Haddad said. "A successful solution needs to get all of the pieces to talk together, and the network is definitely a strong component of the solution."

Dig Deeper on Cloud architecture design and planning