|
@copyconstruct | |||||
|
How awesome would it be if I as a developer didn’t have to fuck around with kubectl, terraform, cloud tooling etc.
If instead, the PaaS would let me choose where to run my app based on *app leve concerns* like latency, CPU usage, RPS, traffic patterns (bursty vs sustained) etc.
|
||||||
|
||||||
|
Cindy Sridharan
@copyconstruct
|
23. pro |
|
What are the biggest pain points you believe tooling can address in the next decade (2020-2029)?
I’ll go first:
- CI/CD. Jenkins is currently the CI gold standard and it’s a very low bar.
- Easier abstractions and paradigms for building infra. Kube is too low level + complex.
|
||
|
|
||
|
Cindy Sridharan
@copyconstruct
|
23. pro |
|
What I mean by “paradigms” is basically this:
Right now the compute spectrum is a bit of an embarrassment of immature riches; as an industry we need to innovate, experiment and educate more on how to pick the right compute option for the wide variety of workloads we already run.
|
||
|
|
||
|
Cindy Sridharan
@copyconstruct
|
23. pro |
|
How can FaaS be leveraged better and applied to existing problems to get better outcome? twitter.com/copyconstruct/…
Can traditional “PaaS” development be rethought from the ground up, given the low level primitives we now have (bare metal servers in the cloud, VMs, FaaS etc).
|
||
|
|
||
|
Cindy Sridharan
@copyconstruct
|
23. pro |
|
And transparently run my workload wherever it’s best suited to be run - be it in “containers” or in VMs or compiled down as a wasm instance and run on the “edge” in CDN POPs or by invoking a lambda function.
With all the debuggability and observability baked in out of the box.
|
||
|
|
||
|
Łukasz
@lukaszkorecki
|
23. pro |
|
I'd say that Google's Cloud Run is going somewhat in that direction - you just give it a container, and the rest (scaling up/down, routing, rollbacks, metrics) are handled for you, BUT you're not locked in into a limited execution environment like Lambda.
|
||
|
|
||
|
Lei Zhang (Harry)
@resouer
|
24. pro |
|
a container is a super low level primitive, but the direction of serverless app is right
|
||
|
|
||
|
stephen cawood
@cawood
|
23. pro |
|
This is the problem @CTO_ai has set out to solve. Free up devs to write features (disclosure: I work for them)
|
||
|
|
||
|
Fintan Ryan
@fintanr
|
23. pro |
|
100% agree and I’d love to see this, but until as an industry we get past the “special snowflake status” every engineering team (and company) has it sadly won’t happen.
|
||
|
|
||
|
Mark Papadakis
@markpapadakis
|
23. pro |
|
That would require exposing a lot of runtime metrics(observability), and at least some basic constraints (so that you can reason about costs and serve as safeguard against resource abuse), and also, in most architectures today slowest service/component defined overall scaldbilth
|
||
|
|
||
|
John Engelman
@johnrengelman
|
23. pro |
|
Or....when you remove the distinction between runtime location, the developer no longer needs this choice. Instead, you model the choice as declarative capabilities and requirements for the app and let the platform decide what best suites.
|
||
|
|
||
|
John Engelman
@johnrengelman
|
23. pro |
|
Don’t have all of that implemented yet, but that’s precisely what we are building/running @Target.
youtu.be/cnHfK4MZA2Y
|
||
|
|
||
|
BK Lau
@bklau2006
|
23. pro |
|
Precisely. Loud and clear. You just hit the nail on its head.
|
||
|
|
||
|
Mark Papadakis
@markpapadakis
|
23. pro |
|
So even if the underlying overseer thing that manages everything works well for most resources, if it doesn’t work for all resources, the business can fail. Need to get everything right.
|
||
|
|
||