Using standard, open source and cloud-centric tools like OpenStack makes it easy to push the cloud to the far edge and customer edge of the network. This includes use cases around universal CPE (uCPE) and edge compute services at the customer site. It standardizes the deployment and changing of virtual network functions (VNFs). But OpenStack comes at a cost, and some deployments only require single VNFs or are largely static. In those scenarios a KVM-only cloudless model may be the right fit.
What do we mean by cloud in a box?
Before we talk about a cloudless model, let’s make clear what we mean by cloud in a box or embedded cloud. We embed a full OpenStack instance in our Ensemble Connector software. A typical Connector deployment has both the OpenStack controller as well as the various OpenStack agents (Neutron, Nova, Cinder, etc.) running on the same server. It contains all the components of a cloud and is a literal cloud in a box.
This approach provides tremendous power in terms of creating and managing dynamic service chains, and resolves some issues seen when trying to run only the OpenStack agents on a uCPE. It fits well with cloud-native architectures, and cloud engineers are comfortable with it.
Sounds great – and it is. So why change?
We put the cloud in a box, and now we can leave it out
The short answer is cost. OpenStack does exact an overhead in terms of memory and CPU power. And many low-end deployments of uCPE are largely static. They tend to host the same services for long periods, perhaps never changing over the life of the service. In these cases, the flexibility of OpenStack is wasted, and the cost is not justified.
Our Connector platform has always contained both OpenStack and KVM. Now we have provided an option to run in a KVM-only or cloudless model. We can still host any VNF or user application, but some of the dynamic features are not needed and have been removed. As a result, the memory and CPU footprint is reduced, which allows customers to deploy smaller uCPE hardware devices.
Some suppliers have taken a different approach to reduce the footprint. They remove the KVM layer and run their application directly on the server hardware. This is known as bare metal. But the problem with this approach is that it does not support the universal aspect of uCPE.
Using ADVA’s solution an operator can still store unconfigured servers in a depot and use zero-touch provisioning (ZTP) to install the correct software (including the customer’s choice of VNF) at time of deployment. This is a radical simplification for the case where servers are stored with unique pre-installed software. But it requires a secure and full-featured ZTP. We include ZTP in our Ensemble Virtualization Director, which is part of our Ensemble management and orchestration (MANO) package. And the ADVA Director, ADVA’s management solution, can manage both OpenStack and KVM-only models.
Comparison of cloudy and cloudless
The cloudy and cloudless options each have benefits and drawbacks. See the table below for a comparison.
|OpenStack / cloud mode||KVM-only / cloudless|
|Interoperable with any orchestration management platform that supports OpenStack||External management tools must integrate with network OS APIs and tools|
|Supports dynamic service creation and service modification via standard orchestration tools, including network, port, insert/delete VM in Day-N||Suitable for single function and static service chain use cases. Change to service chain requires rebuilding the service.|
|Embedded monitoring and troubleshooting tools for cloud resources and virtual machines||Advanced monitoring requires embedding of third-party tools and agents|
|Resource footprint is higher (CPU and RAM)
Separate cores required for datapath and OpenStack
|Smaller footprint requirements (CPU and RAM)|
|VM startup time is on the order of 10-15 minutes||VM startup time is on the order of 2-3 minutes|
Cloudy or cloudless? Use both as needed
The right approach should be determined by your use case, not the limitations of your solution. With ADVA’s Ensemble solution you can have a consistent and open architecture that enables choice and innovation. And one that provides the flexibility needed to optimize each deployment based on cost and required capabilities. It’s the best of both worlds!