Bringing up an Edge Application Platform: “It takes a village”

Have you ever heard the expression “It takes a village”?

”It takes a village” is an often cited idiom, commonly in the context of bringing up a child, and that a “child’s upbringing is a communal effort involving many different people and groups, from parents to teachers to neighbors and grandparents”. When planning to build and deploy a platform to manage container applications at the edge, it might feel like you need the support of a whole village of services. But what have we learned about the “up-bringing” of edge container platforms? Let’s sort it out.

Once you start laying out the requirements you will see various aspects that need to be covered such as autonomous edge clusters, multi-cluster management, edge application networking, observability, edge local image registry, multi-tenancy, and more. Phew! A village is needed for sure.

So next, you might turn around to the Cloud Native Computing Foundation, cncf.io village for tools that can be used to solve all these problems. You start drafting a list of components such as Kubernetes distro, Kubernetes installers, application definition tools, service meshes, logging, service discovery, and the list goes on. End of the day you will have a list of projects that need to be installed and configured.

While this might work fine for your central data centers (since that’s what they were invented for), it will become a challenge for your distributed edge sites. Here’s why:

• Lifecycle management: If you have a few data centers, your operations team can manage the lifecycle of the combination of all these projects. However, if we talk about tens, hundreds, or even thousands of edge sites, the management risks cause too high operational overhead.
• Resource footprint: Edge sites have limited resource footprint and the combination of all needed tools and services might jointly have a too large footprint for your target hardware platform resources.
• Hard to achieve edge intrinsic requirements like security and multi-tenancy across components: including how to secure tenancy isolation for logs, site networking, and application data. As well as how to manage maximum security across the components.
• Lack of application focus: There is a risk that the sheer complexity of the platform consumes too much of your platform teams’ recourses, making them unable to fulfill the needs of the application teams. What you should strive for is application agility, providing application teams with a self-service portal and automated pipeline to deploy edge applications. The platform complexity should not be a blocker.

@kelseyhightower expresses this in his own way:

The fact is, you should be cautious about your edge platform growing into a village.

While we all are grateful for the important work of CNCF and their efforts to move cloud-native technology forward, we need to remind ourselves that the context of that work is a central team managing a few data centers. You can also get someone to provide the life-cycle management of the village, which is a valid option for your central data centers.

So, going back to your edge platform needs:

You need an edge application platform that does not require a village. Make sure you focus on your goals: agile application deployment and minimal operational complexity. Instead of picking (and managing) a large set of components, you should look for a purpose-built edge native platform that provides these core features:

• Multi-tenancy
• Autonomous edge clusters with edge application networking
• Application deployment
• Multi-cluster management
• Telemetry bus
• Distributed secrets manager
• Platform and application monitoring

Keep reading: How we ended up not using Kubernetes in our edge platform

Avassa:

ℹ️ Rolling out your edge platform has never been easier. All you gotta do is pick one purpose-built edge platform and you’re good to go.

Thanks to Kelsey for the inspiration!