Enterprise Distributed Application Service (EDAS) supports the Elastic Compute Service (ECS) environment and Kubernetes environment. Both environments allow you to host applications in them. However, ECS and Kubernetes provide different features. When you make business decisions or decide on the environment to which you want to migrate workloads, questions may arise. This topic describes and compares the ECS and Kubernetes environments. You can choose an environment based on your business requirements.

Background information

EDAS supports the ECS environment and Kubernetes environment. You can deploy applications in ECS or Kubernetes clusters. Both ECS and Kubernetes support the Spring Cloud, Apache Dubbo, High-Speed Service Framework (HSF) microservice frameworks. EDAS allows you to host, govern, and monitor Java applications that use the preceding frameworks. ECS and Kubernetes have different requirements for applications and technology stacks. EDAS also provides different application management features to ECS and Kubernetes.

How to select

Kubernetes is applicable to most scenarios. EDAS is integrated with Container Service for Kubernetes (ACK), which provides a wide array of application management features to help you increase resource utilization.

We recommend that you choose an environment based on the actual business requirements.

Scenario Environment
  • Container images or non-Java applications
  • Multiple applications deployed on the same instance or a large number of applications deployed in the same environment
  • Require Kubernetes features or tools such as kubectl to manage applications
Kubernetes
  • A large number of non-containerized applications deployed in the environment

    ECS is a better alternative to hosting non-containerized applications because it provides an easier way to reuse existing application O&M systems.

  • High requirements for the performance and stability of monolith applications
ECS
Note If your applications are already deployed in ECS clusters, and want to use advanced features provided by Kubernetes, you can migrate the applications to Kubernetes clusters.

Features supported by ECS or Kubernetes

The following table describes the features supported by ECS or Kubernetes. Y indicates supported and N indicates not supported.
Feature ECS Kubernetes Remarks
Deploy an application Y Y Kubernetes provides more types of scheduling policy for deploying instances and allows you to deploy multiple applications on the same instance.
Start an application Y Y N/A
Stop an application Y Y N/A
Delete an application Y Y N/A
Scale an application Y Y N/A
Reset an application Y N This feature is not required in the Kubernetes environment. To reset an application, you can delete the Kubernetes pod where the application is deployed.
Upgrade or downgrade a container Y Y N/A
Roll back an application Y Y N/A
Horizontal scaling Y Y The methods and rules of ECS and Kubernetes are different.
Scheduled scaling N Y N/A
Batch deployment Y Y N/A
Application groups Y N N/A
Configuration of application groups Y N N/A
Real-time log delivery Y Y N/A
Log directory Y Y N/A
Log Service Y Y N/A
Load balancing Y Y N/A
Health check Y Y Kubernetes uses readiness and liveness probes to perform health checks. The health check mechanism is different from that of ECS.
Java virtual machine (JVM) parameters Y Y N/A
Tomcat parameters Y Y N/A
Lifecycle hooks Y Y Kubernetes supports the PostStart and PreStop hooks, which are different from those provided by ECS.
Environment variables Y Y N/A
Canary release Y Y N/A
Traffic monitoring Y Y N/A
Traffic throttling Y Y Kubernetes implements traffic throttling for an application without the need to modify the application code.
Service list Y Y N/A
Configuration push Y Y N/A
Event center Y Y N/A
Alerts Y Y N/A
Application diagnostic Y Y Kubernetes provides an advanced application diagnostic feature that is integrated with monitoring services.
Resource purchases Y N N/A
Service mesh N Y N/A
Deployments from images N Y N/A
Applications written in different programming languages N Y N/A
Network-attached storage (NAS) N Y N/A

FAQ

Does the ECS environment allow me to deploy multiple applications on the same instance?

No, ECS does not allow you to deploy multiple applications on the same instance. If you want to deploy multiple applications on the same instance, choose the Kubernetes environment.

Does the ECS environment support applications written in different programming languages?

No, ECS does not support applications written in different programming languages. If you want to deploy applications written in different programming languages, choose the Kubernetes environment.

Do the ECS and Kubernetes environments support developer tools?

Yes, both the ECS and Kubernetes environments support developer tools. However, the tools have different configuration requirements.

In the Kubernetes environment, how are nodes scaled out?

The Kubernetes environment automatically scales in and scales out pods. In most cases, a Kubernetes cluster does not create new nodes (ECS instances) or release existing nodes.

You can use features provided by ACK to automatically scale in and scale out nodes.

If I have mounted scripts to applications deployed on ECS instances, how do I migrate these applications to a Kubernetes cluster?

In the ECS environment, scripts that are mounted to applications are used to run specified commands when the change order enters the specified stage. ECS allows you to mount scripts to the following lifecycle stages of an application: create an instance, start the application, stop the application, and release the instance.

Kubernetes provides only the PostStart and PreStop lifecycle hooks. The lifecycle stages of a Kubernetes-based application are different from those of an ECS-based application. Therefore, you must modify the scripts before you migrate applications from ECS to Kubernetes.
  • If you want to mount scripts when you create an instance, you can compile the scripts into a Dockerfile and create an image from the Dockerfile.
  • If you want to mount scripts before you start the application, you can compile the scripts into a Dockerfile and create an image from the Dockerfile.

    In a Kubernetes pod, creating an instance and starting the application are considered the same process.

  • To mount scripts after the application is started, mount them as the PostStart hook.
  • To mount scripts before the instance is stopped, mount them as the PreStop hook.
  • We recommend that you gracefully shut down the application so that you can remove scripts that are mounted after the instance is stopped. For example, you can add a Shutdown hook to a Java application or send the SIGTERM signal to the scripts that you want to remove. Alternatively, you can move the scripts to the PreStop hook.
  • We recommend that you gracefully shut down the application so that you can remove scripts that are mounted before the instance is released. For example, you can add a Shutdown hook to a Java application or send the SIGTERM signal to the scripts that you want to remove. Alternatively, you can move the scripts to the PreStop hook.

    In a Kubernetes pod, stopping and releasing an instance are considered the same process.