Elasticity is a defining characteristic of the cloud. Cloud’s ability to scale infrastructure resources up and down in a dynamic way gives organizations the flexibility to do more, pay less and operate more efficiently.
But what about the applications themselves that run on the cloud? Are they elastic by definition? Just because an app in the cloud can accommodate huge spikes of traffic does not necessarily mean the app is elastic. It is more likely that the app was built with high-capacity usage in mind. And let us be clear: built for high demand and built to be elastic are two fundamentally different concepts.
True elastic applications are built to know how to handle variable workloads – and they do so on a self-aware basis. That means the elastic app is able to automatically add and subtract resources when certain triggers signal a change of course. Today, we in the industry are using signals from the infrastructure — inbound traffic from the web and data feeds from IoT devices, to name just two. However, an elastic app is watching both the infrastructure and the application itself for signals that tell it to allocate more resources, or shut some down.
Let us consider a scenario of ordering a car through a popular rideshare app, such as Lyft. If there are six people in your family, you know to order a car that can seat seven (six plus the driver). If the driver brings a car that seats nine, there is no capacity problem, but the car is not elastic – it is just big. But if the driver arrives with a car that seats four, and then suddenly adds three more seats as the car pulls up, that is elastic.
Getting back to reality, retailers who rely on Cyber Monday need significantly larger resources that day than on other days of the year. To prepare for this situation, they have a few options. They can build an app with the strength to handle billions of dollars in orders every day – which would be more costly to build and less efficient to run. Or they can build an elastic app that knows, based on the loads that stream in, whether to dynamically expand to the point where it can field the exact flow of incoming orders.
A true elastic app is self-aware, watches the signals of workload behavior and executes code to increase or decrease services based on demand.
The Pros and Cons of Elastic Applications
Elastic apps are easy to spot. Having your apps act in an agile manner gives you the ability to respond better to demands and to organizational constraints. In most industries, you have no idea when you will need to suddenly scale resources, so you do not want to risk being slow on the trigger, waiting for humans to respond. Elastic apps expand and contract automatically, according to the load.
Risk and governance are new concerns. Elastic apps move faster, respond to changes with software and execute larger, more complex resource changes very fast. Having a solid security and governance framework around the elastic app is critical — and not the norm for most teams. Trust is not there for them, and they need to work their way into the new systems more slowly than the technology proceeds. This is a matter of people getting comfortable with the fact the system is elastic. This is new, and new sometimes scares people.
Also, deploying elastic applications can eliminate the need for certain jobs. If an organization does not have to physically scale apps up and down, it can either shift workers to another function, or trim the jobs from their rolls.
Then there is the ever-present issue of finding developers to build elastic apps. The concept is new in the marketplace, so there is a limited amount of talent available to fill these specialized positions. The money you save on managing capacity could get eaten up paying people to build the apps.
How to Create Elastic Applications
Elastic apps differ in form and function. Serverless elastic apps can be stitched together using PaaS layer services, for example. You can connect AWS Lambda functions in ways you never considered using a server architecture. On the Microsoft Azure side, you could use SQL services for databases, and let Azure scale up and down as SQL services are needed for high volumes of queries. Or you could write all the code yourself.
To run elastic apps, you must rethink how you architect and build your applications. You have to build them to be self-aware, responding to triggers that are constantly determining the loads on the platform. This requires a monitoring system that feeds signals to the app related to important aspects of the platform, such as CPU utilization, traffic volume, disk speed and many more. You need to be watching data coming in and have an early warning system that signals when inbound loads are scaling rapidly enough to need additional accommodation. It is like having a control tower.
The goal is to have eyes on the platform to get early warning signals of the loads, before it is too late to respond.
Where Elastic Apps Make Sense
Certain verticals are natural targets for elastic apps. Web-based retailers are subject to wide swings in demand and are perfect for elastic apps. In the medical arena, globally connected dialysis machines will need to scale operations constantly, as usage waxes and wanes across geographies. Then there are apps that leverage the Internet of things (IoT). They are going to have different streams of data coming in, and how the data gets consumed and processed could evolve radically over time.
Today, elastic apps are a small portion of all apps. Forward-thinking developers see them as must- haves, and are pressing to invest for the long haul. In the future, elastic apps will be closer to the norm. Unless the investment in building one is not justified by the value it would deliver, you will generally prefer applications that tailor automatically to your needs.