I wonder how he feels now about EKS–Elastic Kubernetes 
1 Like
I don’t think this is emphasized enough - you’re moving from the conventional
to the serverless
i.e. the frontend has to be more than just a UI.
If you’re using serverless for cost savings you’re missing a big trick
Mike Roberts of Symphonia (“free” ebook)
His 2016-Aug-04 article on martinfowler.com
While it’s not under the umbrella of serverless, there are other potentially on-the-cheap compute options like bidding for unused capacity.
What I meant that FE and lambda functions are mostly used as a glue for other cloud services like put files into S3, trigger some function on image recognition …
I don’t think so that lamda functions are useful itself without other cloud functionality.
But this is only my opinion 
Example of such application
Yes, but previously that “glue” was encapsulated on “the server” and the “the server” could be used as a single point of contact for the frontend - meaning the frontend’s responsibility could be limited to being a UI. With serverless that is no longer the case - some of the service orchestration has to happen on the frontend. Also the lamda functionality is more than just mere “glue” - it also contains your “domain logic”.
I don’t think so that lamda functions are useful itself without other cloud functionality.
They aren’t mean’t to be. But they are the final piece of the puzzle to let traditional server-side functionality become a commodity.
Most of us don’t have to build, run or manage a powerplant to have electricity coming out of the wall socket. Just because you want electricity doesn’t mean you want to manage a powerplant (generator). But before serverless there was always some server that had to be managed for your application to be on the internet. Before Lamda there was Elastic Compute - but that still is essentially a server.
With serverless you still have to configure the services (Gateway API, Cognito, S3, DynamoDB, RDS, Lamda, etc…) that play a part in your application but you aren’t managing the details of the servers the services are running on.
1 Like
Yes I agree you don’t pay for server but for blocks that are you using in your application. This is totally different concept of building applications from cloud blocks …
This is totally different concept of building applications from cloud blocks …
I think the argument could be made that there are lots of web applications on the web that could be built the serverless way right now. And ultimately there are lots of organizations that view their “web-presence” as a necessary evil rather than as a part of their core business.
Smaller businesses will be attracted to serverless because they don’t have to pay for idle time or be concerned about server provisioning and administration. Larger businesses because they can try out something quickly right now without having to worry about any infrastructure concerns.
I’m not implying it’s better but serverless certainly seems like something a lot of businesses will be attracted to, regardless of what it means to the people who have to implement everything.
2016-Jun-07: “Serverless” is just a name. We could have called it “Jeff”
1 Like
You can also build severless yourselfinside your organization on top off K8s or Docker Swarm - OpneFass. So this is not only limited to public clouds. (But will be more complicated to maintain)
But that would be entirely missing the point - tantamount to building and running your own power plant because you need electricity. You could hypothetically run OpenWhisk in-house but you are also once again responsible for the burden of provisioning and maintaining servers - something lots of businesses and even individuals are not interested in.
I’m more concerned with not being bogged down by maintenance than anything else, so I can focus on more projects.
from Do’s and Don’ts of AWS Lambda.
Larger organizations will still run servers of some description either owned, leased or whatever. But there is going to the temptation to minimize that part of the business and it being considered “legacy operations” i.e. stuff that is necessary for day-to-day operations but where development has plateaued and therefore might be too expensive to keep on the public cloud (and then there is the issue of data that has to be extra secure either by necessity or government regulation).
Personally I believe that doing serverless on in-house hardware is utterly pointless. That would mean accepting all the constraints of serverless (there are better ways to develop and run software on in-house hardware) without having the primary benefits:
- Not having to manage your own server operations
- Not having your (request) scalability limited by the capacity of your in-house infrastructure.
In the past we’ve had Rapid Application Development, agile etc. The same motivation that gave rise to that type of thinking is going to push into serverless.
Are there going to be maintainability problems? Of course there are. Peter Sbarski admitted that they created a Serverless Monolith - so they had to go back and Go Micro i.e. identify the virtual boundaries of their business and enforce them with discipline in their architecture.
1 Like
Yes I agree if you can put all data into cloud, there is no sense to maintain own cloud …
But some times you cannot put all operations in cloud, in this case you can have hybrid cloud.
And when you have hybrid cloud is better to have some consistent.
But there are also companies moved away from cloud to own infrastructure like drobox.
So I would say “it depends”
2 Likes
PS
If someone interested in Kubernetes (K8s), redhat, openshift and cloud great podcast.
1 Like
I think the landscape is changing right now. Yes more dominant are cloud vendor locking but there is some light in tunnel. Everything thx to https://kubernetes.io/ (K8s) . Now Azure, Amazon, Google Cloud have support for K8s. People building blocks on top of K8s like serverless . So cloud become more open …
1 Like
Honestly it’s a bit like describing spherical cow.
-
Provide resiliency in response to a datacenter failure
This sounds great until you consider a simple fact that say vast majority of say Equinix datacenters have better uptime than AWS East region. So to get better uptime than a quality DC you have to do multi-region in AWS and that is even more painful to setup than your “on prem” multi DC solution. -
The ability to scale to meet elastic demands
Majority of points here pretend that enterprises do not run diverse workloads and they can’t run k8s themselves. -
Secure and protect your data
Cmon living in a world that just saw row hummer, spectre, meltdown not even funny to compare on prem with cloud. -
Accelerate the development
Highly depends on particulars AWS has idiotic hard limits that you have to work around. Like managed PG great want to have 7 TB instance tough luck, want to have IOPS equivalent to mid range notebook SSD well tough luck, want to have 4TB RAM tough luck the list is infinite. Want to have snapshot schedule like one every 5 minutes for last hour and every hour for 24 will charge you not by actual size on disk but by logical snapshot size have fun paying the bill…
5 Likes
1 Like
Lambda Days 2018 - Wojciech Gawroński - Functional Programming in Serverless World
1 Like
1 Like
Cutting costs from AWS serverless to just hosting Elixir nodes. You be the judge. https://medium.com/coryodaniel/from-erverless-to-elixir-48752db4d7bc
2 Likes
