The Technical Challenges Behind Servala: Standardizing Application Delivery

In this follow-up to our Servala introduction, we explore the technical challenges of bringing managed services to cloud providers everywhere. Discover how the repetitive and inconsistent nature of application packaging, deployment, and operations inspired our vision for standardization.

We explore the problems platform engineers face today, including inconsistent container behaviors, unpredictable Helm charts, and the chaos of day-2 operations across security, configuration, and dependencies.

Learn how Servala’s proposed open standards will transform the landscape for:

• Software vendors – Accelerating time-to-market and expanding reach without operational overhead
• Cloud providers – Enriching service catalogs with enterprise-grade managed services
• End users – Enjoying self-service freedom with consistent, secure, and compliant applications

Join us on this journey to simplify application delivery and make managed services accessible to everyone.

In our introduction to Servala, we mentioned the technical challenges of enabling software vendors to onboard themselves onto our platform. As we continue building Servala in 2025, we’re tackling the most fundamental challenge: creating a standardized approach to application delivery. Let’s explore these challenges and our proposed solution in more detail.

The Repetitive Nature of Application Management

Over the past years at VSHN, we have taken care of numerous applications as part of our managed services offering that now forms the foundation of Servala. For every single application, we had to do the same tedious tasks:

Packaging: Prepare the application in a deployable format, typically by creating an OCI-compliant container image compatible with Docker, Podman, Kubernetes, and OpenShift. Automate the packaging process to trigger whenever a new version is available.

Deployment: Deploy the packaged application to the target system, typically through automated processes rather than manual steps. Most deployments span multiple environments, such as test, staging, pre-prod, and production, or support self-service provisioning for SaaS. This process often involves creating Helm Charts and setting up automation pipelines or APIs provided by tools like Kubernetes operators (e.g., Crossplane).

Day-2 Operations: After deployment, ongoing responsibilities include collecting metrics, setting up alerts, updating the application, scaling in response to performance issues, backing up and restoring data, analyzing logs, offering 24/7 support, and ensuring compliance with various standards, along with many other operational tasks.

The Current Challenge for Servala

Doing these same steps over and over again becomes tedious. Solving the same problems whenever we must take care of a new application doesn’t feel valuable. In reality, we have to deal with a multitude of different ways in which these things are done. It puts a lot of burden on engineers, having to cope with all the many ways all these tasks can be done. Usually, parts of the functions mentioned above are already done. As an example, container images are already available, but every image behaves differently from the other. And that means we must always figure out how to integrate into the next step. The same applies to the various Helm Charts out there. Standardization will relieve us from this burden, making the process more efficient and less repetitive.

The core issue stems from the flexibility of the tools involved. Container images vary widely in how they’re built and behave, while Helm Charts accept parameters in inconsistent formats. For example, the container image reference might appear as img, image, or image-registry, depending on the chart author.

Security scanning and compliance reporting vary widely between applications. Some include Software Bills of Materials (SBOMs), while others require manual inventory. Configuration handling is equally inconsistent—some applications use environment variables, others expect config files in specific locations, and others require custom configuration APIs.

Day-2 operations vary significantly across applications. Some expose metrics in a Prometheus-compatible format, while others don’t. Identical metrics might use different names, and logging formats range from structured JSON to custom plain text. Dependency management is often neglected, with minimal information about required services or components. As a result, maintaining these applications turns into a tedious game of whack-a-mole.

We must solve these fundamental inconsistencies so that Servala can scale and enable software vendors to onboard their applications easily.

Our Proposed Solution: Standardization

How could we solve these obstacles? We propose to define a set of documents that specify patterns for all the various parts needed to deliver applications through Servala. We could also call these documents specifications, golden paths, patterns, standards, conventions, or defaults. Ultimately, the goal is to document a commonly agreed-upon way to solve the mentioned tasks so that we don’t have to iterate over them repeatedly.

However, doing that just for us feels wrong. As a company, we embrace Open-Source and Open Standards to work together in a defined way. Therefore, we propose to form a group of people from various companies, document the patterns together, and agree on them.

The Vision: A Transformed Application Delivery Landscape

What will application delivery look like once the Servala specifications are widely adopted? The benefits will be transformative for all parties involved:

For Software Vendors:

• Accelerated Time to Market: Instead of spending months building deployment, monitoring, and maintenance systems, vendors can focus on their core product and leverage Servala’s standardized delivery mechanisms to reach cloud providers globally.
• Reduced Operational Overhead: By conforming to the Servala specification, vendors automatically inherit proven operational practices like monitoring, metrics, logs, backups, etc, without maintaining their own operations team.
• Expanded Market Reach: The ability to deploy on any Servala-compatible cloud provider opens new markets without additional engineering effort.
• Enhanced Security Posture: Standardized security scanning, compliance reporting, and configuration management significantly reduce risk, enabling vendors to confidently deploy their applications on Servala-compatible cloud providers, even without dedicated in-house security expertise.

For Cloud Providers:

• Enriched Service Catalogs: Providers can instantly offer dozens of managed services that follow consistent operational patterns, dramatically increasing their value proposition.
• Operational Consistency: All services follow the same patterns for monitoring, alerting, and maintenance, reducing the complexity of running multiple third-party applications.
• Competitive Differentiation: Smaller cloud providers can now compete with hyperscalers by offering comparable catalogs of managed services.

For End Users:

• With Servala’s standardized delivery Mechanisms, end users can deploy complex managed services confidently, knowing they follow consistent operational patterns. This empowerment gives them a sense of control and confidence in their operations.
• The operational interfaces remain consistent regardless of application deployment, providing end users a predictable and secure experience. This predictability reassures them of the system’s stability and reliability.
• Enterprise Readiness: All services automatically include security, backup/restore, monitoring, and other enterprise features without custom integration work.
• Simplified Compliance: Standardized security scanning and compliance reporting make regulatory audits more straightforward and less resource-intensive.
• Dependency Clarity: Clear visibility into service dependencies and compatibility requirements reduces deployment failures and configuration errors.

The Servala Specification Areas

We envision documenting patterns for:

Container image behavior, such as where to store data, how to expose ports, how the entry point behaves, and with which permissions the application runs.

Helm Chart “API”: How do the standard values behave? What does the configuration structure look like?

Unified Operational Framework:

• Backup and Restore: Standardized interfaces for consistent application and data backup procedures with well-defined restoration paths and verification methods
• Metrics: Well-defined endpoints to get application metrics for alerting, monitoring, and performance insights
• Alerting and Monitoring: Common alert definitions, severity classifications, and response expectations across applications
• Logging Standards: Uniform logging formats, retention policies, and search capabilities to simplify troubleshooting
• SLA Definitions: Standardized metrics for measuring and reporting on availability, performance, and reliability
• Maintenance Windows: Clear protocols for coordinating and communicating maintenance events with minimal disruption
• Billing: A Uniform way of billing service usage
• Security Scanning and Compliance: Standardized approaches for vulnerability management, security policy enforcement, and compliance reporting across all applications
• Configuration Management: Unified patterns for handling application configuration, secrets management, and runtime reconfiguration
• Dependency Management: Clear declaration and handling of service dependencies, including versioning requirements and compatibility matrices

Self-Service API Architecture: Propose standardized structures for Kubernetes resources, creating predictable interfaces for application management across environments.

Previous work we want to build on

There have been successful efforts to standardize that we want to build on:

Open Container Image (OCI) Image Format

After a decade of fragmentation in how containers were built and stored, the OCI initiative introduced a unified image format adopted by tools like Docker and Podman. It standardized filesystem locations (e.g., /var/lib/docker/), defined predictable image layering, and enabled interoperability across registries such as Docker Hub, GitHub Container Registry (GHCR), and Quay.

Kubernetes as a container orchestrator

Kubernetes has established itself as the de facto standard for managing container fleets. It provides a unified API for managing compute, networking, and storage regardless of the infrastructure provider.

Kubernetes Pod and Container Lifecycle Conventions

The Kubernetes community has standardized application behavior during lifecycle events, such as startup, shutdown, and health checks, ensuring consistent health monitoring. Applications now respond predictably to restarts and draining, greatly easing the work of platform engineers. Implementing lifecycle hooks has become a de facto standard.

Prometheus Metrics Format

Many applications already implement exposing metrics in the Prometheus OpenMetrics format, and where, by convention, the “/metrics” endpoint exposes a human-readable or OpenMetrics-compliant format, there are some Standard naming conventions (http_requests_total, etc.). While it’s not perfect yet, as some metric names still vary, this is one of the most widely accepted informal standards adopted by applications, exporters, sidecars, service monitors, etc.

Software Bill of Materials (SBOM) standards

With open SBOM standards now established and widely supported by vendors like GitHub, GitLab, and Docker, generating and consuming SBOMs has become a best practice. It’s so fundamental that the EU Cyber Resilience Act (CRA) now mandates SBOMs for all proprietary and open-source software.

12-Factor App

While some inconsistencies remain, we still want to honorably mention the https://12factor.net/ manifesto, which laid the Foundation for cloud-native apps in 2011 and still influences architecture and platform design today. Solving Inconsistent application structure and runtime expectations, these are now widely adopted best practices: config via env vars, statelessness, logging to stdout, etc., often enforced indirectly by platforms.

Helm Chart Best Practices / Guidelines

The Helm community recognizes the inconsistency in chart structures and naming and has responded with best practices, guidelines, and tools like helm lint and helm create. While adoption remains partial, projects like Bitnami, KubeApps, and Backstage increasingly rely on these conventions, laying a strong foundation for what Servala aims to standardize.

OpenAPI / Swagger

The OpenAPI Initiative has significantly impacted API standardization. It enables machine-readable API definitions, automatic generation of SDKs, tests, mocks, and human-friendly documentation. Widely adopted across platforms – from Kubernetes CRDs to GitHub APIs – OpenAPI has brought consistency and interoperability to API design and consumption.

OpenServiceBroker API

We’ve implemented the OpenServiceBroker API and are using it actively with a few clients, but it’s missing the declarative and cloud-native approach to service listing and provisioning.

Crossplane

We’re fans of Crossplane’s declarative approach to service definitions and instantiations. Crossplanes Composite Resource Definitions (XRDs) provide opinionated Kubernetes Custom Resource Definitions (CRDs), which all have the same structure as what the engineer defined in the XRD. Servala is not replacing Crossplane but uses Crossplane under the hood.

Open Application Model (OAM)

The Open Application Model (OAM) supports Servala’s mission by offering a platform-agnostic, standardized way to define cloud-native applications. It cleanly separates core logic (components), operational features (traits), and dependencies (scopes), providing a consistent interface for developers and operators. With reusable metrics, backups, and autoscaling definitions, OAM helps eliminate the fragmentation found in Helm charts and container images, making it an interesting foundation for Servala’s specification and enabling consistent managed services across environments.

The Platform Specification

The Platform Spec initiative contributes to Servala’s vision by offering a standardized contract between developers and platform engineers, defining a standard interface for deploying and managing applications across any internal developer platform (IDP). It focuses on creating a consistent, YAML-based specification for app workloads, including container images, environment variables, secrets, service bindings, and deployment rules. It solves many issues Servala identifies with inconsistent Helm charts and runtime behaviors. By adopting or aligning with Platform Spec, Servala can simplify onboarding, reduce integration overhead, and ensure applications are deployed in a predictable, platform-agnostic way, regardless of the underlying orchestrator or infrastructure.

Cloud Native Application Bundle (CNAB)

The Cloud Native Application Bundle (CNAB) specification supports Servala’s goals by providing a portable, standardized way to package and distribute multi-component applications, including Kubernetes manifests or Helm charts and Terraform plans, scripts, and other deployment artifacts. CNAB defines a consistent format for bundling an application’s code, configuration, and lifecycle operations (install, upgrade, uninstall), making it ideal for complex managed services that span multiple tools or environments. By leveraging CNAB, Servala could offer a unified packaging format that encapsulates everything needed for reliable, repeatable deployment, helping reduce fragmentation, simplify onboarding, and enable consistent Day-2 operations across cloud providers.

The Path Forward

Servala aims to accelerate application onboarding by a factor of 10, reducing weeks of custom integration to just days or hours, while dramatically improving reliability through consistent, proven patterns for deployment and operations. We’ve already begun implementing these standards in our development roadmap, but broad industry collaboration is essential for success. We invite software vendors, cloud providers, and platform engineers to join us in shaping these standards openly and collaboratively. With a solid foundation, Servala can redefine how managed services are delivered, empowering cloud providers to expand their service catalogs and enabling vendors to become SaaS providers without heavy operational overhead.

Subscribe to Updates

Always be the first to find out all the latest news about Servala. Simply add your email below:

What’s Next?

In 2025, we will focus on enabling software vendors to onboard themselves onto the Servala service delivery platform. Find more information about Why we launched Servala in our Servala launch announcement.

Contact us

Interested in learning more? Book a meeting or write us to explore how Servala can help you! Experience the future of cloud native services on servala.com. 🚀