Serverless Architectures(martinfowler.com) |
Serverless Architectures(martinfowler.com) |
And the day before that: https://news.ycombinator.com/item?id=11913463
And the day before that: https://news.ycombinator.com/item?id=11910246
But, last update:
04 August 2016: Added “Future” and “Conclusion”
> If we see the gap of management and scaling between Serverless FaaS and hosted containers narrow the choice between them may just come down to style, and type of application. For example it may be that FaaS is seen as a better choice for 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. I expect in 5 years time that many applications and teams will use both architectural approaches, and it will be fascinating to see patterns of such use emerge.
We will see this gap narrow.
I'm running tons of ECS workloads and operating the servers takes no effort. Amazon releases AMIs, CloudFormation automates AMI updates and scale, and ASGs keep everything running.
It took effort to learn these techniques and build tools that use them, but that's solved by open source software.
See Convox for an OSS project that sets it all up out of the box: https://github.com/convox/rack. Disclaimer: I work on Convox full time.
> containers are seen as a better choice for synchronous-request driven components with many entry points
Is absolutely correct, and describes ~95% of real-world software. For greenfield on AWS, I'd definitely see if Lambda, API Gateway and DynamoDB will work. For all those "old" Java, Python, PHP and Postgres systems out there, we have to run traditional containers, and load balancers and databases.
There's really no future where we are all "serverless". But there is a future where the resource cost and operational burden of both Containers and Functions is very very low.
it will be interesting to see how small these boundaries can become before it is too expensive to measure at the level of granularity sought. when you can spin up a container, run job, and destroy faster than you can even log.
Either you pay to idle 1 GB of ram on some giant server somewhere, or you put it on really fast SSD and pay the time to load it all into ram.
Now a little Python or C routine that uses 8 MB of ram... becomes a much easier thing to do.