Uploaded byBoyan Dimitrov
Moving to microservices – a technology and organisation transformational journey
Moving to microservices was a transformational journey for the company as their system grew rapidly. They started with a monolithic architecture which became difficult to maintain and scale. This led them to redesign their system using microservices built with Go running on AWS (Amazon Web Services). They developed core platform capabilities to support automated provisioning, routing, discovery, monitoring and more. This allowed them to deploy new services rapidly and operate their distributed system more efficiently. The transition required changes to both their technology and organizational culture.
More Related Content
![Building a [micro]services platform on AWS](https://cdn.slidesharecdn.com/ss_thumbnails/awsmeetupmay2016v2-160801142641-thumbnail.jpg?width=640&height=640&fit=bounds)
![Choosing the right messaging service for your serverless app [with lumigo]](https://cdn.slidesharecdn.com/ss_thumbnails/choosingtherightmessagingserviceforyourserverlessappwithlumigo-201217193955-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to Moving to microservices – a technology and organisation transformational journey
![Vibe Coding vs. Spec-Driven Development [Free Meetup]](https://cdn.slidesharecdn.com/ss_thumbnails/vibecodingvsspecdrivendevelopment-251209105622-43f455e7-thumbnail.jpg?width=640&height=640&fit=bounds)
Moving to microservices – a technology and organisation transformational journey
- 1. Moving to microservices– a technology and organisation transformational journey Boyan Dimitrov, Platform Automation Lead @ Hailo @nathariel
- 3. FROM LONDON TOTOKYO, FROM MADRID TO OSAKA.
- 4.
- 5. Back in 2011we started simple System overview: • Started on AWS • PHP frontend and Java backend applications • Built and supported by a small team: 3-4 backend engineers MySQL
- 6. And then westarted expanding rapidly • City-specific environments • Branching the code base • Manually building infrastructure and configuration MySQL PHP Java MySQL PHP Java MySQL PHP Java
- 7. As we grew,getting features out became a challenge We quickly found out that extending monoliths is hard: • Hard to maintain the codebase • Any new feature took weeks to deliver • Hard to scale the dev teams Failure to deliver business value Performance
- 8. Operating a monolithin the cloud got even harder A lot of development and ops time wasted in firefighting: • Lack of automation • Multiple SPOFs • No proper monitoring MySQLMonolith Monolith • Unclear responsibilities • No well defined escalation or ownership process – many non actionable alerts transformed into “all hands on deck” actions
- 9. So in 2013we ended up doing… Monolith
- 10. We wanted tobuild a global platform • Everything had to be automated – any workflow, any action • Everything had to be resilient and self-healing – regardless of the failure source: infrastructure, network or code • Each service had to be responsible for one thing and one thing only Looked at what we did wrong and redesigned it: Key challenges: • We decided to move from PHP & Java to Go • We had to build everything from scratch but move all our production traffic without any downtime • We had to change our culture as we go
- 11. eu-west-1 Message Bus+ API Gateway C* us-east-1 APIGateway C* Message Bus+ Go Service Go Service Go Service Go Service Go Service Go Service Go Service Go Service Go Service Go Service Go Service Go Service
- 12. We started withthe building blocks Logic Storage Library for abstracting service-to-service comms service-layer Handler platform-layer Self-configuring external service adapters A service under the hood: • Service to service communication libs • Discovery • Configuration • A/B testing capabilities • Monitoring & Instrumentation • … and much more Any service gets for free:
- 13. In preparation forthe migration Introducing a smart API Gateway made our life easy: • Let us do a transparent, seamless migration from user perspective • Gave us a lot of flexibility about how we route our traffic • Enabled us to build a lot of failover capabilities API Gateway Monolith
- 14. And then westarted breaking down our monoliths • We aimed to get production traffic on the new platform as quickly as possible • We identified the low hanging fruit first and rewrote them • We kept iterating on our platform and building more tools as we needed API Gateway Decouple
- 15. At present wehave • Microservices ecosystem (99.9% written in Go) • Designed specifically for the cloud – different building blocks and components will constantly be in flux, broken or unavailable • 1000+ AWS instances spanning multiple regions • 200+ services in production
- 16. The Platform Troll aplatform by Swinsto101 / CC BY-SA 3.0 / Desaturated from original
- 17. TeVPC Auto Scaling S3 OrchestrationEnv DNS ReleaseAutoScaling Discovery Monitoring CFEC2 Route 53 Redshift ComputeEIP Routing Core Platform Provisioning Login Services Cloud Provider Whisper Config
- 18. • Lowest levelbuilding blocks • We mostly use basic PaaS components and services as they cover most of our needs • We expect every underlying component to fail and we designed for this TeVPC Auto Scaling S3 CFEC2 Route 53 Redshift Cloud Provider
- 19. eu-west-1 Proxy Layer Message Bus eu-west-1a Services eu-west-1beu-west-1c Shared Infra RabbitMQ RabbitMQ RabbitMQ API API API Go Go Go x many C* NSQ ZK C* NSQ ZK C* NSQ ZK x many x many
- 20. • We useauto scaling groups for everything Guarantees each component can be rebuilt automatically Including our database clusters that run on ephemeral storage ( we do keep 6 copies of each piece of data in 2 regions ) • Minimum of 3 AZs in every region • Every workflow is automated • Every component has to be self-healing and scalable Core principles
- 21. • Our “cloudprovider abstraction” layer • Main purpose is infrastructure and workflow automation and discovery • Has a global view of everything happening across our infrastructure • Provides additional capabilities on top of AWS • The only services directly aware of our cloud provider specifics – gives us a lot of flexibility and let us introduce changes quickly OrchestrationEnv DNS Release AutoScalingComputeEIP Whisper
- 22. Everything in ourplatform emits events So naturally we want to capture all external events as well!
- 23. Whisper Service It’s allabout event driven compute – think Lambda but within our platform Events Events Hundreds of publishers & subscribers NSQ Topics Events External sources Actions To subscribe to any new event source we have to only change a single service
- 24. Provides the mostessential platform functions for every service: • Service Discovery • Service Provisioning • Routing & Load Balancing • Authentication/Authorization • Monitoring • Configuration Discovery Monitoring Routing Core Platform Provisioning Login Config
- 25. • Self-contained unitsof execution • Built around business capabilities or domain objects • Small enough to be rewritten in a few days • Independently scalable • They are all about adding business value Services
- 26. All good butdid we make our development any faster?
- 27. Up and runningin seconds Vetted & Tested & Built ~ 100 – 140 sec Setup ~ 1 sec Trigger a build ~ 1 sec
- 28. Deploying a service servicename version auto scaling group
- 29.
- 30. Service A ServiceA Traffic 5% 95% Smart traffic shaping
- 32. LIVE We can geta completely new service in production in hours Hailo Warp Speed ( measured in many μs or something )
- 33. What about operatingour platform?
- 34.
- 35. Microservices are allabout the tooling!
- 36.
- 37.
- 39. Key Learnings • Automateeverything – it enabled us to do more with less • Identify your KPIs and track them • Invest in tooling: the complexity in a microservices architecture is not in your application code anymore - it is in the thousands of service interactions! • Empowering our engineers increases your velocity tremendously! • Moving to microservices is a journey – make sure you take everyone onboard!
- 40.