U tweetove putem weba ili aplikacija drugih proizvođača možete dodati podatke o lokaciji, kao što su grad ili točna lokacija. Povijest lokacija tweetova uvijek možete izbrisati. Saznajte više
Microservices are a fine way to scale software engineering but a terrible way to scale software execution. The obvious observation is that it induces extra communication overheads with lots of (de)serializing work, overreads from remote caches and databases, and other such taxes.
Other problems caused by typical lagging auto-scalers watching utilization as a control signal. It typically results in over-scaling services until the actual hotspot causing the violation disappears. Expensive and slow. Utilization is ok for batch but not for latency sensitive.
Perhaps the biggest problem is inherent increase in exposure & impact from fat tail latencies. Lots can be done at the hardware, systems software and application levels. But don't seem to be enough for the debt we're piling up.
Service meshes are great; factor out best practices in network-centric scalability and reliability, and provide tooling for developers and operators to cope with the resulting service sprawl. But are passive with slow feedback loop, and don't help in evolving the app at run time.
Distributed tracing is great in profiling & monitoring distributed systems, and post mortem debug. But devs struggle to form intuitions on root causes of issues, and often resort to masking problems, given the difficulty in debugging or tuning many service to service interactions
Where are the tools for real-time investigation features? The equivalent of setting breakpoints, watching variables, single-step, run backwards, statistical profiling, etc. Even better, programmable tracepoints and a dtrace-on-the-cluster type experience.
Could we keep the organizational goodness of microservices while regaining massive performance, efficiency, and observability benefits? Conceptually, it's "easy": separate the granularity of development and deployment from the granularity of execution and scaling.
In other words, developers should still code microservices or, perhaps even better, functions for independent deployment. However, a multi-tenant execution hardware+software fabric should not execute them as written. Instead they should be morphed to a more suitable form.
Could be aggregated|partitioned to minimize RPC traffic/increase locality, use colo'd external state services, auto layout on failure domains. Dynamically re-partition as required for latency-sensitive auto-scaling. Executed in micro-VMs and bypassing kernel for dataplane.
Easiest if done for a single language like typescript, but a lot could be done with an ebpf-extensible 'linux native service mesh' and similar. Start with aws firecracker etc. Probably have to bootstrap within big company or university rather than start from zero with VC funding.
Not sure I'm a fit either way! Got sucked into grad school once, to do some hacking with a particular fun compiler team, but dropped out mostly to support family but also, after cranking out papers, disillusioned with publish-or-perish and writing endless grant proposals
Recent mid-size company guest appearance reminded me I'm better at building things (hw, sw, teams, whatever!) than debugging / massaging broken IT processes.
I suppose the litmus test is at the extremes. Can my network of functions scale down to run on a single core within a single process, and without rewriting, up to many processes in many blast zones when under production load?
Twitter je možda preopterećen ili ima kratkotrajnih poteškoća u radu. Pokušajte ponovno ili potražite dodatne informacije u odjeljku Status Twittera.
