Development and deployment of polyglot systems
-
Upload
david-pichsenmeister -
Category
Technology
-
view
627 -
download
1
description
Transcript of Development and deployment of polyglot systems
@3x14159265
development and deployment of polyglot
systemsby
david pichsenmeister
@3x14159265
charging systems@3x14159265
startup-founder & tech lead:
@3x14159265
the
system
@3x14159265
@3x14159265
why polyglot?
@3x14159265
reasons for polyglot
● system is already live
● technologies/skills evolved
● current stack is already a “technical
debt”
● get rid of legacy code
@3x14159265
service oriented architecture
● backend only
● choose what service to decouple
● design to use from any
language/platform
@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
@3x14159265
“app oriented architecture”
● thin layer on top of SOA
● form set of features to standalone
app
@3x14159265
orat.io appsplatformwidget
moderation
analytics
login
@3x14159265
pros
● easier to maintain/test
● don’t effect your existing codebase
● seperation of business logic
@3x14159265
cons
● over-fragmentation
● repeatedly functionality
● achieve model consistency through
all apps
@3x14159265
model consistency
@3x14159265
code generators
● define MDL
● use/write codegenerators to
distribute models to other languages
● compiler hook
@3x14159265
code generators
● doctrine (php ORM) = MDL
● slick (scala ORM) = generates
classes from SQL
● custom code generator: Scala
classes → TypeScript classes
@3x14159265
continuous deployment
@3x14159265
deployment strategies
● always have working branch
● staging environment
● immutable infrastructure
@3x14159265
automation
● automate everything that’s possible
● make use of cloud provider features
● shell scripts are your friend
@3x14159265
@3x14159265
deployment tools
SaaS:
@3x14159265
database migrations
● some application changes require
changes in db schema
● simple and/or risky
● always a pain
@3x14159265
simple changes
● add table
● add index
● add column
● ...
@3x14159265
risky changes● rename/add column
● change foreign key
● migrate data from one table/column
to another
● ...
@3x14159265
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
how we’ve done it
● delete entity on “old” table
● additionally run this procedure as
background job
@3x14159265
must haves
● tool, which keeps track of db
evolutions
● simple integration into existing
project
@3x14159265
must haves
● changelog
● up/down db evolutions
● intense testing
● backups
@3x14159265
resourceshttp://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
resourceshttps://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
thanks!feel free to add me on:
.../3x14159265