DEV Community

Yos Riady
Yos Riady

Posted on • Updated on

Why Serverless

Find more interesting articles at yos.io

Web applications are traditionally deployed on web servers running on physical machines.

As a software developer, you needed to to be aware of the intricacies of the server that runs your software. In order to get an application running on a server, you can spend hours downloading, compiling, installing, configuring, and connecting all sorts of components. The OS of your machines need to be constantly upgraded and patched for security vulnerabilities.

Managing servers is a time-consuming task which often requires dedicated and experienced systems operations personnel.

What server maintenance can feel like -- Metropolis (1927 film)

What is the point of software engineering?

Contrary to what some might think, the goal of software engineering is not to deliver software. A software engineer's job is to deliver value - to get the usefulness of software into the hands of users.

At the end of the day, you need servers to deliver software. However, the time spent managing servers is time you could have spent on developing new features and improving your application. Instead of worrying about servers, you want to focus on shipping.

When you have a great idea, the last thing you want to do is set up infrastructure. How can we minimize the time required to deliver impact?

Moving to the Cloud

Over the past few decades, improvements in both the network and the platform layer - technologies between the operating system and your application - have made cloud computing easier.

Back in the days of yore (the early 1990s) developers only had bare metal hardware available to run their code, and the process of obtaining a new compute unit can take from days to months. Scaling took a lot of detailed planning, a huge amount of time and, most importantly, money. A shift was inevitable. The invention of virtual machines and the hypervisor shrunk the time to provision a new compute unit down to minutes through virtualization. Today, containers gives us a new compute unit in seconds.

DevOps has evolved and matured over this period, leading to the proliferation of Infrastructure-as-a-Service (IaaS) and Platform-as-a-Service (PaaS) providers. These third-party platforms lets you delegate the task of maintaining the execution environment for their code to capable hands, freeing the software developer from server and deployment concerns.

Platform-as-a-Service (PaaS) providers allows developers to develop, run, and manage applications without the complexity of building and maintaining their own infrastructure

Today, developers have moved away from deploying software on physical computers sitting in their living room. Instead of manually downloading and building a bunch of platform-level technologies on each server instance (and later having to repeat the process when you scale) you can go to a simple web user interface on your PaaS provider of choice, click a few options, and have your application automatically deployed to a fully provisioned cluster.

When your application usage grows, you can add capacity by clicking a few buttons. When you require additional infrastructure components, set up deployment pipelines, or enable database backups, you can do this from the same web interface.

The state of Platform-as-a-Service (PaaS) and cloud computing today is convenient and powerful - but can we do better?

Enter Serverless

The next major shift in cloud computing is commonly known as “Serverless” or “Functions-as-a-Service” (FaaS.)

Keep in mind that the phrase “serverless” doesn’t mean servers are no longer involved. It simply means that developers no longer need to think that much about them.

Computing resources get used as services without having to manage around physical capacities or limits.

Cloud Computing Evolution

Serverless is a software development approach that aims to eliminate the need to manage infrastructure by:

  • Using a managed compute service (Functions-as-a-Service) to execute your code, and
  • Leveraging external services and APIs (third-party Software-as-a-Service products.)

There is now an abundance of third party services: APIs that handles online payments, transactional email, user analytics, code quality measurement, content management, continuous integration, and other secondary concerns.
In our everyday work we also make use of external tools for project management, file sharing, office administration, and more.

Third-party services developers rely on for software development.

Instead of spending valuable resources on building up secondary capabilities such as infrastructure and server maintenance, developers can focus on their core value proposition. Rather than building things from scratch, developers can connect prefabricated parts together and prune away secondary complexity from the application.
By making use of third-party services, you can build loosely coupled, scalable, and efficient architectures quickly.

In closing

The Serverless movement and FaaS platforms are a major step towards delegating infrastructure problems to companies that are much better positioned to deal with them. No matter how good you become at DevOps, Amazon / Google / Microsoft will almost certainly have done it better. You can now get all the benefits of a modern container farm architecture without breaking the bank or spending years building it yourself.

Why go Serverless? So you can always be shipping.

Find more interesting articles at yos.io

Top comments (11)

Collapse
 
xngwng profile image
Xing Wang

There are pros and cons.

One of the growing challenges with serverless computing is monitoring and debugging all those functions. Logging context is now scattered across even more components than even in a microservice architecture. May of the logs are very vendor specific and is not like looking at standard NGINX or HaProxy logs.

But we are still very excited about growth in this space. Interesting that you wrote a book on this topic. Congrats.

Collapse
 
yos profile image
Yos Riady

Yes, absolutely. Monitoring and debugging remains a challenge in serverless because for one
you can't ssh into a running lambda. Fortunately, the serverless landscape is maturing: services such as AWS X-Ray, Iopipe, Dashbird, and a few others have emerged to help solve the visibility problem: they help you see inside your lambda functions.

As serverless continues to grow and mature, I expect we'll see more solutions in this space.
Thank you for reading!

Collapse
 
nitzanshapira profile image
Nitzan Shapira

Great read!

I think that leveraging external services and APIs are a KEY THING here - it enables you to focus just on your business logic, and FaaS enables you further to not even manage the server your code is running on.

Regarding monitoring - at Epsagon (epsagon.com), we are focusing on automatic end-to-end monitoring of the ENTIRE architecture, rather than of a single Lambda - which we found out is the main challenge in serverless today. Feel free to contact us and try it out our beta.

Collapse
 
danielhoffmann_ profile image
Daniel HB

This is a good point, but I feel this is a solvable problem. Surely there must be a way to unify the logs of several microservices somewhere? But I feel this needs to be provided by the platform where your code runs. Like a periodic upload of logs to a central data warehouse

Collapse
 
xngwng profile image
Xing Wang

lol. I'll do my own plug.... Since most serverless and microservices are APIs, if we capture all the data at the API level from all these different sources, and analyze them together can solve this problem. Check out the company that I started. Moesif. (moesif.com)

Collapse
 
rupakg profile image
Rupak Ganguly

One of the growing challenges with serverless computing is monitoring and debugging all those functions.

Yes, true, but things are improving. Check out serverless.com/blog/serverless-mon...

Logging context is now scattered across even more components than even in a microservice architecture.

Checkout AWS X-Ray. Its improving.

May of the logs are very vendor specific and is not like looking at standard NGINX or HaProxy logs.

You can redirect the logs to Splunk or an ELK stack from any of the leading FaaS providers.

Collapse
 
puresecteam profile image
PureSec

Great read, but if I can add one important point- when it comes to serverless, you are responsible for your own security, and not the platform provider. So make sure to have it covered. This is an important read: puresec.io/blog/serverless-top-10-... it covers the top 10 security issues in serverless architectures.

Collapse
 
tojacob profile image
Jacob Samuel G.

Serverless seems great to me. But it can be very expensive.

Collapse
 
yos profile image
Yos Riady

It really depends on what the traffic pattern of your application looks like. For most web applications, traffic can be unpredictable. Instead of paying for idle compute time during low traffic periods (where you waste money on unused compute resources), you can simply pay-what-you-use with serverless: the infrastructure only exists when there is an incoming request.

Collapse
 
xngwng profile image
Xing Wang

The best analogy is ZipCar vs. Buy a car.

Owning or leasing a car is cheaper than ZipCar if you compare the hourly rates.

But, if you only use car occasionally, then owning a car (or even leasing a car) get more expensive, since it is sitting around doing nothing a lot of the time.

Collapse
 
monsieurcellophane profile image
Monsieur Cellophane

Herding cats begins to look attractive.