1. About Container Orchestrator
Container is an affordable way to build, test and deploy applications across multiple environments: from a developer’s local laptop to on-premises production servers and the cloud. A single container might be used to run anything from a small micro-service to a marco-service or a more extensive application. Actually micro-service is probably the most common use case. In large application deployments, multiple connected containers is usually used. This approach allows better scaling strategies, more secure, easier to manage, and saves more infrastructure resources.
In multi-containers case, they should be deployed in a cluster of machines (nodes), or even multiple clusters. Such clusters might be managed by a Container Orchestrator tool such as Kubernetes.
Figure 1: General Container Orchestrator Components
So, to start going with the Container approach, choose the right Container Orchestrator Platform for your application first. It will be an important decision as it will affect your application development and business growth in the long run.
2. What Container Orchestrator Candidates are there?
There are self-hosted and managed Container Orchestrators.
2.1 Self-hosted container orchestrator
Self-hosted tools refer to Orchestrator software installed and maintained by the user. There are Orchestrator which could be self-hosted: open source Kubernetes, commercial ones as OpenShift, HashiCorp Nomad, Docker Swarm, Rancher, Mesos and so on.
Figure 2: Self-hosted Container Orchestration
Be flexible in customization, a lot of components and features, especially powerful in its automation capabilities, the open source Kubernetes is one of the most well-known choices for a Self-hosted approach.
Figure 3: Kubernetes components
2.2 Managed Container Orchestrator Service
Managed Container Orchestrator Service means the Orchestrator software components and their run-time as well as all modifications, replacements, upgrades, enhancements, documentation, materials, and media related to it are handled by the Service Provider. There are Managed Orchestrator Services: Google Container Engine (GKE), AWS Elastic Kubernetes Service (EKS), Azure AKS Service, and Sun Container Spinner (SCS) by Sun Cloud.
Figure 4: Managed Container Orchestration
3. Which Container Orchestrator is better?
There is no single answer to this question. Choosing a container orchestrator tool or a managed service depends on various factors, such as the company’s infrastructure condition, engineering resources, budget, application size and scale, future product plan, etc. The following information could be considered as a reference source for your decision-making.
3.1 Consider application scale
At small scale, a few of containers (i.e. 3-5 containers), under low or middle traffic, don’t make things over complicated as using Kubernetes. A simple self-hosted approach like Docker Swarm or even Docker Composer (if the application is very small and not too important to be HA) may fit enough. The limitation is that you will have to change and migrate later when the application scale increases in the future. By using managed Serverless Orchestration Service at the beginning, you may not need to worry about this issue. I will explain this option in the later section (Level of managed service).
Figure 5: Docker Swarm
At large scale, the Docker Swarm, which is lightweight and tied to the Docker API, limited functionality, it is not enough to manage large applications. It lacks the auto-scaling ability, built-in monitoring, or rich deployment options as Kubernetes. Moreover, Docker Swarm’s automation capabilities are not as robust as Kubernetes. Whether going with a self-host or managed service approach, Kubernetes or the commercialized Kubernetes as OpenShift is still a better option than Docker Swarm.
3.2 Choose self-host or managed service
The most significant advantage of Kubernetes’ self-hosting is the complete control over the platform and flexibility of change. But we pay for this advantage by massive engineering effort on provisioning, operating and troubleshooting the Kubernetes platform. It would be OK if you had Kubernetes and Infrastructure experts in the team to take care of design, setup, and upgrade the platform as well as the infrastructure required for it. A dedicated Platform or DevOps team must maintain and support, customize, configure the scaling, and extend the Kubernetes cluster and other Kubernetes cluster ownership relevant tasks when you need. In some situations, self-hosted Kubernetes can be overly complicated, reduce productivity, or be error-prone.
In some cases, self-host a well Commercialized Platform like OpenShift is a better option. Compared to open-source Kubernetes, OpenShift is more stable, less complicated, fewer problems to deal with. It provides useful features to simplify the operations. The biggest problem is the cost! You must invest and maintain OpenShift-certified infrastructure and pay for the subscription fee for each core you run OpenShift on. So you should have a proper budget plan for both OpenShift certified hardware and OpenShift software license.
If we need a reliable platform without being overhead on resolving its complex problems at a reasonable cost, consider Managed Orchestrator Service. The service is expected to handle all Container Orchestrator Controller and Container Orchestrator Worker and the Infrastructure behind, provision new nodes, set up, upgrade, and troubleshoot the orchestration run-time for you, backup data for you on daily basis or your custom schedule and even take care of the best run-time configuration for each of your applications.
By using a Managed Container Orchestrator, you get these advantages:
-
Very few clicks for provisioning
-
Less platform administration overhead, more time and resources for business applications
-
Higher scalability and availability since the computing resources on the cloud platform are optimized and effectively used.
-
Less cost. Do not have to pay for ownership fee. Only pay for the computer resources you use instead of wasting resources on idle cycles.
-
Be 24/7 supported by platform experts.
-
Integration with more cloud features and services, better application quality, and more opportunity for having a better customer experience.
With managed services, you can focus more of your resource efforts on the application rather than spending time and effort on managing and troubleshooting the platform. So except we have particular purposes to self-host the Orchestrator; for example, to utilize available infrastructure for development or testing, Managed Orchestrator Service is really worth option to be considered.
4. More about Managed Orchestrator Service
4.1 Level of managed service
We have two levels of managed orchestration service:
-
Level 1 – Managed Controller Orchestrator: The service provider provides the Kubernetes Infrastructure and Control Plane components (such as API, DB, Storage, and Network plugins, Core DNS, authentication, load balancing, scaling mechanism, etc.) and maintains them for you. You control the Cluster Size, the Compute Nodes and Kubernetes configuration, the Permanent Volume, the Container Networking then the Applications and how to deploy them or scale them. There are Google GKE, Azure AKS, or Amazon EKS as Managed Kubernetes Orchestration tools. At this level, a limitation is the transition from small scale in Docker Swarm to larger scale in using Managed Container Orchestrator Service can be complicated to manage.
-
Level 2 – Fully Managed Orchestrator: The service providers provide everything except your application. It includes the infrastructure, control plane, worker nodes, and workload management on them as well as other as other external important services such as Permanent Volume. You manage your application only. There is no concern for Kubernetes controller node, worker node or backup the etcd configuration etc. This option is also called “Serverless Container Orchestrator” as I mentioned earlier. Sun Spinner in Sun Cloud supports this approach.
Unlike the level 1 only work best at a large scale, the level 2 group works perfectly at any scale. Whether small-scale or enterprise application, there are no differences if the level 2 is used. Using the Serverless Container Orchestrator at the beginning, you will have a smooth transition from small to larger scale. We have that benefit because the orchestration administrative or how to scale the cluster is no longer concerned at this level. In general, there is no worry about changing the orchestration configuration or orchestration infrastructure when the application scale changes.
Figure 6: Different Levels: Self-hosted – Managed Orchestration Controller – Fully Managed Orchestration
4.2 Which Managed Service is better?
It still depends on your team, your product and your business strategy, and specific orchestration products. I will only introduce a good option that supports the Level 2 of Managed Service: Sun Container Spinner, or in short name Sun Spinner.
Beside a fancy GUI dashboard with a lot of important add-on features such as application run-time history, service rollback — roll forward or fast service publishing and so on, one advantage of Sun Spinner is that it is tightly coupled with the broader Scalable Application Platform ecosystem.
For example, if you’re really into the Sun Cloud ecosystem, build an Event-Driven System that sends events through Pub/Sub Message Brokers as Sun Highway to other components.
If you then want to attach your infrastructure or services on Sun Cloud to Sun Spinner or find a bridge to connect parts of the application with Sun Spinner, you’ll have many configuration options in Sun Spinner compared to a standalone Managed Kubernetes Controller solution. You can easily pass data and orchestrate work between different Spinner instances, calling Spinner functions, feeding data back into a Sun Virtual Machine, or other services in the same Sun workspace.
This way, you can create an excellent ecosystems of Sun Cloud Products. Like these following use-case examples:
E-commerce Use-case Example:
Figure 7: Example use-cases: E-commerce that has Sun Highway and Sun Spinner co-existing
IoT Use-case Example:
Figure 8: Example use-cases: IoT that has Sun VM and Sun Spinner co-existing
So, if you are building containerized systems where the containerized part is just one piece of a broader Sun Cloud ecosystem, Sun Spinner is a reasonable choice.
However, if you’re trying to isolate all your application components into a closed system without connecting them to other services, then a managed Kubernetes is the tool to consider.
In any other case, whether you are already familiar with Kubernetes or not, Sun Spinner could help you make progress and achieve productivity even better than Kubernetes. In general, Sun Spinner is easier to learn than Kubernetes. If you were starting from scratch at a point of Container Orchestration zero-knowledge, you could become a Sun Spinner expert in 1/4 the time it would take you to become a Kubernetes expert. And by Sun Spinner, you can enable a large-scale application two times faster than Kubernetes, with a 15%-50% lower cost.
Figure 9: Sun Spinner Container Architecture
>> Schedule a demo today to learn more about how Sun Spinner helps you achieve these results.
>> See more Sun Cloud product pricing
>> Trial free Sun Cloud products and get more promotions when creating a new account
Chau Nguyen (Charles)
Chief Technology Officer
CTO Chau Nguyen started his high-tech development career in Singapore in 2007. In 2015 he started building Cloud technologies and platform for US market then consulted technology transformation solutions for various companies, including famous brands as logistic startup Logivan in their micro-service re-architecting, Mobifone carrier in MobiEdu education platform scaling up or Electrolux in E-commerce global scaling solution.