Python for OPS and platform teams - Pavel Chunyayev¶

Tags: python, pun

(One of the talks at the 22 June 2016 Amsterdam Python meetup)

The sub-title of his talk is supporting development teams in their journey to Continuous Delivery. Pavel’s job description is continuous delivery architect. He loves biking so he just had to move to Amsterdam :-)

What is continuous delivery? Often you’ll hear something like “safely, rapidly and predictably deliver new features to production”. But that’s a little bit restricted. He likes to start already in the inception and planning stage and only end in the actual operation stage. So the whole process. You don’t want to continuously deliver bad features that won’t be used. You want to include the inception/planning stage to make sure the right features are implemented.

A core idea is to keep the product releasable: build quality in. That is the core that we ought to remember. Quality is an integral part of the product, it is not something you can tack on later.

So… quality in the entire build/test/release cycle.

• Build. All the checks you can do. Linting, static code analysis, unit tests.

• Test. Contract tests, end-to-end testsuites, browser tests, scaling tests.

• Release. Verify the deploy.

Especially in the “test” phase, you need specific clean test environments. Provision infrastructure, run the tests, dispose of the infrastructure. Repeatability is keys.

“Platform as a service”: the real name of every operations team nowadays.

The number of jobs that include configuring servers manually is quickly declining. You need to be a programmer now! You need to enable self-service for the teams you work with.

So: python for system engineers. Python is the best language for this.

• It is the most popular programming language for devops (apart from bash).

• It is easy to learn (but hard to master).

• It is more powerful than bash.

• You can create and distribute real helper applications.

• Devops means you’re a developer now!

What you need to do: create a provisioning service. A self-service. The developer can just click a button and they have a server! Amazon’s AWS was born this way. But these are generic servers. Your company needs custom setups. This is where you come up.

• Services to manage environment lifecycle.

• The same way for everyone.

• Manipulation using API.

• You can mix and match infrastructure providers.

They build something with python + flask + ansible. Flask recieves API calls, analyzes it and creates an ansible object and fires off ansible. Ready!

Also something to look at: Jenkins pipelines. All the jenkins tasks for one job inside one versionable file. You can apparently even write those in python nowadays (instead of the default “groovy” DSL).

Some further thoughts:

• Open all the helper tools to the whole organization.

• Distribute it as docker containers. Both the services and command line tools!

• As sysadmin, act as a developer. Use the same tools!