Can applications be composed almost entirely of microservices in the cloud, running with a smart user device? That's the promise of serverless applications. Here's how they work, and what they'll mean for your business.

Charles Babcock, Editor at Large, Cloud

February 29, 2016

9 Min Read
<p align="left">(Image: <a href="https://pixabay.com/en/users/kewl-24755/"target="_blank">Kewl</a> via <a href="https://pixabay.com/en/server-room-datacenter-network-90389/"target="_blank">Pixabay</a>)</p>

10 Reasons To Snuggle Up To Python

10 Reasons To Snuggle Up To Python


10 Reasons To Snuggle Up To Python (Click image for larger view and slideshow.)

Application development keeps evolving toward a model that produces code faster and puts it into production more quickly. But no matter how many incremental improvements are made to the process, it never seems fast enough. Can serverless applications help your enterprise deliver the rapid development that today's businesses demand?

Going serverless represents a new pattern, made possible by recent additions of application functions and services in cloud computing. It enables developers to create a host of microservices that only fire when needed, and produce the required functions rapidly and seamlessly.

Amazon's AWS Lambda and API Gateway, as well as Google App Engine Cloud and Google Cloud Functions, are among the services designed to aid in creating and executing serverless applications.

What do serverless applications mean to your business?

Here's one scenario, which involves overcoming buyer uncertainty at the point of decision. Let's say several customers are ready to make a purchase in your company's e-commerce application. But, before completing the order, one of these customers asks for confirmation that a third-party part needed for his order is available.

[ Want to learn more about serverless applications? Attend Building Serverless Applications at Interop 2016. ]

A computer-literate business analyst could spot a business need such as this and upload a snippet of JavaScript to Amazon Web Services in response. This script would automatically fire off whenever it was needed. Knowing buyers' uncertainty at the point of decision had stymied deal completion in the past, your inspired business analyst could create a part-confirmation box on the website for the purchase's final stage.

By clicking on it, the customer would activate a notice to the AWS Lambda cloud service to retrieve the analyst's snippet of JavaScript and run it with the event data. The JavaScript then would trigger a query to the correct third party's distribution center and inspect its inventory database system for the part, bringing back the confirmation needed to allow the purchase to go through.

Lambda's ability to respond to a software event (the shopper's click), retrieve the analyst's code, and quickly run it might prove instrumental in converting your shoppers into buyers.

There would be no long pause, no shifting to another application, no launch of a virtual server in the cloud, and no interjection of a human service representative with off-putting questions. The whole process would be automated and amount to a charge of a few pennies of AWS runtime. At the same time, this confirmation process is always available at an instant's notice. No matter how many buyers might need confirmations at one time, it will scale to meet the traffic.

That's one example of how serverless applications might work. The part-availability confirmation is a microservice. Most applications would be built out of multiple microservices. For a company using them, there would be dozens or hundreds of microservices, sitting in the public cloud until needed, then running in an efficient burst to produce results. The application isn't literally serverless, because there are virtual servers and hosts running somewhere to allow the responses. But, as far as the company's IT staff is concerned, the application always runs and produces business results, without any on-premises server hosting it.

Cloud Provider Offerings

The major cloud providers are offering more and more online functionality as part of their infrastructure services. AWS Lambda is a prime example. It allows outside events or other Amazon services to trigger the running of a microservice or other small piece of code in its environment, without a virtual machine. It can make use of the data streamed to it for the purpose. Instead of being charged for by the hour, the use of the microservice is measured in 100 millisecond units of run time.

One advocate of this style of development is Joe Emison, CTO of BuildFax and leader of an Interop 2016 workshop, Building Serverless Applications, on May 3 in Las Vegas. (Interop is produced by UBM Americas, InformationWeek's parent company.) Emison will discuss how Lambda can be paired with the Amazon API Gateway, an API management service, to create sets of related services for a serverless app. Also on the slate will be use of the Google App Engine cloud and its Firebase real-time database service.

Facebook's Parse is also on the agenda for Emison's Interop workshop, but Facebook announced Jan. 28 that it will be discontinuing its Parse service by Jan. 28, 2017. Parse is a scalable, cross-platform set of tools and services for mobile apps.

Nevertheless, more new services are bound to emerge to support serverless applications. These applications will make use of "cloud-enabled services to automate all these things currently done by hand, and done badly by hand," Emison said in an interview with InformationWeek.

[ How are agile companies changing development? Read 8 DevOps Lessons IT Can Teach The Enterprise. ]

Serverless apps are coming, he said, because they represent a better way to step up the pace of software development. "I agree with Marc Andreessen," Emison said. "Software is eating the world. Companies that can develop software most effectively will be among those that succeed" at thriving in such a world.

His measure of good software development no longer has anything to do with the number of lines of code produced, or functionality captured, by a local programmer. "You have to look at what it means to develop software effectively," he said. In a fast-moving world driven by software, that means looking at how frequently, and quickly, you can adjust it to changing conditions. As Emison said: "How many development cycles can you get against the customer base while it's interested in using the software?"

Still a Need for On-Premises Developers

Even with serverless applications, not everything happens in the cloud, nor does all functionality come from the cloud. There's still a need for on-premises developers "who control the end-user experience," said Emison. These developers should assume the end-user part of the application is running on a powerful smartphone, tablet, or other mobile device. A substantial part of the application logic can reside there, given the growing power of the devices.

In that sense, Web applications, which put all the logic on an Internet server and give the end user a browser or other form of thin user interface display, have been re-architected. In serverless applications, the user's experience is determined by the business logic on the end-user device, as well as the Internet data center server, and it represents a significantly larger share of the application than a display window.

But the serverless developer doesn't have to understand the database server, the messaging system, or the security measures in the cloud. They're being managed elsewhere, by the service provider.

Learn to integrate the cloud into legacy systems and new initiatives. Attend the Cloud Connect Track at Interop Las Vegas, May 2-6. Register now!

 

Earlier this year, Google announced Google Cloud Functions, a set of services suitable for use in building a serverless application. These are a "lightweight, event-based, asynchronous compute solution that allows developers to create small, single-purpose functions that respond to cloud events without the need to manage a server," wrote Forbes contributor and analyst, adviser, and architect at Janakiram & Associates, Janakiram MSV, in a blog post Feb. 9.

With Google Cloud Functions, a developer can supply JavaScript functions that are executed in a Google cloud runtime environment with "no requirement to provision or configure virtual machines. The uploaded snippets are invoked by events” that originate from other Google services, such as its Google Cloud Pub/Sub and Google Cloud Storage," Janakiram wrote.

In other words, it's a serverless application environment that can compete with AWS Lambda and API Gateway.

Jeremy Edberg, former chief reliability engineer for Netflix and now co-founder and chief product officer at CloudNative.io, is an early implementer of serverless applications for his firm. CloudNative.io offers a capability to model a customer's use of cloud services, then allow queries to be launched about it.

"My company is building its entire infrastructure on AWS Lambda and other parts of Amazon," he said in an interview.

The Seattle Times is one example of a company that isn't going all-in on serverless, but nevertheless is an early implementer. The newspaper's website uses an application in AWS Lambda that automatically resizes the images appearing in its articles depending on the nature of the device on which the content is about to be read.

A Serverless Future

"The future is going to be serverless," Edberg predictd. "Containers will be a fad that will quickly disappear. People doing containers will just move on to creating serverless applications."

Although serverless applications are frequently built in JavaScript, Edberg's firm is using Python to create them as microservices that will be triggered by customer queries and events. He thinks the transition from containers to serverless-based microservices will not be difficult, because container users have already started to think of applications as sets of microservices. They simply have to envision them running in a cloud runtime environment, instead of a container.

In the future, said Emison, the enterprise IT staff developer will be focused on constantly improving the logic of the customer's interaction with the business, instead of figuring out how to set up and maintain a database server and other infrastructure issues. The shift in resources will help those businesses that understand the concept of constant updates and punish those that fail to adjust quickly enough. It will be possible to achieve frequent additions to the software used to engage your customers throughout a product's lifecycle.

[Editor's note: This article has been updated to clarify references to AWS Lambda.]

Rising stars wanted. Are you an IT professional under age 30 who's making a major contribution to the field? Do you know someone who fits that description? Submit your entry now for InformationWeek's Pearl Award. Full details and a submission form can be found here.

About the Author(s)

Charles Babcock

Editor at Large, Cloud

Charles Babcock is an editor-at-large for InformationWeek and author of Management Strategies for the Cloud Revolution, a McGraw-Hill book. He is the former editor-in-chief of Digital News, former software editor of Computerworld and former technology editor of Interactive Week. He is a graduate of Syracuse University where he obtained a bachelor's degree in journalism. He joined the publication in 2003.

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like


More Insights