Container orchestration is a great way to deploy microservices, but typically we need other services like distributed and often stateful systems such as Apache HDFS, Cassandra, Jenkins, or TensorFlow.
These services have multiple different components that are more tightly coupled than microservices and often have requirements for persistence. A typical environment must support many different services, each with its own set of dependencies. As time goes on and a business scales, the number of services rapidly escalates—even for simple scenarios. In fact, even when working in cloud environments, where services are simple to use, the expenses can become massive over time with large amounts of data. Service orchestration helps cut costs and increase time-to-value as your business grows.
However, orchestrating multitudes of services through the entire service lifecycle in a high-availability and elastically scalable manner is no easy task.
Let’s dig into a use case example for service orchestration.
Continuous Integration/Continuous Deployment (CI/CD) is the process of integrating code from individual developers into a shared repository, and then building and testing that code. CI relies heavily on automation to make integration a simple, repeatable process. The demand for implementing a CI/CD process is increasing as business complexity increases.
The services required to operate a CI/CD infrastructure are a great example of the tangled web of complexity that is growing in datacenters and cloud providers every day.
CI/CD is a critical cluster of services for managing applications across their lifecycle. CI/CD is core to DevOps and most developers are accustomed to working with at least a portion of these tools. The CI/CD process is worth understanding because it is widely implemented as a core component of well-run and efficient IT shops.
The services involved in a basic CI/CD setup include:
- Source Code Control: You need to store your source code somewhere. People often use GitHub (an external cloud service), but in case you want to keep the code in your own datacenter (e.g., for data privacy reasons) you might prefer GitLab for storing your code.
- Build and Test: After a developer has committed her code into the source code control system, she needs a build and test pipeline to ensure the code meets quality criteria. Jenkins and/or Spinnaker are common tools here, but also GitLab offers support.
- Release Artifacts: After the code has been build, the artifacts need to be stored. Artifacts can be stored either as jars or binaries in an artifact store such as JFrog Artifactory, or as a container image stored in a container image registry.
- Deploy, Monitor, and Log: Last, but not least, you need to serve and operate the build artifact. Here, container orchestration tools, such as Kubernetes and Marathon, are very powerful options. In a production environment, you should also include additional services for logging and metrics, such as Prometheus and ElasticSearch.
As you can see, we need at least four to six different services to run a production-grade CI/CD pipeline. It’s easy to see how the management burden of deploying, configuring, scaling, securing, patching, etc of every service quickly adds up.
To learn more about the importance of service orchestration, download our latest eBook “How to Evolve From Container Orchestration to Service Orchestration.”