Our Operating Principals

We are the DevOps tools team, and we operate a number of stateful services, including:

• GitLab (AWS)

• Artifactory (K8s+AWS)

• Jira (K8s+AWS)

• Confluence (VMWare)

• Nexus (VMWare)

• Bitbucket (VMWare)

Like you, we are passionate about automating our service deploys in order to achieve high service availability.

yac evolved from our service operating principals, which include:

• maximize service availability by

  • minimizing operator toil

  • maximizing code reuse

  • leveraging the engineering platform

  • minimizing external dependencies and risks

• maximize team productivity by

  • minimizing external dependencies

  • making best practices easy to consume

• minimize service costs

• maximize state integrity and durability

Principals Alignment

yac aligns nicely with our operating principals by the following measures:

• Because yac allows your complete pipeline to be configured instead of coded/scripted, including:

  • artifact builds (e.g. container images and AMIs)

  • stack templates (e.g. k8s or aws)

  • integration tests (e.g. artillery or custom)

  • pipeline stages 

  • recurring tasks (e.g. api calls)

• Because yac makes is easier to minimize cost

  • companies like us use a hybrid cloud approach to minimize costs

  • yac workflows are the same for all cloud providers

  • cost estimates are provided in build dry runs

• Because yac satisfies the 100% pipeline use case

  • incorporate python code for complex pipelines

  • easy to add support for new cloud providers, artifacts types, etc.

• Because yac was designed for DevOps teams

  • there are a lot of orchestration tools (ansible, chef, puppet, etc)

  • most are IT-centric rather than DevOps-centric

  • tool metaphors matter, and yac metaphors are pipeline driven

• Because portable is better

  • running a service in your namespace should be as easy as running a container on your desktop

  • yac lets you share your services so others can instantiate them from a registry

• Because yac knows all about Nordstrom's engineering platform
  
  

  • native support for all tools in the engineering platform including:

    • Kubernetes Clusters

    • AWS Cv2

    • Gitlab, including runners and registry

    • Artifactory repos

    • Datadog metrics and alerts (coming soon)

    • Hashicorp vaults (coming soon)

    • JIRA releases (coming soon)

    • ServiceNow changes (coming soon)

  • simplifies authentication in kubernetes and aws

• Because your pipelines should work the same on your desktop as they do on your CI/CD server

  • yac and all of your development tools are packaged in a container

  • the yac cli is a shell function

  • allows seamless pipeline promotion from desktop to build server

  • removes build server dependency

• Because yac minimizes the need for documentation

  • Servicefile object defaults contain most of the details of engineering platform services

  • yac provides a native inputs engine

    • the engine allows service providers to prompt service consumers for inputs

    • the result is prompted service installs

• Because you are paranoid and only the paranoid survive!
  
  

  • you've been burned before on CI/CD systems

  • when you bet on yac, you are betting on python

  • yac is written in python and any custom scripts that your service build needs are written in python

  • yac leverages python client libraries that are available for all cloud providers

  • e.g. pykube for kubernetes api, boto3 for aws api calls, hvac for hashicorp vault, etc..