Originally published by Heroku, the methodology was designed specifically to support Software-as-a-Service offerings. In this article we walk through each of the 12 factors and show how Eclipse MicroProfile and Kubernetes provide concrete tools to satisfy them.

Why the 12-Factor App?

Modern cloud-native applications must handle frequent deployments, elastic scaling, and diverse runtime environments. The 12-Factor App methodology answers these challenges with a set of best practices that help teams:

• Use declarative formats for setup automation, reducing onboarding time for new developers.
• Maintain a clean contract with the OS, maximising portability across execution environments.
• Design for deployment on modern cloud platforms, removing the need for bespoke server administration.
• Keep development and production as similar as possible, enabling continuous deployment.
• Scale horizontally without major changes to tooling, architecture, or development practices.

Eclipse MicroProfile: A Brief Overview

Eclipse MicroProfile is an open-source project and community established by the Eclipse Foundation in 2016. Its members include IBM, Red Hat, Tomitribe, Payara, the London Java Community (LJC), and many others. MicroProfile targets lightweight, iterative development with a rapid release cadence—typically three releases per year.

The project has numerous runtime implementations, including Open Liberty, Quarkus, Payara, TomEE, WildFly, KumuluzEE, Piranha, and others. Each implementation provides the MicroProfile APIs on top of a Jakarta EE or compatible base.

The 12 Factors, One by One

1. Codebase

One codebase tracked in version control, many deploys.

Use a dedicated Git repository per microservice so that each service can evolve and be released independently. Version control enforces discipline: maintaining a single repository per application forces teams to analyse the boundaries of their system and identify parts of a potential monolith that should be extracted into separate microservices.

2. Dependencies

Explicitly declare and isolate dependencies.

Avoid bundling third-party libraries inside your packaged artifact. Instead, declare them explicitly in a build descriptor—pom.xml for Maven or settings.gradle / build.gradle for Gradle. This approach makes version upgrades predictable and keeps the artifact lean.

3. Config

Store configuration in the environment.

The golden rule is: write once, configure everywhere. Configuration that changes between deployments (database URLs, credentials, feature flags) must be externalised from application code so that you never need to repackage a service just to change a property.

MicroProfile Config lets you read properties from system properties, environment variables, or custom config sources such as a Kubernetes ConfigMap—without changing application code.

Two access patterns are supported:

// Programmatic lookup
Config config = ConfigProvider.getConfig();
String value = config.getValue("my.string.property", String.class);

// CDI injection
@Inject
@ConfigProperty(name = "my.string.property")
String myPropV;

Because the property can be backed by a Kubernetes ConfigMap or a plain environment variable, updating it does not require rebuilding or redeploying the container image.

4. Backing Services

Treat backing services as attached resources.

Databases, message brokers, and external APIs should be swappable by changing configuration alone. MicroProfile Rest Client lets you model a backing service as a typed Java interface annotated with @RegisterRestClient, and then bind its URL via a config property.

// 1. Declare the interface
@Dependent
@RegisterRestClient
@RegisterProvider(UnknownUrlExceptionMapper.class)
@Path("/properties")
public interface SystemClient {
    @GET
    @Produces(MediaType.APPLICATION_JSON)
    Properties getProperties() throws UnknownUrlException, ProcessingException;
}

// 2. Inject it where needed
@Inject
@RestClient
private SystemClient defaultRestClient;

// 3. Bind the URL in config (e.g., microprofile-config.properties or ConfigMap)
// com.acme.SystemClient/mp-rest/url=http://localhost:9080/system

Swapping the backing service only requires updating the binding property value, provided the replacement service implements the same interface.

5. Build, Release, Run

Strictly separate build and run stages.

• Build stage: Compile source code and produce an artifact — for example, mvn package produces a JAR.
• Release stage: Combine the build artifact with environment-specific configuration and produce a versioned container image — for example, docker build followed by pushing to a registry.
• Run stage: Execute the immutable release image in the target environment — for example, docker run locally or kubectl apply -f deployment.yaml in Kubernetes.

Each release should be uniquely identified and immutable. You never modify a running release; you create a new one.

6. Processes

Execute the app as one or more stateless processes.

Microservices should be stateless so that the infrastructure can destroy and recreate instances without data loss. REST is a widely adopted stateless protocol. JAX-RS, included in MicroProfile, makes it straightforward to build RESTful services:

@ApplicationPath("system")
public class SystemApplication extends Application {}

@Path("properties")
public class PropertiesResource {
    @GET
    @Produces(MediaType.APPLICATION_JSON)
    public JsonObject getProperties() { /* ... */ }
}

This exposes the endpoint http://host:port/system/properties as a stateless RESTful service. Any persistent state belongs in a backing service (factor 4), not in process memory.

7. Port Binding

Export services via port binding.

In cloud environments, service ports change frequently. MicroProfile Config combined with MicroProfile Rest Client handles this cleanly. Store the service URL in a Kubernetes ConfigMap and reference it via the mp-rest/url config property. MicroProfile Config picks up the value automatically at runtime.

Note that Kubernetes environment variable names cannot contain dots (.) or forward slashes (/). Replace non-alphanumeric characters with underscores when mapping property names to environment variables. For example:

# Property name
com.acme.SystemClient/mp-rest/url=http://service-host:9080/system

# Equivalent environment variable name
com_acme_SystemClient_mp_rest_url=http://service-host:9080/system

8. Concurrency

Scale out via the process model.

Stateless microservices can be scaled horizontally by running more instances. Kubernetes Horizontal Pod Autoscaler (HPA) and Knative autoscaling can scale deployments up or down automatically based on observed metrics such as CPU utilisation or incoming request rate.

9. Disposability

Maximise robustness with fast startup and graceful shutdown.

Microservices should start quickly and shut down gracefully. They also need to be resilient to transient failures in downstream services. MicroProfile Fault Tolerance provides a set of annotations that make services more robust:

• @Retry — automatically retry on transient network failures.
• @Timeout — fail fast if a response takes too long.
• @CircuitBreaker — stop calling a failing service to give it time to recover.
• @Bulkhead — limit concurrent calls to prevent one slow service from exhausting all threads.
• @Fallback — execute an alternative method when the primary path fails.

The example below shows a JAX-RS endpoint that will respond within 100 ms regardless of back-end latency, retrying on failure and falling back to a default response if necessary:

@Path("/client")
@ApplicationScoped
public class ClientController {

    @Inject @RestClient
    private Service service;

    @Inject @ConfigProperty(name = "conference")
    String conf;

    @GET
    @Path("/test/{parameter}")
    @Retry
    @Timeout(100)
    @Asynchronous
    @Fallback(fallbackMethod = "fallback")
    public CompletionStage<String> onClientSide(@PathParam("parameter") String parameter) {
        return CompletableFuture.completedFuture(
            "We are live @ " + conf + "! " + service.doSomething(parameter)
        );
    }

    public CompletionStage<String> fallback(@PathParam("parameter") String parameter) {
        return CompletableFuture.completedFuture("This is my fallback!");
    }
}

10. Dev/Prod Parity

Keep development, staging, and production as similar as possible.

Differences between environments are a leading cause of subtle bugs. Container images built with Docker eliminate the classic “it works on my laptop” problem: the same image runs in a developer’s local environment, in CI, in staging, and in production. Kubernetes manifests further codify the expected runtime configuration so that every environment is defined as code.

11. Logs

Treat logs as event streams.

Applications should write log events to standard output (stdout) and let the execution environment handle routing and storage. In Kubernetes, logs written to stdout/stderr are captured by the container runtime and can be forwarded to centralised log aggregation platforms such as the ELK Stack (Elasticsearch, Logstash, Kibana) or Loki. Emitting logs in structured JSON format makes them easier to query and index.

12. Admin Processes

Run admin and management tasks as one-off processes.

Database migrations, cache warming, and similar administrative tasks should run as separate, short-lived processes rather than being embedded in the main application. Kubernetes Jobs are a natural fit: a Job runs a container to completion and then terminates, keeping administrative logic cleanly separated from service logic.

Summary

The table below maps each of the 12 factors to the primary MicroProfile or Kubernetes feature that addresses it:

Eclipse MicroProfile and Kubernetes together provide a comprehensive toolkit for implementing all 12 factors. MicroProfile handles application-level concerns—configuration, service clients, fault tolerance, and RESTful APIs—while Kubernetes provides the runtime infrastructure for scheduling, scaling, secrets management, and job execution.

Original article sourced from msdynamicsworld.com (2020). Code examples are illustrative and based on the MicroProfile API specifications.

Overview

Thycotic, a provider of privileged access management (PAM) solutions, announced an update to its DevOps Secrets Vault product that introduces dynamic secrets and just-in-time (JIT) access for major infrastructure-as-a-service (IaaS) platforms: Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP). The release targets a growing challenge in modern DevOps environments — the secure management of short-lived credentials across complex, multi-cloud pipelines.

The Problem: Secrets Sprawl in Multi-Cloud Environments

As organizations move workloads to cloud IaaS platforms, the DevOps toolchains managing those workloads grow in complexity. A typical pipeline may combine open-source and commercial tools, numerous plug-ins, and library dependencies. Each integration point is a potential surface for secrets leakage — credentials may be improperly stored in memory, written to disk, sent to logging systems, or inadvertently exposed to third-party tools or processes.

Long-lived static credentials compound this risk. If a secret is exfiltrated and remains valid indefinitely, an attacker has a persistent foothold in the environment. Reducing secret lifetime is one of the most effective controls available to security teams.

What Are Dynamic Secrets?

Dynamic secrets are credentials that are generated on demand at the time of a request, rather than stored statically and retrieved when needed. Key characteristics include:

• Ephemeral by design: Each secret is valid only for a defined time window and is automatically revoked after expiry.
• Least-privilege scoping: Secrets are issued with cloud IAM policies that restrict what the credential can access, limiting the blast radius if compromised.
• Just-in-time provisioning: A user, pipeline agent, or configuration tool receives a credential only when it actually needs one, not before.
• Auditability: Because each secret is unique and time-bound, it is straightforward to tie access events to specific requests in audit logs.

In Thycotic DevOps Secrets Vault, dynamic secrets can be issued for AWS, Azure, and GCP, leveraging each platform’s native IAM and policy mechanisms to enforce fine-grained authorization.

Why Just-in-Time Access Matters for DevOps

Traditional PAM solutions were designed around human users and long-lived service accounts. DevOps pipelines operate differently: automation runs continuously, workloads scale elastically, and secrets may be consumed by hundreds of ephemeral containers or CI/CD job runners simultaneously. Static secrets issued to these processes are difficult to rotate and easy to lose track of.

JIT access addresses this by ensuring that no standing privilege exists. A pipeline stage requests a credential, performs its task, and the credential expires automatically. Even if the secret is captured in a log or intercepted in transit, its short validity window significantly reduces its value to an attacker.

“With dynamic secrets, we have added a just-in-time approach to secrets management that further reduces the risk of compromised credentials.”

Jai Dargan, Vice President of Product Management, Thycotic

Platform and Tool Integrations

DevOps Secrets Vault is built on AWS infrastructure, providing elastic scalability suited to high-throughput secrets management workloads. At the time of this release, integrations and SDK support included:

CI/CD and Configuration Management

• Jenkins
• Ansible
• Terraform
• Kubernetes
• Chef (newly added in this release)
• Puppet (newly added in this release)

SDKs

• Java
• Go
• Python
• Ruby (newly added in this release)
• .NET (newly added in this release)

Authentication Methods

DevOps Secrets Vault supports multiple authentication methods, allowing teams to integrate with their existing identity infrastructure:

• AWS: IAM-based authentication for AWS workloads and services.
• Azure: Azure AD-based authentication for Azure-hosted resources.
• GCP: Supports authentication via GCP service accounts, user accounts, Google Compute Engine (GCE) instances, and Google Kubernetes Engine (GKE) workloads.
• Thycotic One: Thycotic’s own identity provider, offering single sign-on (SSO) and two-factor authentication via TOTP (time-based one-time passwords) and SMS.

Positioning Within a Secrets Management Strategy

Dynamic secrets are one layer of a broader secrets management strategy. Organizations implementing JIT access for cloud platforms should also consider:

• Centralized secrets storage: A single vault reduces the sprawl of secrets across config files, environment variables, and code repositories.
• Secrets rotation policies: For secrets that cannot be made fully dynamic, automated rotation limits exposure windows.
• Audit logging and alerting: Every secrets access event should be logged and anomalous patterns should trigger alerts.
• Shift-left secret scanning: Integrating secret detection into source control and CI pipelines catches accidental commits before they reach production.
• Least-privilege IAM policies: Dynamic secrets are only as secure as the policies scoping them — overly broad policies undermine the JIT benefit.

About Thycotic

At the time of this announcement, Thycotic was headquartered in Washington, DC, with offices in the UK and Australia, and served over 10,000 organizations globally. Note: Thycotic merged with Centrify in 2021 to form Delinea. Product names, features, and company details may have changed since this announcement.

What Is the Compose Specification?

Docker has announced that Docker Compose — its system for defining and running multi-container applications — is transitioning to an open, community-governed standard called the Compose Specification. The specification is now hosted publicly on GitHub, open to contributions from any maintainer or organisation that wants to help shape its future.

Previously, Compose existed primarily as a Docker-controlled open-source project: the file format was documented and the tooling was open source, but Docker (the company) remained the de facto sole decision-maker. The move to an open specification changes that governance model, inviting external maintainers to contribute tooling and expand platform support.

Why This Matters for Multi-Container Workflows

The core goal of the Compose Specification is portability. A docker-compose.yml file written to the new spec should be consumable not just by the Docker CLI, but by other container orchestration platforms and tooling — including Kubernetes-based environments and Amazon Elastic Container Service (ECS).

This matters because Docker Compose has long occupied a specific niche: it is simpler than Kubernetes and its associated tooling (such as Helm), making it popular among developers who need just enough orchestration to wire containers together into a working application without the operational overhead of a full Kubernetes cluster. Common use cases include:

• Local development environments with a web server, application container, and database
• Integration test pipelines that spin up dependent services alongside the application under test
• Lightweight staging environments that mirror production topology without full orchestration complexity

Docker Swarm mode shares this appeal as a simpler alternative to Kubernetes for smaller production deployments. Making the Compose file format a genuine open standard strengthens the investment developers and teams have already made in writing Compose files.

Industry Partners: AWS and Microsoft

Docker named Amazon Web Services and Microsoft as early partners for the Compose Specification. Both companies have existing integrations with the Compose file format in their cloud container services:

• Amazon Elastic Container Service (ECS) — AWS supports deploying applications defined with Docker Compose files natively to ECS, reducing the friction of moving from local development to cloud deployment.
• Azure Container Registry / Azure container services — Microsoft’s container platform supports Docker Compose files, and Azure Container Registry also supports Kubernetes configuration files, making it a polyglot target for container workloads.

The involvement of major cloud providers as named partners signals that the Compose file format is being treated as a first-class citizen in cloud-native workflows, not just a local development convenience.

Compose vs. Kubernetes: Understanding the Trade-offs

It is worth clarifying that the Compose Specification is not intended to replace Kubernetes or compete with Helm at the orchestration layer. The two exist at different levels of complexity and capability:

The Compose Specification strengthens Compose’s position at the simpler end of this spectrum while improving its interoperability with more complex platforms when teams are ready to scale up.

What Changes for Developers?

For most developers already using Docker Compose, the day-to-day workflow changes very little in the short term. The key shifts are structural and long-term:

1. Open governance: The specification is no longer solely owned by Docker Inc. Community maintainers can propose changes, and the standard evolves in the open.
2. Broader platform support: As cloud providers and third-party tooling adopt the spec, Compose files become more portable across environments.
3. Clearer separation between spec and implementation: The specification defines what a valid Compose file looks like; individual tools implement support for it. This mirrors how standards like OCI container image formats work.

Getting Involved

The Compose Specification is hosted on GitHub. Developers, platform engineers, and tool authors who want to contribute to the standard — whether by adding features, writing documentation, or building compatible tooling — can participate through the repository’s standard contribution process. Docker is actively seeking maintainers to help grow the ecosystem around the specification.

Examples of multi-service applications written with Docker Compose are widely available on GitHub and remain a useful reference for teams new to the format.

Red Hat, Inc., the world’s leading provider of open source solutions, today announced that Omnitracs, LLC, the global pioneer of fleet management solutions to transportation and logistics companies, has delivered its Omnitracs One platform, the next-generation of fleet management innovation, on the foundation of Red Hat OpenShift. Using the industry’s leading enterprise Kubernetes platform along with Red Hat Ansible Automation Platform, Omnitracs One is a completely cloud-native offering and provides an enhanced user experience with a clear path towards future innovations.

The transportation industry is undergoing a digital revolution and Omnitracs engaged Red Hat as the partner to help accelerate its own transformation efforts. Omnitracs wanted to build upon proven, cloud-native technologies, but with the backing of enterprise-grade support and expertise. The company selected Red Hat based on its reputation for supporting flexible, open technologies in production environments, as well as its knowledge and leadership in enabling cloud-native innovation.

With Red Hat’s expertise and guidance, Omnitracs was able to effectively embrace a shift from on-premises development technologies to cloud-native services, improving overall operations and creating a more collaborative development process culture. Omnitracs One benefits commercial fleets of all sizes through a superior driver experience, a comprehensive library of third-party integrations, device independence and exchangeable data across operations.

The team also enhanced several capabilities, including:

Driving wholesale transformation across the Omnitracs One platform and the entire development process.
Improving the reliability, scalability and overall platform security of the Omnitracs One solution
Reducing development time to bring new features to market and more quickly address changing customer needs
Red Hat’s collaboration with Omnitracs extended beyond technology development, with Red Hat providing training and strategic guidance on product deployment through Red Hat Open Innovation Labs. The Red Hat team also trained the Omnitracs staff on the entire development process, teaching them how to use powerful cloud-based toolchains to create new applications for a cloud-native future.

Although the initial project is complete, Omnitracs and Red Hat are continuing their work together through various community initiatives, including a recent codefest to improve the Truckers Against Trafficking mobile application. Red Hat and Omnitracs plan to continue these initiatives in the future to further enhance the transportation industry through cloud-native solutions.

Supporting Quotes:

Ashesh Badani, senior vice president, Cloud Platforms, Red Hat

“Transformation is more than just changing how code is built or how a new product is delivered; rather true transformation stems from evolving an organization’s development process, from top to bottom, by building on the principles of open technologies, culture and principles. We’re pleased to have helped Omnitracs embrace this change through the expertise of Red Hat Open Innovation Labs and the adoption of cloud-native, fully open technologies like Red Hat OpenShift and Red Hat Ansible Automation Platform.”

Kent Norton, chief technology officer, Omnitracs

“The key result from our successful collaboration with Red Hat is how we now approach technology as well as people and processes. We have re-engineered how we develop, test, secure and deploy software. This has enabled us to not only build and launch an innovative platform for fleet management, but it has also created substantial opportunities for future success with the tools and knowledge needed to address cloud-native demands.”

Additional Resources

Read more Red Hat customer success stories
Learn more about Red Hat OpenShift
Learn more about Red Hat Ansible Automation Platform
Learn more about Red Hat Open Innovation Labs
Learn more about cloud-native application development
Connect with Red Hat

Learn more about Red Hat
Get more news in the Red Hat newsroom
Read the Red Hat blog
Follow Red Hat on Twitter
Join Red Hat on Facebook
Watch Red Hat videos on YouTube
Follow Red Hat on LinkedIn
About Red Hat, Inc.

Red Hat is the world’s leading provider of enterprise open source software solutions, using a community-powered approach to deliver reliable and high-performing Linux, hybrid cloud, container, and Kubernetes technologies. Red Hat helps customers integrate new and existing IT applications, develop cloud-native applications, standardize on our industry-leading operating system, and automate, secure, and manage complex environments. Award-winning support, training, and consulting services make Red Hat a trusted adviser to the Fortune 500. As a strategic partner to cloud providers, system integrators, application vendors, customers, and open source communities, Red Hat can help organizations prepare for the digital future.

Forward-Looking Statements

Certain statements contained in this press release may constitute “forward-looking statements” within the meaning of the Private Securities Litigation Reform Act of 1995. Forward-looking statements provide current expectations of future events based on certain assumptions and include any statement that does not directly relate to any historical or current fact. Actual results may differ materially from those indicated by such forward-looking statements as a result of various important factors, including: risks related to the ability of the Company to compete effectively; the ability to deliver and stimulate demand for new products and technological innovations on a timely basis; delays or reductions in information technology spending; the integration of acquisitions and the ability to market successfully acquired technologies and products; risks related to errors or defects in our offerings and third-party products upon which our offerings depend; risks related to the security of our offerings and other data security vulnerabilities; fluctuations in exchange rates; changes in and a dependence on key personnel; the effects of industry consolidation; uncertainty and adverse results in litigation and related settlements; the inability to adequately protect Company intellectual property and the potential for infringement or breach of license claims of or relating to third party intellectual property; the ability to meet financial and operational challenges encountered in our international operations; and ineffective management of, and control over, the Company’s growth and international operations, as well as other factors. In addition to these factors, actual future performance, outcomes, and results may differ materially because of more general factors including (without limitation) general industry and market conditions and growth rates, economic and political conditions, governmental and public policy changes and the impact of natural disasters such as earthquakes and floods. The forward-looking statements included in this press release represent the Company’s views as of the date of this press release and these views could change. However, while the Company may elect to update these forward-looking statements at some point in the future, the Company specifically disclaims any obligation to do so. These forward-looking statements should not be relied upon as representing the Company’s views as of any date subsequent to the date of this press release.

What Is Application Development Software?

Application development software encompasses the tools, platforms, and environments that developers — and increasingly non-developers — use to design, build, test, deploy, and maintain software applications. The category spans a wide spectrum: from traditional integrated development environments (IDEs) and source control platforms to low-code/no-code builders, cloud application platforms, mobile development tools, and API management services.

Demand for these tools has grown steadily as organizations of all sizes accelerate digital transformation initiatives, adopt DevOps practices, and shift workloads to cloud-native architectures. The market includes both web-based (SaaS) offerings and locally installed toolchains, serving developers targeting Android, iOS, and web platforms.

Key Platforms and Vendors in the Market

The competitive landscape is broad and spans several subcategories. Notable platforms commonly cited in this space include:

• AppSheet – A no-code application development platform (acquired by Google) that allows users to build mobile and web apps from spreadsheet or database data without writing code.
• Google Cloud Platform (GCP) – Google’s cloud infrastructure offering includes App Engine, Cloud Run, Firebase, and other services that support application development and deployment at scale.
• GitHub – The dominant source code hosting and collaboration platform, now a Microsoft subsidiary, also offering GitHub Actions for CI/CD automation.
• Zoho Creator – A low-code platform for building custom business applications, tightly integrated with the broader Zoho ecosystem.
• Microsoft Azure – Microsoft’s cloud platform provides a comprehensive set of application development services including Azure App Service, Azure DevOps, and Azure Functions.
• IntelliJ IDEA – JetBrains’ flagship IDE, widely used for Java and Kotlin development, with extensive plugin support for other languages and frameworks.
• Twilio – A cloud communications platform that provides APIs for SMS, voice, video, and authentication, commonly embedded into application workflows.
• Datadog – Primarily a monitoring and observability platform, Datadog integrates into development pipelines for performance tracking and alerting.
• Axure RP – A prototyping and wireframing tool used by UX/UI designers to create interactive application mockups.
• Joget Workflow – An open-source low-code/no-code platform for building enterprise web applications and automating workflows.
• GitLab – A complete DevOps platform offering source control, CI/CD, security scanning, and project management in a single application.
• SAP HANA Cloud Platform – SAP’s platform-as-a-service offering for building and extending enterprise applications, particularly those integrated with SAP’s ERP ecosystem.
• Snappii – A mobile business app builder targeting field operations and enterprise mobility use cases.
• King of App – A CMS-based mobile app builder platform.

Market Segments: Deployment Type and Target Platform

By Deployment Type

• Web-Based (SaaS) – Delivered via browser with no local installation. This model dominates new tool adoption due to lower friction, automatic updates, and easier collaboration across distributed teams.
• Installed (On-Premises or Desktop) – Traditional locally installed tools such as desktop IDEs. Still preferred in environments with strict data sovereignty or security requirements, or for performance-intensive workloads.

By Target Application Platform

• Android – Development tools targeting Google’s Android OS, including Android Studio, Kotlin/Java SDKs, and cross-platform frameworks such as Flutter and React Native.
• iOS – Development tools targeting Apple’s iOS platform, primarily Xcode, Swift, and Objective-C, alongside cross-platform options.
• Web – Browser-based application development covering front-end, back-end, and full-stack toolchains.

Regional Market Overview

Adoption of application development software varies by region, driven by differences in developer workforce size, enterprise IT maturity, cloud infrastructure investment, and regulatory environment:

• North America (led by the United States) – The largest single market, home to most of the major platform vendors and a mature enterprise software buyer base. Strong adoption of DevOps toolchains and cloud-native development practices.
• Europe (Germany, France, United Kingdom) – Significant enterprise demand, particularly for platforms that comply with GDPR. Growing investment in sovereign cloud and open-source tooling.
• Asia-Pacific (China, Japan, India) – Fast-growing developer population, especially in India. China’s domestic tooling ecosystem is increasingly distinct from Western platforms. Japan shows strong enterprise software adoption.
• Latin America (Brazil) – An emerging market with growing startup activity and increasing cloud platform adoption.
• Middle East and Africa – Developing market with government-led digitalization initiatives driving demand, though infrastructure maturity varies significantly by country.

Key Trends Shaping the Application Development Software Market

1. Low-Code and No-Code Acceleration

Platforms such as AppSheet, Zoho Creator, and Joget Workflow have reduced the barrier to application development. Business analysts and domain experts can now build functional applications without deep programming knowledge, which expands the total addressable market and shifts some development workloads away from traditional engineering teams.

2. DevOps and CI/CD Integration

Source control and collaboration tools like GitHub and GitLab have evolved into full DevOps platforms. Native CI/CD pipelines, container registry support, and security scanning are now expected features rather than add-ons. This has consolidated toolchain sprawl for many development teams.

3. Cloud-Native Development

Vendors like Google Cloud Platform, Microsoft Azure, and SAP HANA Cloud Platform are central to the shift toward containerized, microservices-based application architectures. Serverless computing, managed Kubernetes, and platform-as-a-service offerings reduce operational overhead and allow teams to focus on application logic.

4. AI-Assisted Development

Since the original market data was gathered (circa 2019), AI-assisted coding tools have become a significant new category within application development software. Tools offering code completion, generation, and review are now integrated into IDEs and cloud platforms, meaningfully changing developer productivity dynamics.

5. Observability as a Development Concern

The inclusion of Datadog in this market reflects a broader trend: monitoring and observability are no longer purely operational concerns. Development teams are expected to instrument applications from the start, integrating telemetry, logging, and alerting directly into the development lifecycle.

Evaluating Application Development Software: What to Look For

When assessing platforms for your team or organization, consider the following dimensions:

• Target user persona – Is the tool designed for professional developers, citizen developers, or both?
• Deployment model – SaaS, self-hosted, or hybrid? Does it meet your data residency requirements?
• Integration ecosystem – Does it connect with your existing CI/CD pipeline, cloud provider, and collaboration tools?
• Scalability – Can it support applications that grow from prototype to production workloads?
• Vendor lock-in risk – How portable are the applications and data you build on the platform?
• Security and compliance – Does it support your required compliance frameworks (SOC 2, ISO 27001, GDPR, etc.)?
• Total cost of ownership – Consider licensing, infrastructure, training, and migration costs together.

Summary

The application development software market is broad, competitive, and evolving rapidly. It encompasses everything from cloud platforms and IDEs to low-code builders and API toolkits. The vendors most relevant to any given organization depend heavily on team composition, target platform, cloud strategy, and compliance requirements. Understanding the major players and how they map to specific development use cases is a practical first step in toolchain evaluation.

For teams adopting DevOps practices, the strongest signal in this market is convergence: source control, CI/CD, security scanning, and deployment are increasingly available within single platforms like GitLab or GitHub, while hyperscaler platforms (Azure, GCP) continue to expand their developer tooling surface area.

What Is VMware HCX?

IT administrators extending virtual server environments to the cloud face real obstacles: cost, operational complexity, and migration risk. VMware addresses these challenges with Hybrid Cloud Extension (HCX), a platform that links on-premises vSphere environments to multiple cloud platforms through a unified abstraction layer.

HCX enables secure, bi-directional workload mobility with minimal operational overhead, without requiring application modifications, OS changes, or re-architecting of existing vSphere infrastructure. It supports hybrid and multi-cloud strategies by making workloads portable across environmental boundaries.

How HCX Works

HCX creates an abstraction layer between source and destination vSphere environments, tethering them together so that Layer 2 networks can be stretched across sites. A stretched Layer 2 network gives virtual machines (VMs) seamless mobility — they retain their IP and MAC addresses and can be moved across environmental boundaries without reconfiguration.

Key capabilities built into the platform include:

• WAN optimization: Built-in compression, deduplication, and intelligent routing improve performance over wide-area connections.
• Broad vSphere compatibility: HCX can tether any two environments running vSphere 5.0 or later.
• Cross-domain support: HCX works across multiple administrative domains without requiring a shared Single Sign-On (SSO) domain.
• Network topology support: Compatible with vSphere Distributed Switch and VMware NSX.
• Encryption: Data in transit is protected using IPsec with Suite B encryption.

By eliminating the need to retrofit infrastructure or negotiate complex connectivity arrangements, HCX can accelerate cloud adoption and reduce the risk of large-scale migrations by allowing organizations to move workloads in manageable stages.

HCX Architecture: The Four Core Components

HCX is composed of four virtual appliances. The HCX Manager must be installed first; the remaining three are deployed as optional services depending on your use case.

1. HCX Manager

The HCX Manager appliance is installed in the management zone at both the source and destination sites, adjacent to each site’s vCenter Server. It provides a management plugin for vCenter, bootstraps all HCX services, and manages the deployment and connectivity of the other virtual appliances. The Manager appliances at each site form a unified framework for the entire HCX deployment.

2. HCX Interconnect

The HCX Interconnect appliance creates a secure pipeline for migrating, extending, and protecting VMs across HCX sites using site pairing. It supports both replication-based and vMotion-based migration, provides WAN optimizations such as traffic engineering and intelligent routing, and uses IPsec with Suite B encryption. The appliance is deployed at each HCX site pair.

3. HCX WAN Optimization

The WAN Optimization appliance improves throughput across wide-area connections using compression, deduplication, and line conditioning. Like the Interconnect appliance, it is deployed at each HCX site pair.

4. HCX Network Extension

The Network Extension appliance provides Layer 2 network extension capabilities, allowing a VM to retain its IP and MAC addresses when migrated between sites. The appliance is deployed per vSphere Distributed Switch.

Internally, the Network Extension appliance deploys a high-throughput Layer 2 concentrator at the source site and a mirror concentrator at the destination. The concentrator performs proximity routing, ensuring symmetrical VM forwarding within the stretched network. It is also DR- and vMotion-aware, and supports stateful network devices such as firewalls and intrusion prevention systems (IPS).

Supported Environments and Destinations

HCX can connect an on-premises vSphere environment to a range of destinations, including:

• Other on-premises vSphere environments
• Private cloud infrastructures
• VMware Cloud on AWS
• Hosted cloud environments offered by VMware Cloud Provider Program partners

HCX Use Cases

HCX addresses three primary use cases: application mobility, VM migration, and disaster recovery.

Application Mobility

HCX enables seamless, bi-directional VM movement between vSphere environments. Workloads can be relocated according to changing demand, letting organizations build a hybrid cloud infrastructure that maximizes resource utilization while managing costs. Applications can be distributed across boundaries without modification.

VM Migration

HCX simplifies migrating workloads off aging vSphere infrastructure and extending data center capacity to the cloud at an organization’s own pace. It supports bi-directional migration and four distinct migration types:

Disaster Recovery (DR)

HCX can serve as the foundation of a DR strategy. VMs can be replicated to a secondary vSphere environment at regular intervals. In the event of a primary site failure, secondary VMs can be powered on without changing their IP or MAC addresses, minimizing reconfiguration effort and recovery time.

Summary

VMware HCX provides a structured, appliance-based approach to hybrid and multi-cloud connectivity for vSphere environments. By abstracting the network and compute differences between sites, it enables workload portability, phased cloud adoption, and resilient DR — without requiring architectural changes to existing infrastructure. For teams managing vSphere at scale and planning cloud extension or migration projects, HCX is a platform worth evaluating in depth.

But adopting multiple cloud platforms does not automatically unlock those advantages. More platforms mean more moving parts, more failure domains, and more operational complexity—especially when hybrid and multi-generational infrastructure is also in the mix. The teams that extract real value from a multi-cloud strategy are the ones that solve the hardest operational problem that comes with it: maintaining consistent, unified visibility across every environment.

Why Multi-Cloud Complexity Is Growing

Software now underpins virtually every business function, a shift Marc Andreessen famously described as “software eating the world.” The major cloud providers—Amazon, Google, and Microsoft—recognized this trajectory early and built platforms that let companies consume compute, storage, and managed services on demand. The result is that organizations no longer need to build and operate their own data centers; instead, they can focus capital and engineering effort on delivering value to customers.

This shift also enables a portable, DevOps-driven software stack that is not tied to any single provider. Container orchestration platforms such as Kubernetes, combined with infrastructure-as-code tooling, make it feasible to deploy workloads across clouds with a consistent operational model. The trade-off is that each additional platform, cluster, or service introduces new sources of telemetry, new failure modes, and new operational dependencies—all of which must be observed and understood.

The Missing Piece: Multi-Cloud Monitoring

In a software-dependent organization, availability is a business requirement, not just an engineering goal. Downtime is expensive in direct revenue loss and damaging to customer trust and brand reputation. Monitoring has therefore become a core operational competency, not an optional add-on.

The challenge is that collecting monitoring data across a multi-cloud environment is largely a solved problem—the tooling exists. What remains unsolved for many teams is how to turn that data into actionable, unified visibility. A fragmented set of per-cloud dashboards and siloed alerting systems does not give operators the complete picture they need to detect problems early, correlate events across providers, and avoid costly outages.

A unified monitoring solution—one that aggregates signals from every cloud environment into a single operational view—is what closes this gap. It gives on-call engineers consistent visibility into infrastructure, applications, and service dependencies regardless of where those components run.

Surviving as a Modern Enterprise

Improved operational visibility is consistently cited as a top priority by CIOs and senior operations leaders, and research on high-performing engineering teams shows that good monitoring practice is a common differentiator. Yet monitoring is still frequently implemented reactively—bolted on after a production incident rather than designed as a first-class part of the system.

This reactive pattern is particularly risky in modern cloud-native environments. Ephemeral infrastructure—containers scheduled and destroyed by Kubernetes, serverless functions invoked on demand, auto-scaled virtual machine fleets—means the set of things being monitored is constantly changing. Traditional, host-centric monitoring approaches that assume a relatively static inventory break down in these environments.

Meanwhile, initiatives such as digital transformation, cloud migration, and continuous delivery all share a common goal: shipping more changes faster. Each of these is a genuine productivity win, but each also increases the rate at which the operational environment changes—which in turn increases the number and frequency of day-two operational challenges. Teams that delay building a robust monitoring strategy pay a compounding cost in risk exposure and incident response time.

Be Prepared for the Cloud Gold Rush

The cloud managed-services market continues to expand, with new providers and new service categories emerging regularly. This is broadly good for organizations—competitive markets drive down prices and push providers to innovate—but it does mean the multi-cloud landscape will grow more diverse and complex over time, not less.

Given this trajectory, it is unrealistic to expect any single turnkey monitoring product to provide complete coverage indefinitely. A point tool that works today may not support a new provider or a new workload type tomorrow. A fundamentally different approach is needed: one that is composable and adaptable by design.

Treat Monitoring Like the Rest of Your DevOps Toolchain

The practical answer is to treat monitoring and observability as a pipeline—the same mental model teams already apply to CI/CD. When container adoption accelerated, most engineering teams did not replace their CI pipelines; they adapted them to build and ship container images instead of RPMs or zip archives. The pipeline abstraction remained stable even as the artifact type changed.

The same principle applies to observability. There are a finite set of mechanisms by which systems can be observed:

• APM agents and client libraries that instrument application code and report traces, metrics, and errors.
• Metrics endpoints following the Prometheus scrape model (e.g., /metrics) or push-based equivalents.
• Health check endpoints (e.g., /healthz) for liveness and readiness signaling.
• Log streams from applications, platform components, and cloud provider services.
• Synthetic and service health checks that probe external behavior from outside the system.

A monitoring event pipeline treats each of these as a data source feeding into a composable workflow. Events are collected, normalized, enriched, routed, and acted upon—whether that means triggering an alert, updating a dashboard, feeding a long-term data store, or notifying an on-call engineer. Because the pipeline is decoupled from any specific cloud provider or monitoring backend, it can be extended to support new sources and destinations as the environment evolves.

Key Principles for a Resilient Multi-Cloud Monitoring Strategy

1. Design for ephemerality. Assume the set of monitored entities is always changing. Use service discovery and dynamic tagging rather than static host lists.
2. Normalize across providers. Define a common schema for metrics, events, and log records so that data from AWS, GCP, and Azure can be queried and correlated consistently.
3. Automate the pipeline. Treat monitoring configuration as code, version it, and deploy it through the same pipelines used for application changes.
4. Decouple collection from storage and alerting. A pipeline architecture lets you swap or add backends (time-series databases, log aggregators, incident management platforms) without re-instrumenting your applications.
5. Build monitoring in, not on. Instrument services at development time. Waiting until a production incident to add observability guarantees you will be operating blind when it matters most.

Conclusion

Multi-cloud adoption brings genuine advantages—flexibility, cost optimization, resilience, and freedom from vendor lock-in. But those advantages are only accessible to teams that can see clearly across all of their environments. A fragmented, provider-specific monitoring approach leaves organizations flying blind across exactly the parts of their infrastructure that are hardest to manage.

The solution is not a bigger monitoring tool—it is a better architectural pattern. By treating observability as a pipeline that can be continuously adapted, engineering teams gain the same composability and future-proofing in their monitoring stack that they already expect from their CI/CD toolchain. In a cloud landscape that will only grow more complex, that adaptability is the real key to multi-cloud success.

This article is based on a piece originally published on devops.com.

The right approach lets a business modernise its mainframe estate and benefit from cloud economics—elasticity, pay-as-you-go pricing, and modern tooling—while retaining the intellectual property embedded in decades of proven application code.

Core Requirements for Any Mainframe-to-Cloud Solution

Before evaluating specific migration paths, organisations should establish non-negotiable baseline requirements. A viable cloud solution for mainframe applications must be:

• Cost-effective — ideally shifting capital expenditure (CapEx) to predictable operational expenditure (OpEx).
• Secure — meeting or exceeding the security posture of the existing mainframe environment.
• Reliable — preserving the high availability and resilience that mainframe users typically expect.
• Modernisation-ready — enabling the business to adopt current and future development practices, tools, and languages.

The Three Mainframe Migration Strategies

When planning a mainframe-to-cloud migration, there are three primary options. Each carries a different risk profile, cost, and level of disruption to existing business logic.

1. Rewrite

The existing application functionality is recreated from scratch in a language more typical of cloud-native development (Java, Python, Go, etc.). This addresses concerns around the shrinking pool of COBOL and assembler developers, but it comes at a significant cost. A rewrite requires substantial investment in engineering time without necessarily adding new features or functionality. The risk of regression—failing to replicate complex, battle-tested business logic faithfully—is high. Rewrites frequently overrun budgets and timelines.

2. Replace

Organisations can implement a Software-as-a-Service (SaaS) solution to replace the current system entirely. This creates an opportunity to review and modernise business processes simultaneously. However, for all but the most commodity workloads, off-the-shelf SaaS products rarely replicate the depth of functionality built up over years in a custom mainframe application. Replacing a highly customised system often means accepting reduced capability or surrendering the competitive differentiation that the original application provided.

3. Rehost (Lift and Shift)

Rehosting moves mainframe applications to a cloud platform with minimal or no code changes. Specialised platforms can emulate the mainframe runtime environment—including COBOL execution, JCL job scheduling, VSAM data access, and CICS transaction processing—on standard cloud infrastructure. This approach preserves existing competitive advantage and lets the business continue to run proven code while incrementally modernising over time. The main challenge is organisational and political: mainframe decisions often involve entrenched stakeholders, vendor relationships, and legacy procurement contracts.

Combining Strategies: Replace Plus Rehost

For most organisations, a hybrid approach—replacing commodity components with SaaS where appropriate, and rehosting the core business-logic applications unchanged—delivers the greatest practical benefit. This allows the business to deploy modernised application components to the cloud or an alternative platform based on business and operational requirements, without a high-risk big-bang rewrite.

Benefits of Moving Mainframe Workloads to the Cloud

When executed correctly, migrating mainframe applications to a cloud environment can unlock a broad set of operational and financial benefits:

• Reduced risk — Retaining existing intellectual property and competitive advantage keeps change incremental and risk manageable. There is no need to recreate decades of proven business logic.
• Flexibility — Cloud platforms offer a wide range of virtual environments, and resources can be provisioned or decommissioned on demand rather than according to hardware procurement cycles.
• Faster time to market — Moving test and development environments to the cloud allows teams to provision mainframe-compatible instances in minutes rather than days. This enables genuine mainframe DevOps: faster iteration between development, test, and production teams.
• Cost optimisation — Shifting development, test, and production workloads to the cloud reduces dependency on proprietary mainframe hardware and software licensing. Costs become OpEx rather than CapEx, improving budget predictability.
• Reliability — Major cloud providers offer highly resilient infrastructure with automated failover, geographic redundancy, and strong SLA commitments.
• Scalability — Cloud environments support automatic horizontal and vertical scaling and load balancing, enabling workloads to grow without manual infrastructure intervention or performance degradation.
• High performance — Cloud platforms offer multiple instance types optimised for different compute-to-I/O ratios, allowing organisations to match infrastructure to workload characteristics.
• Security — Rehosted applications can be integrated into a standard cloud security stack, including identity and access management, encryption at rest and in transit, audit logging, and multi-factor authentication—in some cases improving on the security controls available in legacy mainframe environments.

Practical Considerations: Mapping Mainframe Services to the Cloud

A successful migration requires a solution that maps core mainframe services—transaction monitors, job schedulers, data access methods, and security subsystems—to their cloud equivalents, while allowing the application code itself to run unchanged. Getting this mapping right is what makes rehosting viable and what distinguishes it from a full rewrite. Organisations that achieve this can unlock significant savings through reduced operating costs, improved developer productivity, and better system performance.

Moving to a platform such as Microsoft Azure or a comparable cloud provider also frees businesses from the constraints of proprietary mainframe hardware refresh cycles, giving them faster access to infrastructure, greater scalability, higher availability, and improved business continuity—all hosted in highly secure, certified data centres.

Case Study: Migrating COBOL Payroll Processing to the Cloud

A German public-sector IT services organisation provides payroll processing to its clients, handling salary payments for approximately 420,000 individuals every month. The payroll system relied heavily on COBOL for core business logic, running on mainframes. Constantly changing salary rules, tax rates, and regulatory requirements meant the team needed to update software frequently, but the mainframe environment slowed development cycles.

To respond more quickly to client requests and adopt modern development tooling, the organisation chose to migrate its COBOL applications from the mainframe to a cloud environment using a rehosting approach. By moving the COBOL code without rewriting it, the team could migrate the most critical business logic incrementally and with low risk—one component at a time.

The migration was completed quickly, giving the business a stable, future-proof platform. Development teams could now iterate faster using modern IDEs and CI/CD pipelines while the proven COBOL logic continued to execute correctly. As the organisation’s public-sector clients continue to adopt digital workflows, the modernised platform allows the team to deliver high-quality, reliable services while protecting the integrity of critical HR and payroll processes.

Summary: Choosing the Right Path

There is no single correct answer for mainframe modernisation. Rewriting is high-risk and expensive. Replacing with SaaS may sacrifice competitive differentiation. Rehosting preserves proven code but requires organisational buy-in and a platform that genuinely supports mainframe runtime semantics. For most enterprises, a pragmatic combination—rehosting core applications and replacing commodity functions—provides the best balance of speed, risk, and long-term flexibility. The goal is not to abandon what works, but to give proven applications a modern, scalable foundation from which the business can continue to evolve.