Creativa - Fotolia
Explore cloud computing's effect on application development
AWS and cloud computing changed the way organizations build and run applications. Explore why that happened and see what to expect in the future as more businesses jump on board.
When Amazon debuted its cloud computing platform over a decade ago, it set off a major shift in the world of technology and put the IT market on a trajectory to become the 100 billion dollar industry it is today.
Cloud services have evolved into a multifaceted market that focuses on different types of virtual infrastructure, development platforms and managed applications. Although cloud computing didn't invent virtual machines (VMs) -- VMware popularized VMs on x86 servers a few years earlier -- the ability to rent capacity on-demand was a technical and business innovation.
The intervening years have seen cloud service providers unleash a torrent of services that extend far up the application stack, beyond the compute, storage and networking services that defined early cloud offerings. AWS alone has nearly 200 products available from dozens of data centers around the world, and those figures will only grow.
As AWS grew, it became more sophisticated and even influenced architectural decisions. First, it affected infrastructure engineers who planned cloud deployments, and later, it changed how developers designed applications.
Similar to the way the rise of PCs and x86 servers created a wave of client-server enterprise applications, the interest in cloud sparked new development languages and frameworks for browser-based applications. The past decade has seen developers of all stripes create new design patterns, development platforms and workflows based on cloud services, containers and automation tools.
As illustrated in the diagram below, the cloud transition is merely the latest in a cyclic evolutionary path that started with centralized mainframes.
The cycle of centralization and decentralization outlines the defining products of each generation of application development, in the cloud and elsewhere. However, as developers adapted to different types of infrastructure and deployment paradigms, they simultaneously followed another form of architectural evolution. This began to focus on software design that progressively disaggregated applications into smaller components.
The cost and operational complexity of mainframes fostered monolithic designs, with application code packaged and run as a unit. The rise of distributed client-server systems and browser-based UIs motivated the first decoupling of applications into modular, n-tier architectures that split functionality across several elements.
The availability of an enormous variety of cloud services -- particularly container runtime environments, serverless functions, managed databases and analytics services -- has accelerated the trend toward granularity. This retrospective on the origins and implications of cloud computing shows that the cloud is a composite of many services at various levels of logical abstraction. These various services, along with containers, have given rise to the concept of cloud native as the next development in app architecture.
Cloud-native building blocks
Although cloud services have influenced development and deployment practices in many ways, our focus is on the next stage of cloud evolution -- namely the development of cloud-native applications.
There isn't a standard definition of cloud-native, and it's a topic experts endlessly debate. However, a cloud-native application tends to be described as an application developed on the cloud. Ultimately, cloud-native applications are designed to opportunistically exploit all available cloud services to maximize performance, scalability, reliability, security, adaptability and manageability at the lowest possible cost.
In this conception, cloud services are like a box of computational Lego pieces, each with a defined set of features and standard interfaces, usually APIs, for functional control and data I/O that are put together to build an application. Like Legos, a set of pieces can be grouped as a model or template that can be rapidly replicated or reused as a functional module.
After more than a decade of evolution, cloud services now offer a staggering variety of building blocks.
Cloud-native design entails piecing together these components to build custom applications. Cloud savvy designers prefer higher abstraction levels to minimize the effort and this enables greater focus on an application's differentiating features.
Cloud-native app development is closely connected to the processes for software development, integration, testing and deployment. These are typically unified under a DevOps organization or by the less formal adoption of DevOps principles and methodologies.
But don't conflate the two. It's possible to do cloud-native development without using DevOps; and not all DevOps organizations target cloud-first applications. However, cloud-native development is enhanced by DevOps processes. Likewise, DevOps processes greatly benefit from programmable cloud development services that systematize and automate repeatable processes.
For example, organizations with advanced DevOps processes and culture tend to have much shorter application deployment cycles, often multiple times per day, than those not using standardized, repeatable, automated processes.
Cloud-native tradeoffs
And while the cloud has ushered in a great deal of benefits for app development, it's not without its downsides. The most significant risk of cloud-native design is vendor lock-in when using high-level services. Although cloud services wrapped in APIs insulate users from the underlying implementation, the nonstandard nature of the APIs themselves makes porting applications between providers difficult.
Tools have emerged to avoid lock-in. Notably, Kubernetes has become the de facto standard for container management and containerized applications. Indeed, lock-in avoidance is often the chief reason many system architects select a container-based implementation over using native cloud services.
Data gravity, namely the difficulty and expense of moving massive amounts of data from one environment to another, is another drawback of cloud-native designs. IT shops often mitigate these concerns through the use of hybrid environments. In this scenario, the primary database and file repositories are kept on private infrastructure and the cloud infrastructure contains replicas or cached data subsets.
Trends and predictions
Cloud providers have seen remarkable revenue growth in recent years. A big part of that is due to enterprises' increased adoption, and the cloud evolution doesn't look like it will stop any time soon. In fact, early indications show the COVID-19 pandemic has only accelerated the trend.
Enterprises are under tremendous financial pressure to reduce costs and improve efficiency. And they've come to realize that their IT departments can't match the cloud providers' economies of scale, operational efficiencies, and vast research and development efforts that fuel the outpouring of new services.
Many of these companies that are new to the cloud will migrate existing applications to virtual infrastructures. Once ensconced, the cloud will be the home for all their new applications. Those that exploit everything the cloud providers have to offer, including higher-level services and development platforms, will have a competitive advantage. This will put even greater emphasis on the value of cloud-native development.
You can also expect many enterprises to pressure providers to collaborate on a cloud-neutral abstraction model, description language and deployment tools that simplify the migration of cloud-native applications between environments. The open application model (OAM) is a promising first step, initially focused on container-based microservices and Kubernetes environments.
It's unclear how eager the OAM community is to extend the model to higher-level cloud products like serverless functions, distributed data analytics, blockchain, or AI and machine learning. Still, it's the type of multivendor effort that could lead to greater application portability.
