Increasingly, established software vendors want to offer their product portfolio as a software-as-a-service (SaaS) solution. However, parallel development for on-premises and cloud deployments poses some challenges. This article will show how container platforms can be used to reduce the effort involved in operating and delivering SaaS through standardisation in hybrid scenarios.

Bloomberg [1] estimates that the SaaS market will grow to over $600 billion by 2023, quadrupling its 2020 levels. For many software vendors that have traditional licence products for in-house operations, this is an incentive to expand their portfolio and include SaaS or completely convert their business model to it. However, when existing products are converted to SaaS, there’s often a different problem on the agenda on top of technical modernization and building up necessary expertise in operations. What should we do with loyal, pre-existing customers who cannot shift their production operations to the cloud?

There are several reasons this may occur:

• The product is used in a business area subject to strict regulations, forcing the customer to operate over its own IT.
• The customer made significant investments in their on-premise infrastructure and is waiting to move to SaaS after they receive payback on their investment.
• Other customer systems integrate with the product and have low-latency requirements. Therefore, the product must operate in the same data centre.

The software vendor has several options for dealing with this problem:

• Develop the existing product in parallel with the SaaS offering. Both variants will be marketed as one product. The added value of the SaaS solution for customers is simply the outsourcing of operations.
• The existing product enters a sunset phase. This means active development will not continue, and the product will only receive security updates and support for a determined length of time. The SaaS offering can be designated on a greenfield basis.
• The SaaS offering becomes the software manufacturer’s strategic focus and in the future, it expects to be responsible for the main revenue. The inventory product becomes a core of the SaaS offering. A technical architecture and deployment model are chosen that will enable the core product to operate outside the cloud.

In the first example, the software manufacturer needs to be prepared to incur additional expenses in development or market their licensed product’s managed hosting offering as SaaS. In this case, advantages of modern microservices architectures such as shorter release cycles and more efficient operation can often fall by the wayside. Depending on the product, it’s possible that functional parity between the licensed product and the SaaS offering isn’t maintainable in the long term. For instance, cloud providers offer services in the areas of artificial intelligence and machine learning (AI/ML) that can only be implemented by the company itself with much effort. They cannot be operated cost-effectively in single-tenant environments. With the SaaS variant, integrating these services lets the software manufacturer implement innovative use cases that it cannot offer in their existing product outside the cloud.

Therefore, the third option therefore offers a compromise. Self-hosters are given the option of continuing to operate the product under their own responsibility with full control. At the same time, the software manufacturer doesn’t need to consider developing two technical architectures. For new use cases, they can decide on a case-by-case basis if the functionality should (or can) be implemented into the core product. If the use case is developed just for the SaaS variant, then the provider has complete freedom with regard to architecture and design.

If they want to offer the core product as well as the SaaS offering for operation on their own infrastructure, they must find a suitable deployment and operating model. The effective operation of a SaaS solution across a growing number of clients must be made possible by the manufacturer. The same is true for the operation of individual clients on heterogeneous infrastructure in the customer’s data centre. Furthermore, modernization often involves empowering the vendor’s product teams to develop in an agile manner. This means short release cycles with small, low-risk change sets, data-driven management of feature development via end-user feedback, and automating test deployments and demo environments.

Containerized solutions are common because they move many operational tasks around provisioning and deployment to the build phase of development. They support microservices architectures and work well for agile development. Usually, the operations team already has some experience operating container platforms. In particular, the open source Kubernetes platform is commonly used and can be operated on a wide range of hardware.

So does Kubernetes solve the portability problem? Do software vendors just need to make their architecture fit for Kubernetes to enable SaaS in their own operations? Unfortunately, the answer is no. The reason is the Kubernetes project’s high degree of flexibility and rapid development. Current APIs used to describe a workload may already be gone in the next release. Additionally, Kubernetes platform operators can add extensions or even exchange platform standards. Its widespread adoption doesn’t guarantee that its own customer’s operations teams have sufficient experience with the platform to deploy a cluster for mission-critical applications.

Therefore, in this two-part article, we will take a look at two platforms for running a public SaaS offering in the cloud which also allows software to run on customer-provided infrastructure:

• Amazon Elastic Container Service (ECS) is a container platform developed by Amazon Web Services (AWS). It was designed with the goal of simplifying processes in the development and deployment of containerized applications. That’s why ECS is especially suitable when operational efforts are kept low and the operations team doesn’t have much experience with cloud-native developed applications and container platforms.
• With Amazon Elastic Kubernetes Service (EKS), AWS offers a managed service for running Kubernetes applications. EKS is a Cloud Native Compute Foundation (CNCF) certified product and has guaranteed compatibility with the open source version of Kubernetes. EKS users have the flexibility that they’re used to from Kubernetes to customise the cluster to their own needs.

With Amazon ECS Anywhere and Amazon EKS Anywhere, software vendors can run containerized solutions for ECS and EKS outside of the AWS Cloud and can run some or all of their SaaS offerings on customers’ hardware. We will present how software manufacturers can find solutions for the issues mentioned at the beginning of this article, justifying the customer’s wish for on-premises operations. In this series, we’ll limit ourselves to features from the Anywhere components. For more details about ECS and EKS, interested readers should refer to the official documentation [2], [3].

In the following, we’ll take a detailed look at ECS Anywhere...