undefined | Better HN

0 pointsdevereaux7y ago0 comments

So true. For some low latency applications, anything above the bare minimal virtualization is not acceptable.

For what I do, in theory, many things should not impact results. In practice, anything that upon measurement impact results is stripped away. Think A/B testing but for every single component - including the major version of say the python interpreter.

That's how you end up running many things baremetal.

I'll say the future is not serverless but cloudless

0 comments

4 comments · 3 top-level

hjacobs7y ago· 1 in thread

I would argue that the longtail of applications does not really care about the impact of overlay networks. For us, the biggest impact on low-latency applications (where 1ms makes a difference) on Kubernetes was disabling CPU throttling in all clusters (you can also remove container limits). Background: a Kernel CFS quota bug leads to throttling even if quota is not yet reached, see https://www.youtube.com/watch?v=eBChCFD9hfs&feature=youtu.be...

lykr0n7y ago

Overlay networks compound unstable networks. If your internal network latency spikes to 2ms from 0.5ms, normally that's not a huge issue but if you have micro-services that need to talk to each other- using my example, a 1.5ms round trip time would cause an additional 8ms of latency.

Sure, that's a low number but if you already have 150ms of processing, adding another 10ms might cause issues.

Also, if you're disabling the resource controls on kubernetes- you're kinda defeating the whole point.

bostik7y ago

If you do trading or adtech (which, let's face it, is trading) then yes, the overhead from virtualisation and cloud environments is an unacceptable tradeoff.

For most companies and their operating environments cloud gives flexibility in capacity planning, freedom to experiment wildly, access to practically unlimited storage[ß], plus reliable perimeter load balancing. And of course, for most companies engineering costs far more than compute. Paying the premium for cloud environment makes business sense if it means your development teams don't have to spend time waiting for available resources.

Funnily enough, even a number of high-end trading firms (including HFT shops) are moving to cloud. Number crunching for models, backtesting, CI, analysis and simulation pipelines, ... All of those require resources and rarely need to operate in tandem with the real-time trading systems. The same flexibility, ease of capacity expansion and freedom to bring transient resources online as needed saves on expensive development time.

If you're big enough, or need to operate fast enough then cloudless and baremetal are going to bring better ROI. Most companies aren't at these extreme ends, though.

ß: within limits; if you need to produce and store petabytes of changing data on a daily basis...

romeisendcoming7y ago

I'll be retired by then..and I disagree that it will be cloudless but for some compute the cloud is a risky option being forced upon them by exec level marketing, solutions hype (like k8s and docker).

Some of the old hands always keep a colo + baremetal in the back pocket for always on and base testing; only pushing to the cloud after due diligence in comparative testing. That's a more realistic approach than 'cloudless' for scale.

j / k navigate · click thread line to collapse