Snapchat re-architecture
From Monolith to Microservices….
A monolith is one single big fat service containing all the code and serving all the requests. Whereas, microservice-based architecture consists of many small services interacting with each other or even with outside requests.
2. The first question is why they wanted to do this shift.? As the snap engineering team started to grow, different engineering teams wanted to function independently, They wanted to own architecture and also limit the blast radius in an outage.
3. This was not an easy task. There were many elements of their underlying infrastructure that needed to be considered: network topology, authentication, cloud resource provisioning, deployment, logs, metrics, traffic routing, rate limiting, and staging vs. production environments.
4. They brainstormed a layered architecture to achieve the above. It encompassed networking, identity, provisioning, deployments, separation of business logic from infrastructure via Docker containers, and orchestration via Kubernetes.
5. But, as simple as it sounds, the task is not that simple. If you create multiple services, you need to take care of each of the service’s configurations. How will they interact with each other? Security controls for each service.
6. To make their tasks simple, they started using Envoy, an open-source framework developed by Lyft and now used across multiple different organizations. They created a service mesh with Envoy as a sidecar container running alongside the main service and handling all the communications between services. All the requests that came went through the envoy, ensuring security. Also, this helped in easy configuration management for different services discovery.
7. Envoy would enforce TLS and publish metrics on all inbound and outbound traffic. Through this, they could guarantee that all requests between services were secure and observable.
8. They wanted to minimize the number of services that are exposed to the Internet. This gives the first level of defense in the event of vulnerabilities, similar to what on-premises network topologies achieve with physical firewalls. They designed a shared, internal, regional network for our microservices. Services within the same region can communicate without going over the public Internet. No external traffic source could communicate directly with the internal network. In each region, only a single system would be deployed exposed to the Internet: API Gateways. All the external calls would come through it and then be routed to the required service.
_
Subscribe to my youtube channel: https://lnkd.in/eS-vkqi3
