How to (not)

fail at  operations

Alex

Systems Architect

About me

  • Used to be a frontend engineer
  • Used to work as an SRE (some called it DevOps engineer)
  • Working as a Systems Architect

It's very easy to fail at operations (1):

  • have your operations team manually provision servers
  • have your operations team install your applications on the server
  • don't even think about virtualisation

Off to the chopping block!

Servers as cattle

  • All the same
  • You don't really care when you loose one, just rebuild
  • Easy to monitor, and behaviour is predictable

Servers as pets

  • Every one is different and created with love
  • You care about it, you watched it grow ever since you got it and can never be replaced
  • You never really know what you're getting in terms of performance and availability

Throwing things over the wall

  • Your development environment is perfect, production is flawed
  • Never document anything, let ops figure it out
  • Always use the bleeding edge versions of libraries, try multiple versions of the same thing

It's very easy to fail at operations (2):

  • configuration management is for hippies, real sysadmins write their own scripts
  • docker is already dead, why bother with it
  • kubernetes is a buzzword

Writing  automation

  • Use whatever feels easier for you
  • Mix as many possible scripting languages
  • There's even PowerShell for linux now

Terraform

  • Creates reproducible infrastructure on various providers
  • Knows about  the current state your infrastructure  is in
  • Allows us to view the changes before applying them

Ansible

  • Easy to group servers  into "Roles"
  • Declarative syntax
  • Can automate everything from infrastructure provisioning, to network switch configuration

Docker  is dead

  • Docker Inc. no longer believes in docker 
  • Why do I need another "package manager" I already have  jars, wars, etc
  • Docker gets in the way of my logging, slows down networking, etc

The cloud orchestrator

  • Makes decisions on where an application goes
  • Allows for for declarative deployments
  • Makes sure that the state of the system matches what is declared

It's very easy to fail at operations (3):

  • always use your preferred tools and means of setting up dependencies when developing your apps

  • I'm a programmer, I don't need to understand the OS or hardware my app is running on
  • 12factor apps is for hipsters real programmers build their own configuration systems

Make your development environment unique

  • Use  as many ways of installing dependencies  as possible
  • Make those dependencies complicated, make sure your dependency has a  dependency that you depend on at a different version
  • Don't always  state your  dependencies in package manager  configuration files, live a little install things by hand (depend on the GAC in .NET)

Don't bother with the hardware

You are an application developer, you live at layer 7, everything below does not apply to you.

It's very easy to fail at operations (4):

  • always write your own authn/authz, logging, http clients, etc

Service mesh

  • Offload common tasks outside of the application
  • Allow you to visualise the flow of data between applications
  • Allow  complex traffic  shaping strategies

Thank
You!
 

Made with Slides.com