Technology runs on servers, right? So what is this “serverless architecture” idea all about?
Turns out, it’s less about eliminating servers, and more about changing where (and by whom) they’re managed. (Of course, there are a lot more nitty-gritty details to it!)
In this post, Robert Fisher — the VP of Product Development at Seamgen — explains what serverless architecture is and how it’s evolved, before delving into its pros and cons. If you’re a developer or decision-maker trying to decide if serverless computing is right for you, Robert’s perspective can provide guidance.
Take it away, Robert!
What Is Serverless Architecture?
Serverless architecture offers companies a way to manage applications and services without having to handle the actual server infrastructure.
Although “serverless” is in the name, it doesn’t mean servers are completely out of the picture. Rather, “serverless” is used because you no longer have to manage the infrastructure. Instead, the responsibility falls on the cloud providers. With server management out of the picture on their end, companies can dedicate more focus to product development and achieving business goals.
A Brief History of Hosted Services
Software systems have evolved tremendously since the early days of computing, when all software ran on giant mainframe computers.
With the advent of networking technologies and smaller, more personal computers, the computing work was often divided between centralized servers that would do the heavy lifting, and so-called clients that would be focused more on presenting the results.
This division of labor was only amplified with the advent of the web, to the point that the concept of a server had become “a computer whose job it is to serve up information on the internet.”
As computers continued to become more and more powerful, it became increasingly likely that server tasks would not require a dedicated computer to perform them. This led to the next phase of the evolution of services: virtualization.
What Is Virtualization?
Virtualization is using software to share a computer’s resources among several independent operating systems — essentially multiple servers in one. The concept of what constituted a server shifted from hardware to software. When AWS started providing cloud computing with their EC2 service, the servers they provided were virtual servers running on hardware shared with other AWS customers.
At this stage in the evolution of services, you still needed to do a lot of the server management tasks. You might not be responsible for hardware issues like hard drives and network cards, but you still had to configure and maintain the operating system and install, configure, and maintain all the other software, including things like the web server and database.
The next step in service evolution freed developers from most of these maintenance tasks for lower-level software like the operating system. At that point, users just needed to build the application that serves up data to the website, mobile application, or other client. Services like Elastic Beanstalk and Azure Web Apps simplified the process of deploying applications to the cloud. At this stage, the term “server” came to mean “software that processes a collection of API requests.”
One of the important things these new servers retained from the original web servers was the ability to “remember” things from a previous request. Programmers call servers that can do this “stateful.”
The last stage in the evolution to serverless abandoned state in favor of the flexibility of small, disconnected pieces of code that can be run, updated, and scaled independently of any other parts of the system.
The Current State of Serverless
Serverless today generally refers to an application or API that relies heavily on microservices, with code hosted on Function as a Service (FaaS) platforms.
Examples of FaaS platforms are AWS Lambda, Microsoft Azure Functions and Google Cloud Functions. AWS Lambda is an Amazon serverless computing platform that was introduced in November 2014 and was one of the earliest FaaS offerings. Lambda allows users to write functions in virtually any language that can be invoked from most other AWS services.
For example, serverless apps for the web can be created using API Gateway to handle the web requests, Lambda functions for the business logic, and Aurora for the database. With this configuration, you only pay for the compute time you use handling a request, and the storage in the database. Since the functions are independent and directly accessible, the services can be used by many applications.
Start coding now
Stop waiting and start learning! Get my 10 tips on teaching yourself how to code.
Pros and Cons of Serverless Architecture
Serverless computing obviously has its advantages, but it’s not without disadvantages either. Let’s look at both.
Pros of Serverless Architecture
Serverless applications provide many advantages for application development and it can also influence your workflow.
1. Lower costs
With serverless, you only pay for what you use—there are no hardware costs and no costs when your services are not in use. Reduced cost is one of the main advantages of going serverless. If your services aren’t heavily used all of the time, then the ‘pay-as-you-go’ model gives you optimal resource utilization without paying for idle server time.
2. Fewer things to worry about
You are relieved from worrying about if the latest security has been applied. Because your servers are now in the hands of a third-party service provider, you no longer need to be concerned with keeping up with patches and bug fixes.
3. Enhanced scalability
You may want to build a viral app like Instagram or Uber, but would you risk provisioning infrastructure just in case? With serverless architecture, you don’t have to think twice about it because of its ability to automatically scale with traffic volumes. Scaling also depends on the location of users and their network connection. Serverless providers have points of presence around all users, which diminishes delays and allows apps to perform as they should, regardless of your geographic location.
4. More focus on user experience
Your users don’t care about infrastructure; they care about features. With server maintenance out of mind, companies can dedicate more time and effort to improving the customer-facing elements. A quality UX design is essential if you want to keep users engaged with your app.
Cons of Serverless Architecture
Regardless of all the great features serverless can bring you, sometimes traditional architecture still comes out on top. Some potential drawbacks of going serverless are:
1. Vendor lock-in
You’re playing by their rules now. Once you give control of your servers to third-party providers, you lose control over the hardware, the run times, and updates. This can create issues in consistency and limit the resources you have available.
Additionally, when you commit to a service provider, you are in it for the long-run. If you build your application on one serverless infrastructure, and then you want to transition to another vendor, they don’t make it easy to switch. It is a very difficult process, and you may need to reengineer your application if you wish to do so. Plus, there is a risk that a vendor will change its pricing or service terms or even stop offering serverless options.
2. Unsuitable for long-term tasks
Serverless is great for short-term or real-time processes like sending out emails. However, for longer duration tasks, where functions are running constantly, you may end up paying more for compute time than when paying for a reserved instance. A task such as uploading large video files would require additional functions to be called on.
For example, Lambda gives you five minutes to complete a task. If it takes longer, you must call another function, and so on until the task is complete. Lambda also imposes a limit on how many simultaneous functions can be running, so if you execute too many functions you’ll “denial of service” (DoS) your production applications.
3. Cold starts
You only pay for what you use, but if you don’t use your function often, you will pay with a dramatic performance penalty. Hosted functions suffer from a cold-start penalty and can be very slow the first time they are called in a while.
However, you can attempt to minimize cold starts by keeping your functions small and precise, as cold starts increase with code size and memory. This will help keep your functions warm (but the drawback is that it is complicated and inefficient to manage numerous small functions).
The learning curve in serverless application is a steep one. Units of integration with serverless are a lot smaller than with other architectures. This requires extra time to go into organizing the functions so they work in line with your data. There can also be problems with deployment and versioning.
AWS functions are time-restricted, allowing you a maximum of five minutes. If you have a task that requires a large amount of data that could exceed these runtime limits, a lot of effort will have to go into rewriting the code in another architecture. You may need to deploy a separate piece of code for every function in your entire logical application.
There are frameworks that allow you to deploy a collection of AWS resources, but it’s more difficult to update multiple functions than to update a monolithic architecture. However, if you want to migrate your application over to serverless you need to tackle the complicated task of splitting your monolithic application to microservices.
From a business perspective, the disadvantages of vendor lock-in and loss of control could be damaging. Even though it may be cost-effective, it is also unpredictable because the number of executions is not predefined.
For developers, serverless is a relatively new technology. It can be very complex and testing becomes tricky. If not developed correctly, companies using serverless can lose customers due to poor performance.
Although serverless has its disadvantages, its overall functions can provide numerous benefits. Its cost-saving abilities extend to cutting server run times as well as labor costs. Serverless can also increase the speed at which a company can get new features and fixes out to market.
From a developer’s perspective, serverless can reduce the time spent on infrastructure and eliminate worries about scalability. The developer can focus their attention and efforts on the product instead. By decreasing the time required to launch new features and improving the users’ experience, you can create a larger and more loyal user base.
Any decision like this will have trade-offs. It’s up to the developers and their companies to weigh the costs and benefits of all options.
If you would like to learn more about serverless architecture and the opportunities it presents, check out this great resource:
If you’re feeling confident, here’s a video that discusses how to build your own serverless application:
And lastly, this is a more advanced resource if you’re looking for a deep dive into serverless technology:
Overall, serverless architecture is a new technology that we will be seeing much more of in the near future. As more companies search for innovative ways to maximize their cloud investments, they’ll look towards serverless.
Because serverless can be a very beneficial tool when developing an application, it is important to gain a solid understanding of all of its components. We have only touched the surface here. So, if you are looking for more information on serverless technology or looking to develop your own serverless application, reach out to a software development firm that offers advanced web and mobile app development services.
About the Author
Robert Fisher is the Vice President of Product Development at Seamgen. He is a lover of all things cloud and has over 20 years of experience writing software and leading teams of software engineers. Robert has architected and launched dozens of successful applications in the market today.