This document discusses different types of automation and how they have evolved over time. It identifies seven main types: imperative, declarative, templating, implicit, design, UI, and frameworks. The document then provides examples to illustrate how certain automation types have replaced others as technologies advanced. It highlights projects like Polymer, PolyRest, Spring Boot, Spring Data, and Docker that represent shifts toward more implicit and design-based approaches over declarative configurations and templating. The document concludes with references to view the code, slides, and demo for the PolyRest project discussed.

1. Code, Slides, Demo:
✤ code: polyrest at github
✤ slides: petecarapetyan at slideshare.net
✤ demo: [google] polyrest

2. Feb 2016
Merged Automation:
Ecosystems - Devops, JS, Java
What automation looks like when combining state of the art from each

3. Automation?
The Phoenix
Project
✤ Vague about
automation
✤ Lets you imagine
your own
ideas of what
automation really is.

4. Different ideas about automation
✤ Imperative - as in, php, java, ruby, etc
✤ Declarative - You provide the nouns, we provide the actions. Puppet, xml/json config, … Spring
2002 over EJBs
✤ Templating - advanced copypasting from external variables - Chef + infinity others.
Brilliant solutions from the weak minded engineer. [Me, for example.]
✤ Implicit - explicit metadata not required! We will guess/deduce from minimal info - languages,
DSLs, platforms, … Otto, Ruby, Spring Boot
✤ Design - [API/Tooling] wrapping work inside any [headless] API or tool. OSGi, OO, design,
Jenkins, CI/CD, ORM, REST, RPC … not always thought of as automation.
✤ UI - Just answer these questions… believe it or not that used to be called automation. Ouch.
Jenkins UI, Virtual Box, almost all of ops before devops.
✤ Frameworks - Just let us do these groups of actions for you, our way. Angular.

5. Automation
Types
partial list
✤ Imperative
✤ Declarative
✤ Templating
✤ Implicit
✤ Design
✤ UI
✤ Frameworks

6. Automating
“Persistence”
✤ 1970 - Fortran code - Imperative
✤ 1980 - C code - Imperative
✤ 1992 - SQL92 RDBMS - Framework
✤ 1999 - EJB - Framework
✤ 2003 - Spring - Framework
✤ 2005 - ORM - Design/Framework
✤ 2012 - NoSQL - Design
✤ 2014 - Hadoop - Framework
✤ 2016 - Spring Data - Implicit

7. This
Automation
Trumps
That
Automation:
Templating, for example, is often
and easily replaced in later years by
better APIs and clean Design.
✤ XDoclet was replaced by Rails/
Grails
✤ Virtual Box UI by Vagrant by Otto
✤ Chef/Docker/Ansible by Docker
anyone?

8. Automation
Too Far?
✤ Implicit as example of
sometimes one step too far?
✤ Tooling and authoring
sometimes much faster in
explicit languages/toolsets.
✤ Example:
James Strachan invented implicit
language: Groovy, only to favor
static typing of Scala, later.
James Strachan
Creator of Groovy

9. “All things implicit are evil.”
–Pete Carapetyan

10. Tonight: Evolving Automation
✤ Polymer as Design over Frameworks
✤ PolyRest as Implicit over Declarative - a P.O.C. by me.
✤ Spring Data, Spring Boot as Implicit over Declarative
✤ Docker as Design over Templating or Declarative

11. Polymer
Look Ma! No copypasting!
Framework being replaced by Design
by Google

12. PolyRest
✤ Look Ma!
No db/table specific UI
code!
✤ Written in Polymer
✤ Consumes HATEOAS
REST APIs

13. [demo]

14. Spring Boot
Spring Data
Look Ma, it’s all implicit!
Almost no code, or declarative config.

15. Docker
✤ Look Ma!
Takes the management out of
Configuration Management.
sorta.
[Still seems a lot cleaner than Chef]

16. Code, Slides, Demo:
✤ code: polyrest at github
✤ slides: petecarapetyan at slideshare.net
✤ demo: [google] polyrest

17. [demo]