The second important process in a secure system architecture is authorization, aka AuthZ. In the digital world not just the end users have an identity but the services also do. With the introduction of the OAuth 2.0 standards we have defined ways of implementing authorization in our systems. As always, my story is going to be a little different from then normal!. You will get to see a flow which involves 3 flavors of AuthZ.
The most common version is the one that involves the end-user authenticating with an Identity System, completing the authorization by providing consent or rights to the client that he/she uses to reach the resource server. Common clients used in this flow are the apps that run in your browsers and smart phones. With the advancements in the cyber security to battle all the latest attacks, the implicit-grant flow has been marked as a “Do-Not Use” variation in OAuth and is said to be obsolete(at least according to the latest RFCs). …
The stories of high availability and horizontal scaling of services to handle millions of transactions depend on a service — The Load Balancer.
The Load Balancer can be one at the edge (L4 or L7) or can be internal (ILB).The Traffic Manager services are considered to be Load Balancers as well but for geographically spread targets. The Load balancer fronts any service that needs to scale-out, aka horizontal scaling. This load balancer is again a system in the cloud that does a specific work of efficient routing based on a load-balancing algorithm. Have you ever thought in the lines of “the load balancer can handle only so much. Its just a machine, an IO optimized one, may be. …
There would probably be thousands of articles about K8s to date. You may ask — What would this story be about then? :) This story would be all about my appreciation for the architecture and system design of Kubernetes.
All the people that have started the k8s journey would have figured out the components of the master plane and the worker plane. Less do we know about
Some of the Microsoft-Azure developers might have used Azure Managed Identities and the rest might not have. Do you know what happens behind the scenes when you enable “Managed Identity” for a service?
Lets use a couple of scenarios to set the stage for this topic.
This story is in continuation to the previous one in this series. Let us continue comparing a few other architectural aspects of the distributed systems.
Kafka - Scaling the Kafka topic can be done by adding more brokers/partitions to the kafka topic. Each broker is a separate Virtual Machine instance that can handle the message broker work. This will help is increasing the throughput and handling spike in traffic.
Note: Zoo-keeper is supposed to keep track of all active partitions after scaling. This helps in distributing the traffic after the scale-out is completed.
Cassandra — Scaling in a Cassandra cluster means adding more shards to the ring (more DB servers/instances) to the cluster. The newly added set of nodes would now store some of the primary shards of data (in addition to any replicas). …
In my quest to explore the internals (the architectural aspects) of three of the famous distributed systems there are in today’s world, I spent a solid 2 days just to compare and contrast the architectural decisions. Why not share these amazing learning with you folks??
Disclaimer — I am not going to get into the depth of the below listed concepts. I have shared relevant links that can help if you are new to these topics.
3 distributed systems that form an integral part of a majority of the cloud native architectures today
A distributed Message broker (Kafka), a distributed database (Cassandra) and a distributed cache…