4 ms·

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 m

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?

fragmede 12y ago
> 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.
nl 12y ago
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? Just about every PAAS (including AppEngine) does this[1][2][3][4]. What am I missing? [1] https://www.heroku.com/pricing https://www.heroku.com/pricing [2] https://cloud.google.com/appengine/docs/quotas https://cloud.google.com/appengine/docs/quotas [3] https://www.openshift.com/products/pricing https://www.openshift.com/products/pricing [4] https://appharbor.com/pricing https://appharbor.com/pricing
- jambox888 12y ago
  Don't forget BlueMix!
- marktangotango 12y ago
  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?
  - mietek 12y ago
    You can do auto-scaling on OpenShift, as part of the platform, and on Heroku, with HireFire: http://hirefire.io http://hirefire.io
  - nl 12y ago
    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 https://cloud.google.com/appengine/pricing
thomseddon 12y ago
>> >> 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-openflow.pdf http://www.opennetsummit.org/archives/apr12/hoelzle-tue-open... [2] http://youtu.be/VLHJUfgxEO4?t=39m20s http://youtu.be/VLHJUfgxEO4?t=39m20s
- donavanm 12y ago
  +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.
  - thomseddon 12y ago
    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/ http://www.projectfloodlight.org/indigo/
andyidsinga 12y ago
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-scale-aws/ http://www.enterprisetech.com/2014/11/14/rare-peek-massive-s...

fragmede 12y ago

> 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.

nl 12y ago

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? Just about every PAAS (including AppEngine) does this[1][2][3][4]. What am I missing? [1] https://www.heroku.com/pricing https://www.heroku.com/pricing [2] https://cloud.google.com/appengine/docs/quotas https://cloud.google.com/appengine/docs/quotas [3] https://www.openshift.com/products/pricing https://www.openshift.com/products/pricing [4] https://appharbor.com/pricing https://appharbor.com/pricing

jambox888 12y ago
Don't forget BlueMix!
marktangotango 12y ago
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?
- mietek 12y ago
  You can do auto-scaling on OpenShift, as part of the platform, and on Heroku, with HireFire: http://hirefire.io http://hirefire.io
- nl 12y ago
  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 https://cloud.google.com/appengine/pricing

thomseddon 12y ago

>> >> 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-openflow.pdf http://www.opennetsummit.org/archives/apr12/hoelzle-tue-open... [2] http://youtu.be/VLHJUfgxEO4?t=39m20s http://youtu.be/VLHJUfgxEO4?t=39m20s

donavanm 12y ago
+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.
- thomseddon 12y ago
  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/ http://www.projectfloodlight.org/indigo/

andyidsinga 12y ago

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-scale-aws/ http://www.enterprisetech.com/2014/11/14/rare-peek-massive-s...