Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

What I Learned Attending a Serverless Conference

DZone's Guide to

What I Learned Attending a Serverless Conference

If you need a way to justify your attendance at a fall serverless conference, check out what this developer learned at Severlessconf.

· Cloud Zone ·
Free Resource

Container Monitoring and Management eBook: Read about the new realities of containerization.

Four weeks ago, I attended the Serverlessconf in San Francisco. The following are my notes, observations, opinions, and pictures from the conference (in no particular order).

Serverless Awesome

Serverless is awesome because:

  • You can build apps faster
  • Development-focused
  • Serverless architecture offers the most productivity and agility
  • Never think about servers
  • Never think about cost 
  • Never think about performance

A common message that I have been hearing (and reading) is that serverless allows devs to concentrate on app business/logic. And that's true. You write the code and the cloud platform simply runs your function, it ensures virtually unlimited scalability, and you only pay when your function is running. No need to worry about servers, maintenance, deployment, etc.

As a side note, I find the "allows you to concentrate on app business/logic" message interesting because every new technology/software/framework in the past had the same message.

AWS Lambda Is the Leader

AWS Lambda is no doubt the leader in the serverless space right now. Probably because they were the first to introduce serverless on their cloud. I think most non-Amazon speakers mentioned or used AWS Lambda. They are closely followed by Microsoft with Azure Functions, then Google Cloud Functions and then IBM Cloud Functions.

Containers vs. Functions

A number of talks mentioned containers vs. functions. It's not really one vs. the other. Functions are easier and give you higher abstraction. Containers give you more control and flexibility. It depends on the context and the problem you are trying to solve. In general, this is how it looks:

Image title


Function Cold Start

A number of talks mentioned that function cold start can be a problem but believe this problem will soon be solved by the cloud providers. I think context is important here. If the function is responsible for launching a rocket into space then every fraction of second probably counts. A cold start can be a problem in this case. If a function is used to deliver an internal business application, then a cold start is probably not a big deal.

3 Myths and 3 Predictions

Tim Wagner from AWS talked about three myths about serverless:

  1. Serverless is insecure
  2. Serverless is expensive
  3. Serverless is just an unzip library in a container

and then had a number of predictions:

  1. Serverless is the new supercompute
  2. Blockchain/ledgers connected to Serverless
  3. Vendor limitations going away

Serverless and Security

Two main areas in serverless architecture that impact security:

  1. Function code
  2. Execution environment

This was also mentioned:

"Serverless is secure by default because it is someone else problem"

It sounds good but I'm not convinced this is 100% true. 

Evolution of Business Logic

Image title


I also liked the following two slides:

Image title


and this one:

Image title


I think this makes a lot of sense. Try serverless first and see what you can build. Not every application needs to go the containers route right away. If some services need to be optimized, configured, then go and use containers.

I think there is a fear that you might need more flexibility/features in the future and this pushes people to use tools that provide more flexibility, configuration but also bring a lot more complexity. In many cases that's unnecessary.

Again, I think the type of application you are building is also important here. A backend office application is most definitely a good candidate to start with serverless.

More Tips, Patterns, and Anti-Patterns

Yochay Kiriaty from the Microsoft Azure team shared some best practices:

  • Functions logic should be stateless
  • Functions should be idempotent
  • One task per function
  • Functions should finish as quickly as possible
  • Avoid recursion
  • Concurrency and rate limits

And one more thing he shared is to avoid functions trying to do too many things. Otherwise, you end up with a "mini-monolith" function.

Scalability

One of the major serverless benefits is scalability. Basically, you get auto/unlimited scalability from the cloud platform. Rob Gruhi from Nordstrom shared that this works very well during events such as Black Friday where demand can spike up very fast (and then drop as fast).

Serverless and BaaS

I was a bit surprised that no one mentioned backend as a service (BaaS). I think serverless is a component of BaaS. The pricing structure is different, yes. Now, BaaS providers have existed for a long time. You might have heard of Parse (acquired by Facebook and now lives as an open source project), StackMob (acquired by PayPal) and Kinvey (acquired by Progress). There are a few smaller players. One of them is Appery.io (my previous company). These companies provide a server-side environment where you can execute code. Language support was probably limited to JavaScript (so yes, this is different now). They also provided storage services (database as a service) and other services such as push notifications.

There are hundreds of companies that do something-as-a-service. I think they all can be viewed as serverless companies. I think so, or am I missing something? 

Of course, all these services also need to be "serverless" — in other words, scale as demand increases. If a function calls a service that can't scale then, of course, is a big challenge.

What did change is the pricing structure and how services would scale.

You would pay for a number of API calls up front. If you used them all — great. If you didn't use them all — well, not much you can do, you already paid for them. And if you went over your limit, you would be charged overages.

How to scale your application/services was somewhat of a gray area. I think the basic idea was that if your app grows fast, let us know and we will figure out something.

Rapid Development/Low Code/Citizen Developers

I think combining low code/rapid development/visual development with serverless can be a very nice fit. The closest mention of that I saw from StdLib:

Image title


Serverless vs. FaaS vs. Cloud Functions Naming

I think serverless should refer to general application architecture — meaning that an application is built from various components and services (which are serverless or available as something-as-a-service). Cloud functions are simply a component of the serverless architecture (a server-side environment where you write application code/logic). Other components of a serverless architecture would be a database, push notifications and other services (pricing and scalability can be different from the current serverless model).

I think specifically for the environment where code is executed (what people today call serverless), I prefer "cloud functions" name or FaaS (Function as a Service) instead of serverless.

One More (Funny) Note

(Almost) every serverless talk starts "Well, there are actually servers behind the scene".

Great conference.

The Essentials of Container Monitoring: Learn the 4 principles of application containerization. Download Now.

Topics:
cloud ,dev career ,conferences ,serverless computing ,containers

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}