This article is based on a fireside conversation hosted by Philippe Ensarguet, VP Cloud & Software Engineering, Fellow and Sylva Project Governing Board co-chair, with David Carrera, co-founder and CTO of Nearby Computing, on why orchestration across the edge-to-cloud continuum, federation, and European sovereignty are becoming essential parts of the Sylva stack.
Welcome Nearby Computing to the Sylva Community
Sylva has spent the last three years answering a hard question well: what does a trustworthy, telco-grade, cloud native platform actually look like? The framework, the reference implementation, the validation program, the hardening. We now have an infrastructure where an operator can put a 5G Core on and sleep at night.
There is a second question sitting right behind it, and it is the one that decides whether any of this pays off: what happens when you have three thousand of them?
Because a telco cloud is not just a cluster. It is a distribution. Central data centres, regional sites, far edge nodes in a room at the bottom of a tower or in the back office of a factory, each with its own footprint, its own connectivity, its own tenant, its own lifecycle. Building one good platform is an engineering problem. Operating thousands of them, across domains that were historically run by different teams with different tools, infrastructure, network, applications, is an operations problem.. Deployment is a project. Day-2 at scale is a business model.
That is the layer we are glad to see reinforced today, and it is why we welcome Nearby Computing to the Sylva community. Founded in Barcelona in 2018 as a spin-off of the Barcelona Supercomputing Center (BSC), Nearby Computing builds NearbyOne, an orchestration and automation platform that treats infrastructure, connectivity and applications as one continuum rather than three silos, from the cloud down to the constrained edge node. They have been doing this in production with operators and enterprises across Europe and beyond, and they have been doing it in the open.
To mark their membership, I sat down with David Carrera, co-founder and CTO. David is an unusual profile for this seat: a researcher who spent years at UPC and the Barcelona Supercomputing Center working on exactly the problem the industry now calls edge orchestration, resource management, workload placement, performance of distributed systems, before turning it into a product. So we went deep on the architecture: what actually breaks when you scale a control plane to thousands of sites, why federation had to be expressed in Kubernetes terms, and what changes when the workloads landing on those nodes stop being CNFs and start being AI.
My hope coming out of this conversation is simple: that Sylva keeps growing beyond a platform you deploy into a stack you operate, at the scale and distribution our networks actually have.
Here is what David had to say:
Who is Nearby Computing?
David, let’s start with where this comes from.
You spent a large part of your career researching resource management and workload placement for distributed systems before co-founding Nearby Computing. What did that work make obvious to you that the industry was still getting wrong about the edge?
Placement is only an interesting problem when you cannot move the workload.
Before Nearby Computing, my work focused on placing workloads across heterogeneous hardware in data centres — how to get the best out of machines that are not identical, alongside companies such as IBM, Intel and Cisco who were addressing that problem at scale. In a data centre, placement is an optimisation: everything is fungible, and if you get it wrong you migrate. The moment you go to the edge, that stops being true. The location is the requirement. A workload is at that site because of a latency budget, a piece of data that cannot leave a building, or a machine it has to communicate to. You are not optimising any more, you are satisfying constraints, and most of them are not negotiable.
The industry spent years getting that backwards. “Edge” was described as a small cloud, and the investment went into putting boxes in places. But the box was never the hard part. The hard part is operating tens of thousands of boxes you may never visit, most of which you did not choose, under conditions you do not control.
The other thing that becomes obvious, and which I would say more quietly, is that a research mindset optimises for one objective, while an operator has several that may contradict each other. Latency must be balanced against energy use , cost, and restrictions on where the data is allowed to reside. There is no single number to minimise. That realization is what pushed us towards a declarative model rather than a clever scheduler — describe the constraints, let the system converge, and be able to explain afterwards why something landed where it did.
Nearby Computing came out of the university as a spin-off in 2018, when “edge” was mostly a slide. What survived the journey from research to production, and what did you have to throw away once real operators and real hardware were involved?
What survived was the model: declarative intent, continuous reconciliation, heterogeneity as a first-class property rather than an inconvenience. That has not changed in eight years, and if anything the industry has moved towards it.
What we threw away was our estimate that advanced optimisers would be adopted quickly. We found that the industry was not ready for, or not yet need, advanced placement decisions using multi-dimensional parameters such as energy, location and latency.The path to adoption is slower than we had expectedI assumed we would spend our time writing schedulers; instead we have spent it writing adapters — the layer that wraps somebody else’s 5G core, hypervisor, switch or cluster into a common model so it can be reconciled like everything else.
NearbyOne orchestrates three things most vendors keep separate: infrastructure, connectivity and applications. Why does that separation break down specifically at the edge, and what did you have to build differently once you rejected it?
Because at the edge those three are not separate decisions, they are one decision viewed from three different desks.
Take a real-world scenario we see regularly.: a video analytics application operating in a factory, over a private 5G network. Whether it works depends on the node having been provisioned with the right kernel and drivers, on a data network and a slice existing on the core with the right QoS, and on the application being placed where both conditions are met.. When it does not work, the infrastructure team sees a healthy node, the network team sees a healthy core, and the application team sees a pod that will not schedule. Everyone is right, and nobody can identify the fault, because the failure domain does not respect the organisational chart. In a central data centre, you can get away with that separation, because the network is a service you order and somebody else’s responsibility. At the edge, there is no somebody else.
What we had to build differently is a single resource model in which all three domains are represented by the same kind of object — an intent, with a desired state and a status that is continuously reconciled. Critically, resources can depend on one another across domains. A fact produced by the network domain-an endpoint, a credential, a live KPI can be an input to an application deployment without a person having it to copy it into a ticket. That is the piece that actually breaks down the silos; a shared dashboard does not.
The architecture
I’m really curious about where NearbyOne stops being “another orchestrator”.
Let’s talk about the control plane. Reconciling one cluster is a solved problem; reconciling several thousand, many of them small, remote and intermittently connected, is not. What breaks first at that scale, and what did you have to design differently?
What breaks first is not compute, it is status. Every resource wants to report it’s status, that status changes constantly, and this is multiplied across every site. The watch fan-out and the cardinality of status fail long before anything interesting happens to the reconciliation logic itself.
Three design decisions came out of that. First, our orchestration engine is built on the Kubernetes API machinery — a declarative API server with spec and status, watches, and controllers running reconciliation loops — but deliberately without being a Kubernetes operator, and does not inherit Kubernetes’ workload assumptions. We took the best from the Kubernetes project without the constraints in some internal aspects of being an operator.
We wanted those semantics at a scope wider than a cluster: infrastructure, network elements, SIMs, APIs, models. We use eventual consistency rather than transactions, self-healing loops rather than orchestration scripts. Anything else at this scale becomes a distributed transaction problem, and distributed transactions across three thousand intermittently connected sites are not an engineering plan. They are a wish.
Second, templating and fan-out are first-class capabilities. An operator declares one intent with a selector, and the platform materialises zero, one or a thousand concrete deployments depending on what currently matches. Intent stays O(1) in the relation to the number of sites; only materialisation is O(n). If a site appears, it converges without anyone editing anything.
The third, and least glamorous decision, is that reconciliation has to be almost free when nothing has changed. At this scale most of the cost comes from no-op operations. This requires back-off, partial status, batching, and avoiding re-rendering the entire environment because one label changed.
Following on that: what happens at a far edge node when the link to the control plane goes down for a day? How much autonomy does a site have, and where do you draw the line between local decision and central intent?
The workloads keep running. That sounds obvious but it is worth stating. A standalone far-edge node runs its own control plane and data plane, so local loops continue performing local tasks — restarting failed workloads, monitoring local health, managing failover, and applying the intent they already have.
What stops is convergence towards new intent, as well as the freshness of the centre view of the site. When the link comes back, the site does not replay a queue of commands, it reconciles: The centre says what should be true, and the site works out the difference. That is the property that makes a day-long outage boring rather than dangerous, and it is the main reason we did not build a command-and-control design.
We draw the line by asking what information a decision needs. Anything that depends on a purely local state stays local. Anything that depends on a global state — which site receives a new version, where a service should be placed across a fleet or how an allocation between sites should be handles— stays central. A disconnected site making a global decision on stale information is exactly how you get a split- brain situation. I would rather have a site wait than guess.
The main gap is intent staging. Not everything a site might need is pre-positioned there today. If an upgrade requires an artefact it does not have, it must wait for the link. Determining the minimum durable local state that a far-edge site should be — enough to converge independently, but not so much that it diverges — is a genuinely open question.
One more detail matters in production: a site only ever needs a single outbound connection to the controller. Nothing needs to reach into it. No inbound firewall ports needs to be open.. That is good for security, and it makes reconnection uneventful. We leverage our L7 interconnect technology to make it possible.
Zero-touch provisioning is a claim everyone makes. Walk me through what it actually takes to bring up a node in a location with no engineer, no stable connectivity, and hardware you did not choose. Where does the real difficulty lie?
The difficulty is not the automation. Network-booting a machine and laying down an image is well-understood and has been for twenty years. The difficulty lies in four areas.
The first is identity before trust. A machine you have never seen powers on and asks to join your estate. How does it prove it is yours, and how does it obtain a credential, with no engineer present and nothing has been pre-shared that you would be comfortable having stolen? Everything downstream is straightforward once that is solved.
The second is hardware you did not choose: management controllers that behave differently, firmware that changes boot order after an update, and interface naming that is not stable. This is where the adapter layer comes in again. e model provisioning as reconciled resources rather than as a script is precisely so that the vendor-specific part is contained rather than spread throughout the process.
The third is that it must be idempotent and resumable, because the link will drop halfway through. If provisioning is a procedure, a dropped link means an unknown state and a van. If provisioning is a reconciliation loop over declared stages, a dropped link means that the process continues when the connection returns.
The fourth is remote diagnosis, and this is where the money actually is. The cost of the operating fleet lies largely in situations where somebody has to decide whether to send a person. The decision is only as good as the available visibility into which provisioning stage failed and why.
One important caveat is that zero-touch means no engineer configures the node. Somebody still has to racks it and plugs it in, and the network at that site has to be ready to respond. We should all be precise about that, because “zero touch” oversells it and the overselling is what makes operators skeptical of the rest.
Smart workload placement is your differentiator, and it is also your research heritage. What does the decision function consider today, latency, cost, data residency, energy, all of them(?), how much of the decision is based on declared by the operator how much is inferred by the platform?
Placement in NearbyOne is expressed through constraints and selectors on the intent itself. these include capability tags advertise by a site, labels, residency and jurisdiction requirements, and live KPIs that the platform is already collecting for example latency, resource usage, or thermals usage – which are particularly relevant in street cabinets, or, for instance) .The platform determines which targets currently satisfy the constraints and reconciles against that set.Because the set is continuously re-evaluated, if a site changes, the materialisation accordingly without anyone having to re-declare anything.
My instinct from the optimisation work says the objective function should be learned, and I still believe there is significant headroom there. My product experience says an operator will not deploy a placement decision they cannot justify. Therefore the rule we set for ourselves is that the platform must always be able to answer the question “why here”, in terms a person can explain to somebody else.
Declared constraints are explainable by construction. A learned policy is not, unless you do considerably more work than anyone is currently doing.Where I think inference genuinely earns its place is in proposing rather than deciding — Identifying when a a set of workloads would be better placed elsewhere, and allowing a person to accept the proposal. We have taken that approach elsewhere in the product and it has held up.
Residency is worth examining more closely on. Jurisdiction is not a property of a workload; it is a property of where that workload is placed. Jurisdiction decides placement, not by the type of workload that you placed.. Once you accept that, sovereignty stops being a label on a catalogue entry and becomes something for which the orchestrator is responsible..
Energy is the constraint I would most like to see standardised across the industry, and Sylva’s energy observability work is directly relevant to that.You cannot make placement decisions based on a signal that nobody agrees how to measure.
Being genuinely vendor-agnostic is easy to say and expensive to hold. What has the commitment cost you architecturally, and where do you draw the line?
The biggest architectural decision we made was to make the Kubernetes Resource Model our own model, not simply as a format we deploy onto, but the language in which platform itself thinks.
Concretely, our connectors are KRM. The platform natively reads, imports and renders Kubernetes objects across clusters and across APIs. That means any operator running in any cluster we have registered becomes an extension of the platform.
We have no proprietary plugin format. We never wrote an SDK that somebody has to license, learn, and then become locked into. If a vendor, a community or a customer ships a standard Kubernetes operator — Crossplane for a hyperscaler, a NETCONF operator for a router, an IPAM operator, a core vendor’s own operator — it plugs in as it is, and the intent that drives it is expressed in the same resource model as everything else. Anything that is already cloud-native needs no operator at all; we drive it from KRM to KRM.
That is what makes vendor neutrality structural. Anyone can extend the platform without asking us: no licensing, no private libraries, no proprietary technology. And part that may go underestimated is the enormous pool of existing knowledge. Writing operators is now a widely held skill. We are not asking the industry to learn our abstraction; we are using the one it already knows.
The engine underneath is deliberately not an operator. It is a reconciliation engine that runs its own etcd and apiserver on top of Kubernetes, for isolation and for scale. models its own resources in KRM. As a result, the only genuinely proprietary thing we have is the reconciliation engine and the modelling language around it. Everything beyond that line is powered by open community work.
Wedraw the line is at the point where somebody else’s API becomes the source of the truth. We model the intent and call that API; we do not reimplement a mobile core’s provisioning logic, and we do not build or observe the physical fabric. We consume a working cluster.
Why Sylva?
David, we are really happy to have you. But you already participate in NeoNephos, CAMARA, and several EU projects. Why add Sylva?
Sylva hardens the cloud native platform layer for telco and edge. Where does orchestration sit in relation to that today, and what gap did you see that made Sylva the right place to address it rather than the broader CNCF landscape?
We participate in several initiatives but they operate at different layers. CAMARA defines the API surface interface, and there we closely follow the evolution of APIs and operators needs. The GSMA Operator Platform Group is where the Operator Platform definition takes place, and operator requirements are written. NeoNephos is where we have contributed open source code, specifically the OPG EWBI operator and API in the Katalis project — we contributed the first reference implementation of the East-West platform federation. The EU research projects are where we get to test ideas publicaly five years early.
Sylva is different from all of those because it is the layer that an operator actually runs. It answers the question “what is a trustworthy cluster, and how is one created?” extremely well, and the validation programme reinforces that answer.
What Sylva does not yet address is what happens above the cluster boundary. Orchestration across a fleet — thousands of these, across sites and tenants and domains that were historically separate teams — sits above Sylva today. us that space is the most productive place to work.
As for why not just CNCF: CNCF has no shortage of multi-cluster projects, and some of them are excellent. What CNCF does not bring into the room is the operating constraint. The reason to do this in Sylva is that when I describe a Day-2 design here, somebody who runs a national network can tell me it is wrong before we build it, rather than eighteen months later.
The honest architectural question: Sylva has its own opinionated view of cluster lifecycle and GitOps-based management. Where is the seam between that and NearbyOne, what does Sylva provide that you build on, and what do you add above it?
Sylva owns the cluster. Cluster API manages the lifecycle across infrastructure providers, Flux reconciles the stack from Git, and Sylva provides hardened components and validation. We have no interest in duplicating any of it . ASylva cluster is a target for us, and one of the legitimate ways a cluster comes into existence within our infrastructure model.
What we add sits above that in three directions. The first is the fleet dimension: treating thousands of clusters as one estate, with inventory, configuration drift, vulnerability correlation against what is actually installed, and maintenance windows so change occurs when the operator allows them. The second is the cross-domain dimension: the network and the applications as first-class alongside the infrastructure, which is the part that cannot be done from inside a cluster because the dependencies leave it. The third is multi-tenancy and the service catalogue — somebody has to control who is allowed to deploy what and where.
The genuinely interesting seam, and I would rather raise it than paper over it, is that Sylva’s source of truth is Git per cluster, and ours is an API across the estate with templating that fans out. There are two ways those reconcile loops can meet: they can be nested, where we render intent into Git and Flux applies it, or they can sit side by side, where we apply directly to clusters Sylva built. Both approaches work. They have different failure modes, different audit stories, and different answers to the question “who wins when they disagree”.
Sylva was born from a sovereignty conviction as much as a technical one: European networks, European control, verifiable rather than declared. As a Barcelona company contributing to European open source initiatives, how much of your decision is architecture and how much is shared values?
The values part is not a positioning exercise for us. We are a Barcelona company, a spin-off of a public university, and a substantial part of our R&D has been co-funded by European programmes. The people who built this platform were trained within the European research system. So when the conversation turns to whether Europe should be able to operate its own networks, that is not an abstract policy position in our office.
But the argument I trust is the architectural one, because it survives a change of government. Sylva’s own blog puts it better than I would: sovereignty is more than trusted hosting. A sovereign claim you cannot verify is marketing. What makes it real is that the stack is inspectable and replaceable, and that the control plane genuinely belongs to the operator — including the ability to remove us from it.
There is a specific thing I would add from the orchestration layer, because it is where our part of this becomes concrete. In a distributed estate the sovereignty question is not “where is the data centre”. It is “where did this particular request go, what left the perimeter, and who can prove it”.
That is an orchestration question, and it can only answer if placement and connectivity are modeled rather than assumed. Take the case that is going to catch a lot of people out over the next two years: an agent running legitimately on a European site calls, at some point in its reasoning process, a model hosted outside EU jurisdiction. Nobody declared that crossing — it emerged at runtime from how the agent was configured., It has to be detected and controlled at the moment it happens rather than discovered in an audit months later, and that is precisely what our new module for distributed AI inference exists to do. It is why we ended up building a view of exactly that — what crosses a boundary and by which path.
Was there a specific conversation or moment where joining Sylva went from a good idea to an obvious one?
Yes, and it was not a strategy discussion. It was going into production.
We went live with, Orange, a Tier-1 operator that uses Sylva internally. That changed the relationship completely, because until then ours with Sylva had been essentially intellectual — we followed the work, we agreed with the direction, we contributed around the validation centre when we could. Then we began operating on top of it, in production, with real traffic and real consequences.
What clicked was how little there was to argue about. The platform underneath was not a negotiation. We did not spend the first months of the engagement discovering which assumptions this particular operator’s clusters made, because they were the assumptions the community had already written down, validated and hardened. That is the whole promise of a common stack, and it is one thing to agree with it on a slide and quite another to feel it give you back a quarter of engineering time.
Once you have had that benefit as a supplier, being an occasional participant starts to feel like taking the value without carrying any of the weight.
And I will also say the part that usually goes unsaid. Joining communities and projects has a real cost — the membership, but far more the people and the time, which for a company our size is the scarcer currency. We have been absorbing that cost progressively, as our revenue has grown. I would rather say it plainly, because I think this is more useful to other companies our size who are watching this and wondering when the right moment is. For us the answer was when the value stopped being theoretical.
What Nearby Computing brings to the community
Finally, could you share with us what you want to build here.
Telco infrastructure is increasingly carrying AI workloads to the edge, including inference close to the data, models that need updating across thousands of sites. What does orchestrating that look like in practice, and what is genuinely different from orchestrating a CNF?
Four things are genuinely different, and I think only the first is widely appreciated.
First, a network function is a piece of software. An AI service consists of software, a model, a corpus, and an accelerator — four artifacts with four lifecycles, wildly different sizes. Updating a model is not shaped like a Helm upgrade; it involves multi-gigabyte artifact distribution across thousands of sites with bad links, often with no change to the software at all.
Second, the dependency graph is external and dynamic: an agent talks to models, tools and MCP servers that it discovers at runtime. some maybe outside your perimeter and none of them may have been deployed by you. Third, the economics are inverted — GPU capacity is a hard placement constraint in a way that CPU never was, and the unit of consumption moved from instances to tokens, which drags metering into the orchestration layer. , and most relevant to this community, the direction of the data is reversed: a network function processes traffic passing through it, while an AI service reaches out and pulls data in. As a result, egress and jurisdiction become runtime properties rather than architectural statements.
That is what our AI module, Nearby AI Mesh, exists to absorb — an answer to distributed inference rather than a catalogue of models. Three elements support it.
First, AI services are treated as ordinary workloads in the same intent model: a model server, an agent, an MCP server or a knowledge base is deployed, versioned and reconciled exactly like anything else, on any registered site. We deliberately did not build a parallel stack for AI — the fleet machinery, the tenancy and the placement constraints already existed.
Second, a service fabric allows those services to find and reach each other by name across clusters, clouds and network boundaries, using one outbound connection per site and no public load balancers. That is what makes inference genuinely distributed rather than centralised with remote clients attached It is the same property the far-edge conversation depends.
Third, a two-tier gateway topology, places an aggregation tier in front of the model-serving sites. It directs every call — whether to a model we host or an external provider — through exactly one checkpoint doing identity, policy, routing and metering. That is what makes the jurisdiction question answerable at all: if every inference call crosses a checkpoint, you can see when the agent reaches outside the perimeter; if it does not, you are guessing.
The other direction is just as interesting, and it is closely related to your research: using AI inside the orchestrator. Where do you see agents or learned policies genuinely changing day-2 operations at this scale, and where do you think the industry is getting ahead of itself?
We already have this running, so I can answer based on something built across several years of innovation and experience in EU-funded projects. It is called AgentOne, and it already shipped as part of the platform.
The first important point is that it has no privileged back door. AgentOne reads the estate through the platform’s own northbound API. It uses the same tools, the same modeled resources, the same tenancy and permissions any other client gets. It cannot see more than the person asking it. That may sound like a restriction and it is actually the source of its value: it means the agent answers using from the same source of truth for which the operator is accountable to, rather than using a parallel index somebody has to keep accurate..
The second point is a hard rule that we do not bend: AgentOne may only report values that returned by a tool call. It never estimates. A language model asked about capacity will happily produce a plausible number, and a plausible number in an operations console is worse than no answer at all, because it looks like every other number on the screen. If the tool did not return the value, the agent says so.
The third point concerns write operations, and it directly answers to your question about learned policies. Anything that changes the state is collected field by field, played back as a complete summary, and executed only on an explicit confirmation — and answering a field question is never treated as consent to execute. The agent composes intent. A person authorises it through forms, via Slack/Teams, or potentially other options. The reconciliation engine remains the only component that enacts it.
That division represents the line I would not cross today. Reconciliation is safe because the loop is bounded and inspectable; the moment an unbounded reasoner is allowed to author the desired state directly, you lose both of those properties at once, and in a control plane an incorrect action is silent and expensive rather than loud and cheap.
Within that boundary the wins are real and, honestly, unglamorous. One is Triage — ranking thousands of alarms by blast radius is exactly what humans do badly under load. Another is explaining the state. , Answering the question “why has this not converged” may require combining ten sources with different vocabularies and is more a language problem than a control problem. the third is authoring the adapters and templates that, as I said earlier, account for most of the work.
Where the industry is getting ahead of itself is in demonstrating the happy path. Day-2 is the unhappy path. That is the whole job.
What do you actually want to contribute – code, integrations, validation work, a reference pattern, and what do you hope to get back from the Sylva community in return?
We have clearly identified several contributions…
The first is code that we have already opened. The OPG EWBI operator and API that we contributed through NeoNephos express GSMA federation as Kubernetes resources. In other words, they represent federation as reconciliation across an API boundary rather than as a bespoke integration. If Sylva addresses the multi-operator and multi-domain question, this material directly reusable material and we are happy for it to be used with or without us.
The second is validation work. We have been evolved with the WG02 validation centre for some time and can keep contributing, particularly with workloads that are edge-shaped rather than core-shaped, which stress different assumptions.
The third and the unglamorous one, which may matter most: integration scars. Bug reports and honest failure reports from deployments on heterogeneous hardware in real conditions. That is the feedback a hardened stack cannot generate about itself and that together with our customers we try to identify and report.
What I want in return is primarily one thing: a shared definition of the seam and of what a Sylva cluster exposes to whatever manages a fleet of such clusters. If that becomes a common definition, everyone benefits — including our competitors. I am entirely comfortable with that, because the market lacks not share, it is operators who believe that the edge is operable at all.
Beyond that: I want reviews from people who operate networks, and the discipline provided by the validation programme. It is very easy to believe your own claims. A community that tests those claims is worth paying for.
If this works, what does an operator get in two years that they cannot get today?
They will have a single description of what their network is supposed to be — including infrastructure, connectivity, workloads, and now AI. They will be able to deploy to a site that nobody from their team may ever visit, while being able to prove where every workload runs and what has crossed each border.
But the clause that actually matters is economic. Today the cost of operating an infrastructure is roughly linear in the number of sites. Every new site becomes a project: new hardware, a new country, a new tenant, a new integration, a new team, a timeline. That linearity is precisely why the edge keeps making sense on a slide and struggling in a business case. Nothing else we do matters if we do not break that line.
The concrete and testable version of my answer is this: in two years, adding a new kind of site should require a configuration change rather than entire project. A new vendor, new jurisdiction, new tenant — a reviewed change to a declared model, not a programme of work. Today it is a programme of work. It should be a pull request.
What Comes Next?
The work ahead is now clear: make the Sylva stack something that an operator can not only deploy but also operate, wherever it needs to run, from the central data centre to the node at the far edge.
Welcome aboard, Nearby Computing and David. Let’s build it.
