Take aways: Have a thick frontend, use spreadsheets more, have a good reason to write custom code. The world is full of "the main person can't program" scenarios. Ignore: Use closed source, lock-in heavy products like firebase, if you don't like it switch to sql... That's not reality. Good first 22 minutes
Great topic, excellent advice. For many use cases one could recommend use of Step Functions as the pattern to counter the functions-calling-functions anti pattern. Also, the relatively recent Amplify framework/tool chain has much to recommend it for anyone pursuing this sort of dev/deployment approach, composing component cloud services.
Ok, at first I thought "serverless" means "not one big server, but 100 smaller ones", kinda like migrating from monolith to microservices. But I am starting to think that what we call "serverless" is basically saying "the biggest part of the processing for my app/website will not be handled by me, but by a 3rd party". Am I far from the truth?
pretty much :) its fancy word for outsourcing infrastructure... which can be fine, but also you loose quite a lot of control . On other side when you try to do it your self its quite challenging to get everything working production kubernetes infrastructure can be quite complex and you for sure constantly beta testing 2+ components in it :D
@@vladoportos I am really wondering, for your key business process if you depend on 3rd party, how far this is going to be successful.. imagine .. if every one start outsourcing to every other.. how can the quality can be achieved?
I am always happy to watch some actual use cases around serverless, thank you for posting this. Some critiques: early on he mentioned how back-end folks can somehow be treated as if they are better than front end folks, that is sad because everybody is needed to add value, including the spreadsheet person he mentioned later as if they were second-rate because of only knowing spreadsheets. Another observation: serverless is supposed to make things easier and ultimately simpler for the developer, the application needs to be simpler for the owner, that space application example that was demoed has way too many moving parts, creating serverless applications should not look like an octopus with tentacles reaching out to so many third-party services that it would be impossible for a normal person to hold anyting accountable when the service fails for some reason. The run and maintain aspect and total cost of ownership certainly needs to factor in the daunting task of wrangling a dozen third-party API providers and services spread out all over the internet that are sure to fail at random times and become difficult to troubleshoot and support long after the original developers that built the monster are gone. Serverless can certainly make the life of the developer much nicer, that developer should not go crazy and make the life of the application owner a living hell. Step forward into year number 2, imagine something is not working... in a poorly architected octopus application with tentacles reaching all over the place think about the person it will need to open a ticket with the ISP, the serverless hosting provider, all the different authentication and API providers, there will be much finger-pointing and very little traction with little hope of identifying let alone fixing some of the complex problems that will certainly arise with so many vendors in the picture. Unless of course the software developer is selling a maintenance contract and will abstract all of the complexity of multiple vendors away from the application owner, that might be a win-win if done correctly.
Great talk! Firebase is the base. Cloudant & CouchBase are like the super hero version of fb. Your world will be shattered from the ground with those technologies. Waiting for the rest of the planet to catch up.
Take aways: Have a thick frontend, use spreadsheets more, have a good reason to write custom code. The world is full of "the main person can't program" scenarios.
Ignore: Use closed source, lock-in heavy products like firebase, if you don't like it switch to sql... That's not reality.
Good first 22 minutes
Great topic, excellent advice. For many use cases one could recommend use of Step Functions as the pattern to counter the functions-calling-functions anti pattern. Also, the relatively recent Amplify framework/tool chain has much to recommend it for anyone pursuing this sort of dev/deployment approach, composing component cloud services.
Great stuff
Ok, at first I thought "serverless" means "not one big server, but 100 smaller ones", kinda like migrating from monolith to microservices. But I am starting to think that what we call "serverless" is basically saying "the biggest part of the processing for my app/website will not be handled by me, but by a 3rd party". Am I far from the truth?
pretty much :) its fancy word for outsourcing infrastructure... which can be fine, but also you loose quite a lot of control . On other side when you try to do it your self its quite challenging to get everything working production kubernetes infrastructure can be quite complex and you for sure constantly beta testing 2+ components in it :D
@@vladoportos I am really wondering, for your key business process if you depend on 3rd party, how far this is going to be successful.. imagine .. if every one start outsourcing to every other.. how can the quality can be achieved?
I am always happy to watch some actual use cases around serverless, thank you for posting this. Some critiques: early on he mentioned how back-end folks can somehow be treated as if they are better than front end folks, that is sad because everybody is needed to add value, including the spreadsheet person he mentioned later as if they were second-rate because of only knowing spreadsheets. Another observation: serverless is supposed to make things easier and ultimately simpler for the developer, the application needs to be simpler for the owner, that space application example that was demoed has way too many moving parts, creating serverless applications should not look like an octopus with tentacles reaching out to so many third-party services that it would be impossible for a normal person to hold anyting accountable when the service fails for some reason. The run and maintain aspect and total cost of ownership certainly needs to factor in the daunting task of wrangling a dozen third-party API providers and services spread out all over the internet that are sure to fail at random times and become difficult to troubleshoot and support long after the original developers that built the monster are gone. Serverless can certainly make the life of the developer much nicer, that developer should not go crazy and make the life of the application owner a living hell. Step forward into year number 2, imagine something is not working... in a poorly architected octopus application with tentacles reaching all over the place think about the person it will need to open a ticket with the ISP, the serverless hosting provider, all the different authentication and API providers, there will be much finger-pointing and very little traction with little hope of identifying let alone fixing some of the complex problems that will certainly arise with so many vendors in the picture. Unless of course the software developer is selling a maintenance contract and will abstract all of the complexity of multiple vendors away from the application owner, that might be a win-win if done correctly.
serverless == pay other people to take care of your infrastructure :D ( or pay amazon )
Great talk! Firebase is the base. Cloudant & CouchBase are like the super hero version of fb. Your world will be shattered from the ground with those technologies. Waiting for the rest of the planet to catch up.
24:18 singularity U market will be satisfied ~= Moore U Kurzweil
19:19 assets are stored at Firebase? O_o
But why not Firebase just has a service for that specifically it's not like they store assests in a database
Netlifly ? 😜