We use cookies to keep our website secure, personalize your experience and for web analytics purposes. Read our Privacy Policy to learn more. By clicking Accept, you agree to our use of cookies.
Traditionally, when you needed more computing power to perform a certain business function, IT would allocate resources including servers that would handle processing. The cloud introduced virtualization and the ability to host servers in data centers. Now, serverless technology offers businesses ways to implement workflows without managing a physical or virtual machine. Serverless computing offers a number of benefits including better scalability, flexibility, cost efficiency and an increase in speed from development to production.
A serverless environment eliminates overhead required to manage a server but still provides application functionality to process computing tasks. With serverless technology, the organization doesn’t need to provision any hardware or software. Instead, applications can use the cloud provider’s computing power to process information and return output to its frontend. The organization’s frontend application passes data to the serverless endpoint, and the serverless function returns output to it, usually in JSON format.
The term “serverless” is a bit of a misnomer. Cloud servers handle the computing process, but only the serverless function is available to the customer and not the server hardware or management interface. The cloud provider handles backend processes while the developer handles the frontend. Think of serverless computing as a way to offload all processing power to the cloud while still maintaining the business logic and workflow from a lightweight frontend application.
To give an example of serverless computing, imagine that the organization has a frontend web application that must request data for analytics. You could create a new web application and host the server processing on a cloud virtual machine, or you could simply create a frontend application and have it query a serverless function that will process the request and return JSON output to the frontend. In the latter scenario, the organization does not need to host or manage the backend workflow.
Whether you need to reduce IT costs or want to provide faster deployment to production, serverless takes away much of the overhead involved with in-house applications. Developers can work directly with serverless architecture without worrying about destroying server resources, and operations staff does not need to patch and manage the server operating system.
The cost savings is the primary benefit for organizations. It’s much cheaper to work with serverless architecture than to pay staff to manage virtual machines and pay for the resources. With serverless architecture, the organization only pays for the resources used during data processing.
Executing anything in the cloud makes it scalable. Cloud applications scale dynamically, so computing resources can be expanded during peak business hours and reduced during slow seasons. This benefit ties back to lower costs, since the organization only pays for the resources used. Scalability affects performance, which also has an effect on costs. Poor performing applications frustrate users and developers, so speed is always a factor in customer satisfaction and productivity.
Developers can more quickly deploy applications with serverless architecture. There’s no need to test applications on the server to ensure it does not interfere with other applications or the operating system. The serverless instances started in the cloud simply process requests, so only the business logic and syntax of the application are essential for a successful deployment.
The final benefit is that serverless applications run in data centers across the globe. With the right setup, the applications run from servers closest to the customer’s geolocation. Applications that run close to a user’s geographic location have better performance due to proximity to where the data is processed and returned to the frontend.
As with any technology, there are some disadvantages for organizations to consider. Not every application should be transformed into serverless architecture, but most organizations can re-engineer at least one inefficient application to cloud infrastructure, including serverless.
The first issue is with development. Developers can’t debug backend processes, so it’s more difficult to debug and fix issues. Developers have no insight into the way backend processes execute, so developers can only work with their frontend code to determine root-cause analysis during the debug process.
Security concerns are also an issue. Security is handled by the backend application and the cloud provider. While cloud computing is more secure than most on-premise infrastructure, it’s the responsibility of the customer to properly configure services. Misconfigured cloud services are one of the primary reasons for data breaches, so developers and operations staff must understand what each access control and configuration means to the application’s security.
Vendor lock-in is a risk for any cloud environment. Multicloud environments are used for failover and to avoid the vendor lock-in issue, but once you build an application around serverless architecture with one specific vendor, it’s a delicate tedious task to move to another vendor. Multicloud eliminates a single point of failure, but it’s unlikely that there will be a 1:1 ratio of services across multiple vendors.
Before designing a serverless workflow in GCP, you should first define your use case. In this article, we’ll use an example use case to walk you through the way GCP can be used to set up serverless workflows. Suppose that you own a pest control company and have a system where an invoice is generated after your employee is finished treating a customer’s home. You could have a mobile app that the employee uses to call an API on your servers, or you can take advantage of GCP’s serverless architecture to create an invoice, generate a PDF, and then send the PDF invoice to the customer’s email address.
Cloud applications are much more reliable than on-premise solutions, so your organization is guaranteed to have the backend available to all employees across your fleet. The smartphone app will send data to the serverless application where the PDF is generated and emailed to the customer. Should the application fail, serverless architecture generates an exception and returns it to the application frontend.
The following Google image describes the basic workflow:
(Image: Google)
In this ecommerce use case, the “user” data point is sent to the serverless application. This user field is the internal ID for the user, which can be used to identify the customer in a database. The application determines if the customer’s balance is $0.00. If the response is “No,” then an invoice PDF is generated and emailed to the customer.
We can turn the above logic into serverless syntax by feeding GCP workflows JSON input. Take a look at the following JSON input source:
(Image: Google)
The highlighted area shows the first step in the workflow. The URL is a link to Google Firestore API with a user ID argument appended to it. Google Firestore is GCP’s NoSQL database that can be used to store your customer information. Notice the type parameter in the auth section indicates that the request requires authentication. Without this restriction, anyone would be able to generate an invoice PDF.
The record is returned to a userRecord object, which is set in the result output variable:
(Image: Google)
The next step is to provide a condition for the process workflow. You don’t want to send a PDF to a customer with a $0 balance, so the condition argument is passed to GCP:
(Image: Google)
If the customer has a balance, the next step is to generate a PDF. The following highlighted URL is the GCP API to generate a PDF:
(Image: Google)
The generatePDF function is also an authenticated request or anyone would be able to generate an invoice. In the body variable, a message is set up that contains your organization’s invoice message to the customer. This text is what will be used when generating the PDF. The PDF output is then stored in the pdfOutput object in the result variable.
After the PDF is created, the application needs your API secret to send email. This secret is like a password that should not be shared with anyone and should be kept in a safe place. The key is sent to the API to allow for email generation.
(Image: Google)
Notice that the cloud project number is also sent to indicate that the email request is related to your GCP workflow service.
Finally, the sendMail process is called, which uses the SendGrid application to send the PDF:
(Image: Google)
That’s all it takes to build an automated invoicing system using GCP serverless. This workflow could replace an application that would be much more difficult to maintain, code, update, and deploy.
As you search for a solution to turn a monolithic application into a more efficient codebase, you will find content that promotes microservices and containers. It’s important to understand the difference between the two technologies before refactoring code. Containers are beneficial in some use case scenarios, but they can create unnecessary overhead that serverless architecture can eliminate.
Containers also break down large applications into smaller parts. The container can be deployed across any operating system. Containers are deployed on a host to function as a part of an application. For instance, you might break a monolithic application into a finance container and a sales container. Each one would be dedicated to a specific business application.
With serverless applications, you virtualize functions. Think of these functions as an even smaller part of a container application. Using the invoice generation example, a container might run a billing application for your business, but the serverless workflow serves to function as the process to create an invoice and email it to a customer.
For organizations that need to reduce cost and improve application performance, serverless workflows can take much of the overhead and costs away from IT staff and budgets. They’re easier to manage and deploy, which takes much of the overhead away from developers, and they can streamline your organization’s application functions in the cloud.
