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 ...

  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. ...

 What is Sharding? Sharding is a database architecture pattern related to horizontal partitioning — the practice of separating one table’s rows into multiple different tables, known as partitions. Each partition has the same schema and columns, but also entirely different rows. Likewise, the data held in each is unique and independent of the data held in other partitions. It can be helpful to think of horizontal partitioning in terms of how it relates to vertical partitioning. In a vertically-partitioned table, entire columns are separated out and put into new, distinct tables. The data held within one vertical partition is independent from the data in all the others, and each holds both distinct rows and columns. Should I Shard ?  Whether or not one should implement a sharded database architecture is almost always a matter of debate. Some see sharding as an inevitable outcome for databases that reach a certain size, while others see it as a headache that should...