Hacker News Reader

Comment by marktangotango | Hacker News Reader

Sounds like these guys are doubling down on the IAAS model, 'premium bare metal'? Certainly there are a lot of people who'd like to run on bare metal, with a more configurable network, but how realistic is it at this time?

>>You see, physical switch operating systems leave a lot to be desired in terms of supporting modern automation and API interaction (Juniper’s forthcoming 14.2 JUNOS updates offer some refreshing REST API’s!).

This. Network hardware vendors have no incentive to make their devices more easily automated, and in fact face disincentive not to.

Doe anyone remember the excitement and promise around Google App engine when it was first announced, and before they changed the pricing model to per instance? The ability to put your app on the cloud, and scale up to the free tier, then out from the free tier on a paid plan if that's what you needed.

That model entirely disappeared. I miss it. Is anyone doing that now?

View on HN

>> >> You see, physical switch operating systems leave a lot to be desired in terms of supporting modern automation and API interaction (Juniper’s forthcoming 14.2 JUNOS updates offer some refreshing REST API’s!).

>> This. Network hardware vendors have no incentive to make their devices more easily automated, and in fact face disincentive not to.

There is actually a relatively established roadmap for the solution to this in "bare metal" / "white box" switches that essentially just talk OpenFlow to a controller. Google moved their entire international internal backbone (more traffic than public facing) to this model[1].

The issue at the moment is that there isn't lots of OS options and subsequently very little hardware support. Google developed their own hardware (despite preferring to have bought it[2]) and my understanding is they wrote their own software too.

[1] http://www.opennetsummit.org/archives/apr12/hoelzle-tue-open... [2] http://youtu.be/VLHJUfgxEO4?t=39m20s

+1, talking about rest endpoints hosted by junos is missing the forest for the trees. Protocols like Openflow, and whatever the contrail version was called, seems o be where network automation is headed. Centralized state & modelling and pushing specific paths/updates out to the edge.

With regards to "bare metal" virtualization I'd expect to see a lot more in the next 12-18 months. On the network you need dynamic path configuration and traffic encapsulation/isolation. That should be "openflow" and vxlan/nvgre. On the host hardware youll want io virtualization (sr/mr iov) and possibly hardware encap as well. Substantial progress is being made on both fronts.

Edit: although its great to have two encap options I think theyre incomplete at best. All of the hard work has been punted to the centralized controllers and the rfcs have nothing useful to contribute there. Some of the rfc behavior is also insane/laughable; multicast for broadcast and mac/tunnel endpoint discovery ORLY? Ill be very surprised if there are any large vxlan/nvgre deployments which arent bespoke.

The opportunity extends beyond support for x86 devices in that more traditional hardware switches etc. should also work with openflow.

I've found there's lots of OSS around the controller and virtual switches for testing/lab but the only serious openflow agent designed for hardware switches I've found is Big Switch's Indigo[1] it has very limited hardware support.

I see experimental support in OpenWRT - this is very interesting as it opens up a shed load of hardware options.

[1] http://www.projectfloodlight.org/indigo/

As someone who works with OpenFlow (a lot) I have my doubts if the tech will pan out. Look at what Facebook did to their network using traditional technologies. Look at Cisco's ACI, and Jupier's Contrail. About the only thing OpenFlow has going for it is that it runs on multiple vendor platforms (assuming you ignore all the switch-to-controller interop problems).

That model entirely disappeared. I miss it. Is anyone doing that now?

Just about every PAAS (including AppEngine) does this[1][2][3][4]. What am I missing?

[1] https://www.heroku.com/pricing

[2] https://cloud.google.com/appengine/docs/quotas

[3] https://www.openshift.com/products/pricing

[4] https://appharbor.com/pricing

Don't forget BlueMix!

The difference in my estimation is: pricing based on per instance (what ever an instance is) and pricing per resource used, past the free tier. And auto scaling. I could have been clearer, apologies.

Edit; further, in the original GAE pricing model, the customer paid for specific services, usually by volume. Maybe accounting was prohibitive?

You can do auto-scaling on OpenShift, as part of the platform, and on Heroku, with HireFire:

http://hirefire.io

GAE still uses the same model - the prices just are more than they were previously. See my previous link and [1] for details. It even explicitly gives you an instance/hour cost (above the free quota).

Plenty of PAASs do autoscaling.

[1] https://cloud.google.com/appengine/pricing

It might not be a bad area at all to be solving problems in.

I was a little incredulous when I read that they started writing ip manager code, but then I remembered this article about amazon AWS scale:

see section titled "The Network Is A Bigger Pain Point Than Servers" in this article about AWS scale: http://www.enterprisetech.com/2014/11/14/rare-peek-massive-s...

> how realistic is it at this time?

Quite realistic, as there are many bare-metal offerings at this time, as a quick Google search will attest to. What exactly the packet.net people mean when they say 'premium', however, is unclear.

> That model entirely disappeared. I miss it. Is anyone doing that now?

Heroku still offers a free-tier to start.

Reply on news.ycombinator.com