Page 33 - EE|Times Europe Magazine - December 2020

EE|Times EUROPE 33

Cloud-Native Processors for a Cloud-Native World

another end user, often in a negative manner.
If a CPU core has two SMT threads, for
example, applications running on those
threads must share execution resources
(Figure 1). If the workloads are balanced, this
may result in certain amount of predictable
degradation. However, if one of the workloads
is resource-intensive — a noisy neighbor —
then workloads on the other SMT thread will
starve for execution resources and slow down
(Figure 2). This can be a major problem in
multi-tenant cloud environments.
Noisy neighbors present another major
issue in the cloud environment: shared-
resource attacks. SMT threads provide very
poor isolation between customers, with phys-
Figure 1: In enterprise-class processors with SMT, applications share CPU execution ically shared execution resources and caches.
resources. As a result, one workload can dominate consumption while the other becomes The security level of a core is only as good as
resource-starved. the least secure thread. By monitoring access
to a shared cache by one workload, hackers
the rated operating frequencies if the CPU is operating below the rated can potentially identify the location of sensitive data in use by the
thermal design power (TDP). This feature relies on cores’ being under- other thread. These side-channel attacks put all tenants in a multi-
subscribed, and the fewer the cores that are being used, the higher the tenant environment at risk, especially those sharing cores with SMT.
Turbo Boost frequencies. Like SMT, this is another technology that can
make life complicated for CSPs. MITIGATING NOISY NEIGHBORS
CSPs that use SMT on enterprise-class processors have multiple
Cloud-native processors options for addressing the noisy neighbor issue, but none of them are
Software development in the cloud is evolving rapidly to better utilize ideal. Sophisticated software exists for rebalancing workloads during
the on-demand and elastic resources on which developers rely today. runtime but is computationally intensive and complex to manage. More
These cloud-native applications are increasingly built from collections to the point, it’s not fully effective. Alternatively, the CSP can offer
of distributed components, such as micro-services that perform specific tiered services. Customers at the lower levels will pay a lower price, but
tasks and collaborate to achieve higher-level business objectives. These the tradeoff is placement in a shared core with its reduced quality of
lightweight applications are faster to develop, test, and integrate, service (QoS).
leading to practices like continuous integration/continuous delivery Most frequently, the CSP resorts to simply renting both SMT threads
(CI/CD), in which new versions of applications can be released multiple in a core to the same enterprise customer. To retain customers, cloud
times a day. They are typically containerized — packaged with data center operators must meet contracted SLAs. Restricting a core
specialized OS or data libraries — making them both portable and agile. with two threads to a single customer might ensure QoS is met and
Taking a clean-slate approach to CPU design, companies are starting the attack surface is reduced, but it runs counter to the cloud business
to develop a class of processors that cater to these newer software
paradigms and that better support multi-tenant environments. These
cloud-native processors sport features such as larger core counts for
service scale-out and higher energy efficiencies — design principles
that provide flexibility to developers while enabling CSPs to host more
end users per server with dedicated physical cores.
Such processors can run enterprise-class workloads, but they are
particularly well-suited to running cloud-native applications.
Enterprise-class processors, on the other hand, can create problems in
cloud deployments that can negatively affect SLAs. Some of these prob-
lems are discussed below.
The fundamental assumption of the cloud computing model is that
the computing resources will be able to support the needs of all end
users when required. Unfortunately, that assumption does not always
hold true. Companies that decide to “lift and shift” their enterprise
applications to the cloud recognize that they are moving to a shared
infrastructure, but they may not fully grasp the tradeoffs involved in
the multi-tenant environment. The same premise that makes the cloud
attractive to developers (seemingly infinite elastic resources) and to
CSPs (high utilization through multi-tenancy) can also make it difficult
to share those resources in a fair manner. Figure 2: The timeline for execution instructions (l.–r.) for two
single-threaded cores versus a core with SMT show the execution
NOISY NEIGHBORS delays introduced by the second application. The single-threaded
When applications with different resource requirements share cores have dedicated resources to satisfy both applications. In the
resources in multi-tenant cloud environments, there is always a pos- core with SMT, both applications share common resources, thus
sibility that one end user’s application can unknowingly affect that of lowering overall performance.

www.eetimes.eu | DECEMBER 2020