,
6 tweets,
2 min read
Read on Twitter
The serverless shift
* From Code to Configuration
* From High LoC towards Low LoC (preferably zero)
* From Building Services to Consuming Services
* From Owning Workloads to Disowning Workloads
* From Code to Configuration
* From High LoC towards Low LoC (preferably zero)
* From Building Services to Consuming Services
* From Owning Workloads to Disowning Workloads
From Code to Configuration
Configuration is a form of "code", but is not necessarily programming. It defines the resources and services used and how they are combined for an application. The code is the ***unique business logic*** required for the application.
Configuration is a form of "code", but is not necessarily programming. It defines the resources and services used and how they are combined for an application. The code is the ***unique business logic*** required for the application.
From High LoC to Low LoC (preferably zero)
Today's code is tomorrow's technical debt. Code is always a liability at some point in the future. Limiting this future liability is a good thing. Working to reduce this liability from the beginning is simply good practice.
Today's code is tomorrow's technical debt. Code is always a liability at some point in the future. Limiting this future liability is a good thing. Working to reduce this liability from the beginning is simply good practice.
From Building Services to Consuming Services
Who wants to manage and maintain a service or a server or anything that looks like one? Management requires people, and people should be employed developing features and moving a business forward, not maintaining technical debt
Who wants to manage and maintain a service or a server or anything that looks like one? Management requires people, and people should be employed developing features and moving a business forward, not maintaining technical debt
From Owning Workloads to Disowning Workloads
Build in such a way as to avoid ever owning a workload that is not business critical. If it isn't business critical, then why do it? Disown it as quickly as possible and hand it to the vendor.
Build in such a way as to avoid ever owning a workload that is not business critical. If it isn't business critical, then why do it? Disown it as quickly as possible and hand it to the vendor.
This is the shift that teams and people need to take to start to go #serverless. It's not about FaaS or what technologies you use, but about the mindset you take. There may be more but this is my starting point.
