AWS

With more and more applications using public cloud (AWS/Azure/GCP) and the ever changing number of features services that are available on these hyperscalers, how do you maintain a stable process of deploying and managing resources and applications in the public cloud? We know that most enterprise companies have a shift in organizational boundaries to start and “Grapple” with this shift. That shift is a segmenting of their IT organization into two distinct parts Traditional IT - tasked with managing “on-prem” data centers and usually requires the individual in this organization to have a balance between HW and SW knowledge and skills.

In a previous blog we reviewed how to create and manage EKS Clusters on AWS. Apperati.io. In particular we discussed: How to use a simple tool from Weaveworks eksctl to setup and use EC2 nodes, network, security, and policies to get your cluster up. Providing access to the EKS cluster and how to use a easy but non-scalable configuration to provide access (modifying aws-auth configmap in the EKS cluster). Showcased Day 2 operations with respect to cost and utilization, security in AWS, and observability.

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.