In October of 2008, The Economist published a special report on a then relatively new, rapidly growing IT development, - cloud computing. In the lead article, technology editor Ludwig Siegele defined cloud computing by first giving a very succinct history of computing:
“In the beginning computers were human. Then they took the shape of metal boxes, filling entire rooms before becoming ever smaller and more widespread. Now they are evaporating altogether and becoming accessible from anywhere… Now,… computing is taking on yet another new shape. It is becoming more centralised again as some of the activity moves into data centres. But more importantly, it is turning into what has come to be called a ‘cloud’, or collections of clouds. Computing power will become more and more disembodied and will be consumed where and when it is needed… It will allow digital technology to penetrate every nook and cranny of the economy and of society…”
I was reminded of Siegele’s decade-old article when recently learning about another, relatively new, IT innovation, - serverless computing, - a name that connotes the increasingly disembodied nature of computing. I first came across the term in a Forrester report on the Top Emerging Technologies to Watch in 2018.
Serverless is an approach to software development for quickly building and deploying applications as a collection of loosely coupled modules and microservices. According to Forrester, “Firms report a better software development experience, rapid scaling of services that compose applications, lower costs, and better infrastructure utilization when workloads are variable. They also spend less time maintaining cloud infrastructure.”
Ten years ago, cloud was viewed as a promising technology about which people said that “there’s a clear consensus that there’s no real consensus on what cloud computing is.” It was clear at the time that something big and profound was going on, although we weren’t totally sure what it was yet. A decade later, those early definitional debates are over. Cloud is now an integral part of a company’s IT strategy, grounded in the day-to-day nuts and bolts of implementing change.
Serverless is closely associated with cloud computing. All major cloud vendors offer serverless technologies to dynamically manage the allocation of hardware and software resources, - including Amazon’s AWS Lambda, Google’s Cloud Functions, Microsoft’s Azure Functions, and IBM’s Cloud Functions. There’s also an open-source serverless platform, Apache OpenWhisk, on which IBM’s offerings are based, as well as those from other vendors. Serverless execution environments support the development of lightweight applications or microservices in a variety of languages.
I particularly like this recent article on Serverless Architectures by Mike Roberts. Roberts sees serverless as the next evolution of cloud systems. As was the case with cloud in its early years, there’s no one clear view of what serverless is. It encompasses two different but overlapping software design methods: Backend as a Service (BaaS), - which significantly incorporate third-party, cloud-hosted applications and services, e.g., authentication, search, business services and data bases; and Functions as a Service (FaaS), - which include custom code written by the application developers, then uploaded to the cloud, only invoked when triggered by specific events, and fully managed by the cloud provider.
All designs involve tradeoffs. I found it useful to compare the serverless methodology with that of traditional server-based applications. Server-based applications tend to be long lived. Once loaded and started, the applications are ready and listening for requests so they can quickly handle them. Developers are responsible for provisioning the resources required to support their applications, including estimating their types and capacities, how they should be allocated among the various components, and how they should scale based upon the applications’ actual loads.
Cloud makes these activities easier, but they must still be done. Cloud providers must be given the estimated resources required so they can do their own planning and effectively support their various customers. And, since resource planning is not a precise activity, developers will generally estimate a larger load than expected and over-provision the required resources, whether in-house or through a cloud provider. As a recent WSJ CIO Journal article noted:
“By purchasing more cloud computing capacity then they really need - even as a deliberate strategy to safeguard against crashing key systems - or buying advanced reserves that they will never use, companies across all industries may be overspending on cloud services by an average of 42%, according to data compiled by Densify, a cloud optimization firm that works with big companies worldwide. That can translate into hundreds of thousands or even millions of lost dollars in IT budgets a year, depending on the size of cloud deployments, the firm said. Its estimates are based on input from 200 cloud-industry professionals and 70 global companies over the last year.”
Serverless is based on a very different resource management model. The biggest overhead is in the design of the application. Serverless applications are woven or composed from a collection of loosely coupled, lightweight modules or microservices. Each such module is only given resources when triggered by another application module or invoked by an external function. Serverless modules are expected to run for a relatively short time, and are generally limited in how long each invocation is allowed to run. Once the module finishes running, its resources are returned to the serverless platform and made available to other modules that need them. The modules are stateless, meaning that no information is carried over or remembered between invocations. Any information that needs to be persistent across invocations must be explicitly stored in a separate file or data base.
Given the special nature of serverless applications, developers no longer need to plan, allocate or provision module instances. Once a module is invoked, the serverless platform will figure out the resources it requires and automatically provision them. As other modules are invoked, the platform will automatically allocate them the required resources, and take them away once they’ve finished running. Developers are only charged for the resources used during the time their modules actually run. If invoked infrequently, or if invocations are spiky, there’s no need to plan for and pay for just-in-case-resources.
“Serverless architectures may benefit from significantly reduced operational cost, complexity, and engineering lead time, at a cost of increased reliance on vendor dependencies and comparatively immature supporting services,” notes Roberts. While there’s a lot to like in serverless, his article also points out a number of trade-offs and drawbacks.
One of them is the potential for delays in response to a request. Unlike a traditional server application, there’s no code constantly running, looking out for potential requests. Serverless code is only instantiated when the function is actually invoked. Such a cold start latency might not be acceptable for certain applications. However, if the function is frequently invoked, there’s a good chance that a previous invocation is still around and the delays will be significantly shorter.
Vendor lock-in is another potential drawback. “It’s very likely that whatever Serverless features you’re using from one vendor will be implemented differently by another vendor,” writes Roberts. “If you want to switch vendors you’ll almost certainly need to update your operational tools (deployment, monitoring, etc.), you’ll probably need to change your code (e.g., to satisfy a different FaaS interface), and you may even need to change your design or architecture if there are differences to how competing vendor implementations behave.”
Testing is another potential concern. While unit testing serverless modules is relatively simple, testing and debugging a serverless application composed of many such modules is quite hard.
“Serverless is not the correct approach for every problem, so be wary of anyone who says it will replace all of your existing architectures,” writes Roberts in conclusion. “Be careful if you take the plunge into Serverless systems now, especially in the FaaS realm. While there are riches - of scaling and saved deployment effort - to be plundered, there also be dragons - of debugging and monitoring - lurking right around the next corner…”
“Serverless services, and our understanding of how to use them, are today (May 2018) in the ‘slightly awkward teenage years’ of maturity.” So was cloud computing not all that long ago, and over the years that teenager has nicely grown up. “There will be many advances in the field over the coming years, and it will be fascinating to see how Serverless fits into our architectural toolkit.”
Comments