1.
development and
deployment of polyglot
@3x14159265
systems
by
david pichsenmeister

2.
charging systems @3x14159265
@3x14159265
startup-founder & tech lead:

3.
@3x14159265
the
system

4.
@3x14159265

5.
@3x14159265
why polyglot?

6.
reasons for polyglot
● system is already live
● technologies/skills evolved
● current stack is already a “technical
debt”
● get rid of legacy code
@3x14159265

7.
@3x14159265
service oriented
architecture
● backend only
● choose what service to decouple
● design to use from any
language/platform

8.
@3x14159265
possible pitfalls
● use only one(!) message format (e.g.
json, xml, soap,...)
● make use of different HTTP request
and status codes
● document your internal API

9.
“app oriented architecture”
● thin layer on top of SOA
● form set of features to standalone
app
@3x14159265

10.
@3x14159265
orat.io apps
widget platform
moderation
analytics
login

11.
@3x14159265
pros
● easier to maintain/test
● don’t effect your existing codebase
● seperation of business logic

12.
@3x14159265
cons
● over-fragmentation
● repeatedly functionality
● achieve model consistency through
all apps

13.
model consistency
@3x14159265

14.
@3x14159265
code generators
● define MDL
● use/write codegenerators to
distribute models to other languages
● compiler hook

15.
@3x14159265
code generators
● doctrine (php ORM) = MDL
● slick (scala ORM) = generates
classes from SQL
● custom code generator: Scala
classes → TypeScript classes

16.
continuous deployment
@3x14159265

17.
deployment strategies
● always have working branch
● staging environment
● immutable infrastructure
@3x14159265

18.
@3x14159265
automation
● automate everything that’s possible
● make use of cloud provider features
● shell scripts are your friend

19.
@3x14159265

20.
@3x14159265
deployment tools
SaaS:

21.
database migrations
● some application changes require
changes in db schema
● simple and/or risky
● always a pain
@3x14159265

22.
@3x14159265
simple changes
● add table
● add index
● add column
● ...

23.
@3x14159265
risky changes
● rename/add column
● change foreign key
● migrate data from one table/column
to another
● ...

24.
how we’ve done it
● migrate “on-the-fly”
● create new table for entity to be
changed
● “transfer” entity to new table when
queried
@3x14159265

25.
how we’ve done it
● delete entity on “old” table
● additionally run this procedure as
background job
@3x14159265

26.
@3x14159265
must haves
● tool, which keeps track of db
evolutions
● simple integration into existing
project

27.
@3x14159265
must haves
● changelog
● up/down db evolutions
● intense testing
● backups

28.
resources
http://blog.codeship.io/2013/09/06/the-codeship-workflow-part-4-immutable-infrastructure.
html
http://www.slideshare.net/b0ris_1/btrofimov-dbmigrationodjug
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
https://www.getchef.com/chef/
https://codeship.io/
http://jenkins-ci.org/
http://capistranorb.com/
@3x14159265

29.
resources
https://circleci.com/
http://git-scm.com/
http://blog.codeship.io/2013/08/30/the-codeship-workflow-part-3-deployment-pipelines.
html
http://www.pichsenmeister.com/
@3x14159265

30.
@3x14159265
thanks!
feel free to add me on:
.../3x14159265