techthumb

https://docs.aws.amazon.com/bedrock/latest/userguide/bedrock...

I've often noticed that these boundaries are not considered when carving out microservices.

Subsequently, workarounds are put in place that tend to be complicated as they attempt to implement two phase commits.

https://www.nasdaq.com/press-release/nasdaq-completes-migrat...

  It helps standardize:
    - deployments of containers
    - health checks
    - cron jobs
    - load balancing

Is it same/similar across teams within and outside your organization.

If not, what would it cost to build consensus and shared understanding?

How would you build this consensus outside your organization?

For small organizations, one should do whatever makes them productive.

However, as soon as you need to standardize across teams and projects, you can either build your own standards and tooling or use something like K8S.

  Once you have K8S, the extensibility feature kicks in to address issues such as:
   - Encrypted comms between pods
   - Rotating short lived certificates

However, if not K8S then, what alternative should we consider to build consensus and a shared understanding?

From a moat perspective, I wonder if the TAM of this business in the context of the three cloud providers is substantial.

Their stock price is back down to reasonable levels.

Perhaps they'll remain a niche player in the market?

    #!/bin/sh

    set -e

    if [ -n "$VERBOSE" ]; then
      set -x
    fi

    if [ "$1" = "--show" ] && [ $2 = "twitter" ]; then
      echo "https://twitter.com/teaxyz_"
    elif [ -n "$1" ]; then
      # Hi, I know you’re excited but genuinely, pls wait for release
      # I added this so I can do CI :/
      case $(uname) in
        Darwin) suffix=macOS-aarch64;;
        Linux)  suffix=linux-x86-64;;
        *)
          echo "unsupported OS or architecture" >&2
          exit 1;;
      esac

      if [ "$1" = "brew" ]; then
        d="$HOME"/.tea/bin
        mkdir -p "$d"
        curl https://tea.xyz/dist/tea-$suffix -o "$d"/tea
        echo "$d" >> $GITHUB_PATH
      else
        mkdir opt
        curl https://tea.xyz/dist/tea-$suffix -o ./opt/tea
        chmod u+x ./opt/tea
        shift
        ./opt/tea "$@"
      fi
    else
      echo
      echo "418 I’m a teapot"
      echo
      echo "thanks for your interest in tea."
      echo "alas, we’re not quite ready to serve you yet."
      echo
      echo "while you wait why not follow us on Twitter:"
      echo
      echo '    open $(sh <(curl tea.xyz) --show twitter)'
      echo
    fi

From https://incoggo.com/faq/

  If you’re a very security-minded individual (or you use your computer for very sensitive tasks), before using Incoggo you may want to be aware that the application does the following:

  Upon installation, Incoggo adds a file to your system’s sudoers.d folder that whitelists specific commands from requiring a sudo password to perform. (This allows Incoggo to manage your system proxy settings, kill certain processes on shutdown / restart, and perform tasks related to Incoggo’s auto-updating feature without requiring that a sudo password be prompted each time.)

  Incoggo loads external Javascript files when you visit specific domains (i.e. those we filter paywalls / clear cookies on / clear storage on / etc.).

  Incoggo overwrites a few system defaults (re: open page / process limits) at runtime for performance reasons.

  Upon installation, Incoggo also installs a trusted root certificate in your system keystore. This is required for Incoggo’s advanced filtering functionality to work (unlike the issues above – which we intend to clean up shortly – this one is a hard requirement for the app to work).

The conflating part here is that using the callback as a mechanism to imply subscription.

This works for your situation.

However, if you need to start making multiple backend calls, then, you will likely need to separate the authentication part from the subscription part.

Generally, OAuth implies that the requirement is to get authenticated by a provider and making multiple subsequent calls to some backend. Additionally, the backend will verify the authenticity of the short-lived token before allowing the operation to proceed.

The title of the article says OAuth, and hence assumed that you wanted an authenticated client to be able to make the call to the backend for subscribing.

  ... one might think implementing OAuth sign up is relatively trivial; after all, you just need to write a fetch request that redirects the user to the OAuth page, then another request that sends their email to the newsletter service of choice to sign them up. Well, the issue is that in order to do the second step of that process, one needs to hit an API endpoint that requires authentication (an API key). That is essentially a password and not something you want to expose on the front end and give everyone access to.

This article Auth0 does a good job of explaining PKCE: https://auth0.com/docs/authorization/flows/authorization-cod...

I recommend https://www.peplink.com/products/ap-one-ax/

Minikube sets up a Linux VM using MacOS Hypervisor.

It even has a convenience command to configure docker-cli/docker-client.

  $ minikube docker-env
    export DOCKER_TLS_VERIFY="1"
    export DOCKER_HOST="tcp://192.168.65.11:2376"
    export DOCKER_CERT_PATH="/Users/wibble/.minikube/certs"
    export MINIKUBE_ACTIVE_DOCKERD="minikube"

  $ minikube start --embed-certs

  $ docker pull hello-world@sha256:7d91b69e04a9029b99f3585aaaccae2baa80bcf318f4a5d2165a9898cd2dc0a1

Available options:

  --driver='': Driver is one of: virtualbox, parallels, vmwarefusion, hyperkit, vmware, docker, ssh (defaults to auto-detect)

Minikube sets up a Linux VM using MacOS Hypervisor.

It even has a convenience command to configure docker-cli/docker-client.

  $ minikube docker-env
    export DOCKER_TLS_VERIFY="1"
    export DOCKER_HOST="tcp://192.168.65.11:2376"
    export DOCKER_CERT_PATH="/Users/wibble/.minikube/certs"
    export MINIKUBE_ACTIVE_DOCKERD="minikube"

  $ minikube start --embed-certs

Also, one of these timer based lock boxes may help: https://www.amazon.com/s?k=lock+box+timer+for+phone

In my experience, being at either extreme becomes counter-productive.

To me, it comes down to finding the "happy middle" for your project.

Monolith v/s Micro-services/Serverless are similar. Neither extreme is productive. There exists a happy middle depending on the situation.

But, the price tag of US$69.99 doesn't justify its value for my use case of diff and merge in git.

BRK plans to, and has the capacity to hold on to their investments while their valuation has dropped.

However, if one had a million dollars sitting in the bank, it may not be prudent to dollar cost average. Portfolio management and a time horizon are necessary to achieve the desired mix

Learning tends to be inefficient. You do have to put in the time.

Working with people who have experience in the field will save time as they will be able to guide along the way.

Articulating what you have learned to someone will re-enforce your understanding.

> An open source, batteries-included, multiplayer dedicated game server scaling and orchestration platform that can run anywhere Kubernetes can run.

It is specific to setting up game servers. However a lot of the concepts are likely to be applicable to setting up a new environment per customer/user etc.

https://agones.dev/