The document describes the evolution of Shomi's platform architecture over multiple versions from 1.0 to the planned 4.0. Key points include: - The architecture transitioned from monolithic to microservices and from single to multiple technologies. - Resiliency improved from failure-prone to handling outages and overloads across services and clouds. - Later versions used microservices, data sharding, polyglot solutions, and event streaming to improve agility, scalability, and adaptability. - Version 3.0 introduced platform services, assumed unreliability, and used multiple clouds for redundancy. - Version 4.0 plans to use containers and improve quality of service across database and search

1. Evolution of Platform
Architecture
by (the delusional) Vlad Khazin

2. Architecture from 1.0 and upwards
● from monolith to micro-service
● from single platform to polyglot solution
● from failure prone to failure safe
● from virtual machines to multi-cloud services

5. Shomi 1.0
● we've launched x2 with least initial number of hassles I
have ever seen
● we've team of awesome people working together (despite
management style)
● we have grown fat to move, slow to adopt, and heavy to
lift

8. Shomi 1.1
● micro-services made us more agile and nimble
● Sharded backend made us more scalable
● polyglot solution, as diversity in nature, made us more
sustainable and adaptive
● prioritization meeting for each new
microservice/language/tool is killing it

10. Shomi 1.2
● more micro-services on the road to more agile and nimble
● leaning away from Microsoft technologies to leverage
more tools, frameworks and cloud services
● faster and easier deployment process...

13. Shomi 2.0
● soa is broken down to micro-services, each one controls
its own data
● data has moved to sharded and replicated systems
● Admin soa merged with public soa and protected by
authC/authZ rather than by network settings
● there is a problem left behind though...

16. Resilient By Design
● connectivity issue accounted for and domino effect
failures are prevented
● back-end systems are expected to have outages and/or
being overloaded - Backpressure
● external/internal services are expected to be unavailable

19. Paradigm Shift is needed
● from ACID to ACID 2.0: Associative, Commutative,
Idempotent, Distributed
● from all-in-one database to CQRS: use a different model
to update information than the model you use to read
information
● from data/message processing to data/event streaming

21. Shomi 3.0
● from virtual machines to platform as a service
● from vpc to zero administration
● code handles infrastructure failures rather than
infrastructure handles non resilient code
● every cloud has something in common and something
different: platform as a service for Node.Js and
Elasticsearch as a service
● database as a service - code handles the differences
between different repositories - not as scary as it sounds.

22. Shomi 3.0
● Halo Service communicates the url’s
● Configuration service communicates other settings
● Replication messages sent between cloud providers
● Every individual service and cloud provider is assumed to
be unreliable.
● More redundancy achieved by adding availability zones or
by adding cloud providers
● Shomi service cannot be down unless both complimentary
cloud providers go down

23. Shomi 4.0
● and you thought it can’t get any more insane than 3.0…
● Containers replace platform as a service to further simplify
deployment
● Database and Search as a service are no more from the
same cloud provider as QoS improves
● Replication is simplified by new tools that are yet to come