serverless notes.

parent a08f0b9f
......@@ -72,7 +72,7 @@ The insane number of services you have to use [to use lambda] (IAM, API Gateway,
eliminating server maintenance,... LEO com PaaS tipo Heroku, tb não há "server maintenance"
LEO parece como q explodingo microserviços... deploy não apenas cada microserviço, mas deploy cada função.
LEO parece como q explodindo microserviços... deploy não apenas cada microserviço, mas deploy cada função.
you would be able to create a "micro-repo" of serverless functions that are in the source of your microservice application, in this case Spring Boot.
......@@ -101,16 +101,81 @@
Serverless Architectures
functions fronted by an API gateway.
we see a preference for choreography over orchestration, with each component playing a more architecturally aware role—an idea also common in a microservices approach.
long-lived server applications—is a key difference when comparing with other modern architectural trends like containers and PaaS (Platform as a Service).
If we go back to our click-processing example from earlier, FaaS replaces the click-processing server (possibly a physical machine, but definitely a specific application) with something that doesn’t need a provisioned server, nor an application that is running all the time.
It takes some time for a FaaS platform to initialize an instance of a function before each event.
“warm start” vs “cold start” -> Similar to Heroku
Java (typically the language with the slowest startup time)
if you were writing a low-latency trading application you probably wouldn’t want to use cloud-hosted FaaS systems at this time
most PaaS applications are not geared towards bringing entire applications up and down in response to an event, whereas FaaS platforms do exactly this.
Serverless vs PaaS
The key operational difference between FaaS and PaaS is scaling. Generally with a PaaS you still need to think about how to scale—for example, with Heroku, how many Dynos do you want to run? With a FaaS application this is completely transparent. Even if you set up your PaaS application to auto-scale you won’t be doing this to the level of individual requests (unless you have a very specifically shaped traffic profile), so a FaaS application is much more efficient when it comes to costs.
Principally the argument I made for PaaS still holds with containers - for Serverless FaaS scaling is automatically managed, transparent, and fine grained, and this is tied in with the automatic resource provisioning and allocation I mentioned earlier. Container platforms have traditionally still needed you to manage the size and shape of your clusters.
it may be that FaaS is seen as a better choice for an event-driven style with few event types per application component, and containers are seen as a better choice for synchronous-request–driven components with many entry points.
Serverless doesn’t mean "No Ops"—though it might mean “No sysadmin”
the biggest benefit is that you only pay for the compute that you need
Auto-scaling is likely not a good option here due to how long new instances of servers will take to come up—by the time your new instances have booted the spike phase will be over.
any performance optimizations you make to your code will not only increase the speed of your app, but they’ll have a direct and immediate link to reduction in operational costs
if you’ve gotten to the point of using auto-scaling in a non-FaaS architecture, that still requires setup and maintenance. This work is no longer necessary with FaaS.
you no longer need to think about the question of how many concurrent requests you can handle
a fully Serverless solution requires zero system administration.
less time spent on operations equals fewer people needed for operations
With a Serverless approach we no longer make such capacity decisions ourselves
Nate Taggart on Serverless
IEEE Software
Serverless as an evolution from microservices.
This event-driven model is interest-
ing because it actually makes applica-
tions feel much more distributed.
the development model is also distributed.
You have different teams relying on and
potentially reacting to both code and
events that other teams may be respon-
sible for managing.
Once again, you don’t have to man-
age the orchestration, or the scaling,
or the availability, or the underlying
* Underlying infra (and its scaling) becoming more abstract -> less infra management -> path to NoOps
* Very close to PaaS, but without server or container concecpt
(in PaaS you do not manage the server/container, but usually you still have some abstraction from it).
* More focus on pay per use than PaaS.
* Risen from Single Page Application with a lot of logic on client code.
* [extra] Talks as sources: important sources to know about very recent hypes (no books or papers yet).
* custom logic around events
GOTO 2018 • Confusion in the Land of the Serverless • Sam Newman (author of Building Microservices)
Good talk!
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment