- Why are microservices and continuous delivery critical to Poppulo's expansion?
- How did Poppulo transition from a single team building a monolithic application to six teams developing microservices?
- How are microservices changing the way we develop our product today?
- What are the main challenges we faced in our transition and what's next?
TIME: 1min (0)
Site Reliability Engineering Manager at Poppulo (formerly NW)
Global leader in Employee Communication Technology
Help large orgs communicate with their employees to unleash the power of their people.
10 years working at Poppulo, saw a lot of growth and change – started as Dev, Led multiple teams, and now SRE mgr
Will talk about what role Microservices took in our growth
TIME: 2min (1-3)
History – app developed in monolithic architecture over ~6-7 years
Mostly focused on Email channel
Large single code base (typical J2EE app) – single database (MySQL)
Long release cycle of 4 weeks (even if down from 3 months cycles)
TIME: 2min (3-5)
Increasing complexity:
Decreasing velocity / Decreasing stability / Hard to onboard
Stuck with original technology decisions
Long release cycle:
More bundled changes = More risks
Maintenance windows out-of-office
Turnaround time for critical fixes ~ 2 days
Long feedback loop (leading to building more upfront)
TIME: 1min (5-6)
3yrs ago: app mostly focused on email
Business Goal: grow to become global leader in IC
Platform of IC tools, Cross-channel analytics
Incompatible with current Engineering structure
No ROI on adding a Team (slow onboard & ultimately adding more complexity)
Impossible to conceive going from 1 to 5+ teams in short term
Can’t “throw people at the problem”
TIME: 2min (6-8)
Added new Team with focus on XC analytics – Sept 2014
Needed to change ways
new work has to be scalable
minimise impact/coupling to existing system
3 month tech spike:
analytics product (big data etc.)
Tools, practices and architecture patterns to enable scalable CD
TIME: 3min (8-11)
Microservices architecture
Prevent creeping complexity of large codebase
Isolated changes:
1 service does 1 thing
Easier to understand
Minimise risk of changes
Loosely coupled:
- well-defined interfaces (API / message based)
- each service need to be independently deployable
Data ownership: no more shared databases
TIME: 3min (11-14)
Monolith changes deployed every 4 weeks
Not feasible to rely on manual deployments for microservices
Reducing handoffs: no more manual ops deploy
Automation: CI on each code commit (build, code analysis, tests)
Zero-downtime: seamless for end-user
Pipeline: from code commit to production
Docker images as unit of deployments
Kubernetes to orchestrate containers
TIME: 1.5min (14-15.5)
No more handoffs for deploying code changes:
Team gets an understanding of running code in production
Team makes the decision to go live
Responsibility in production
Must understand how application behaves (telemetry / monitoring)
React when problem occur (alerting)
Operations should not be the ones woken up at night for application issues
TIME: 1.5 min (15.5-17)
Teams responsible and expert in their Product area (e.g. events, analytics, surveys…)
Data-driven
Independence of changes: no unsustainable increase in complexity
Teams can work fast, on their own
Faster changes = easy to experiment and iterate
Less upfront planning, more real feedback from users
Enabled each team to do this
TIME: 1.5min (17-18.5)
Cross-functional: full team expert in their context
Existing core app still monolithic
Takes time to break down, need to actively budget for it
More and more teams participating in breakdown
No new features in core app
All new work built in new stack
TIME: 0.5min (18.5-19)
TIME: 3min (19-22)
No silver bullet:
High cost, high reward if done right
Monoliths are not bad (most startups started with them!)
Distributed systems are hard: Networks are unreliable, Interfaces are easier to break
Automation is not optional:
From commit to live 25 times a day: can’t leave anything to chance
Repeatability is crucial
Cultural shift:
Ownership requires teams to take responsibility
Operational overhead:
Ops responsibility changes from deploy to providing autonomous capability to teams
Engineering awareness and responsibility to run things in production (DevOps)
Deployment pipeline setup and ownership
For us: SRE model emerged
Apply Engineering techniques to Operation problems
Automate Operations and PAAS & guide teams to manage their services in production
TIME: 2min (22-24)
Scaling by limiting complexity creep
Allows teams to work without interfering with each other
Agility in dev:
Evolutionary architecture: not stuck with decisions of the past
Build a more relevant product by getting it in front of customers faster
Team ownership and engagement in their area of the product
Awareness in product:
Also plays in ownership
“you build it, you run it” (and you get paged for it!) – shift in mindset