devopsy.kinsta.cloud

Tag: function as a service

  • Evolving from FaaS to a Truly Serverless Paradigm

    Evolving from FaaS to a Truly Serverless Paradigm

    True serverless helps alleviate some of the administration and management issues related to FaaS

    Creating distributed applications demands a thorough understanding of cloud infrastructures and architectures. Engineers must address complex operational issues, including provisioning, configuration and how their code will behave over a distributed architecture.

    The current standard is to architect programs into microservices, before deploying to cloud hardware. Docker and similar technologies ensure that the microservices are strongly isolated in-terms of access, dependencies, and the potential overcommit of resources.

    However, containerization is an imperfect solution that masks rather than addresses the core problems of running cloud applications. As an application scales, scripting architectures and defining how different containers communicate with one another becomes exponentially complex. The solution—orchestration technologies such as Kuberenetes—adds yet another layer to an already bloated stack ill-designed for the needs of distributed computing.

    These problems were, in theory, to be alleviated by the concept of serverless—not the removal of servers, but rather the removal of their administration. However, since its emergence in the early part of the last decade, the term has become conflated with function as a service (FaaS).

    FaaS tools such as AWS Lambda break code into computational event-driven units, which only run when called. The event-driven logic scales quickly, efficiently and dynamically, driving down costs as the provider takes care of all server updates and administration, while developers only pay for what is used.

    However, functions run on their own custom framework and are limited in memory and execution time, rendering FaaS an inappropriate approach for scaling an entire application. Regularly scheduled database tasks, CPU-bound processes and long-running persistent connections to a server are examples of common patterns that map poorly onto FaaS.

    Serverless Is More Than Just FaaS

    A platform that looks after the infrastructure of an entire application (as opposed to specific functions) is the logical evolution of FaaS, and represents a truly serverless paradigm. Serverless, in this sense, takes the dynamic scaling properties of FaaS, but without fragmenting the application.

    Rather than simply linking together different components of a larger system, a serverless platform ensures long-running processes and fast discovery, enabling services to communicate and cooperate with one another quickly and reliably. Arbitrarily large memory capacity and unbounded execution time are underpinned by predictable execution and robustness guarantees well beyond the layered stack approach of FaaS. Developers can altogether ignore the management and configuration of servers, treating computation in purely algorithmic or data terms.

    Whereas containerization and FaaS solve pieces of the distributed computing puzzle, they also introduce new issues as the user must engineer their own infrastructure stack to carry out even basic tasks. By contrast, serverless could reduce an application engineered with Chef, Docker, Kubernetes, the JVM and Akka to a single abstraction. It allows for programs to be easily scaled up and down, harnessing almost limitless computing power, without compromising runtime.

  • How FaaS Is Disrupting Workflows: New CSP vs. CDN Services

    How FaaS Is Disrupting Workflows: New CSP vs. CDN Services

    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 vs. CDN FaaS

    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.

    Empowering Innovation by Enabling Customization

    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.

    The Make Or Break Element: Latency

    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. 

    How Do the Costs Stack Up?

    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. 

    Not All Faas Services Are Created Equal

    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.

  • FaaS is Key to DevOps Efficiency

    FaaS is Key to DevOps Efficiency

    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?

    Back to Focus

    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.

    Speedier Implementation

    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.

    FaaS Challenges

    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.

    The FaaS Road Ahead

    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.

    — Mike Duensing

  • The Limiting Factors of Microservices Also Apply to FaaS

    The Limiting Factors of Microservices Also Apply to FaaS

    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.

    — Don Macvittie

  • Should You Go ‘Serverless’? The Pros and Cons

    Should You Go ‘Serverless’? The Pros and Cons

    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.

    What is ‘Serverless’?

    “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.

    BaaS and FaaS

    Two approaches that often are mentioned together with serverless are backend as a service (BaaS) and function as a service (FaaS).

    BaaS

    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).

    FaaS

    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.

    What is Not ‘Serverless’?

    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.

    The Benefits and Drawbacks of “Serverless”

    As we already mentioned, “serverless” has the following main benefits:

    • Reduced time to market and quicker software release.
    • Lower operational and development costs.
    • A smaller cost to scale – there is no need for developers to implement code to scale and administrators do not need to upgrade existing servers or add additional ones.
    • Works with agile development and allows developers to focus on code and to deliver faster.
    • Fits with microservices, which can be implemented as functions.
    • Reduces the complexity of software.
    • Simplifies packaging and deployment and requires no system administration.

    At the same time, “serverless” has the following drawbacks:

    • Serverless is not efficient for long-running applications. In certain cases, using long tasks can be much more expensive than, for example, running a workload on a dedicated server or virtual machine.
    • Vendor lock-in. Your application is completely dependent on a third-party provider. You do not have a full control of your application. Most likely, you cannot change your platform or provider without making significant changes to your application. Also, you are dependent on platform availability, and the platform’s API and costs can change. Needles to say, the existing FaaS implementations are not compatible with each other.
    • Serverless (and microservice) architectures introduce additional overhead for function/microservice calls. There are no “local” operations; you cannot assume that two communicating functions are located on the same server.
    • To utilize its resources more efficiently, a service provider may run software for several different customers on the same physical server (this is also known as “multitenancy”). Even if customers’ workloads are isolated in virtual machines or containers, there can be different bugs in the early stages of FaaS offerings. This can be a major security issue for your application if you work with sensitive data. Such potential bugs in a platform or failures in one customer’s code (a “noisy neighbor”) can affect the performance or availability of your application.
    • In practice, it takes some time for a scalable serverless platform to handle a first request by your function. This problem is know as “cold start”—a platform needs to initialize internal resources (AWS Lambda, for example, needs to start a container). The platform may also release such resources (such as stopping the container) if there have been no requests to your function for a long time. One option to avoid the cold start is to make sure your function remains in an active state by sending periodic requests to your function.
    • Some FaaS implementations—such as AWS Lambda—do not provide out-of-the-box tools to test functions locally (assuming that a developer will use the same cloud for testing). This is not an ideal decision, especially considering that you will pay for each function invocation. As a result, several third-party solutions are trying to fill this gap, enabling you to test functions locally.
    • Different FaaS implementations provide different methods for logging in functions. For example, AWS Lambda allows writing logs to AWS CloudWatch using the standard frameworks for the specific language (Log4j for Java, console methods for Node.js, logging module for Python). It is completely up to the developer how to implement more advanced logging.

    Summary

    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.

    — Asaf Yigal