Amit Tayade Thoughts on QA | SDET

    The most widely used tools in the modern cloud-native container ecosystem are Docker and Kubernetes . These two open platforms have enabled the container revolution to thrive, thanks to the utility they provide and the openness of their communities. Though often used together, Docker and Kubernetes accomplish different goals. This difference is foundational to understanding how modern containers are built, deployed and managed in production. The increase in container adoption has risen in parallel with the rise of microservices. Containers are a helpful way to package software for these applications as they isolate code with all dependencies necessary for runtime. But as the number of containers rises, managing them at scale becomes a hurdle. Thus, DevOps engineers often implement standard tools to generate containers and orchestrate their deployment to maximize efficiency and resource optimisation. For those readers with short attention spans, the TL;DR is that  Docker is about bu

  The challenge of how to work with different release cadences eventually hits every microservice-based application. Some microservices will be updated more frequently than others which leads to uncertainty about the compatibility between different versions. How quickly this happens depends on the size of the development teams. Initially the team members can keep the knowledge in their heads and there is a hidden manual check to prevent incompatible versions from being released. However, as teams grow or people simply take vacations, the uncertainty builds until those checks fail and there is an incident that forces a change. Kubernetes Deployments for an Example E-commerce Application Depending on the maturity of the development teams, the incident may be a production outage caused by an incompatible version of a microservice being released. Or simply one too many failed integration tests and broken builds. Typically, the next move is to formalise the existing informal processes. Maki