1. Reliability: You need to have a discussion with the various stakeholders of the service: Developers, Product Managers, Sales, etc., about the expected uptime to define SLAs and about the expected performance may be to define SLOs.

2. Visibility: Discussion around the logs, metrics, and monitoring is imperative as they enable the measurements around the service.

3. Performance: It is necessary that a baseline of expectations is set and met while taking a service into production so the room for improvement can be defined early on in this journey. It also helps while setting up alerts if the performance tanks.

4. Capacity Planning: How much capacity would be required to meet the performance expectations or traffic estimates? Can we refer to any other service to decide the capacity for this one? Is it within our budget? These questions simplify a lot of discussion around capacity.

5. Emergency Response: Through books and experience, I learned the cardinal rule of being an SRE - no matter what, something might go wrong, and your service will fail. So it is best to define the firefighters. A couple of developers and SREs on-call with good training and documentation make the emergency response process much more manageable. And without the emergency response plan, you should not consider taking a service to production.

6. Change Management: This directly impacts your SLA, so you need to define how frequently new changes would be pushed and how to handle the service during the changes. There are various approaches to change management that you should look up.

7. Security: Based on the type of business or service, some security standards might need to be met. So, ensure that everything is clear in that dimension.

This is not an exhaustive checklist of everything that you should do while taking a service live, but it is a good baseline that I was able to chalk out through this article and my personal experience.

• HSTS Lookup

• • The HSTS list consists of sites that require HTTPS only to access them. Google maintains such a list remotely, and a copy of the list remains on the browser that is updated frequently.

    * When the request is made from the browser, it first checks if the host is present in the HSTS list. If the host is found, then the request is made using port 443; otherwise, the request is made using port 80.

    * HSTS can also be configured as a header on the server or the application. The use of HSTS is to protect against SSL Stripping Attacks, which is a form of a man-in-the-middle attack.

• DNS Lookup

• • In the DNS lookup, the browser first checks the local cache. If it is not found in the local cache, it checks for any entries in the local hosts file of the operating system.

• ARP Lookup

• • If the entry for the host is not found in the local hosts file, the browser needs to check outside and get the IP of the server hosting the website. To do this the computer sends an ARP request.

    * First, the ARP cache is checked for the IP address of the router and its MAC address, if it is not there, then an ARP request is broadcast to the network.

    * First, the computer sends an ARP request to the router to get its MAC address. The router responds with the MAC address. This MAC address, along with the IPv4 of the router, is then used to create an ethernet frame to send the IP packet to the router.

    * The router then uses its routing table to forward the packet to the gateway server. In this step, the browser just needs the IP of the gateway or the DNS server. Once it gets the IP of the DNS server, it opens a UDP connection on port 53 with a source port greater than 1023 (basically from the ephemeral port range) to get the IP of the target server.

• DNS Resolution

• • First, the browser makes a query to the local resolver or the gateway to check for the host entry in their cache.

    * If the gateway server doesn’t have it, then it makes a DNS query to the root servers that have the entries of the TLDs. (There are 13 root servers).

    * These TLDs then further point down the tree to the authoritative or the recursive nameservers. Once the query reaches the authoritative nameservers, the SOA is reached, and the A record returns the IP address of the target server.

• TCP Handshake

• • Once the browser receives the IP address of the target server, it takes the port number from the URL based on the HSTS result and starts the process of creating a TCP socket stream.

    * First, the request is sent to the Transport layer, where the TCP segment is crafted, and the destination port, source port, etc., is added to the header.

    * Then the segment is sent to the Network layer, which wraps an IP header. The IP address of the destination server as well as the sender.

    * Then the segment is sent to the Data Link layer, where the MAC addresses of the NIC and the gateway are added, and the packet is now ready to be sent.

    * Once the packet reaches the local subnet, from there, it travels through Autonomous Systems border routers using Border Gateway Protocol. In BGP, the routers figure out the smallest path to reach the destination server, and communication between the AS routers is based on trust.

    * So once the packet reaches the destination server, the TCP handshake starts. One important feature is the TTL field which is decreased by one every time a packet reaches a router. If the TTL field reaches 0, the packet is dropped.

    * The handshake happens as:

    * * The client chooses an Initial Sequence Number and sends SYN to the server to indicate its intent to connect.

    * The server then chooses its own ISN and indicates it wants to connect by sending an SYN-ACK packet. Meanwhile, it increases the client’s sequence number by 1.

    * The client acknowledges the packet, increases the ISN by 1, and sends the ACK packet.

• TLS Connection

• • After a TCP connection is established between the client and the server, the client initiates the TLS connection by sending a ClientHello message to the server along with acceptable cipher suites and the TLS version. (this happens only if HTTPS is requested)

    * The server replies with a ServerHello message and also sends the cipher suites, TLS version, compression methods, Certificate, etc. The certificate contains the public key.

    * The client verifies the certificate against some trusted CAs. If trust is established, it generates some random bytes, encrypts them using the public key, and sends them to the server.

    * The server decrypts the random numbers using the private key and generates a symmertic key using the random bytes sent by the client.

    * The client and the server exchange the change_cipher_specs if there are any to agree on a cipher suite.

    * Finally they exchange the finished message and from here on forward, the data exchanged is encrypted using the symmetric key.

• HTTP Protocol

• • Now to access the webpage, the browser starts HTTP to fetch the webpage.

    * The browser sends the HTTP request which contains the Port, URL, Headers, and HTTP version to the server.

    * The request reaches the external most point of the target network and is usually handled by a load balancer. The load balancer then forwards the request to the internal application server.

    * Once the request reaches the server, it breaks down the request components into

    * * Request Method

    * Request Path

    * Request Headers

    * IP, etc.

    * The server, which can usually be something like Nginx or Apache serving maybe a PHP or a Python application, talks to the application through FPM or WSGI. These components help retrieve the webpage and send the response to the server, which in turn sends the response back to the client.

    * In the response, the server includes Headers, HTTP Status Code, HTTP Version, etc.

• Web Page Construction

• • The browser collects the CSS, JS, or HTML files and builds the DOM that eventually builds the webpage in the browser.

Do check out - https://github.com/alex/what-happens-when

On the internet, various networks are called Autonomous Systems (AS). These ASes belong to various ISPs or Network Providers or Companies like Verizon, Xfinity, Google, Facebook, etc. Their interconnection makes up the internet around the world. These ASes have numerous routers at the borders of their network, which spans the globe.

The border router of the ISP sends the request to another border router of an AS, and it goes forward and reaches the destination using the smallest path. What happens is that each router uses BGP to figure out the smallest path to the destination and sends the request accordingly to the next router.

Eventually, the request reaches the network that is hosting the website, and BGP is used to route the request to the specific server that is hosting the website. BGP is also used to route the response back to the user's browser, following the same path in reverse.

In summary, BGP plays a critical role in determining the best path for network traffic to travel between different networks on the internet, including when a user tries to access a website in a browser.

A stateful set is a Kubernetes object that manages a set of pods that need to maintain persistent storage. The StatefulSet ensures that each pod in the set has a unique identity and that the pods are always started in the same order.

A StatefulSet is a Kubernetes object used to manage stateful applications. It is designed to manage stateful applications by creating and managing a set of replica Pods, each of which has a unique network identity and persistent storage. Each Pod in a StatefulSet is created sequentially, and each Pod is assigned a unique hostname that is based on its position in the StatefulSet.

StatefulSets are useful for running stateful applications such as databases, key-value stores, and message brokers, where each instance has a unique identity and requires persistent storage. StatefulSets can provide stable network identities and persistent storage for these applications.

Here is an example scenario where a StatefulSet can be used:

Let's say you have a stateful application like a database that requires a specific amount of storage and a specific network identity. You want to run this application on Kubernetes to take advantage of its container orchestration capabilities, but you also need to ensure that the application's data is stored persistently and that each instance of the application has a unique identity.

In this scenario, you can use a StatefulSet to manage the database instances. The StatefulSet will create and manage a set of replica Pods, each of which has a unique network identity and persistent storage. Each instance of the database will be created sequentially and will have a unique hostname based on its position in the StatefulSet.

An example of a StatefulSet configuration file is as follows:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: database
spec:
  serviceName: database
  replicas: 3
  selector:
    matchLabels:
      app: database
  template:
    metadata:
      labels:
        app: database
    spec:
      containers:
      - name: database
        image: your-database-image:latest
        ports:
        - containerPort: 5432
        volumeMounts:
        - name: database-storage
          mountPath: /var/lib/postgresql/data
  volumeClaimTemplates:
  - metadata:
      name: database-storage
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 10Gi

A daemonset creates one pod on each node and ensures that it stays running as long as the node is available. When a new node is added to the cluster, the daemonset controller creates a new pod on that node. When a node is removed from the cluster, the daemonset controller automatically removes the pod from that node.

DaemonSets are a powerful tool that can be used to ensure that essential services are running on every node in a cluster. They are also useful for running applications that need to be installed on every node, such as logging and monitoring daemons.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd
  namespace: kube-system
spec:
  selector: #Should only manage pods with labels app: fluentd
    matchLabels:
      app: fluentd
  template: #Specifies the configurations of the pods
    metadata:
      labels:
        app: fluentd
    spec:
      containers:
        - name: fluentd
          image: fluent/fluentd:v1.3
          volumeMounts:
            - name: varlog
              mountPath: /var/log
          resources:
            limits:
              memory: 200Mi
            requests:
              cpu: 100m
              memory: 100Mi
      volumes:
        - name: varlog
          hostPath:
            path: /var/log

In this example, we're using a daemonset to run Fluentd, a popular logging agent, on every node in the cluster. The selector field specifies that the daemonset should only manage pods with the app: fluentd label, and the template field specifies the configuration of the pods.

In the containers section, we define a single container that runs the fluent/fluentd:v1.3 image. We also mount the host's /var/log directory into the container so that Fluentd can collect logs from the node. Finally, we specify resource limits to ensure that Fluentd doesn't consume too much CPU or memory on each node.

With this configuration, Kubernetes will automatically create a Fluentd pod on each node in the cluster and ensure that it stays running as long as the node is available. If a node is added or removed from the cluster, the daemonset controller will automatically adjust the number of pods to match the desired state.

• Control

Deployments give you more control over the deployment process. You can specify how the pods are updated, and you can roll back to a previous version if necessary.

• Scalability

Deployments are more scalable than replication controllers. They can be used to deploy large applications with multiple replicas.

• Features

Deployments have more features than replication controllers. They support rolling updates, blue-green deployments, and canary deployments.

Here’s what a deployment can do that a replication controller cannot

• Rollout updates. A deployment can be used to roll out updates to a running application in a controlled manner. This can be done using a rolling update, blue-green deployment, or canary deployment.

• Rollback updates. If an update to an application fails, a deployment can be used to roll back to the previous version of the application.

• Monitor the health of the application. A deployment can be used to monitor the health of the application and to automatically restart pods that are not healthy.

• Scale the application. A deployment can be used to scale the application up or down based on demand.

• Configure the application's environment. A deployment can be used to configure the application's environment, such as the amount of memory and CPU that is available to the application.

• Deploy the application to multiple clusters. A deployment can be used to deploy the application to multiple clusters.

Companies can optimize this selection by considering various factors such as server load, price, region restriction, quality of content, packet loss, etc. So after considering these factors, the DNS server of the CDN refers to the edge location closest to the user, and that's how the request is served from the closest edge location.

To know more..

Autonomous System Numbers are assigned to Local Internet Registries (LIRs) and end-user organizations by their respective Regional Internet Registries (RIRs), which in turn receive blocks of ASNs for reassignment from the Internet Assigned Numbers Authority (IANA).

The purpose of autonomous systems is to allow for the efficient routing of traffic on the Internet. By grouping networks together into ASes, network operators can control how traffic is routed within their ASes and to other ASes. This helps to ensure that traffic is routed in the most efficient way possible and that congestion is avoided.

The ASN is a 16-bit or 32-bit integer that is assigned to the AS by a Regional Internet Registry (RIR) or the Internet Assigned Numbers Authority (IANA). ASNs are used in Border Gateway Protocol (BGP) routing, which is the protocol used to exchange routing information between different Autonomous Systems on the Internet.

ASNs are important in network engineering and internet infrastructure management, as they help to identify and manage routing policies and interconnections between different Autonomous Systems. By exchanging routing information via BGP, Autonomous Systems can route traffic between each other and ensure efficient and reliable communication on the Internet.

Here are some examples of autonomous systems:

• Google's AS is 15169.

• Facebook's AS is 15189.

• Microsoft's AS is 16384.

• Amazon's AS is 16509.

• AT&T's AS is 701.

• Verizon's AS is 702.

Fun Fact: BGP is facilitated by the routers of these ASes. So imagine you have a Verizon FIOS and accessing Facebook. Your request when it reaches at the "Border" of the Verizon's AS, the last router runs BGP to find the shortest path to the AS of Facebook. So this shortest path can mean it will pass through the AS of XFinity, or Google or University of Maryland, etc. But after hopping from the border routers of these ASes, the request will reach facebook.

The HSTS Preload list is a centralized list maintained by Google, of which every browser usually maintains a local copy that is regularly updated. The websites need to submit to Google to get added to the HSTS preload list. The recommended max-age is two years if the preload directive is also being used.

HSTS is particularly important as it forces HTTPS. It also helps save clients from MITM attacks. There are still scenarios when HSTS fails to protect from MITM, but to avoid that, don't connect to WIFIs you don't know or trust.

• SLI stands for Service Level Indicator (basically metrics). These are the metrics that are used to measure the performance of a service. For example, an SLI might be latency, RPS, etc.

• SLO stands for Service Level Objective. It is a target value for an SLI (basically, what are the limits for my metrics). For example, an SLO might be that the website should be able to process 100 requests per second.

• SLA stands for Service Level Agreement. It is a contract between a service provider and a customer that specifies the level of service that the customer can expect to receive. The SLA will typically include the SLOs that the service provider is committed to meeting. So when AWS says that S3 has an SLA of 99.999999999% for durability, it means that for a period of a year, S3 is making a commitment to you that of all the data that you store in S3, 99.99...% of the objects will be available, and AWS takes the responsibility of ensuring that it meets the agreement.

  \>> AWS also mentions the penalty it is liable to if the SLAs are not met

The SLI, SLO, and SLA are all important parts of service-level management. The SLI is used to measure the performance of the service, the SLO is used to set targets for the performance, and the SLA is used to communicate the level of service to the customer.

Here is an example of how SLIs, SLOs, and SLAs might be used in a real-world scenario. A company might have an SLA with its customers that guarantee 99.9% uptime. The company might then set an SLO of 99.95% uptime. To measure uptime, the company might use an SLI that measures the number of minutes that the website is unavailable each day. If the website is unavailable for more than 0.05% of the day, the company will be in breach of its SLA and will have to pay penalties to its customers.

SLIs, SLOs, and SLAs are all important tools for managing the performance of services. By understanding these terms and how they are used, you can help to ensure that your services are meeting the needs of your customers.