Lalit Kale lalitkale

Availability Availability is the proportion of time that the system is functional and working. It is usually measured as a percentage of uptime. Application errors, infrastructure problems, and system load can all reduce availability.

A cloud application should have a service level objective (SLO) that clearly defines the expected availability, and how the availability is measured. When defining availability, look at the critical path. The web front-end might be able to service client requests, but if every transaction fails because it can't connect to the database, the application is not available to users.

Availability is often described in terms of "9s" — for example, "four 9s" means 99.99% uptime. The following table shows the potential cumulative downtime at different availability levels.

99% 1.68 hours 7.2 hours 3.65 days

ECS Role Types

Host Role

When running ECS on EC2, the EC2 instances hosting the containers need a role. This role gives them permission to, among other things, pull images from ECR, manage tasks in the ECS API, and put logs into cloudwatch.

Task Execution Role

When running in Fargate, there are no EC2 instances hosting your containers, so these permissions have to go somewhere. This is called a Task Execution Role. It gives the Fargate service the same permissions the EC2 instance would need. This role is not required when running tasks on EC2 backed ECS.

ECS Service-Linked Role

This is a role used by the ECS service itself to perform functions such as managing load balancer configuration, doing service discovery, as well as attaching network interfaces when using the awsvpc network mode. There is only one of these per account.

Async Await Best Practices Cheat Sheet

Summary of Asynchronous Programming Guidelines

Name	Description	Exceptions
Avoid async void	Prefer async Task methods over async void methods	Event handlers
Async all the way	Don't mix blocking and async code	Console main method
Configure context	Use `ConfigureAwait(false)` when you can	Methods that require context

Just documenting docs, articles, and discussion related to gRPC and load balancing.

https://github.com/grpc/grpc/blob/master/doc/load-balancing.md

Seems gRPC prefers thin client-side load balancing where a client gets a list of connected clients and a load balancing policy from a "load balancer" and then performs client-side load balancing based on the information. However, this could be useful for traditional load banaling approaches in clound deployments.

https://groups.google.com/forum/#!topic/grpc-io/8s7UHY_Q1po

gRPC "works" in AWS. That is, you can run gRPC services on EC2 nodes and have them connect to other nodes, and everything is fine. If you are using AWS for easy access to hardware then all is fine. What doesn't work is ELB (aka CLB), and ALBs. Neither of these support HTTP/2 (h2c) in a way that gRPC needs.

Official Exam Links & Resources

The Exam Itself

Official Exam Links & Resources

	# 1. export bookmarks
	# 2. awk -f cbdd.awk bookmarks_12_4_16.html > uniq.html
	# 3. import uniq.html

	BEGIN { FS = " " }

	$2 ~ /^HREF/ {
	if (!($2 in seen)) {
	seen[$2]
	print $0

	I have run an nginx container...

	docker ps
	CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
	6d67de07731d nginx "nginx -g 'daemon ..." 40 minutes ago Up 40 minutes 80/tcp, 443/tcp epic_goldberg

	I want to use Debian for debug:
	docker run -it --pid=container:6d67de07731d --net=container:6d67de07731d --cap-add sys_admin debian

	I can see the nginx process:

	1. Monolithic applications and architectures can vary in their monolithness. This is an under-specified description.
	2. Microservice applications and architectures can vary in their microness. This is an under-specified description.
	3. Microservices and monolithic architectures have both benefits and disadvantages.
	4. Organizations will exploit those benefits while working around any weaknesses.
	5. Success of the business is a large influence on the exploitation of benefits and implementation and costs of workarounds.
	6. All benefits and work arounds are context-sensitive. Meaning that they are both technically and socially constructed by the organization that navigates them.
	7. Path dependency is a thing. History matters and manifests in these architectural decisions and evolution in an organization.
	8. Patterns exist to inform practice, not dictate it. Zealous adherence to an architectural pattern brings peril when it is to the exclusion of cultural context in actual practice.
	9. Architectural patterns w

	namespace Analogy
	{
	/// <summary>
	/// This example shows that a library that needs access to target .NET Standard 1.3
	/// can only access APIs available in that .NET Standard. Even though similar the APIs exist on .NET
	/// Framework 4.5, it implements a version of .NET Standard that isn't compatible with the library.
	/// </summary>INetCoreApp10
	class Example1
	{
	public void Net45Application(INetFramework45 platform)