imbriaco

It's very true in my experience, and we've looked pretty hard at all the options. Thanks for the offer of the slides, I have first hand experience with this at scale.

It certainly depends a lot on how sophisticated your autoscaling is and how closely you're able to follow demand to limit waste, how well you can manage per-host utilization, whether you are CPU or memory bound, and lots of other factors. But even at truly massive scale the cloud hosting option can be very competitive without nearly as much management overhead.

The vast majority of game servers are hosted on public cloud providers. They turn out to be a pretty perfect example of an ideal cloud workload:

- Very elastic demand curve

- Generally ephemeral with any necessary persistent state stored off-host

- Benefit from geographic distribution of cloud regions because they're generally quite latency sensitive

Totally agree, there's definitely an opportunity there if the surface area of what the system is doing gets smaller. The big difference today is that it's a lot easier to compose a debugging suite using additional tools on top of a traditional host-based runtime for now.

Definitely excited to see how the technology evolves over the next few years. It hasn't moved as fast as I'd have expected over the last 2-3 years but I'd love to see that accelerate.

No, I'm not moving any goal posts. I was reacting to the statement "Tooling/Perf/etc is not needed when running". I'm not sure where you'd get the idea that I'm anti-unikernel, I just wanted to not disregard that challenge since it does matter.

> Tooling/Perf/etc is not needed when running (do you really want to debug in production) but tooling can be used in the process of development.

Whether or not you want to debug in production, reality often means that you will see things in a live environment that you will not see in other environments.

Unikernels are very interesting and have a number of compelling attributes, but let's not pretend that the current state of available tooling for troubleshooting, instrumentation, and general debugging isn't a challenge.

This is an asinine argument that seems to be driven by the belief that there is such a thing as efficient allocation of capital in the real world. Or perhaps just sour grapes that some of the unsophisticated investors they like to take advantage of are instead putting their money index funds.

Maybe both.

It actually is unreasonable for you to ask that. It's also a pretty bad take to bring up the 150,000 people die every day statistic as if the fact that a single person who many people had a connection to dying is not of significance.

If you truly don't care just move on. If you want to know more, it doesn't take a great deal of skill to use Twitter, GitHub, Google, and more to find out all that you want to know.

The Glowforge will only engrave from a bitmap. You need a vector to do cutting.

But MQDs.

This is extra delicious irony given the fact that the typical, and often only, requirement for these SDN layers is IP connectivity.

Yes. They've been hosting it outside of their production infrastructure for several years.

Hi, I'm Mark Imbriaco. That's my deck.

As I said in response to another comment in this thread, I don't often share my slides without the context of the recording of the talk that went with it. That recording isn't available yet, but these slides have more words than most of the ones I present usually do so I thought I'd share them.

In my talk, each of the main points was accompanied with an anecdote to give some background on the experiences that led me to believe them, as well as some expand on the content of the slide.

The talk was specifically built for an audience of attendees of the DevOps Enterprise Summit. It's a fantastic event with one of the most thoughtful and engaged group of attendees I've experienced, and I've been to a lot of conferences. These folks are, generally speaking, development or operations leaders at enterprise companies who are in the midst of a transition to a style of work that's a significant departure from traditional enterprise IT. Since much of what we call DevOps now is built on the way that many of us in the world of startups and Internet companies have been doing things for a long time, Gene Kim asked me to share some ideas that I think are universal.

It was one of the most fun talks I can remember since I was given the license to tell stories. ;)