Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week, four things that caught my eye from Amazon Web Services’ re:Invent 2022 conference: SnapStart turbocharges Lambda, Graviton3E ARM HPC SoC, AWS continues hiring, and AWS’s origin story. (more…)
Function as a Service (FaaS), the popular incarnation of serverless computing, along with containers, has played an important role in the migration from monolithic application architectures to those based on microservices. Its introduction has changed the way developers think about infrastructure and application development. While at the same time, it has also driven evolution in the consumption-based infrastructure models we saw introduced with the advent of elastic computing.
FaaS has simplified broad adoption of value-add platform services from the major cloud service providers (CSPs) such as database and authentication services. It has quickly grown to become a viable infrastructure option for developers and IT professionals alike, serving as another tool in the chest – perfect for short-lived or ephemeral tasks. In recent months, we’ve seen announcements from content delivery network (CDN) providers touting a new breed of FaaS offerings promising low latency, workflow customization and cost containment.
CSP FaaS resides in regional hyper scale data centers with the number of data centers in a region typically in the low single digits. These are the same data centers where the myriad of infrastructure and platform services are offered. Enterprises spin up their applications in virtual private clouds in a single region, sometimes they configure a backup region but even with today’s tools it is still complicated to manage data replication/consistency and ensure environments are kept in lockstep.
In contrast to CSP FaaS, CDN FaaS solutions are highly distributed with various PoP locations. These CDN FaaS architectures are typically integrated with the providers’ edge delivery locations. Depending on vendor architecture, there could be hundreds of edge locations. Whereas CSP FaaS benefits from being collocated with platform services, CDN FaaS benefits from being closest to CDN action, where end-user requests/responses are received and processed. This is where edge computing comes into play because it minimizes latency while allowing for custom content delivery workflows.
Developers use functions to customize content delivery workflows to create more compelling user experiences. Up to this point, CDNs provided limited capability for developers to define custom workflows via their own code. Flexibility has been limited to predefined “rewrite rules” and custom behaviors are the product of professional services-led engagements, which is not exactly developer friendly. CDN FaaS changed this, handing power to developers to deploy code and create unique, differentiated user experiences.
It is important to minimize latency between application services that rely on FaaS to avoid program timeouts. CSP FaaS options typically offer a broad range of event-triggers and run-times/programming languages to support developer preferences and align with the other elements of the development environment.
CDN FaaS has request triggers that are integrated with end-user or origin server request/response flows. FaaS invocations are typically a result of an end-user requesting content or an origin server providing a response that needs to be customized on a per end-user basis to reflect their preferences. The scale and latency expectations are so demanding that the run-time options are often limited to those that provide the lowest memory footprints and highest performance. CDN FaaS can also take advantage of the caching technologies further improving latency to complete functions – especially when remote service or network calls are involved.
For CSP FaaS, the pricing model is two dimensional. It is based on the number of requests combined with the allocated memory and the elapsed time of function execution. Some of the CSPs are offering generous free tiers to entice customer adoption – and remember, Function as a Service drives adoption of many of the CSP’s higher value platform services.
When it comes to CDN FaaS, the pricing models are similar, some organizations are charging for requests only but they limit memory foot and the time a given function is allowed to run. However, there is typically a premium to run FaaS in those highly distributed edge locations. Which is no surprise because cost models are higher for distributed/global build outs than centralized models. Also, due to the nature and demands of web and video services, request volumes are likely to be an order of magnitude higher than CSP FaaS requests.
Function as a Service is an important part of our infrastructure as a service (IaaS) choice but it’s unlikely enterprises make a CSP solely on the FaaS offering. Typically, the decision is based on what value-add platform servers are available to build and support the application, and how seamless can those services be integrated with FaaS.
For CSP FaaS, it is all about the bigger picture, the infrastructure and platform choices. This is also true with CDN FaaS because it is unlikely a CDN purchasing decision will be made on that CDN’s FaaS capabilities in isolation. The selection criteria will include FaaS but the larger weighting factors will include the content delivery capabilities, such as global reach, capacity, origin offload, feature support and so on.
Overall, CSP FaaS are optimized for flexibility, multiple run-times, broad range of request triggers and tight coupling with CSPs’ higher-value platform services. Latency is important but the focus is within the CSP region or customer’s VPC and the use cases are often enterprise applications for B2B technology companies. Meanwhile CDN FaaS is all about performance, run-time efficiency and latency. It’s about running the functions in conjunction with the CDN – closest to where end-user requests originate and media responses are delivered. CDN FaaS requires enormous scale – on a global scale versus a single, centralized region.
Zero-configuration hosting solutions such as Zeit Now and Netlify are taking the frontend community by storm due to their ease of use. If we add static site generators such as Gatsby/Next.js/Nuxt.js/Hugo/Jekyll to the mix and deploy our statically generated pages to a content delivery network (CDN), we get something highly desired with minimal effort: distributed auto-scaling applications with zero configuration.
The usage of static site generators and CDNs became quite popular, so much so that Netlify decided to give it a name: JAMstack. At first, this might not strike you as something very newsworthy. Haven’t we all deployed static sites such as blogs or documentation on CDNs? What is different about this approach?
To answer that, let’s first look at the definition that is typically used to explain JAMstack: The JAMstack is a static HTML site, rebuilt automatically every time you update the content, and deployed directly to a CDN.
Of course, that still does not explain why this approach is different. The first time I read this definition, I wondered how I could ever build something more dynamic than a blog with such a stack. However, note that nothing in the previous description says that every element of our site has to be statically generated. In fact, the JAM acronym stands for JavaScript, APIs and Markup, where the letter A is the answer to dynamic content.
The idea is to pregenerate markup where you can and then enrich these statically generated pages with dynamic content fetched from APIs. The APIs of choice in a JAMstack application are typically APIs from third-party services (SaaS platforms) or custom-built with Functions as a Service (FaaS). Both Netlify and Zeit have great zero-configuration FaaS offerings to write APIs for your JAMstack.
In essence, developers in the JAMstack community are often looking for a specific set of requirements:
By combining easy-to-use hosting solutions, static site generators, CDNs and scalable APIs in one stack, we can relatively easily get these requirements.
Imagine that you are building a social network for professionals on which professionals can create profiles. Professionals create profiles to promote their skills, and companies search the network to hire professionals for specific projects. For such an application, you need to store, search, filter and paginate data.
To build such an application, you need a database, but not just any database. Ideally, you want to avoid losing the zero-configuration, pay-as-you-go, scaling and speed benefits that a JAMstack application typically delivers. There are several features a database can possess that make it a perfect fit for a JAMstack application.
In this article, we will describe these features and explain how each of them makes a database a better candidate for a JAMstack application. Since such applications often rely on serverless functions, many of these properties also apply for applications built with FaaS.
Multi-Region, Globally Replicated
To understand why multi-region distribution is desirable, let’s revisit why static websites on CDNs are incredibly fast. A CDN is fast to deliver your content because it contains copies of your content at different locations. When content is requested from the CDN from a specific location, it will attempt to deliver that content from the closest location to the requestor. In order to get an idea of how much that matters, take a glance at the Zeit CDN status page which shows you the difference in latency between your current location and other locations. By deploying our applications to a CDN, our pages automatically load from the closest location to the user, which results in low loading latencies. And low latencies result in a great user experience.
In order to keep this user experience, the dynamic data that will be loaded from our APIs has to exhibit low latencies as well, and the best way to achieve this is to use a distributed database. Databases that feature multi-region replicas such as FaunaDB, Google Spanner or Amazon Aurora not only provide the dynamic querying that you need, but also deliver your data from the closest location, just like a CDN.
Connectionless
Many traditional databases are not connectionless, which means that they require persistent connections with the process that queries the database. There is often a limit on the number of connections that a database can handle, and setting up a connection takes time and puts more strain on the database. A database that supports a JAMstack application will either be called from the frontend (if it’s possible to do securely) or from serverless functions. An increase in the number of users increases the number of running functions or frontend calls.
Having a limit on connections and/or creating/destroying many connections then quickly becomes a problem. An ideal JAMstack database behaves like an API; it does not require connections. There is an excellent article on this topic that describes the connection problem from a FaaS perspective.
Flexible Security
Providing security out-of-the-box takes away tedious configuration from developers. If this security layer can also provide a means to securely access the database from the frontend, we can potentially write our application backendless, eliminating an extra hop and reducing the low latency we’ve gained from distribution even more. When a database is connectionless and can be accessed securely from the front-end, we consider it to be frontend-friendly. However, security requirements can be complex. If we completely rely on the database security layer, it has to be flexible enough to express custom rules. Firebase Cloud Firestore, FaunaDB and the upcoming Userbase offer direct access via clients, like browsers.
Scaling and Pay-as-You-Go
Before we add a database, our typical JAMstack application is completely auto-scaling and pay-as-you-g(r)o(w), which is considered an advantage for many startups. We only pay for the CDN bandwidth and function calls that our application actually uses. If our database is also pay-as-you-go and scales automatically, we do not lose this advantage.
Strong Consistency
Strong consistency is quite a technical matter, so we’ll explain it briefly, and for the technical details, this article is a great resource. Strong consistency is important in distributed databases when your application stores and updates data. In that case, there are two requirements to preserve a great developer experience:
Strong consistency (or strict serializability) is the opposite of eventual consistency. By adopting a database that does what you expect it to do, you can focus entirely on your application. Only a few distributed databases provide strong consistency without limitations.
JAMstack applications are not limited to pages that are entirely static; they can be partly static and partly dynamic by retrieving data from APIs. A distributed database can be one of these APIs and is essential in case your application contains dynamic pages with filtered or paginated data. Ideally, such database fulfills the six described requirements so that we can build dynamic JAMstack applications without losing speed, scalability, pay as you go or the zero-configuration approach that we love.
In case you wonder how a partly static, partly dynamic JAMstack can be created in an elegant way with modern frontend frameworks, take a look at hydration, which might be the topic of a forthcoming article.
Gartner estimated that by 2020, 20% of the world’s organizations will have gone serverless. Serverless computing initiates a mind shift in the way businesses are run and improves the accuracy and impact of technology services. Leading to higher functionality, reduced AWS bills, increased delivery speed and multi-cloud support, serverless computing paves the way into the future.
The scope of serverless is yet unexplored. With new and high-potential developments (such as FaaS and GitOps) still in their nascent stages, organizations can expect massive benefits leveraging the power of serverless computing going forward.
Servers have been a very important part of the computing architecture for decades. But, with the introduction of cloud, we’ve moved to predominantly web-based server infrastructure, and the migration to serverless architecture has begun.
Serverless computing–abstract and virtual server support–has made the computing landscape more dynamic, robust, intuitive and powerful. But advancement in serverless technology is still in its nascent stage. The next few years are expected to bring in numerous developments and transformations.
First, let’s take a look at some serverless trends you should keep an eye out for.
Kubernetes has become synonymous with open-source containerization. But in the next few years, we will see Kubernetes become the base for serverless infrastructure. Features such as networking, service discovery, agile scaling and multi-cloud environment support make Kubernetes the perfect choice for serverless.
Additionally, with Knative already released, the process of standardization and interoperability of serverless platforms may soon become a reality.
Restriction of serverless for stateless apps is a thing of the past. The next few years will see stateful apps benefiting from the immense power of serverless. Developers will be able to use database connections, BaaS and event payloads to run their applications.
The FaaS market is expected to grow to $7.72 billion by 2021. Large-scale adoption of serverless will be seen across the world, and there will be a 32.7% CGAR.
The version-controlled system of DevOps, GitOps, will see more takers in the future, especially in FaaS. GitOps is expected to improve operational workflows, especially in fast-moving projects, and enable implementation of technologies such as Kubernetes and other cloud solutions.
Additionally, this will enable cloud vendors to provide greater ecosystem support and tooling capabilities to users.
Containers by nature are segmented, isolated and contained spaces of application-specific servers. While they offer high degrees of specialized (and often customized) tools, resources and support, they suffer from numerous challenges:
The challenges that come with containers prompt organizations to choose serverless. Already, many companies have implemented serverless.
Here is how the move to serverless will benefit you, too.
Developing even the most basic server-bound application is a challenging task. It requires the set-up of high-powered and complex application stacks that can be both difficult to build and difficult to manage. By going serverless, organizations can eliminate all these heartaches.
Serverless stacks, such as Lambda and Azure, create a robust and intuitive environment for the development of agile applications, by providing organizations with a large set of capabilities and allowing them to run at scale, at the lowest costs.
Unfortunately, IT infrastructure is considered a capital expenditure by many organizations. So, building your own servers can lead to a high CapEx.
Consider this. Physical servers are vulnerable to breakdown and depreciation, which add to CapEx. If you report this value as expenses in your income statement, it may ultimately negatively affect your P&L and your company valuation. Going serverless allows organizations to avoid such a challenge and maintain their profitability and high valuation.
Plus, serverless infrastructure reduces the need for human resource deployment as focus on batch processing decreases. Additionally, serverless allows organizations to convert workflows into step functions, which reduces the number of EC2 and SWF issues. Together, these reduce company expenses tremendously.
Serverless computing allows organizations to benefit from the magnificent power and scope of microservices. From making minute application-specific developments to isolating and rectifying issues, to managing and deploying individual applications, organizations can do a lot of things using serverless computing.
In fact, a survey shows that utilizing serverless microservices can bring down the standard release cycle from 65 days to a mere 16 days.
Again, serverless computing microservices gives organizations the flexibility, technical support and clarity needed to process data. ELT tasks become more consistent and allow the creation of structured data warehouses.
Similarly, since isolated components and applications can be created, deployed and fixed in serverless, it’s easier to implement cron-type jobs as well.
Adoption of serverless computing allows organizations to shift from the restrictive, time-consuming and draining traditional workflows and engage in event-based computing. Now, coders can just write the algorithms and allow the serverless provider to take care of the data storage and computing needs. Not only will this reduce the time of transaction processing and the cost of DevOps, but it will also free up the time and space for coders to take on other business logic tasks.
With climate change becoming such an imminent threat to the world, it’s important for organizations to become mindful about the way they operate. One way to become sustainable is to go serverless.
For one, serverless computing ensures organizations don’t over-utilize electricity. Additionally, with no physical servers and data centers that emit toxic radiation as they cool down, there will be lesser concerns about health and climate change.
Another aspect is scalability. Serverless is highly-scalable, meaning you don’t need to set-up more servers at your office. Given that 30% of the world’s servers are unused at any point in time and most servers only utilize 5%-15% of their total capacity, serverless may be the best way to go green.
Serverless computing gives organizations the freedom to focus on their core business offerings and deal with only low-level OS issues. This time, money and opportunity can be used by deployers, coders and top management to develop competitive offerings, which can help the organization overtake competitors.
With physical servers, it’s more likely than not for organizations to focus on technical server issues than the business process.
Serverless computing could be one of the most exciting developments of the 21st century. It is breaking down old barriers and allowing organizations to expand and explore new frontiers. Its high deliverability, coupled with the immense opportunities it promises, makes it a must-adopt in any organization.
When AWS announced Lambda–a serverless Function-as-a-Service (FaaS) technology offering–the idea of encapsulating a specific task into a function that resides in the cloud was introduced into mainstream access.
Now, with the rising popularity of microservices, DevOps is waking up the benefits of FaaS where it is used to build and maintain enterprise applications in agile environments. The move to serverless architecture using FaaS is one organizations are now increasingly likely to investigate in 2019.
Given these industry realities, we need to ask ourselves what place will FaaS take in contemporary computing environments and how will its core efficiency proposition enable DevOps to flourish and improve experiences for users at every level?
First let’s remind ourselves what any FaaS platform really does. It allows us to focus on developing and executing business logic because server provisioning and management is handled automatically at the backend. Developers can deploy applications into a space with zero server administration, yet with the ability to enjoy high availability and high scalability.
The impact for DevOps is immediately apparent.
Developers are able to work in a zone where they are essentially abstracted away from the servers their applications live and breath on. The services developers draw upon are event-driven and eminently scalable. Even if they have to scale by some massively parallel level of magnitude, server-side service optimization is handled at the backend by the FaaS vendor.
At the same time, the cost structure is shifted and operations staff are able to oversee compute billing models based on actual execution of functions, as opposed to being dependent on the physical size of a pre-provisioned cloud server established at best guess size and core optimization parameters for compute, I/O, storage, analytics and so on.
If we have so far looked at the FaaS efficiencies that reside at the backend server-side management element of the equation, let us also turn our attention toward the way FaaS allows developers to reduce the amount of time it takes to deploy code in a new environment.
Adopting a FaaS-centric approach to application architectures allows the developer team to encapsulate specific software tasks into functions, hence the name. For a mortgage calculation application, for example, we can encapsulate functions such as interest rate calculations, payments, length of contract etc., and then place those functions in the cloud on a FaaS platform. The FaaS provider is responsible for the hosting of that function and also looks after the heavy lifting associated with availability and redundancy.
The benefit to developers is a very rapid environment for deploying new code, getting feedback and iterating. The operations benefit is one of hosted happiness as the FaaS provider shoulders a significant administrative burden.
FaaS and microservices are now increasingly viable options in any modern technology architecture and it’s important to distinguish between the two.
Microservices are made up of self-contained elements of business logic designed to perform a very specific job. They are optimized for their single responsibility and can communicate with other services via application programming interfaces (APIs). Further, they can be developed, deployed and scaled independently without impacting other services.
A FaaS-based approach is well-suited for transactional workloads where code is run periodically. This is also a technology that is quicker to establish, as and when needed. A FaaS function might also make a call to other application logic that (in the case of our mortgage example) calculates interest rate and so on.
Like any still-nascent technology, FaaS has its functionality flaws and challenges. The automated nature of foundational provisioning in FaaS is great news, but it’s not a panacea.
Why? For one, DevOps teams will have limits on the debugging capabilities for applications that run on FaaS DNA. Also, functions are instantiated and then de-instantiated as needed, which requires time, especially for a cold start. This process can cause unwanted delays in time-sensitive operations. The transient nature of FaaS also impedes state preservation among dependent functions, which requires careful design considerations.
FaaS is a place where the burden of server resources control has been shifted. But there’s no such thing as a free lunch and this means DevOps won’t be able to interject some level of application monitoring function at the server level itself. You’ll need to know more about your FaaS-based application before you FaaS it up.
We must also remember for any distributed software architecture, there’s an up-front responsibility to design to accommodate the limitations and increasing options available in modern services.
Examples of FaaS now extend beyond AWS Lambda, we can also look to Microsoft for Azure Functions, Google for Cloud Functions, IBM OpenWhisk, Oracle Functions, Fn Project and IronFunctions with its Iron.io platform.
This sector of the software landscape is guaranteed to grow over the coming years. FaaS can be an appropriate option in an overall software architecture, but there are specific limitations, so choose wisely. Observing the evolution of FaaS over the coming years will be a fascinating process.
In enterprise development and deployment, the pattern is easy to detect. A big monolithic application is targeted for re-architecting as a microservices architecture. People excited about microservices get together and break up the design to make it far less monolithic and far more loosely coupled.
If your organization is lucky, it is at this stage that those responsible realize that breaking a monolithic application down too far is bad for complexity, performance, monitoring and maintenance—pretty much everything re-architecting is supposed to fix.
Far too many organizations don’t realize this until the implementation phase, though. First, a metric ton of little tiny microservices are deployed, then the organization realizes that functionality such as database access can be applied much more efficiently through one larger service that handles all interaction with the database for the app, rather than through five or 10 smaller services that replicate code and end up calling each other anyway.
Function as a service (FaaS) has much the same issue. It is an astounding solution for some uses, but in the end, users must consider what access the function requires to other parts of the system and what task is being achieved. The early uses of FaaS are well-documented; longer running independent jobs such as image or video processing were a bit early hit, for example, particularly for services that have highly varying traffic rates. But other uses, such as handling bottlenecks in traffic spikes (hello holiday shopping season!) or out-of-band operations processing, are less documented at this point. Entire applications have been designed from the ground up in serverless, but they are relatively few in terms of overall applications out there.
FaaS is highly suited to DevOps, because upgrading the function is as simple as redeploying code. There are no concerns about OS or library version, because those are largely beyond your control. But that is as big a negative as it is a positive. There is no flexibility in OS version or library inclusion because those are beyond your control—for the most part, anyway.
As with the vast majority of new technologies, expect adoption of serverless to grow and the hype to grow more quickly. It is definitely in the market where we have seen massive shifts—virtualization and then containers really did live up to the hype in terms of usage—but it needs to have a driving reason for adoption. Look closely at what your application and its DevOps toolchain are doing before hopping into the deep end. For some uses, FaaS is the fastest/easiest/lowest-maintenance solution. But that does not make it the Swiss army knife that virtualization and containers have proven to be. Indeed, if you think persistent storage is painful under containers, try it in a FaaS environment—as just one example.
FaaS is useful in many scenarios, but just remember where/when/why you are adding FaaS into your DevOps processes, and take advantage of on-demand processing with few scaling limitations while avoiding seeing everything as a FaaS problem because FaaS is the FaD.
The popularity of the “serverless” term started to grow when Amazon launched AWS Lambda in 2014. Ever since, we’ve seen the term exponentially grow in use and reference, with more vendors entering the market with their own solutions (Azure recently went GA with Functions, for example).
What is it all about and how does this new trend affect the way people write and deploy applications? Is “serverless” a paradigm shift or just a natural evolution of infrastructure as a service (IaaS) and platform as a service (PaaS)? In this post, I will discuss what “serverless” is and is not—and how it shapes up in comparison to existing PaaS solutions.
“Serverless” denotes a special kind of software architecture in which application logic is executed in an environment without visible processes, operating systems, servers or virtual machines. It’s worth mentioning that such an environment is actually running on the top of an operating system and uses physical servers or virtual machines, but the responsibility for provisioning and managing the infrastructure belongs entirely to the service provider. Therefore, a software developer focuses on writing code.
In other words, a developer thinks in terms of services or functions that communicate with each other and with the external world. After implementing these services, developers using a traditional approach would combine them into a number of distributed processes when installing, running, monitoring and updating such processes for specific operating systems that are running on specific servers or virtual machines. In the “serverless” approach, a third-party service provider is responsible for everything from the processes to the operating systems to the servers.
When a third-party service provider is responsible for the underlying IT infrastructure, a developer no longer is in charge of purchasing a dedicated server or virtual machine. At the same time, the service provider is free to decide how to efficiently utilize its infrastructure to serve requests from all of its clients. As a result, the service provider is not usually required to run a permanent workload for a specific client; instead, the software handles requests from all of the customers at the same time, spending just a limited time on handling each request from a specific customer. Therefore, such providers usually charge their customers based on the total number of requests, the frequency of requests over a specified period or the total time spent to serve all of the requests from a customer.
The same approach works well for different types of loads because third-party service providers usually have elastic, scalable services. When customers start using a third-party service, the expected number of requests can be low and customers pay significantly less compared to purchasing, configuring and managing their own infrastructure on-premises or in the cloud. For a larger number of requests—either expected or unexpected load peaks—customers do not need to add servers to horizontally scale their application. Instead, a service provider does care about increased load. For sure, handling a bigger number of requests will cost more, but in most cases it is still more efficient than using a dedicated IT infrastructure.
Two approaches that often are mentioned together with serverless are backend as a service (BaaS) and function as a service (FaaS).
The growing number of third-party services that implement required functionality, provide server-side logic and manage their internal states has led to applications that do not have application-specific, server-side logic and use third-party services for everything. In this respect, such applications are serverless.
Some examples of third-party services include identity and authentication as a service (Auth0, AWS Cognito), logging as a service (Loggly, Logsense, Amazon Elasticsearch Service) and analytics as a service (Amazon Kinesis, Keen IO).
When an application still requires specific server-side logic, a developer can use a modern alternative to traditional architectures: FaaS. With this approach, a developer focuses on implementing short-living stateless functions that are triggered by events and can communicate with each other and the external world. A FaaS provider does the rest—provisioning as many instances of such functions as necessary to handle all of the requests, terminate instances that are no longer required, monitor all of them and provide identity and logging services. FaaS ideally fits with microservices architecture because the FaaS provides everything that an organization needs for running microservices.
Auth0 Webtask, AWS Lambda, Google Cloud Functions and Azure Functions are examples of FaaS implementation. IronFunctions is an ambitious initiative from Iron.io that is targeted to run AWS Lambda functionality on the most popular cloud providers as well as on-premises.
The main difference between serverless and PaaS is that traditional PaaS providers such as Heroku or OpenShift usually lack the automatic scaling feature. A user of traditional PaaS has to specify the amount of resources—such as dynos for Heroku or gears for OpenShift—for the application. It still is possible to manually scale the application up or down by changing the number of assigned resources, but mostly this is the responsibility of a developer or system administrator.
The second difference is that traditional PaaSes are designed for long-running server applications. With such a design, the application always should be running to serve incoming requests. If you bring the application down, it obviously will not serve the requests. With FaaS, your function starts to serve a request and terminates when the request is processed. Ideally, your functions should not consume provider resources when there are no incoming requests (see also “cold start” issue below).
Traditional PaaS implementations are not “serverless” under the strict definition of this term because they do not have automated scaling and require that server-side applications are always running so that requests can be served. Traditional container management platforms are not “serverless” for the same reasons.
Another way to know if a provider allows the serverless approach is to identify the border between two areas of responsibility: the provider’s consumer and the provider itself. In “serverless,” the border is between application code and how is this code is actually deployed and running on physical servers. In container platforms, a platform’s consumer is still responsible for working with the operating-system level to define things such as the processes that will run in which containers and how many containers of each kind will run.
Nonetheless, there is an inherent similarity between containers and serverless. For example, Kubernetes—an open-source container orchestration platform—allows for the automated scaling of containers using application-provided metrics such as the number of concurrent requests. AWS Lambda actually runs a container for each function.
In other words, containers and container orchestration may provide an efficient way to implement FaaS while FaaS provides an additional abstraction level that hides specific processes, operating systems and containers from developers and allows them to focus on code.
As we already mentioned, “serverless” has the following main benefits:
At the same time, “serverless” has the following drawbacks:
Serverless architecture is a new approach to writing and deploying application that allows developers to focus on code. Such an approach can reduce time to market, operational costs and system complexity. While serverless leverages third-party services such as AWS Lambda to eliminate the requirement to set up and configure physical servers or virtual machines, it also locks in the application and its architecture to the specific service provider. In the future, we can expect more movement toward the unification of FaaS APIs or frameworks such as IronFunctions that will help to avoid vendor lock-in and enable us to run serverless applications on different cloud providers or even on-premises.