2. Today’s Agenda
• Monolithic System
• Mircoservice and its Charecteristics?
• Microservice Achitecture
• Legacy Systems
• Monolitic Systems
• SOA
• Monolithic vs Microservice
• Advantage & Disadvantage.
• Benefits of Microservices
• Examples
• Takeaway
• Q&A
3. Monolithic Architecture
• A monolithic application is self-contained, and independent from other
computing applications. The design philosophy is that the application is
responsible not just for a particular task, but can perform every step
needed to complete a particular function.
• Complete task, end to end
• Work together
• No Modularity
• Reuse of parts of the application logic
• Maintenance by allowing repair or replacement of parts
5. Examples
• Most programs you deal with day-to-day
• word processing, spreadsheets , powerpoint
• e-mail (?)
• development environments
• Compilers
• many games
• Large, corporate batch systems
• payroll
• reports
• astounding number of very large mainframe
6. Characteristics
• Usually written in a single programming language.
• Everything compiled and linked into a single (monolithic) application
• May operate in both batch and GUI
• Data
• – load into memory – write all back on explicit save
• – No simultaneous data sharing
• May have concurrency
• – multi-threading
• – multi-processing (but only one executable)
7. Advantages
• Performance
– Reading and writing of data can be optimized for performance without regard to
issues such as multi-user data sharing.
– read data directly from the disk via file system
– read data less directly from the disk via layers of intervening software (e.g.,
RDBMS, OODBMS, distributed data server).
– modifying data needn’t worry about writers in other address spaces.
• In-memory is massively quicker
• Caching would present many subtle issues for shared data systems – No IPC overhead
• Simplicity – less code to write – fewer issues to deal with
• locking, transactions, integrity, performance, geographic distribution
8. Disadvantages
• Lack of support for shared access, forces one-at-a-time access
• Mitigate:
• allowing datasets that merge multiple files
• hybrid approaches
• complex monolithic analysis software
• simple data client/server update software
• Quantity of data
– when quantity of data is too large to load into memory
– too much time to load too much virtual memory used
– Depending on which is possible
– sequential access (lock db or shadow db)
– selective access
9. Some Definitions...
• Microservices are small, autonomous services that work together.
• The microservice architectural style is an approach to developing a
single application as a suite of small services, each running in its own
process and communicating with lightweight mechanisms.
• A typically referenced guideline is the Two-Pizza Team rule, which states
if you cannot feed the team building a microservice with two pizzas,
your microservice is too big.
10. What is Microservice?
• Each service is loosely coupled / independently deployable.
• Changes made only to this service.
• Each service has a bounded context.
• Service should not know about surrounding service.
• Remotely accessible service (typically http).
• Does “one thing” (and does it well?).
• Executes stand alone in a container (JVM - in this case).
• Can be composed into a larger service.
11. Challenges
• Scaling monolithic applications is challenging as we have just one
degree of freedom to scale out
• The same challenge applies to replication
• Innovation is constrained by the fact that we cannot easily mix different
technologies for implementing the various functionalities
• Incremental Change is constrained by the fact that can’t incrementally
deploy new functionalities . We needto redeploy an entire subsystem.
• Loose Coupling and High Cohesion are harder to achieve and especially
to preserve as the barriers” between functionalities are very thin
12. Why not monolithic?
• Development Phase
• Apps grow (teams grow too!)
• Different parts change at different rates.
• Different execution container needs (resources)
• Different teams?
• Company grows?
• Deployment Phase
• Deploying a change to a microservice does not
• Increase blood pressure as much as deploying the
• ONE MASSIVE APP THAT RUNS EVERYTHING
• Fear of deploying a change.
• Risk of trying a new technique, new framework.
14. Characteristics
• Services
• Products vs Projects
• Smart endpoints / dumb pipes
• Decentralized governance
• Decentralised data management
• Automation
• Design for failure
• Evolutionary design
15. Microservice Architectures
• Individual functionalities become unit of deployment and run
in their own process
• Microservices communicate
through some lightweight
mechanism.
20. Advantages
• Small code base / easier to test / maintain
• Easy to scale - clone
• Easy to throw away
• Easy to deploy and track errors
• Freedom to switch tech stack
• Maximise team agility
• Maximise resource utilisation
• Debugging
• Smooth deployments
21. Disadvantages
• Devops challenge on multiple fronts
• Complexity in messaging and front end
• Most container technologies still new
• Freedom of tech stack not always good news (for the future
and for the CTO)
• Cost
• Performance
• Deployment and
• Operation
22. Anatomy of a Microservice
• Decoupled Middleware design pattern
• Microservices communicate across a Service Bus (Kafka, RabbitMQ,
NATS.io)
• Service Bus is centralised
• Microservices are distributed
• TCP communication is generally favoured
• Microservices do 1 thing only, and they do it very well
• Not restricted to a specific technology
• Facilitates Circuit Breaker, Bulkhead, and Handshaking design patterns
• Avoids cascading failure
23. Technical Benefits
• Eliminates dependencies
• Failure is isolated
• React to change quicker
• Scale is less expensive
• More intuitive learning curve
• Technology stack is not limited to specific skillsets
• Shielded from legal pitfalls
• Reusable components
• Flexible – will bend rather than break under pressure
24. Micro Service and agility
• Modern agile practice can not ignore tech
• No modern tech = no absolute agility
• Micro services enable agility in a special way
• Enforce team creation
• Enforce faster deployments / better & easier tests
• CI / CD
• Easier communication flow methods (APIs)
• Each service = small scale product
25. Container Technology in micros
• Containers assist micro architecture in
• Visualising services
• Building / sharing services between coders
• Deploying services
• Utilising server resources to run containers
• irrespective of underlying tech
• Popular container technologies
• Docker
• Rocket
26.
27. Container Management
• Used to maintain and utilize containers /services
• Make sure all services up and running
• Make sure server utilisation is maxed out
• Popular container management technologies
• CoreOS fleet
• Docker-machine
• Mesos
• Kubernetes
• AWS ECS / Google Container Engine
