Monolithic architectures are the result of the continued growth of modern applications’ size and complexity. When apps were small, things such as eliminating bugs or adding new features, updating the UI or UX, or implementing additional security were projects that were done by the same team. There would be a central repository that housed all of the code for all of the business’s needs all in one place. As applications grew, the different responsibilities begin to be assigned to individual teams with specific roles and functions. These individual teams have specific roles, but they still need to operate on the same centralized codebase which leads to cross-team dependencies and the potential for code that is unable to merge. The introduction of microservices promises to eliminate the work that crosses over between teams by separating the application into independent services that work together, with each service providing a specific function. The most beneficial aspects of this architecture are rapid scaling, increased reliability, and faster development times.

Managing your microservices

Containers are used to provide the essential layer of isolation between microservices. Orchestration tools developed to control how multiple services would run in multiple containers became a requirement as the complexity of applications and the interactions between their services in the cloud grew. As of now, Kubernetes is the only container orchestration solution that is available natively from Amazon (AWS EKS), Microsoft (AKS), and Google (GKE), the three biggest cloud service providers. Increased reliance on cloud services for deploying applications has been paralleled by an increase in the use of OSS due to the flexibility, reliability, and transparency that these projects provide. Kubernetes is the most popular project of the open source standards body CNCF and has shown to be the clear leader of orchestration tools.

The benefits of a microservices approach to your architecture does not come without cost. An application may require many, many services including proprietary services from third parties and/or OSS projects. Individually, these services may be simpler to manage, or in the case of third party and OSS it may be up to others to manage them, but the interconnected way that all of them behave and operate together may be very complex. Not only can a Kubernetes solution be difficult to implement, it can also be difficult to update and debug. That is what makes your choice of which CI tool to use so important. You want a CI tool that allows you to use Kubernetes right out-of-the-box with all of the services that you already use.

Faced with a common problem

With CircleCI’s orbs, you get that out-of-the-box solution for the most important services in your pipeline. Orbs are reusable, shareable, open source packages of CircleCI config that enable the immediate integration of these services. They allow for a crowd-sourced solution to common problems. Our focus here is on the orbs that do major operations such as deploying to GKE, but others allow for things like sending custom Slack notifications about your project. The key benefit is that you have access to all of these services without having to learn to integrate them yourself. To send a custom Slack notification to USERID1 after logging in to GCP, building and deploying a Docker image, and then rolling that image out to a GKE cluster, one only needs to update their .circleci/config.yml by importing the Slack and GCP-GKE orbs:

    slack: circleci/slack@x.y.z
    gke: circleci/gcp-gke@x.y.z

Then running a slack/notify command in a job after gke/publish-and-rollout-image with the required parameters:

  - build
  - gke/publish-and-rollout-image:
      deployment: k8s-deployment-name
      container: container-name
      image: image-name
  - slack/notify:
      mentions: ‘USERID1’
      message: ‘deployment to GKE’

While a savvy senior DevOps engineer may be able to script this functionality into the configuration of their CI tool of choice, CircelCI’s orbs eliminates that development and replaces it with a community supported integration that is working and tested. The slack/notify command is over 125 lines of code by itself. The entire Slack orb is almost 500 lines. No team using CircleCI will ever have to write that code themselves.

CircleCI orbs are the simplest way to use Kubernetes. Do you just want to install kubectl or kops? The Kubernetes orb can install those for you. Are you using Kubernetes to deploy to GKE? In the example above, I showed how one could achieve this easily with the GCP-GKE orb. Maybe you are using Helm for your Kubernetes deployments. We have the Helm orb for doing just that. Regardless of how you are using Kubernetes, CircleCI is the only CI tool that can get you up and running quickly so that you can spend your time developing your project and not your deployment pipeline.

What you can do

Are there additional features that you would like to see from a current Kubernetes orb? Since orbs are open source, you can add functionality to an existing orb by getting your PR approved and merged. You could also create an issue and see if there is community support for the development. Do you have a use case that you feel stands apart from the current set of Kubernetes orbs? You can author one yourself and contribute it to the community. We’ve even published best practices for creating automated build, test, and deploy pipelines for orbs (part 1 and part 2) to help you along your way. Check out all of the available orbs in the Orbs Registry.

Microservices allow your team to take advantage of third party services and OSS, eliminating the need for in house development of these common tools and resources. With orbs, your team only needs to know how to use those services, not how to integrate or manage them.