Traits of Serverless Architecture
thoughtworks.com
thoughtworks.com
A good serverless platform lets you focus on those issues instead of OS patches and hardware upgrades.
Considering that 'serverless' actually needs a more experienced and expensive ops team, no, it really wouldn't.
From my experiences the opposite is the case: The amount of time spent on operating a serverless architecture is much smaller than having to care about the underlying servers as well.
A pretty good example are all the nasty OS-related security vulnerabilities. Instead of patching hundreds of servers, like in the old days, with serverless applications you don't need to do anything. Even better: Your provider (at least if it's one of the major ones) has probably already patched these vulnerabilities, before they get published.
EDIT: markup (not a frequent poster here :) )
"Auto-scaled-CGI-as-a-service"
We still worry about costs, forecasting, latency, monitoring, availability, access controls, auditing, and resource utilization. So, I don't think "opsless" is applicable in the least.
But we don't worry about servers or nodes. We don't worry about zones or regions (we do worry about legal jurisdictions, but that's non-technical concern).
When I go to a Jimmy John's, I'm never served by Jimmy John. So what?
It's great marketing, albeit not what every person imagines, when encountering the term.
E.g. server hosting, container hosting, database hosting, app hosting, function hosting, web hosting.
Some will say that PaaS did have knobs for amount of servers/instances/dynos/whatever but that's a minor detail and the innovation is called autoscaling. No need for an entirely new buzzword. But naming is both hard and exciting so we have "serverless".
Whereas serverless/Lambda/container service can take the billed cpu to zero when you deem fit. There are still cpus managing and administering, but you have the option to take your utilization that you get billed for to zero, where in the PaaS that I've been sold to, I didn't have that option. YMMV, of course.
Those who don't "get" cloud likely haven't seen one big use case where the costs of cloud services are pretty immaterial: very large organizations with human-dominated change processes. The win here with cloud is the policies and contracts are embedded into the API and access configurations. The speed-up isn't from elastic services, it is eliminating the layers of humans standing between you and the service you want delivered.
If you work in such an organization where you send in a change ticket with the exact Unix commands you want run, and it takes a week for the sysadmins to get around to processing the ticket, the cloud seems lightning-fast by comparison. Then all the scaffolding to set up CI/CD, CMDB, configuration management, secrets store, elastic services, etc. either on-prem or in the cloud doesn't seem nearly so tedious any longer.
* edit was working on vault and for some reason typed that word instead of lambda
But sure, Hello World is easy.
One trend in this space I'm super excited about is tools like pywren (from UC Berkeley) and gg (from Stanford), which show the way to building much higher level abstractions that allow non-experts to build and run pretty huge systems. I think we're going to be seeing a lot more of that, and the serverless infrastructure is a huge enabler there.
Another trend is observability, and all the cool tools folks are building to see how systems work 'as built'. These tools can cut through a lot of complexity when debugging systems, and point very clearly to where problems are happening. This is an area where serverless is catching up to single-box tools, and will be for some time. Still, the core problem here is that distributed systems are still harder to debug than single-box systems, but I think that's entirely a reflection on immature tooling. I believe that the fundamental law here is that with the right abstractions distributed systems can be significantly easier to debug that single-box systems.
This article suffers from the same problem though. Where are the downsides? What about production debugging? Moving complexity from inside of services to service interoperability? Vendor lock-in? Lack of human support? Etc.
Two broad use cases for serverless -- event based triggers and APIs. With event based triggers you're already locked in by the events you're subscribing to and as far as API's, at least with AWS, if you're using proxy integration, you can use your standard Node/Express, C#/WebAPI, Python/Flask, etc. framework. You add a few lines of code for the lambda proxy but you can use the same code without any changes with your standard web servers.
With AWS, you also have "serverless Docker" with Fargate and you use standard Docker containers.
Production debugging? The same issues and solutions with any micro-service implementation. The solution usually being a common logging infrastructure.
On a broader scale, "vendor lock in" is severely overrated. Despite all of the "repository patterns that will let us hypothetically move our million dollar Oracle implementation to MySql", it rarely happens and often you end up with sub optimal and more expensive/harder to maintain solutions by not going all in on your vendor's of choice solution.
A mature service mesh will let privileged users get inside containers to attach profilers and debuggers, manually as needed or systematically through performance monitoring tools, in situ or with temporary exclusion from the load balancer pool. It's also sometimes necessary to correlate issues with host-level metrics to understand weirder bottlenecks and tail latency issues.
> it rarely happens
The credible threat of it happening keeps prices low enough to make it unnecessary.
As far as vendor lock in, in general not just with respect to the cloud, there are so many path dependencies and the risk of disruption versus the reward is so rarely worth it, it hardly ever happens.
How much would Oracle or Microsoft have to raise their prices on their database products for instance to make it worthwhile for a large enterprise company to move away from them to an open source alternative?
I agree with the general sentiment that optimizing for extreme portability does not make sense- but there is a balance that needs to be struck. Designing your apps to be relatively SQL agnostic, or at least isolating those dependencies, makes a lot of sense.
What about all of the programs that you used that depended on Oracle specific drivers. Even in a perfect world where everything was using standard SQL, would the regression testing and migrations be something you would want to tackle as a CTO? Would you be willing to take the reputational risks of something going wrong?
This is possible because the data modification operations are triggered directly on the frontend using a SDK, and they are sent straight to the service provider, which will then validate if the operation can go through, like for example checking if the user is authenticated and has write access to the data.
No application code is involved in this process, other than the client-side code.
Not having to constantly hand-code REST endpoints just for doing secure CRUD is huge!
If the business case doesn't require partner/3rd party API access, then maybe Firebase is appropriate.
Mentioned elsewhere in the comments here is the risk of vendor lock-in.
Given Google's history of EOLing products from under developers, there is real risk in putting all the business logic eggs in the Google basket.
It gives easy to use serverless CRUD (with Firestore), authentication, authorization, secure file upload, hosting and server-side functions for things like image processing or database triggers.
I don't think Firebase will be end of live anytime soon, worst case it's user base would get migrated to Google Cloud, as it's really just Google Cloud under the hood. I don't think it's an option for Google to give up on the cloud at this point, even though AFIK Amazon has the biggest market share.
The issue with that design pattern is that you end up with those hand-coded REST (or GraphQL) endpoints anyways.
You can't push all the business logic into the client because as soon as you do that, you end up duplicating all the business logic twice when you want to add a different client (especially in a different language).
For example, I have my Flutter phone app which is primarily for inputting data. I'm not going to put all the logic for talking to the firestore in the app because I also need to have a backend management app for viewing/editing all the data, which is web based.
So, instead, I built the logic into firebase functions via a graphql interface. Now both the phone and web clients can talk to graphql and share that single typesafe interface.
It is really nice that firebase is this flexible though. You can pick and choose and it is still relatively easy to secure the backend by using firebase functions.
How do you tie in to version control?
How do you QA this? (Can it be QA'd locally?)
Would you have unit tests for serverless code? E2E tests?
How would you catch/diagnose a more junior engineer making an infinite loop of events? Would this potentially bring down production or eat the budget?
> How do you tie in to version control?
You're probably talking about the infrastructure definition? Infrastructure-as-Code (e.g. AWS CloudFormation) works quite well and can easily be put under version control.
> How do you QA this? (Can it be QA'd locally?)
For AWS there are projects like the AWS SAM CLI (https://github.com/awslabs/aws-sam-cli) which try to offer the ability to run your serverless application locally, but I believe such approaches are fundamentelly flawed once your application reaches a certain complexity, as I believe such projects will never be able to re-implement all features and services made available by the Cloud provider.
What works well for us is to simply have QA environments spun up in addition to the productive ones. Once you got the infrastructure codified properly that's quite easy. The biggest downside is that it, depending on your architecture, might take some time to provision, so it's not as instant as if you'd run it locally. And you need internet access of course.
> Would you have unit tests for serverless code? E2E tests?
Yes and yes. Actually I see no reason why you'd want to handle test coverage differently from traditional applications.
> How would you catch/diagnose a more junior engineer making an infinite loop of events? Would this potentially bring down production or eat the budget?
Running code during development should never be able to affect production. For AWS the way to go is to use separate AWS accounts for production and testing/QA. You could even go so far to give each engineer his own account.
Regarding catching and diagnosing infinite loops, it all comes down to monitoring: Monitor how the cost evolves and other metrics of interest (e.g. the number of invocations of your serverless functions) and have automatic notifications once certain thresholds are crossed. Additionally limiting the maximum concurrency of serverless functions for non-production accounts might help to avoid things getting out of control too fast.
This is more a characteristic of certain stacks rather than a trait of serverless.
For example, it's a common practice in AWS Lambda functions to cache DB connections using static variables.
Data locality, and amortizing the cost of expensive operations across multiple requests, are still things that matter in the serverless world.
Porting the Go monitoring code to Lambda was trivial. I spent much more time trying to automate the deployment to Lambda & API Gateway and in the end gave up and just deployed it manually via the AWS console.
I also recently moved the main web app from a self-managed Linode setup to Heroku. Deploying via "git push" and not having to worry about configuring or updating servers is a huge time saver. Heroku provides the best of both worlds since I can still login into an ephemeral shell if I want to interactively poke around my live Django environment.
Many people think FaaS is the definition of serverless which leads to false assumptions.
First "We can build serverless with containers at home, because everyone can host FaaS!"
And "Coldstarts make serverless unusable for many problems!"
If you have to manage servers, vms or container (clusters) your solution isn't serverless.
If you don't like coldstarts, don't use FaaS for your API. Use something like Firestore, AppSync or FaunaDB.
There are plenty of stateful serverless services. DynamoDB, BigQuery, Serverless Aurora, etc. In all these cases, you get statefulness without managing or controlling servers.
no thanks.
https://www.cloudflare.com/learning/serverless/serverless-pe...
Firstly, the Cloudflare number includes network time, which isn't included in Google's number.
Secondly you can't compare the numbers unless you know the percentiles used.
Thirdly, you are presuming your function is always cold loaded - which is only for the free tier of pricing from what I could see.
Google (v4 pagespeed) says: "Server response time is the time it takes for a server to return the initial HTML, factoring out the network transport time. Because we only have so little time, this time should be kept at a minimum - ideally within 200 milliseconds, and preferably even less!"
Disclaimer: happy customer of Cloudflare, we don't use Workers except for one debugging purpose.
But it could be luck of the draw that Google's crawler hits your site during a period of low traffic, and your functions have to cold boot. That could impact page rankings, as response times influence those.
Why would you use a slow provider for a comparison point?
> and your functions have to cold boot
For $5 per month, it looks like you get warm startup always on CloudFlare, which is very fast.
Also: Google surely pay some attention to network delays: serving Kenya from a Mombasa POP is going to be way faster than using some server in the US. I would expect Google to give that some juice.