Container-Native App Services

A growing number of app services are an integral component of a cloud-native architecture. This is, in part, why we see a shift in responsibility for app services away from IT operations toward DevOps.

We track over 30 different application services in our State of App Services research. There are more, and every year we review the list to determine what to drop and what to add.

For 2020, we consolidated several app services into broader categories. For example, network firewall, anti-spam, IPS/IDS, and spam mitigation were aggregated into "common security services."  We decided on this approach for two reasons. First, because six years of data indicated groupings of app services with very similar deployment rates. Second, because we wanted to make room for emerging app services and don't want to overwhelm our already very patient respondent base.

Those emerging app services are almost exclusively container-native app services. These are generally—though not always—deployed as part of the operating environment required to deliver a cloud-native application. Think ingress control, service discovery, and service mesh. API gateways, too, are often closely coupled to cloud-native applications, though their usage is broadly aligned with any API-based application.

Given their rising importance to delivering modern, cloud-native apps and the incredible deployment rates we're seeing, it seems like a good time to provide some color on these champions of cloud-native approaches.

Ingress Control

State of Application Services 2020 Deployment: Ingress Control

Ingress control is a concept introduced into the Kubernetes world to slice and dice HTTP requests. It allows operators to easily map a URI to a specific Kubernetes Service. This enables the routing of inbound (ingress) requests to the right microservice instance.

This was not a new concept. Avid readers will recall that I often extol the virtues of HTTP (Layer 7) routing, particularly as an architectural component designed to assist in more efficient scaling strategies. If you don't recall or are just joining us, this keynote is a good refresher: So you think you can scale?

What is new is the way in which the "maps" are managed. Ingress controllers need to be dynamically updated based on current conditions inside a container cluster. That means an ingress controller needs to have visibility into the current state of a cluster. That means integration with the appropriate Kubernetes components via its operational API.

This integration is what tethers ingress control to the environment and thus bakes it into the app architecture. A fully functional ingress controller is inherently "container-native" because it is part of the infrastructure required to scale and operate a cloud-native application. 

Service Discovery

State of Application Services 2020 Deployment: Service Discovery

An interesting fact about cloud-native applications is the lifespan of its composite parts. The dynamic nature of scalability inside a container cluster necessarily means that "containers" are in constant flux. The latest data from Sysdig shows increasing amounts of flux, with 39% of containers living less than one minute, and 54% living less than 5 minutes.

The problem with this is that other components need to be able to find those containers.

This is the raison d'être of the service discovery component. These components run inside the container cluster and serve as the "authoritative source" for services. Interested parties can query this component to discovery how to connect to and communicate with a given service. By keeping track of services in real-time, the service discovery component addresses the volatility of a cluster and enables other components—such as ingress control—to function properly. 

Service Mesh

State of Application Services 2020 Deployment: Service Mesh

Service mesh is probably the most controversial of container-native app services. Not because of its conceptual value, but because of implementation preferences. Service meshes are designed to address issues with visibility, scale, and security within container clusters. They are implemented as hyperconnected proxies—either sidecar or per-app—and offer a variety of features for both developers and operators.

A service mesh is not an application service you will find outside a container cluster. Like discovery and ingress control, a service mesh is intimately integrated with the container environment. This makes it a container-native app service as well. 

Container-Native App Services

We (the industry and the corporate We) have never categorized application services in this way before. Certainly, we categorize based on their primary usage: security, availability, performance, mobility, and identity. But these are broad usage categories, and none are peculiar to an app architecture.

But the integration into and dependencies upon a cloud-native architecture may make it necessary to do so for these app services (and any others that may crop up in the future). That’s because the growth of one (the app service) clearly indicates growth of the other (the app architecture)—and vice-versa. This is a unique situation, in which app services and apps are so intimately intertwined that the two will see very similar deployment rates. 

Much in the same way we distinguish between mobile IOS and Android apps, we may find it valuable to tag those app services designed to operate only within a containerized environment as "container-native" versus those that operate everywhere else.

Regardless of what how we categorize them, they are definitely on the rise—along with the apps that depend on them.