You likely have heard the term serverless
(and wondered why someone thought it didn’t use servers). You may have
heard of Functions-as-a-Service (FaaS) – perhaps in the context of
Lambda from Amazon Web Services, introduced in 2014. You’ve probably
encountered event-driven programming in some form. How do all these
things fit together and, more importantly, when might you consider using
them? Read on.
Servers are still involved; developers just don’t need to think about them in a traditional way.
Let’s start with FaaS. With FaaS, you write code to accomplish some
specific task and upload the code for our function to a FaaS provider.
The public cloud provider or on-premise platform then does everything
else necessary to provision, run, scale, and manage the code. As a
developer, you don’t need to do anything other than write your code and
wire it up to other functions and services. FaaS provides programmers
with an abstraction that allows them to focus on just writing code that
takes action in response to events rather than interacting with the
underlying server (whether bare metal, virtualized, or containerized). [ Struggling to explain containers to non-techies? Read also: How to explain containers in plain English. ]
Now enter event-driven programming. Functions run in response to
external events. It could be a call generated by a mouse click in a web
app. But it could also be in response to some other action. For example,
uploading a media file could trigger custom code that transcodes the
file into a variety of formats.
Serverless then describes a set of architectural patterns that build
on FaaS. Serverless combines custom FaaS code with common back-end
services (such as databases and authentication) connected primarily
through an event-driven execution model. From the perspective of a
developer, these services are all managed by a third-party (whether an
ops team or an external provider). Of course, servers are still
involved; developers just don’t need to think about them in a
traditional way.
Why serverless?
Serverless is an emerging technology area. There’s a lot of interest
in the technology and approach although it’s early on and has yet to
appear on many enterprise IT radar screens. To understand the interest,
it’s useful to consider serverless from both operations and developer
perspectives.
PaaS and FaaS are best thought of as being on a continuum rather than being entirely discrete.
For operations teams, one of the initial selling points of FaaS on
public clouds was its pricing model. By paying only for an ephemeral
(typically stateless) function while it was executing, you “didn’t pay
for idle.” In general, while this aspect of serverless is still
important to some, it’s less emphasized today. As a broader concept that
brings in a wide range of services of which FaaS is just one part, the
FaaS pricing model by itself is less relevant.
However, pricing model aside, serverless also allows operations teams
to provide developers with a self-service platform and then get out of
the way. This is a concept that has been present in platforms like OpenShift from the beginning. Serverless effectively extends the approach for certain types of applications.
The arguably more important aspect of serverless is increased developer productivity. This has two different aspects.
The first is that, as noted earlier, FaaS abstracts away many of the
housekeeping details associated with server provisioning and management
that are often just overhead for developers. In practice, this may not
appear all that different to developers than a Platform-as-a-Service
(PaaS). FaaS can even use containers under the covers just like a PaaS
typically does. PaaS and FaaS are best thought of as being on a
continuum rather than being entirely discrete.
The second is that, by offering common managed services out of the
box, developers don’t need to constantly recreate them for new
applications.
Where does serverless fit?
Serverless targets specific architectural patterns. As described
earlier, it’s more or less wedded to a programming model in which
functions and services react to each other in an event-driven and
largely asynchronous way. Functions themselves are generally expected to
be stateless, handle single tasks, and finish quickly. The fact that
the interactions between services and functions are all happening over
the network also means that the application as a whole should be fairly
tolerant of latencies in these interactions.
You can think of FaaS as both simplifying and limiting.
While there are overlaps between the technologies used by FaaS, microservices,
and even coarser-grained architectural patterns, you can think of FaaS
as both simplifying and limiting. FaaS requires you to be more
prescriptive about how you write applications.
Although serverless was originally most associated with public cloud
providers, that comes with a caveat. Serverless, as implemented on
public clouds, has a high degree of lock-in to a specific cloud vendor.
This is true to some degree even with FaaS, but serverless explicitly
encourages bringing in a variety of cloud provider services that are
incompatible to varying degrees with other providers and on-premise
solutions.
As a result, there’s considerable interest in and work going into open source implementations of FaaS and serverless, such as Knative and OpenWhisk, so that users can write applications that are portable across different platforms. [ What's next for portable apps? Read also: Disrupt or be disrupted: 3 trends enabling next-level IT agility. ]
The speedy road ahead
Building more modern applications is a top priority for IT executives
as part of their digital transformation journeys; it’s seen as the key
ingredient to moving faster. To that end, organizations across a broad
swath of industries are seeking ways to create new applications more
quickly. Doing so involves both making traditional developers more
productive and seeking ways to lower the barriers to software
development for a larger pool of employees.
Serverless is an important emerging service implementation
architecture that will be a good fit for certain types of applications.
It will coexist with, rather than replace, architecture alternatives
such as microservices used with containers and even just virtual
machines. All of these architectural choices support a general trend
toward simplifying the developer experience and making developers more
productive.
No comments:
Post a Comment