Containers

Virtualization environment for running applications.
Bundles apps + operating system + runtime.
Run on top of a host operating system like VMs.
- But unlike VMs, containers don't include an operating system for the apps running inside the container.
  - A container doesn't use virtualization
- Instead, containers bundle the libraries and components needed to run the application and use the existing host OS running the container.
  - Those not waste resources simulating virtual hardware with a redundant OS.
    - You can run multiple isolated applications on a single container host.
    - Much more lightweight than VMs.
      - Allows you to quickly respond to changes in demand or failure
  - E.g. if five containers are running on a server with a specific Linux kernel, all five containers and the apps within them share that same Linux kernel.
The container orchestrator can start, stop, and scale out application instances as needed.
- Faster than VM (seconds instead of minutes)
You can use same server to host multiple container applications
- They are secured and isolated
More efficient than VM
- Run containers side by side without sacrificing isolation.
- Much smaller in size
- Development process is simplified. Dev env = prod env.

Containers in Azure

Orchestration = The task of automating, managing, and interacting with a large number of containers
Azure Kubernetes Service (AKS) is a complete orchestration service for containers
You can migrate existing apps to AKS e.g. :
1. Convert an existing application to one or more containers and then publish one or more container images to the Azure Container Registry.
2. Deploy the containers to an AKS cluster using the Azure portal or the command line.
3. Azure AD controls access to AKS resources.
4. You access SLA-backed Azure services, such as Azure Database for MySQL, via OSBA.
5. Optionally, AKS is deployed with a virtual network.

Most popular option for managing container-based workloads
Combines container management automation with an API
Cloud-native: Can run across different clouds
Pod management
- A pod is a group of one or more containers that share the same network namespace and can communicate with eachother via 'localhost'
- 1 pod = 1 or more containers on a node
  - If node is removed = Kubernetes move affected workloads to different node.
- If one pod crashes = Kubernetes creates new instance
- Pods can be scaled manually or automatically (horizontal)
Spreads deployment to minimize downtime
- If update is problematic, it can roll-back
Can manage storage
- Persistent volumes to represent data storage to one or more containers
- Data can be persisted across many pod instances
- Can utilize cloud-based storage and data system e.g. Azure storage + Cosmos DB
Can manage networking
- Can expose pods to internet
- Load balances traffic across multiple replicas of a pod
- Network isolation
- Policy-driven network security.
- Manage communication + name resolution between pods
It can be extended with additional capabilities
- E.g. cloud events on pod creation, custom pod scheduling logic, on-demand provisioning of managed cloud services.

Architecture where you break solutions into smaller, independent pieces.
Allows you to separate portions of your app into logical sections that can be maintained, scaled, or updated independently.
Each service has small code-base that can be managed by a small development team.
Don't need to share same technology stack, libraries or frameworks.
- Each team can choose the right tool for the job.
- Single development team can test & build & deploy a service
Results in continuous innovation and faster release cadence.
Smaller scope =
- Easier to understand code-base
- Easier for new team members to get started
Each micro-service is completely autonomous with no cross-dependencies.
- Provides fault isolation: If one goes down, it does not take out all application
Communicates with each other using Application Programming Interface (API)
- APIs encapsulate internal functionality.
  - Internal implementation details of each services are encapsulated behind their interface.
- 💡Good practices:
  - Reduce interdependencies
  - Introduce orchestration / management layer in the higher level consuming application to coordinate calls and combine results.
💡 Good for:
- High release velocity
- Highly scalable applications
- Applications with rich domains / subdomains
- Organizations with small development teams

Allows each microservice to be deployed independently of every other microservice.
A team can update an existing service without rebuilding/redeploying the entire application.
They can easily roll back & roll forward & update if something goes wrong.
Makes bug fixes + feature releases more manageable & less risky
Allows each microservice
- to be scaled independently
- persist own data & external state without common repository layer
E.g. one for front-end, one for back-end and one for storage.
- If back-end reaches capacity but not others, you can scale it individually.
- Allows you replace storage microservice without affecting rest of the application.