In July Four weeks ago ( this week ) 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:
- 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 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 you function is running. No need to worry about servers, maintenance, deployment, etc.
As a side note, I find “allows 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.
Contaners 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:
Liquid error: internal
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. Yes. 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:
- Serverless is insecure
- Serverless is expensive
- Serverless is just an unzip library in a container
and then had a number of predictions:
- Serverless is the new supercompute
- Blockchain/ledgers connected to Serverless
- Vendor limitations going away
- Memory
- Scale
- Cold start
3 myths:
- Serverless is insecure
- Serverless is expensive
- Serverless is just an unzip library in a couple container
Liquid error: internal
Serverless and Security
Two main areas in serverless architecture that impact security:
- Function code
- 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
Liquid error: internal
I also liked the following two slides:
Liquid error: internal
and this one:
Liquid error: internal
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. Rapid development ⚡. If some services need to be optimized, configured – then and yes 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. Pricing structure is different – yes. Now, BaaS providers existed for a long time. You might have heard of Parse (acquired by Facebook ad 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 upfront. 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 – 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:
Standard Library @StdLibHQ is a tool for managers, marketers & business people to build APIs 💪
Liquid error: internal
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 👏
Top comments (3)
How? AWS Lambda is priced per usage. Write a bad function and your wallet takes the hit. Performance still matters here and will always matter.
I agree. That's why I had a 🤔next to "Never think about cost" bullet point. You obviously still need to think about cost but to some degree in less capacity. I think performance is more about the infrastructure/servers - not your function code.
That thing next to your bullet point appears as a square to me, something that won't render, so that's why I missed your point there.
In my mind performance is code performance, but sure.