Serverless, containers and microservices are making infrastructure invisible, benefitting technology consumers that expect to access, assemble, and pay for digital services in a simple, seamless and automated manner, without requiring any specific knowledge of the underlying physical infrastructure. The 'invisible infrastructure' must be instantly available, operate and scale regardless of specific requirements, and be billed and metered in a manner the customer prescribes. It just works. However, this does not mean it is any less important. In fact, the paradox is that the more important the role infrastructure plays in our lives, the more important it becomes to shield users from having to directly interact with, or even consider, it.
The 451 Take
The impact of cloud-native approaches (including containers, serverless and microservices) will have a profound effect on the IT landscape. Infrastructure (and associated complexity) becomes invisible (to the consumer), and cloud may eventually disappear as a separate IT category. How 'cloud-native' plays out with regard to existing/alternative application-focused approaches including PaaS remains to be seen. It is relatively immature by comparison, but the disruption it causes will be significant. No wonder most IT vendors and service providers are embracing a cloud-native position. The 'building blocks' of cloud-native are used mostly to assemble other blocks and address cloud-native challenges, rather than being provided as packaged offerings that solve business problems. However, stacks that use these blocks will emerge, and anyone not paying attention to the opportunities and challenges risks becoming irrelevant.
451 Research data shows that the majority of cloud-native or cloud-enabled software is developed internally, rather than purchased commercially (including SaaS). This suggests that enterprises are currently using the building blocks of cloud-native (containers, microservices, serverless, etc.) to create their own software. The data (see Figure 1) from our Voice of the Enterprise: Cloud, Hosting & Managed Services, Workloads and Key Projects 2018 survey also shows that most enterprises design cloud-native software to run on multiple clouds, while about one-third of respondents are designing it for one specific public cloud and 17% design for their own private cloud (see Figure 2). Taken together, this suggests that the opportunity for commercial cloud-native software is mostly in front of us, and that offerings which support multiple cloud environments are likely to be more successful than those that only target one.
'Write once, deploy to any serverless' is CNCF's goal
Cloud Native Computing Foundation (CNCF) doesn't have a serverless project on its books, and doesn't plan to adopt one – at least at this point. Instead, its serverless working group is focusing on standards – how to write once and deploy to all serverless/function-as-a-service environments, which all have different formats, runtimes and plumbing. It has working demos and reports into the CNCF's technical committee. There are a number of OSS serverless projects, such as IBM-originated Apache Whisk (underpins IBM Cloud Functions), Oracle's (Apache) Fn, Platform9 Fission (uses Kubernetes), Iron.io IronFunctions, OpenFaaS, Bitnami's Kubeless and Riff (basis of Pivotal Function Service).
A service mesh is an inter-service communication mechanism for microservices. Microservices don't communicate directly with other microservices; instead, they use software called a service mesh or sidecar proxy. Service meshes variously support some network functions, such as resiliency and service discovery; some also support traffic management, policy enforcement, observability, and security and identity. They act as a control plane, leaving the developer to focus on the business logic. Service meshes are effectively solving the same kinds of problems that enterprise service buses and message-oriented middleware tried to in the world of service-oriented architecture. It means that, for example, content servers, order management and payment processes can all interact. Service mesh implementations include Envoy (via NGINX and HAProxy), which was developed by Lyft; Istio (uses Envoy and is used by Google, IBM, Lyft, Cisco and F5 Networks' Aspen Mesh, among others); Conduit (via Bouyant); and Linkerd (from a Twitter technology and now a CNCF incubation project).
PaaS and the cloud-native world
Viewed through the lens of serverless, is the world of PaaS in danger of being disintermediated? Serverless looks set to deliver, for all intents and purposes, what PaaS should have been doing a decade ago – making infrastructure invisible. Moreover, the astonishing number of value-added services being introduced by the hyperscalers collectively serve as de facto PaaS. Red Hat's OpenShift PaaS was introduced in 2011, but it's now more or less pivoted to become a 'go to' for enterprise Kubernetes with the introduction of OpenShift Container Platform (Kubernetes is a Google invention).