Apperati.io

Application development and deployment have come a long way over the years. From manual processes to scripting, to full Continuous Integration and Continuous Deployment (or Delivery) processes along with pipelining tools. Using CI/CD has helped automate and streamline application development and deployment processes. It has also helped improve the general operations process. GitOps (Infrastructure updates via pull request, while using Git as the source of truth for all configurations) helps continuously manage not only the application configuration but also the business and operations configurations governing the application and the resources its using.

This post represents an interesting departure for me. Typically, I cover technical topics related to applications, Kubernetes, and portions of the “cloud native” world. In this piece, however, I’d like to address an issue much more steeped in people and process concerns; cloud operations. My colleagues and I spend quite a bit of time interacting with administrators and operators representing a wide variety of organizations. Whether these conversations begin with a particular set of technologies or projects, the discussion inevitably turns to the differences in operating across public cloud and software-as-a-service environments.

Deploying applications into the cloud is the norm. Majority of these applications are landing on AWS, GCP or Azure. In addition, more and more of these applications are also using containers and utilizing Kubernetes. Kubernetes is becoming more mainstream and the “mainstay” in many organizations. Adoption is growing, as are the number of options for Kubernetes. There are many Kubernetes choices to deploy your containerized application: Custom deployment solutions - from VMware Essential PKS, Kubespray, VMware Enterprise PKS, Stackpoint, etc.

Cloud Native applications have become a norm these days. Developers and Operations engineers are continuously finding ways to improve the quality and speed of deploying and maintaining these applications. It started with folks writing bash scripts, migrating to python like scripting and then over to configuration management and infrastructure as code tools. The philosophy behind these Infrastructure as Code and Configuration Management tools is to treat your infrastructure as programmable assets. That also means use of version control systems like Git.

In a previous blog we discussed the configuration and use of fluentbit with AWS elasticsearch. https://medium.com/@bahubalishetti/configuring-fluentbit-on-kubernetes-for-aws-elasticsearch-bec486bcc727 It helped provide a basic configuration of “logging” from a Kubernetes cluster. “Logging” is one aspect of “Observability” in Kubernetes. Lets review: Observability for the cluster and the application covers three areas: Monitoring metrics — Pulling metrics from the cluster, through cAdvisor, metrics server, and/or prometheus, along with application data which can be aggregated across clusters in Wavefront by VMware.

As noted in one of my earlier blogs, one of the key issues with managing Kubernetes is observability. Observability is the ability to gain insight into multiple data points/sets from the Kubernetes cluster and analyze this data in resolving issues. As review, observability for the cluster and application covers three areas: Monitoring metrics — Pulling metrics from the cluster, through cAdvisor, metrics server, and/or prometheus, along with application data which can be aggregated across clusters in Wavefront by VMware.