Serverless is an increasingly popular approach to software development that is growing extremely fast in companies of all sizes. The launch of AWS Lambda in 2014 kicked off the serverless movement, and many other cloud providers followed by launching their own offerings.
With any trending technology, there are plenty of questions, such as:
Let’s jump right in and answer them.
Serverless can be described as a software architecture where the execution of code is fully managed by a cloud provider, and the compute power only exists when requested and disappears after the task is completed.
However it’s defined, the term “serverless” is actually a misnomer.
There are certainly servers involved in running your app; it’s just that your cloud provider is managing these servers, and they’re not always running. Rather, your application pings the cloud server when it should execute the code, and when that task is complete, the server essentially stops running until another action is requested.
For Instance, let’s say you’re building your company’s investor relations website. You could set up AWS Lambda with the Serverless framework to recognize different types of files and do different things with them based on their file type.
If a user uploads a PDF report to cloud storage, that file can be automatically indexed for the “reports” section of the site. If someone uploads an image, Lambda can create thumbnails of those images to be displayed properly on the site.
And the servers that power these actions would not be active until the events are triggered by your users.
This approach is also known as Function-as-a-Service (FaaS), and it allows developers to focus on building their applications instead of spending time managing server infrastructure. And because the servers only run when necessary, serverless apps cost less to run.
It’s an option that has recently seen a lot of momentum and might be a good option for the next app or website that you build.
Due to the popularity of serverless frameworks, there are a growing number of options to choose from.
AWS Lambda, launched in 2014, was the first serverless framework. Lambda is the most mature and developed framework available, supporting Node.js, Java, Python, and C# (.Net core) and seamlessly integrates with many other AWS offerings.
More cloud providers are jumping in the game with their own serverless offerings.
For Instance, Microsoft launched its Azure Functions in 2016, while Google Cloud Functions is available in a beta release. IBM also released a serverless platform – OpenWhisk.
Other serverless options include:
Your development team will benefit from the many advantages serverless provides. But, there will be cons to consider before implementing, as well.
Let’s start with the positive.
You only pay for what you use
The first pro is that you don’t have to pay for idle server time, and only pay for the time that your app uses the server. As mentioned prior, the server runs and stops as needed. If your application needs to execute certain tasks, the server will run. When those tasks are completed, the server stops until another task needs to be executed.
This is a very cost-efficient way to run an application and can save you a lot of money in the long term.
Your app is elastic
With a serverless architecture, your app can automatically scale up to accommodate spikes in traffic, and scale down when there are fewer concurrent users.
Let’s say that you’ve built a concert ticketing platform. Traffic will likely spike when you release tickets for that big U2 concert, but then the volume might normalize at the times when new, very popular events aren’t announced. A serverless architecture allows your application to quickly scale up to handle the demand of rabid U2 fans searching for tickets, and scale down during the other times of lower traffic. This helps cut costs, since you’ll only pay for what you use. Maybe more importantly, the performance of your platform will increase and your customers won’t ever have to deal with a slow, unresponsive website.
Less time and money spent on managing servers
In addition to the direct server cost savings, serverless will allow you to spend less money and time managing servers, because most of the work will be done for you by your cloud computing provider. The elasticity of a serverless architecture will alleviate the need for your IT team to manage the expansion and contraction of server capacity, because the serverless architecture scales automatically to meet the demand. No more guessing and much less worrying. And in the case that something goes wrong and a server goes down (which is extremely rare), it’s on your cloud computing provider to figure out and fix the problem. Cloud providers are the very best at dealing with these kinds of issues.
Thus, you can focus on what’s important – the design and development of your app and running your business.
Reduces development time and time to market
Serverless architectures can have a significant impact on the time it takes for you to get your product to the market. Your developers don’t need to worry about deploying, managing, and Scaling servers. There are no operating systems they need to select, secure, or patch. They can simply focus on building the best product possible, as fast as possible.
This will help you serve your customers better by getting your products to market much more quickly.
Fits well with microservices
Microservices is a popular approach to development where engineers build modular software that’s more flexible, scalable, and easier to manage than massive monolithic applications. With the microservices approach, developers can work autonomously and in parallel to build smaller pieces of the application. Because these smaller pieces are less dependent on each other, they can be changed faster and scaled independently.
One issue with microservices is that each developer may need to spin up their own instance of infrastructure to build their portion of the product. Each developer will need to worry about provisioning servers, scaling for high traffic, managing costs, and more. And across all developers involved, this can result in a lot of overhead, high costs, and wasted time. Serverless addresses many of these concerns.
Developers don’t have to worry about provisioning and managing servers, each microservice can scale almost instantly, and the team can build each piece of the product faster.
Drawbacks are to be expected with any new technology, and here are some cons of serverless that you should think about.
No real roadmap or standards
Serverless is still in its early days, so there aren’t any true standards or roadmaps to follow. Each of the cloud companies who provide serverless architectures may take a different approach. There may be varying methods of integrating different programming languages and frameworks. And different types of applications will use serverless in different ways.
Though serverless is progressing quickly, there are still no concrete standards, so be prepared to adapt to changes.
Not all programming languages are fully supported
Existing serverless frameworks support many programming languages, but there are a bunch of popular languages where it’s more difficult to implement a serverless architecture.
AWS Lambda directly supports Java, C#, Python, and Node.js (JavaScript); Google Cloud Functions operates with Node.js; Microsoft Azure Functions works with JavaScript, C#, F#, Python, and PHP; and IBM OpenWhisk supports JavaScript, Python, Java, PHP, and Swift.
But for other popular programming languages like C++, Golang, Clojure, and more, it’s more difficult to go serverless. Many languages still lack full support from major serverless players, and tools like Iron.io are trying to solve this problem.
Higher latency in responding to application events Serverless isn’t a good fit for all types of applications. Because the server sits idle until an application event occurs, it may take some time to fire up and execute the command. For example, if you use AWS and your function hasn’t been run in a while or you’ve made changes to your code, Lambda may have to create another container, which will be slower than if you were using an always-on virtual machine. This can have an impact on a couple of things. First of all, serverless may not be a good fit for applications where page load speed is absolutely essential, such as social media, search, and e-commerce sites.
Also, you may have to build your app to send periodic requests to your function so that it remains in an active state in order to make your application run faster.
Inefficient for long-running tasks
Because of its event-based nature, a serverless architecture might not work well for applications that execute long-running tasks. If you’re building an online game where gamers can play for hours and hours, the event-based nature of serverless wouldn’t be a good fit.
Most serverless providers have a time limit on how long a function can run. For instance, AWS Lambda and Microsoft Azure Functions don’t allow you to run a task for longer than 5 minutes; after that, the task will be terminated. In this case, you’ll have to resort to a couple of options:
Additionally, running long tasks with a serverless architecture might wind up being more costly than using a virtual machine or a dedicated server over time.
Few engineers are truly serverless experts, so hiring is expensive
Another drawback of serverless being in such an early stage is the lack of true experts. Thus, hiring serverless developers and architects can come at a steep price.
Traditional cloud architects and developers can certainly pick up the skills needed to build serverless architectures, but there will be a learning curve. Furthermore, the technology continues to change very rapidly, making it even more difficult to keep up.
As serverless’ popularity rises, so will the number of experts. But right now they are few and far between, so they can be tough to find and expensive to hire.
Vendor lock-in
Vendor lock-in is one of the primary concerns of moving to the cloud, and using serverless is no different. The back-end of your serverless architecture is completely managed by your cloud service provider. Thus if you’re on Microsoft Azure and decide to move AWS, you’ll have to make major changes to your application. Aside from porting your code, you’ll have to consider changes to other parts of your application such as databases, identity and access management, storage, and more. That can cost additional time, money, and resources.
Before incorporating serverless architectures into your app, there are many pros and cons that you’ll need to think about and understand. Make sure that serverless fits well with your particular application and situation before implementing.
Many of the world’s largest companies are taking advantage of serverless to deliver their products. Brooklyn-based media company Bustle migrated to serverless to handle a growing audience of over 50 million monthly visitors between two sites, Bustle.com and Romper.com.
Bustle initially implemented AWS Lambda to process high volumes of site metric data from Amazon Kinesis Streams in real time, allowing them to rapidly understand how new site features affected user engagement. Bustle then decided to use AWS Lambda and Amazon API Gateway to build Romper.com to be an entirely serverless website.
Bustle also built their own AWS Lambda and Amazon API Gateway software-delivery tool to allow developers to easily perform integration tests and release their code into production.
By moving to a serverless architecture, Bustle has experienced approximately 84% cost savings, engineers no longer have to deal with infrastructure management, and the company can keep their engineering team lean.
Serverless is going to have an increasing role in the future of software development. More companies will adopt serverless architectures to gain a competitive advantage, lower costs, and bring products to market faster. Components and architectures will become more standardized and more programming languages will be supported. Therefore, more developers can easily use the platform and become proficient with the technology. Problems with latency and efficiency will continue to be addressed.
In short, the future is extremely bright for serverless and this approach will be around for a long time.
By Mike Chan
