Introduction

In my last post [1] I discussed how cloud computing is changing the way enterprise software is being built, operated, and sold. Businesses who understand the profound impact of cloud computing on their products are embracing cloud-native software development & operations and are poised for great success.

In this post I will attempt to define the characteristics of cloud-native software applications i.e. what exactly does it mean to be “cloud native”? Simply put, cloud-native means that the application is designed to run optimally on the cloud. But that does not help understand what makes cloud-native applications different and how we can develop them. So, let’s dig a little deeper:

Computing and Programming Paradigms

Programming paradigms define how applications are designed and developed. They define how software data and behavior are packaged, and translated into executing programs. To take advantage of the latest infrastructure, programing paradigms tend to mimic and adapt-to the current computing paradigms.

In the mainframe era, we had imperative programming where entire applications were organized as a series of instructions (e.g. procedures) that operated on shared memory data structures. Next in the client-server era, object-oriented programming became mainstream. In this evolution, software was packaged based on domain roles (i.e. objects) and separated into distribution tiers. Applications were composed of two or more tiers, and each tier had a clearly defined role providing separation of concerns.

With cloud computing, infrastructure is now abstracted and delivered as a service and on-demand. To take maximum advantage of Infrastructure-as-a-Service (IaaS) capabilities, cloud applications are also built as a collection of loosely coupled services. By some estimates [2] , applications designed for clouds can be 70% more efficient than running traditional applications migrated to a cloud.

Cloud native applications are service-oriented.

Characteristics of Cloud-native Applications

A cloud-native application is composed of multiple services and each service is elastic, resilient, and composable. Let’s dissect this a bit:

The Application is composed of multiple services: what looks like a single application to the end user, for example a Software-as-a-Service (SaaS) human resources application, or a streaming music service, is actually delivered by a set of co-operating services. Clients interact with the application as a whole; typically via a single API. However, internally the application is made up of multiple cooperating services, much like an object-oriented application is made up of multiple cooperating objects.

Each service is elastic: this means that each service can scale-up or scale-down independently of other services. Ideally the scaling is automatic, based on load or other defined triggers. Cloud computing costs are typically based on usage, and being able to dynamically manage scalability in a granular manner enables efficient use of the underlying resources.

Each service is resilient: this means that each service is highly-available and can survive infrastructure failures. This characteristic limits the failure domain, due to software bugs or hardware issues.

Each service is composable: this implies that the service is designed to allow it to be part of other applications. At the minimum, each Service has an Application Programming Interface (API) that is uniform and discoverable, and in addition can have well defined behaviors for registration, discovery, and request management.

SOA Deja Vu?

To many of us this may sound like Service-Oriented Architecture (SOA) from the early 2000’s. But didn’t we already declare SOA as dead somewhere around 2009? [3]

Yes, the fundamentals of service-orientation are not new. Just as object-oriented design and programming were first researched in the late 1950s and early 1960s, but did not become a mainstream approach till the early 1990s, it is only now that SOA principles are being successfully applied in large-scale systems.

During the SOA wave that occurred in late 1990s and early 2000s, infrastructure was not yet delivered as a service, as it is today. This limited the usefulness of a service-oriented system to mostly being within an enterprise. The implementations were heavily vendor middleware influenced with an Enterprise Service Bus (ESB) being sold as an requirement for SOA. The implementations were hard to integrate, manage and scale and the use case for SOA within the enterprise for the client-server era did not prove to be economically compelling. This relegated the first wave of SOA to something that all enterprise architects agreed to in theory (sounds great!) but not very practical to implement.

Things have changed since then. Cloud computing now delivers infrastructure as a service and at great price-points. A relatively thin layer of middleware, designed using REST architectural constraints and SOA principles can deliver the benefits of a service-orientation. The value proposition is compelling - businesses can now leverage multiple cloud services and operate software at scale, for their customers. The irony here is that its now the enterprise vendors who need to implement service-oriented systems to be successful, and the customers can consume them “as a service”, at low cost and without risk.

Benefits of Cloud-Native Applications

Web and internet giants, like Netflix, Twitter, Square, LinkedIn, have all successfully transformed their software systems to be service-oriented. There are two major drivers for the change:

1. Operate at scale on low-cost IaaS
2. Continuous delivery of software

The early adopters of cloud computing were web, mobile, and SaaS providers who were forced to adopt certain software architectures and operational practices due to unpredictable workloads as well as unpredictable infrastructure.

While most IaaS offerings are fairly stable today, a major side benefit of a cloud-native architecture was the flexibility in deploying and operating software. With a cloud-native application, each individual service could be released independently. Multiple versions of the same service could be running, and software based request management can be used to control which users get access to each version. Metrics were available on actual usage and performance, and fully automated roll-out and roll-back became possible.

This approach in stark contrast to an integrated software approach, where even though the development teams may follow agile development and produce weekly iterations, the business is only able to put out a few major releases in a year. The constraint here is the monolith tiered architecture, which requires integration and tests on a large set of complex features as a whole.

Cloud-native software allows small autonomous teams to quickly deliver features and changes, without waiting months for integration and releases, and measure usage and adapt accordingly. This is the software engineering version of the OODA loop [4] that allows businesses to innovate faster.

Summary

The ability to deliver cloud-native software faster and at scale, allows rapid innovation and will separate the next-generation of business leaders from the rest.

Cloud-native software is optimized for operation on clouds. In this post I outlined the critical characteristics of cloud-native applications:

• Cloud-native applications are service-oriented
• Cloud-native applications are composed of multiple services, and each service is designed to be elastic, resilient, and composable.

In my next post, I will go deeper into the principles and patterns of cloud-native applications.

About

Jim Bugwadia is a co-founder at Nirmata.

References

[1] Jim Bugwadia, The Inflection Point in Enterprise Software

[2] David Linthicum, What Being Cloud Native Really Means

[3] The Burton Group, SOA is Dead; Long Live Services

[4] Adrian Cockroft, Velocity and Volume (or Speed Wins)