Nowadays, LoadBalancing is one of the basic needs for the application systems to perform optimally while considering some important factors like- scalability and high availability. Every cloud is providing LBaaS (LoadBalancing as a Service) as an offering so the consumers don’t have to worry about the setup and management of load-balancers by themselves.
But it’s not like that cloud is offering a single type of load balancer for every use case because for different use-case we require a different type of load balancer. For example- we have different load-balancers for Layer4 and Layer7 level traffic.
Recently AWS had a new family member in their load-balancer family and they named it “Gateway Load Balancer“. So gateway load-balancer is a load-balancing service provided by AWS to send traffic to the different appliances, applications, firewalls, etc. that are not part of the current VPC.
Continue reading “AWS Gateway LoadBalancer: A Load Balancer that we deserve”
MongoDB is a popular NoSQL database that supports large as well as small size of datasets. Just like any other database standalone setup, MongoDB is straightforward but we have to make a replicated or shared cluster of MongoDB, and there we have certain complications. Especially if we are doing these kinds of setups in orchestration tools like Kubernetes.
There is a lot of complexity in setting up MongoDB on Kubernetes that people(including me) have faced for a long time which I would like to highlight:-
Continue reading “MongoDB Setup on Kubernetes using MongoDB Operator”
- Standalone setup is pretty straightforward but for replicated and sharded clusters additional mongo configurations are required.
- In the replicated scenario, separate configurations need to be managed for the leader and follower.
- Monitoring and access management of MongoDB inside Kubernetes is a little tricky part to handle.
We are living in the microservice era, where we have a number of applications to support a business model. But our application success cannot be determined by the features only, it should have a scalable model as well. Otherwise, something like this would happen:-
When we generally talk about the scaling in the microservices, people think that applications that are running inside Kubernetes as containers. Since Kubernetes has its own method of autoscaling using the metrics-server, we don’t have to worry about the scaling of the applications inside it.
Continue reading “Autoscaling in Nomad Cluster”
Initially, we had the DevOps framework in which Development and Operation team collaborated to create an “Agile” ecosystem. But nowadays a lot of people are talking about the “DevSecOps” realm in which people do not treat security as an afterthought instead of that people are inculcating security in their development and operation practices.
Continue reading “Introducing Kubernetes Vault Web-hook”
Whenever someone says orchestration for microservices, the first thing that usually comes to mind is Kubernetes. I believe that’s normal. I used to think the same but then I came across an interesting scenario that changed the way I used to think about microservice orchestration completely.
Usually, people think microservices mean containers, hence they build their application in a cloud-native approach so that it can easily run on any platform using the containerized approach. Well, I agree that containerization is a decent way of designing a cloud-native application especially when we integrate it with orchestrators like Kubernetes or OpenShift. It takes away a lot of overhead from us like:- scaling, failover, deployment, etc but it doesn’t imply that microservices can only be managed inside a containerized ecosystem. Microservice is an ideology or mindset for designing the application and containerization is a power-up that supports the ideology.
Continue reading “Running Non-containerized Microservices”