Refactoring to Serverless | Serverless Office Hours

Find out from the experts how to improve the design of your serverless application by replacing application code with automation code.

Gregor Hohpe and Sindhu Pillai and join Julian Wood to go through how serverless is more than just a run-time for your code. Learn how to take advantage of the suite of cloud provider managed services to help fine-grained, event-driven applications best utilize the cloud. See how automation is an integral part of building serverless applications, how the same functionality can be achieved from application code or through a platform feature, and take your serverless building to a new level

We are also available to answer any of your serverless questions.




Stream links:

#serverless #aws


🌥️🌥️ SERVERLESS OFFICE HOURS 🌥️🌥️

A weekly live office hours to learn about building serverless applications. We cover a separate topic each week including what's new with serverless, deep dives into feature launches and best practices, and explore real world use-cases. Join us live to ask us anything you want about serverless technologies and applications.

Your resource for learning about serverless technology.
Learn to use and build apps that scale automatically on low-cost, fully-managed serverless architecture.

Chapters:
00:00 Last Week in AWS Serverless
05:00 Why refactor to serverless?
23:37 Tools and code

[TechInnovatorForndCentury]

The elegance of this approach is that there is a single code base that provides instructions to the machine, regardless of the level (application or infrastructure). I'm surprised that no one else has come up with this idea before, as it seems so natural and obvious. Another advantage is the encapsulation (or simplification) of the communication topology through the use of object orientation. This harmonizes communication within the application logic and at the infrastructure level.
However, there are perhaps some drawbacks with this approach. One is the increases the demand for object-oriented programmers, which are more expensive. Additionally, there is a higher risk that the architecture layers (concerns) of application logic, communication, and infrastructure might become convoluted if handled by less experienced developers. If these concerns are not properly separated, there may be greater reliance on AWS. Latter might not be emense issue if AWS continues to offer cost-effective services, but if a cheaper public cloud provider is desired, the question arises whether the migration costs from AWS would outweigh the savings.