Bahubali Shetti

As more and more applications convert to cloud native with Kubernetes as a normalizing layer the ability to have portability between public clouds also becomes easier. Theoretically, the app can now move easily between AWS/Azure/GCP. However, a couple of issues are always in the back of developer’s minds:  Do I connect to cloud services like ML/AI, DevOps tool chains, DBs, Storage, etc? This might lock me in. Should I roll my own database or use a cloud services like CosmosDB, Azure Postgres DB, etc.

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 and multiple methods to help build and manage them. There are many Kubernetes choices to deploy your containerized application:

Microservices give us as developers an incredible amount of freedom. We can choose our language and we can decide where and when to deploy our service. One of the biggest challenges with microservices, though, is figuring out how things go wrong. With microservices, we can build large, distributed applications, but that also means finding what goes wrong is challenging. It’s even harder to trace errors when you use a platform like AWS Lambda. As good developers, we write our unit tests and integration tests and we make sure those tests all pass.

Managing deployments into the public cloud requires a strong set of guardrails to ensure low cost, efficient utilization, highly secure and efficient use of resources. With the constant change in features and capabilities on the hyperscalers (AWS/Azure/GCP) the CI/CD becomes the main control point to manages these guardrails. We discussed how to “shift left” day 2 operations into CI/CD using “Continuous Verification” in a previous blog In any public cloud operations process there are multiple pipelines managing different aspects of the the environment.

As more and more applications convert to cloud native with Kubernetes as a normalizing layer the ability to have portability between public clouds also becomes easier. Theoretically, the app can now move easily between AWS/Azure/GCP. However, a couple of issues are always in the back of developer’s minds:  Do I connect to cloud services like ML/AI, DevOps tool chains, DBs, Storage, etc? This might lock me in.  Should I roll my own database or use a cloud services like CosmosDB, Azure Postgres DB, etc.

In managing applications deployed on Kubernetes, developers have a significant number of options to choose from. These options cover both open source, and commercial options and cover three main categories: Metrics — are a numeric representation of data measured over intervals of time. And you can use mathematical modeling and prediction to derive the behavior of the system over an internal of time - either present or the future. Hence, metrics are useful for monitoring but more powerful when enabled with analysis mechanisms such as correlation and anomaly detection.

As we’ve discussed in multiple blogs on this site, our application of choice has always been the AcmeShop App. It has multiple services, some of which are also DBs, redis and mongo. We built this app to show case multiple services, and to keep the application portable. Hence the inclusion of Mongo and Redis in the app as a Kubernetes service. While this architecture is fairly typical for test/dev environments, its not typical with regards to production environments.

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.

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.