Microservice oriented architecture is very fashion. It is very easy to find posts describing success story with this kind of architecture. However, this kind of architecture comes with a set of traps and assume a lot of things about your company's IT.
In this task I will show in which context this kind of architecture makes sense, the challenges coming with it, the kind of data architecture it implies and the most mature existing stacks to work with.
Transcript available http://francesbagual.net/2015/11/03/Microservices-architecture-Nirvana-or-Nightmare-part-i.html
17. Issues
➔ Teams depending from other teams to release
➔ Feature synchronization overhead
➔ Creating stubs to parallelize development
➔ Release synchronization overhead
➔ Impossible to experiment
➔ Very little innovation
41. 12 Factors
➔ One codebase tracked in
revision control, many deploys
➔ Explicitly declare and isolate
dependencies
➔ Store config in the
environment
➔ Treat backing services as
attached resources
➔ Strictly separate build and run
stages
➔ Execute the app as one or
more stateless processes
➔ Export services via port
binding
➔ Export services via port
binding
➔ Scale out via the process
model
➔ Maximize robustness with fast
startup and graceful shutdown
➔ Keep development, staging,
and production as similar as
possible
➔ Treat logs as event streams
➔ Run admin/management tasks
as one-off processes
74. Summary
➔ Architecture to scale Teams
➔ Highly Flexible
➔ Highly complex
➔ Ownership using Management 3.0
➔ Development Mastering using Agile Coaching
➔ Agile deploy thanks to a Platform as a Service
➔ Data Architecture
➔ DevOps