Most IT organizations like to think of themselves as continuously improving. The best ones constantly invest in building new skills, deploying new infrastructure, acquiring new tools, creating new processes, or even tuning what they already have in order to wring more efficiency and productivity out of their environments. Many are migrating to the cloud, as cloud service providers (or CSPs) cheerily advertise three, four or even five 9s of availability (e.g., 99.999% uptime).

Disaster recovery involves planning for the worst so organizations can quickly bounce back from a disruptive event. To prepare for hardware failure, power outages, human error, natural disasters — or whatever type of disaster life has in store — companies should put together a disaster recovery plan that identifies risks and outlines steps to mitigate them. For example, to minimize downtime, companies might regularly back up important data and set up redundant offsite infrastructure.

Over the years, automation has become a key component in the management of the entire software release lifecycle. Automation helps teams get code from development into the hands of users faster and more reliably. While this principle is critical to your source code and continuous integration and delivery processes, it is equally essential to the underlying infrastructure you depend on.

Enterprise IT and ISV developers are intrigued by technology benefits of containers and Kubernetes. However, when they go with a recommendation to their senior management to containerize applications, one question is asked – Why do we need to containerize? Didn’t we rehost our application to the cloud?

In the last few years, the primitive and conservative world is vanishing. In its place is emerging new world whose base is science and technology. The DevOps community has been flourished due to microservices and containerization-based architecture. According to 451 Research, container technology such as Docker and Kubernetes will eventually face the fastest growth in contrast with other cloud-enabling technologies, with an estimated CAGR of 40% through 2020.

Containers provide a nifty solution to package up applications along with their dependencies, and for the whole encapsulated process to be run on a host system. This technology is undeniably popular due to its ability to allow developers to create flexible, scalable, reliable solutions in a quicker amount of time. It has enabled more freedom in choosing the technology we use in our applications and has brought development and production environments closer to parity.

While there are plenty of articles aiming to instruct newbies on “how to become a DevOps engineer”, none of them answer a simple question – should you become one to start with? For me, it’s been a long and winding journey to becoming what is called a Site Reliability Engineer (SRE). The journey was unplanned, and for each step, I had to figure out what I want my next challenge to be and how to achieve it.

As containers and orchestrators have surged in popularity, they have created highly dynamic environments with rapidly changing workloads—and the need for equally dynamic ways of monitoring them. After all, orchestration technologies like Kubernetes, DC/OS, and Swarm manage container workloads both at the node level and at the cluster level, which means that you need to gather insights from every layer to fully understand the state of your infrastructure.