Serverless computing is a hot topic right now\u2014perhaps even hotter than
\nDocker containers. Is that because serverless computing is a replacement
\nfor containers? Or is it just another popular technology that can be
\nused alongside containers? In this post, I take a look at what you need
\nto know about serverless computing, and how it should figure into your
\nIT strategy.<\/p>\n
Serverless Is Not Server-less<\/h2>\n
But first, let\u2019s clear up one point: As you may already know,
\nserverless computing does not mean that there are no servers involved.
\nIt\u2019s a cloud-based service, and just like everything else in the cloud,
\nit runs on servers. That said, serverless is called serverless because
\nthe service provider handles all of the server-side IT. All you need to
\ndo is write code and deploy it. The serverless computing provider takes
\ncare of just about everything else. So your experience is serverless,
\neven if the underlying infrastructure is not.<\/p>\n
How Serverless Works<\/h2>\n
How does it work? One of the most popular serverless platforms is AWS
\nLambda. To use it, you write code (in C#, Java, Node.js, or Python),
\nset a few simple configuration parameters, and upload everything (along
\nwith required dependencies) to Lambda. In Lambda terminology, the
\npackage that you\u2019ve uploaded is called a function. You can run the
\nfunction by calling it from an application running on an AWS service
\nsuch as S3 or EC2. Lambda then deploys your function in a container,
\nwhich persists until your function has done its job, then disappears.
\nThe key point to keep in mind is that Lambda takes care of provisioning,
\ndeploying, and managing the container. All you do is provide the code
\nthat runs in the container. Everything else goes on behind the scenes.<\/p>\n
A Serverless World?<\/h2>\n
Does this mean that we now live in a world where software developers and
\nIT teams no longer need to deal directly with containers, or with
\nnuts-and-bolts backend IT at all? Will you be able to just write code,
\ntoss it to Lambda, and let AWS take care of everything else? If that
\nsounds too good to be true, it\u2019s for a very good reason\u2014It is too
\ngood to be true. Serverless computing of the type represented by AWS
\nLambda can be an extremely valuable resource, and if it isn\u2019t already
\npart of your DevOps delivery chain, it probably should be. The key word,
\nhowever, is \u201cpart.\u201d Serverless computing is very well suited to a
\nvariety of tasks, but it is far from being an all-around substitute for
\ndeploying and managing your own containers. Serverless computing is
\nreally designed to work with containers, rather than replacing them.<\/p>\n
What Serverless Computing Does Well<\/h2>\n
What, then, are the advantages of serverless computing? When used for
\nthe kinds of services which it was designed to host, serverless
\ncomputing can be:<\/p>\n
Inexpensive<\/h3>\n
With serverless, you typically pay only for the actual time and volume
\nof traffic used. Lambda, for example, breaks its time-based pricing down
\ninto increments of 100 milliseconds. The actual cost is generally quite
\nlow as well, in part because serverless functions are small, perform
\nrelatively simple tasks, and run in generic containers with very little
\noverhead.<\/p>\n
Low maintenance<\/h3>\n
The list of things that you don\u2019t need to do when you deploy a function
\non a serverless platform is much longer than the list of things that you
\ndo need to do. Among other things, you don\u2019t need to provision
\ncontainers, set system policies and availability levels, or handle any
\nbackend server tasks, for that matter. You can use automatic scaling, or
\nmanually scale use by means of some simple capacity-based settings, if
\nyou want to.<\/p>\n
Simple<\/h3>\n
The standardized programming environment and the lack of server and
\ncontainer-deployment overhead means that you can focus on writing code.
\nFrom the point of view of your main application, the serverless function
\nis basically an external service which doesn\u2019t need to be closely
\nintegrated into the application\u2019s container ecosystem.<\/p>\n
Serverless Use Cases<\/h2>\n
When would you use serverless computing? Consider these possibilities:<\/p>\n
- \n
- Handling backend tasks for a website or mobile application. A
\nserverless function can take a request (for information from a user
\ndatabase or an external source, for example) from the site or
\napplication frontend, retrieve the information, and hand it back to
\nthe frontend. It\u2019s a quick and relatively simple task that can be
\nperformed as needed, with very little use of frontend time or
\nresources\u2014billing only for the actual duration of the backend
\ntask.<\/li>\n - Processing real-time data streams and uploads. A serverless function
\ncan clean up, parse, and filter incoming data streams, process
\nuploaded files, manage input from real-time devices, and take care
\nof other workhorse tasks associated with intermittent or
\nhigh-throughput data streams. Using serverless functions moves
\nresource-intensive real-time processes out of the main application.<\/li>\n - Taking care of high-volume background processes. You can use
\nserverless functions to move data to long-term storage, and to
\nconvert, process, and analyze data, and forward metrics to an
\nanalytics service. In a point-of-sale system, for example,
\nserverless functions could coordinate inventory, customer, order,
\nand transaction databases, as well as intermittent tasks such as
\nrestocking and flagging variances.<\/li>\n<\/ul>\n![\"network\nimage\"](\"http:\/\/cdn.rancher.com\/wp-content\/uploads\/2017\/10\/09091352\/network-2402637_1280-1024x576.jpg\")
<\/p>\nThe Limits of Serverless Computing<\/h2>\n
But serverless computing has some very definite limits. Lambda, for
\nexample, has built-in restrictions on size, memory use, and time
\navailable for a function to run. These, along with the limited list of
\nnatively supported programming languages, are not necessarily intrinsic
\nto serverless computing at a fundamental level, but they reflect the
\npractical constraints of the system. It is important, for example, to
\nkeep functions small and prevent them from taking up too much of the
\nsystem\u2019s resources in order to prevent a relatively small number of
\nhigh-demand users from locking everyone else out, or overloading the
\nsystem. There are also some built-in limits that arise out of the basic
\nnature of serverless computing. For instance, it may be difficult or
\nimpossible to use most monitoring tools with serverless functions, since
\nyou typically have no access to the function\u2019s container or
\ncontainer-management system. Debugging and performance analysis may thus
\nbe restricted to fairly primitive or indirect methods. Speed and
\nresponse time can also be uneven; these limits, along with the
\nconstraints on size, memory, and duration, are likely to limit its use
\nin situations where performance is important.<\/p>\nWhat Containers Can Do Better<\/h2>\n
The list of things that containers can do better than serverless
\nfunctions is probably too long and detailed to present in a single
\narticle. What we\u2019ll do here is simply point out some of the main areas
\nwhere serverless functions cannot and should not be expected to replace
\ncontainer-based applications.<\/p>\nYou Can Go Big<\/h3>\n
A container-based application can be as large and as complex as you need
\nit to be. You can, for example, refactor a very large and complicated
\nmonolithic application into container-based microservices, tailoring the
\nnew architecture entirely to the requirements of the redesigned system.
\nIf you tried to refactor the same application to run on a serverless
\nplatform, you would encounter multiple bottlenecks based on size and
\nmemory constraints. The resulting application would probably be composed
\nof extremely fragmented microservices, with a high degree of uncertainty
\nabout availability and latency time for each fragment.<\/p>\nYou Have Full Control<\/h3>\n
Container-based deployment gives you full control over both the
\nindividual containers and the overall container system, as well as the
\nvirtualized infrastructure on which it runs. This allows you to set
\npolicies, allocate and manage resources, have fine-grained control over
\nsecurity, and make full use of container-management and migration
\nservices. With serverless computing, on the other hand, you have no
\nchoice but to rely on the kindness of strangers.<\/p>\nYou Have the Power to Debug, Test, and Monitor<\/h3>\n
With full control over the container environment comes full power to
\nlook at what goes on both inside and outside of containers. This allows
\neffective, comprehensive debugging and testing using a full range of
\nresources, as well as in-depth performance monitoring at all levels. You
\ncan identify and analyze performance problems, and fine-tune performance
\non a microservice-by-microservice basis to meet the specific performance
\nneeds of your system. Monitoring access at the system,
\ncontainer-management, and container levels also makes it possible to
\nimplement full analytics at all of these levels, with drill-down.<\/p>\nWorking Together<\/h4>\n
The truth is that serverless computing and containers work best when
\nthey work together, with each platform doing what it does well. A
\ncontainer-based application, combined with a full-featured system for
\nmanaging and deploying containers, is the best choice by far for
\nlarge-scale and complex applications and application suites,
\nparticularly in an enterprise or Internet environment. Serverless
\ncomputing, on the other hand, is often best for individual tasks that
\ncan easily be run in the background or accessed as outside services.
\nContainer-based systems can hand off such tasks to serverless
\napplications without tying up the resources of the main program.
\nServerless applications, for their part, can provide services to
\nmultiple clients, and can be updated, upgraded, or switched out with
\nother serverless applications entirely independently of the container
\nsystems that use their services.<\/p>\nConclusion<\/h2>\n
Are serverless computing services and containers competing platforms?
\nHardly. Container-based and serverless computing are mutually supporting
\nparts of the ever-evolving world of contemporary cloud- and continuous
\ndelivery-based software.<\/p>\n