devopsy.kinsta.cloud

Tag: self-healing applications

Decoding the Self-Healing Kubernetes
A business application that fails to operate 24/7 would be considered inefficient in the market. The idea is that applications run uninterrupted, irrespective of a technical glitch, feature update or a natural disaster. In today’s heterogeneous environment where infrastructure is intricately layered, a continuous workflow of application is possible via self-healing.

Kubernetes, which is a container orchestration tool, facilitates the smooth working of the application by abstracting machines physically. Moreover, the pods and containers in Kubernetes can self-heal.

In the Avengers movie, Captain America asked Bruce Banner to get angry so he could transform into The Hulk. Bruce replied, “That’s my secret Captain. I’m always angry.” You must have understood the analogy here. Let’s simplify: Kubernetes will self-heal organically, whenever the system is affected.

Kubernetes’s self-healing property ensures that the clusters always function at the optimal state. Kubernetes can effectively self-detect two types of objects—podstatus and container status. Kubernetes’s orchestration capabilities can monitor and replace unhealthy containers as per the desired configuration. Likewise, Kubernetes can fix pods, which are the smallest units encompassing single or multiple containers.

The Three Container States Include
1. Waiting: created but not running. A container, which is in a waiting stage, will still run operations such as pulling images or applying secrets, etc. To check the waiting pod status, use the following command:
  
  Along with this state, a message and reason about the state are displayed to provide more information.
2. Running Pods: containers that are running without issues. The following command is executed before the pod enters the running state:
  
  Running pods will display the time of the entrance of the container.
3. Terminated Pods: a container that fails or completes its execution. The following command is executed before the pod is moved to terminated:
  
  Terminated pods will display the time of the entrance of the container.
Kubernetes’ Self-Healing Concepts – Pod’s Phase, Probes and Restart Policy

The pod phase in Kubernetes offers insight into the pod’s placement. We can have:
- Pending Pods–created but not running.
- Running Pods–runs all the containers.
- Succeeded Pods–successfully completed container lifecycle.
- Failed Pods–minimum one container failed and all containers terminated.
- Unknown Pods.
Kubernetes execute liveness and readiness probes for the pods to check if they function as per the desired state. The liveness probe will check a container for its running status. If a container fails the probe, Kubernetes will terminate it and create a new container in accordance with the restart policy. The readiness probe will check a container for its service request serving capabilities. If a container fails the probe, then Kubernetes will remove the IP address of the related pod.

Liveness probe example:

The probes include:
- ExecAction–to execute commands in containers.
- TCPSocketAction–to implement a TCP check w.r.t to the IP address of a container.
- HTTPGetAction–to implement a HTTP Get check w.r.t to the IP address of a container.
Each probe gives one of three results:
- Success: The container passed the diagnostic.
- Failure: The container failed the diagnostic.
- Unknown: The diagnostic failed, so no action should be taken.
Demo Description of Self-Healing Kubernetes

We need to set the code replication to trigger the self-healing capability of Kubernetes.

Let’s see an example of the Nginx file:

In the above code, we see that the total number of pods across the cluster must be four.

Next, let’s deploy the file.

Let’s list the pods, using:

Here is the output:

As you see above, we have created four pods.

Now, let’s delete one of the pods.

The pod is now deleted. We get the following output:

Let’s list the pods again.

We get the following output:

We have four pods again, despite deleting one. Kubernetes has self-healed to create a new node and maintain the count to four.

Conclusion

Kubernetes can self-heal applications and containers, but what about healing itself when the nodes are down? For Kubernetes to continue self-healing, it needs a dedicated set of infrastructure, with access to self-healing nodes all the time. The infrastructure must be driven by automation and powered by predictive analytics to preempt and fix issues beforehand. The bottom line is that at any given point in time, the infrastructure nodes should maintain the required count for uninterrupted services.
May 12, 2020
How AI and Microservices Create a Reliable Enterprise of the Future
The Rise of Microservices

Enterprise adoption of microservices is continuing to rise. Its popularity is so strong that 86% of development professionals internationally expect microservices to become the default application architecture within the next five years. Looking out even longer, nearly all professionals see microservices becoming their company’s default application architecture.

At its core, a microservice approach centers on the idea of breaking up complex enterprise software into smaller, more manageable pieces, containing everything from the operating system to the platform to the framework to run time and dependencies, packaged as one unit of execution.

By dividing an application into smaller stand-alone services, each performing a single function and communicating over the network to work together, microservices offer increased modularity and make applications easier to scale and faster to develop. In a world of ever-increasing apps, websites and digital experiences, there are immense benefits to deploying microservices.

However, the use of microservices is no silver bullet and, for all their benefits, they have their own limitations and challenges. When it comes to deploying microservices, scale, complexity and constant change are the new realities. Microservices architecture introduces complexity with respect to network latency, network communication, load balancing, fault tolerance and message formats. With great flexibility also comes a higher risk of something slipping through the cracks. Managing many services requires understanding deep structures, dependency graphs and more.

Process scalability is another challenge. An enterprise can run one cloud-based service with relative ease, but simultaneously running dozens of services across multiple clouds quickly becomes a complicated juggling act. In fact, with all the moving parts that come with microservices, it is becoming increasingly difficult to manage these processes manually.

No wonder that, along with the rise of microservices, we have seen the emergence of auto-remediation/self-healing capabilities. To the untrained eye, the terms auto-remediation and self-healing would seem to be the answer, but don’t be fooled. Many of these features, although making the management of microservices easier, use static thresholds for data points such as waiting time, throughput, message queue size and more. When the thresholds are passed, the system will correct or self-heal as necessary. Although helpful, they’re not necessarily smart or intelligent—and that is where AI can help.

Advanced Self-Healing and Self-Defense

AI can help solve some of the hardest problems facing microservices today. Below are a few achievements we’re already seeing AI accomplish:
- Load Prediction: Understanding the load on the system and acting on it before it happens will allow systems to provision more resources before they’re needed. Provision of resources is not just limited to the network and number of tasks running; AI can trigger customer support representatives to be on hand when—and only when—needed.
- Decay Detection: Anomaly detection is built into a lot of monitoring services and is efficient at detecting spikes, loads and abnormal behaviors; however, detecting a service decay, even gradual or subtle, is difficult. AI can help systems recognize whether services are reacting differently over time and what the reasons are for this decay. It also has the potential to be more effective in identifying bugs based on studying clusters of microservices having continuous issues.
- Resource Planning: As the scale and complexity of microservices grows, so does the use of the cloud. The ability to plan ahead using smart resource management could save significant costs while maintaining a stable and robust service.
- Security: Security is already leveraging AI in many places by discovering attack patterns based on known behaviors. Leveraging these capabilities at the network and database level can improve security for actions done by an authorized person. If you can understand the usage patterns and act on them, you can define a more secure system for all users.
Benefits aside, using AI is not without pitfalls. For example, despite all its potential, the so-called state-of-the-art AI models are still quite primitive when compared to what they have the potential to achieve. Another issue is how to manage the possibility of bias creeping into AI models to avoid unintended consequences. Technology professionals are already working on ways to solve these complications. However, it will take time to develop the right models, data sets and algorithms.

The Future

If the future of application architecture is truly to be dominated by the ever-increasing use of microservices, then those architectures will need to also be dominated by AI. The reality is microservices are simply becoming far too complex for humans to manage on their own effectively. Because of the dynamic nature of their structure, their complex dependencies and their sheer scale, machine learning must be applied to assist with monitoring and management tasks. AI is best suited to meet this challenge and tackle it head on.

— Martin Henley
September 24, 2019
9 Essential Ingredients for Modern Enterprise Applications

Digital transformation. It’s the latest in a series of buzz phrases intended to describe how enterprises are embarking on top-to-bottom modernization of their IT environments. It’s easy to see why it’s a hot topic. Emerging technologies including cloud, containers, microservices and distributed applications hold the promise of greater flexibility, lower cost and faster release cycles. The benefits to companies that make this journey can be enormous.

Unfortunately, making this journey can take years with today’s manual processes and antiquated tools. Not to mention that most IT budgets are at least 80 percent focused on keeping the lights on. Application modernization projects can be extremely complicated since legacy, monolithic enterprise applications are intrinsically dependent on underlying infrastructure and data stores. Cloning complex application environments, including critical production data, for upgrades or testing often can take days or weeks, slowing down cycles and contributing to lower quality releases. Even new applications are too often designed with infrastructure dependencies, trapping organizations onto specific cloud, server or container vendors. This vendor lock-in reduces choice and leaves IT organizations open to unexpected price hikes down the road.

The truth is that the way we have designed, built, deployed and managed enterprise applications needs to change. Business-critical software is too often built in monolithic blocks that are nearly impossible to move to new infrastructure or storage options without lots of effort and time. The applications are hard to upgrade since updating even one small portion means rebuilding and retesting the entire thing. Managing the various versions of the discrete application modules and the resulting testing permutations can be quite challenging. It’s not unusual to hear from CIOs that they feel trapped in a world where they can only reasonably expect to update critical enterprise applications just twice a year at most.

Business needs to move faster. There’s no reason why release cycles, even for enterprise applications, couldn’t be every few days instead of months. Application quality should actually be better in this world. Continuous delivery models such as DevOps should be an integral part of the process. And security should not be an afterthought; it should be built-in. To accomplish this, the future of enterprise applications must look very different from today.

What are the essential ingredients for modern enterprise application platforms and tools in this new world? Here are a few suggestions.

Complete Portability, Without Code Change

Enterprise applications must be abstracted and separated from any dependency on underlying infrastructure, including sources of data. By abstracting the functions of an application into components that can run anywhere, it’s possible to then move the application to different infrastructure combinations, without changing a single line of code. It’s only through complete portability between cloud environments, container tools and servers that IT organizations will break vendor lock-in and gain the flexibility required to move their applications to vendors that offer the best combination of price, performance, reliability and features.

On-Demand

All enterprise applications should be on-demand, meaning the provisioning of new instances should be hands-free and fully automated. This implies tight integration with orchestration tools that most companies are already using to provision infrastructure. The key difference here is that the provisioning of storage options also needs to be fully automated. This is made possible by the fact that modern applications won’t have any dependencies on the specific data stores they rely on. This on-demand nature is not restricted to technical teams but includes business users that can easily perform user acceptance testing by simply provisioning full-fledged application environments.

Self-Healing

Modern enterprise applications should be self-healing, which means applications not only should have measurable data points to define their health but can then react based on these metrics. They must be able to scale up (or down) based on performance characteristics up to a certain cost threshold, restart on a healthy node in case of infrastructure bottlenecks and cache or deploy closer to the user based on latent use performance.

Composable (DevOps-friendly)

All enterprise applications should consist of a number of building blocks: APIs, web servers with content, databases seeded with data, security policies, the operating system, network configurations, deployment configurations and application binaries. By breaking apart monolithic enterprise applications into smaller components that can then act as independent services, IT organizations gain the flexibility to upgrade and automatically deploy individual components through standard DevOps processes and orchestration tools. The services can run anywhere desired, giving flexibility of choice in infrastructure or sources of data. And developers can use a point-and-click UI to pull pre-defined components together to build larger functions of an application.

Model, Snapshot and Clone

Once an application is separated into its essential components, a catalog can be maintained that makes it easy to create new versions of the application. Developers, test engineers and DevOps teams can then pick and choose whatever combinations of components they need to create or clone complex application environments for testing or deployment. The state of the application environments can be snapshotted, cloned and replicated. This cloning process should be efficient and quick. This dramatically speeds up development and testing processes, which to-date have been largely manual.

Scalable

Scaling application and infrastructure environments automatically, on-demand, and in near real-time is one of the essential capabilities that makes modern infrastructure so valuable. Any solution that is used to develop, test, deploy and manage enterprise applications should offer these same capabilities, giving the ultimate in cost flexibility, performance and scalability. As containers are moving quickly from the lab into production environments, look for a container-based solution that complements this strategy.

Security is Included

Application security should not be tacked on after deployment. This slows down continuous delivery processes like DevOps and creates friction between development/ops and the security team. Instead, security should be considered an essential component of the overall application environment and treated the same as any other component and baked into the application from the start.

Push-Button Upgrades

Upgrading enterprise applications should be made much easier by taking a point-and-click, push-button approach through a modern UI and integration with continuous deployment tools. Once an application is blueprinted into its various components, using a modern UI to choose versions and assemble the final application becomes entirely possible, saving time and reducing manual errors.

Single-Pane-of-Glass Application Management

By taking an end-to-end view of the enterprise application development, testing, deployment and management process, it’s now possible to create a “single pane of glass” console that gives development and deployment teams a powerful way to manage what’s been deployed to various infrastructures in the organization. With this approach, it’s also now possible to collect invaluable utilization and cost metrics which can help an IT organization continuously improve their portfolio.

Enterprise applications of the future are going to look very different from today’s monolithic behemoths. By leveraging new technologies and processes, IT organizations will be able to dramatically speed up their modernization efforts and release cycles, improving competitive position. The inherent cost savings of this approach will be transformational as well, as IT budgets shift toward net-new innovation, not just keeping the lights on. The future looks bright indeed.

About the Author / Rahul Ravulur

Rahul Ravulur is the cofounder and CEO of appOrbit, which was founded in 2014. Most recently, he was the Director of Product Management at VMware managing the Availability suite of products. Before that, Rahul managed the vCenter Server and Client set of products with a special focus on scalability and extensibility to chart the evolution of vCenter to a broad virtualization management platform. Prior to VMware, Rahul held engineering leadership roles at BMC Software and Marimba.

August 10, 2017