Not really my main field, but in web technology it seems that severless architectures such as Amazon Lambda will be a pretty big game changer in the near future:
Lambdas are lightweight function calls that can be spawned on demand in sub-millisecond time and don't need a server that's constantly running. They can replace most server code in many settings, e.g. when building REST APIs that are backed by cloud services such as Amazon DynamoDB.
I've heard many impressive things about this way of designing your architecture, and it seems to be able to dramatically reduce cost in some cases, sometimes by more than 10 times.
The drawback is that currently there is a lot of vendor lock-in, as Amazon is (to my knowledge) the only cloud service that offers lambda functions with a really tight and well-working integration with their other services (this is important because on their own lambdas are not very useful).
I have to admit, I'm pretty bearish when it comes to serverless. Mostly because it's an abstraction which leaks to hell and back.
Your input is tightly restricted, and with Amazon in particular, easy to break before you even get to the Lambda code (the Gateway is fragile in silly ways). Your execution schedule is tightly controlled by factors outside your control - such as the "one Lambda execution per Kinesis shard". You can be throttled arbitrarily, and when it just fails to run, you are limited to "contact tech support".
In short, I can't trust that Lambda and its ilk are really designed for my use cases, and so I can only really trust it with things that don't matter.
I'm bearish on it right now, though conceptually it's a fantastic idea which just has quite a way to go before it's ready for prime time. I definitely think a lot of people have jumped the gun by pushing serverless before it's really ready for the outside world.
But the reality is that they don't, with cold-start times upward of 30 seconds. If you use them enough to avoid the cold-start penalties, then you're better of with reserved instances because lambdas are 10x the price. If you can't handle the 30 second penalty then you're better off with reserved instances because they're always on. If you have rare and highly latency-tolerable events, then use lambda.
To add, you don't really need that many lambda call for it to be the same price to just have a small always running instance. You can still use it lambda style if you wish, with automatic deployment.
I am pretty bullish on "serverless". I really do think it's the future. It fulfills the vision of Cloud Computing. But it's early days and I wouldn't yet bet the ranch on it. I am doing a new project with Azure Functions and so far am quite happy with the offering.
I don't know, to me it looks like serverless benefits, (ie theoretical lower cost) are not worth the downsides, (essentially complete vendor lockdown), but would love to hear why am wrong :-)
If you go serverless - specifically AWS Lambda, then you must be comfortable with using old and out of date programming environments, as these are what AWS Lambda supports.
Lambdas are lightweight function calls that can be spawned on demand in sub-millisecond time and don't need a server that's constantly running. They can replace most server code in many settings, e.g. when building REST APIs that are backed by cloud services such as Amazon DynamoDB.
I've heard many impressive things about this way of designing your architecture, and it seems to be able to dramatically reduce cost in some cases, sometimes by more than 10 times.
The drawback is that currently there is a lot of vendor lock-in, as Amazon is (to my knowledge) the only cloud service that offers lambda functions with a really tight and well-working integration with their other services (this is important because on their own lambdas are not very useful).