Thursday, 16 May 2019

jax devops 2019 Day 2

Program

Rip it up and start again

Sam Newman

Books

  • Monolith To Microservices
  • Building Microservices

independent deployability key element of microservice devisions.

Architectures often aligned to different goals to microservice independent deployment

Contention between teams slows us down.

Vertical slice focused around business domain - slice may including range of tech, e.g. FE, BE, DAO instead of component based on tech (layered architecture)

Code Ownership - Martin Fowler

Collective ownership - flexible working ; retaining product and technical alignment? ; Business alignment? ; co-ordination ; scale? (breaks down with larger teams) => struggles with scale ; easier to achieve global consistency.

Strong ownership (Services owned by teams) - clear lines of ownership ; increased autonomy ; easier tech / business alignment ; bottlenecks? ; orphaned services? (e.g. team vanishes) ; local vs global => local optimisation problem

Steve Yegge's platform rant

Explicit service interface - define communications between teams / services.

Iterating orphaned service - 100+ service organisations tend to have a service registry => source code ; maintainers.

Local optimisation - does it make sense for an organisation to support several types of databases, even though each service might have local preference - e.g. mongo vs oracle vs cassandra

Would you know this local choice / global divergence is happening? Cross service communications.

Co-ordination between teams helps to assign appropriate priority to work - e.g. something that would benefit many.

Incremental journey to microservice architecture. Pushes issues into operational space. Incremental lessons.

Distribution of responsibility, lining up with what business is trying to get done. Anchor ground level work against business goals.

Getting Started with Terraform

Lorenzo Galelli

Terraform

Challenges ; Consistent deployment methods ; planning ; execution ; collaboration ; knowledge share

DevOps principals - CAMS Culture ; Automation ; Measurement ; Sharing

Terraform K8S provider

Automate all things ; version control ; CI / CD ; infrastructure as code

brew install terraform

"tf" files => json state files

variables.tf => define variables

main.tf => define provider ; bind variables ; define resources - e.g. data center, public LAN, private LAN

resource "myprovider_mytype" "myresourcename" {
  name              = "myname"
  # ...
}

provisioner with local-exec to exec commands

tf file can be split into ordered list of files - e.g. 10-infrastructure.tf, 20-wordpress.tf, 30-redis.tf

(note that dependencies can also be specified to control order of execution)

terraform init
terraform plan
terraform apply
terraform show
terraform graph | dot -Tpng > graph.png

Example configuration files

plan => aggregate what is going to be created

providers

In Search of the Perfect Cloud-Native Developer Experience

Automate inner dev loop

Draft vs Gitkube vs Helm vs Ksonnet vs Metaparticle vs Skaffold

draft ; gitkube ; Skaffold ; Tilt ; Garden

Helm ; Ksonnet - define k8s manifest ; Telepresence - enables local-to-prod development ; Squash

Develop and test services locally or within the cluster

Bring the cloud to you vs Put you in the cloud

Observability in production

Monitor Synthetic transactions

Canary testing - launching and only send a proportion of traffic to new release

What is a service mesh

Envoy for Managing L7 Traffic

Ambassador API Gateway

Canary gotchas - Observability - SLIs, SLOs and KPIS - pre-requisites. Watch for side effects, e.g. canary deploying DB change, breaking old services.

Service virtualisation (Hoverfly)

Observability UX - Kibana

Guard rails - offer platform, but allow service teams freedom and responsibility. Lay paved road, allow to team but diverge with responsibility. RBAC ; Kritis - e.g. only deploy images certified by QA team. Cert manager.

Where to focus -

  • Prototype - inner development loop / run locally & CI/CD
  • Production - observability & scaffolding (codify best practice)
  • Mission critical - debugging, recreatability (environment / synthetic data), replay events

Replaying / tracing events - LightStep, honeycomb

The spotify model

https://web.devopstopologies.com

How to Build Your Own “Spotify Model”

Squads focused on a business domain ; Collection of squads = tribe ; Chapter = group of role in tribe ; guild = people interested in a particular thing.

Encourage flow of change.

Plan and budget for cross-team enablers.

There is No Spotify Model

Conway's Law - mirroring or architecture on organisation

Team cognitive load ; team-first thinking ; the team is the means of delivery.

Choose boundaries for team ownership ; physical / digital workspace.

Reverse Conway law - change org to get better chance of achieving desired architecture.

Team's improve dev ex for consumers of service.

Wrong kind of interaction between teams => boundaries not OK or capabilities in team not OK.

Triggers for change.

Thinnest Viable Platform. What is the thinnest platform that could work? inc docs, examples, stubs making dev experience strong.

DevOps and everyone else – how to support more Collaboration across Teams

James Mountifield