<div dir="ltr"><div>The short answer is that the "Cloud Native Computing" folks need to talk to the Intel Embedded Systems Application engineers to discover that micro services have been running on Intel hardware in (non-standard) containers for years. We call it real time computing, process control,... Current multi Terabit Ethernet interfaces require specialized hardware and interfaces that will connect fiber optics to clouds but cannot be run on clouds.</div><div><br></div>Some comments on Software Controlled Telecomm (/datacom) networking. When DTMF was invented the telco used in band signaling for call control. Kevin Mitnick et. al. designed red and black boxes to control the telco systems so the telcos moved call control out of band. They created SIgnal Control Points which managed the actual circuit switch hardware to route calls or eventually 64kbps digital paths and this protocol was SS#7. There were six to seven volumes of CLASS services that were enabled by SS#7 which ran on UNIX systems developed by Bell Labs. In the mid seventies, I worked on VM systems from DEC and Apollo of which Apollo had the better virtualization that worked across the network and was the first "cloud" system that I worked on.<div><br></div><div>In the mid nineties, I had worked on large Gigabit/Terabit routers but again the control plane was part of the data plane until ATM based networks  could use out of band control to setup a SVC between input port and output port and switch the IP packets instead of routing them achieving network end to end delays of less than milliseconds. VLAN and MPLS protocols were developed to switch packets in the backbone of the networks and not to route them.<br><br>In 2000 we put our first pre-standard cloud together with multi Gigabit routers and Sun workstations at 45 PoPs in the US, 3 in Asia and 6 in Europe and implemented a "cloud" O/S. Our fastest links were 10 Gbps. Now we can have 2-50 Tbps per fiber using Superchannel DWDM technology between PoP, data centers or cell towers. Network control functions can dynamically change by using Dynamic Reprogrammable EPROMs from companies like Xilinx and Intel to repurpose firmware control and device functions.<br><br>Embedded systems have implemented "micro services" for years as that is how you handle interrupt driven real time control. We call this a context switch which is still hardware CPU dependent. As far as I know, current standard containers do not handle real time CPU interrupts or do they allow very tight timing reponse loops within the standard containers? </div><div><br></div><div>Certain 5G proposals are discussing network slicing et al to virtualize control functions that can work better without virtualization. Current 5G protocol submissions that I have reviewed are way too complex to work out in the real world on real networks, maintained by union labor. (This is not a dig at union labor, as they are some of the best trained techs.) :)</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Aug 1, 2020 at 8:35 AM Mark Tinka <<a href="mailto:mark.tinka@seacom.com">mark.tinka@seacom.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
    <br>
    <br>
    <div>On 1/Aug/20 11:23, Etienne-Victor
      Depasquale wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">
        <div>Over the past few weeks, I've attended webinars and watched
          videos organized by Intel. </div>
        <div>These activities have centred on 5G and examined
          applications (like "visual cloud" and "gaming"), </div>
        <div>as well as segment-oriented aspects (like edge networks, 5G
          RAN and 5G Core).</div>
        <div><br>
        </div>
        <div>I am stunned (no hyperbole) by the emphasis on Kubernetes
          in particular,</div>
        <div>and cloud-native computing in general. </div>
        <div>Equally stunning (for me), public telecommunications
          networks have been portrayed </div>
        <div>as having a history that moved from integrated software and
          hardware, </div>
        <div>to virtualization and now to cloud-native computing. </div>
        <div>See, for example Alex Quach, <a href="https://www.telecomtv.com/content/intel-vsummit-5g-ran-5g-core/the-5g-core-is-vital-to-deliver-the-promise-of-5g-39164/" target="_blank">here</a> @10:30). I
          reason that Intel's implication is that virtualization is
          becoming obsolete.</div>
        <div><br>
        </div>
        <div>Would anyone care to let me know his thoughts on this
          prediction?</div>
      </div>
    </blockquote>
    <br>
    In the early dawn of SDN, where it was cool to have the RP's in
    Beirut and the line cards in Lagos, the industry quickly realized
    that was not entirely feasible.<br>
    <br>
    If you are looking at over-the-top services, so-called cloud-native
    computing makes sense in order to deliver that value accordingly,
    and with agility. But as it pertains to actual network transport,
    I'm not yet sure the industry is at the stage where we are confident
    enough to decompose packet forwarding through a cloud.<br>
    <br>
    Network operators are more likely to keep using kit that integrates
    forwarding hardware as well as a NOS, as no amount of cloud
    architecting is going to rival a 100Gbps purpose-built port, for
    example.<br>
    <br>
    Suffice it to say, there was a time when folk were considering
    running their critical infrastructure (such as your route
    reflectors) in AWS or similar. I'm not quite sure public clouds are
    at that level of confidence yet. So if some kind of cloud-native
    infrastructure is to be considered for critical infrastructure, I
    highly suspect it will be in-house.<br>
    <br>
    On the other hand, for any new budding entrepreneurs that want to
    get into the mobile game with as little cost as possible, there is a
    huge opportunity to do so by building all that infrastructure in an
    on-prem cloud-native architecture, and offer packet forwarding using
    general-purpose hardware provided they don't exceed their
    expectations. This way, they wouldn't have to deal with the high
    costs traditional vendors (Ericsson, Nokia, Huawei, Siemens, ZTE,
    e.t.c.) impose. Granted, it would be small scale, but maybe that is
    the business model. And in an industry where capex is fast
    out-pacing revenue, it would be the mobile network equivalent of
    low-cost carrier airlines.<br>
    <br>
    I very well could be talking out the side of my neck, but my
    prediction is mobile operators will be optimistic but cautious. I
    reckon a healthy mix between cloud-native and tried & tested
    practices.<br>
    <br>
    Mark.<br>
  </div>

</blockquote></div>