2. 2
Agenda
1. Why Microservices
2. What are Microservices
3. Best practices
4. Containers
5. Orchestration
6. MongoDB & Microservices
7. Business benefits
8. When to use Microservices
9. Use Cases
10.Resources
3. 3
Microservices - The Attraction
Web
Scale
Speed
Iterate
Agile
ReactIsolate
Maintain
Empower
13. 13
Conway’s Law
"Any organization that designs a system will
inevitably produce a design whose structure
is a copy of the organization's
communication structure.”
– Melvin Conway
15. 15
Containers – Powering Microservices
Real world shipping containers
• Same container efficiently transports goods by road,
rail, and sea
• Contents remain untouched through all those
environments; no repacking needed
• Ubiquitous and standardized
• Simple to use – open, fill, close
• Contents of each container safe from the others
• Know how much space the container consumes
16. 16
Containers – Powering Microservices
Software containers
• Build an image containing the full application stack only
once
• Spin up many containers from the same image in
multiple environments
– Laptop, data center, cloud
– Development, QA, production, support
• Simple to use & efficient
• Contents of each container isolated from the others
– Storage, memory, namespace
• Constrain resources available to each container
– Storage, memory, CPU, IO
17. VM VMVM
VMs Containers
Bare Metal
Host Operating System
Hypervisor
Guest OS
Libraries
Apps
Service
Guest OS
Libraries
Apps
Service
Guest OS
Libraries
Apps
Service
Container ContainerContainer
Bare Metal
Host Operating System
Docker Engine
Libraries
Libraries
Apps
Libraries
Apps
Service ServiceService
18. 18
Docker
The most popular container technology
• Simple to use and has a rich ecosystem
• 100,000+ images available from Docker Hub
– Including mongo hub.docker.com/_/mongo/
– Syncs with GitHub projects
• Define new images built upon base images
• Define interfaces between containers
• LINUX, (and now) Windows, and OS X
• Runs on bare metal, VMs, and cloud. Cloud
providers supply the Docker infrastructure (e.g.
Google Container Engine)
22. 22
Containers and Microservices
Microservices built by combining multiple
containers
• Build sophisticated services from many small,
focused processes (containers)
– Well defined APIs between components
– Each component can use different libraries,
middleware & programming languages
• Modular, decoupled architecture simplifies
maintenance and enables reuse
• Fault tolerant
• Scalable
Cmglee
24. 24
Orchestration
Automated deployment, connecting, and
maintenance of multiple containers
• Provision hosts
• Instantiate containers
• Reschedule failed containers
• Link containers through defined interfaces
• Expose services to the outside world
• Scale out and back in
25. 25
Orchestration – Kubernetes
Created by Google, feature-rich and widely
adopted
• Automated container deployment and ‘replication’
• On-line scale out/in
• Rolling upgrades
• HA – automatic rescheduling of failed containers
• Exposure of network ports to external apps
• Load balancing over groups of containers providing
a service
• Provided as a service by Google Compute Engine
26. 26
Orchestration – Apache Mesos
Designed to scale to 10,000s of physical
servers; used by Twitter, Airbnb & Apple
• Developer writes code to turn application into a
framework to run on Mesos
• Less feature rich than Kubernetes; considers many
functions such as load balancing, rescheduling, and
scaling to be a higher level function
– Project exists to run Kubernetes as a Mesos
framework
• Foundation for distributed systems
– Apache Aurora, Chronos, Marathon
27. 27
Choosing an Orchestration Framework
Factors to consider…
• Integration with existing DevOps frameworks?
• Number of hosts?
• Bare metal, VMs, or cloud deployment?
• Automated High Availability?
• Grouping and load balancing?
• Existing skills?
• Install your own orchestration framework or use as a
service?
28. 28
Security
Containers provide opportunities to
improve security
• Containers provide isolation; resources can only be
accessed from outside through explicitly provided
APIs
• Resources can be rationed
• A container’s role can be very narrow – remove
anything not required
• Images and containers should be kept current;
rolling upgrades with Kubernetes or Aurora
• Typically log into container as root so restrict access
29. 29
Orchestrating MongoDB
Orchestrating MongoDB containers
requires special treatment as it’s a
distributed, stateful application…
• State should survive rescheduling; use Kubernetes’
persistent volumes abstraction
• Replica Set members must communicate with each
other; expose external IP addresses/ports which
survive rescheduling
• Replica Set must be initialized from exactly one
member
• MongoDB must still be monitored and backed up –
MongoDB Cloud Manager
35. 35
Resources
• Case Study – FuboTV
https://www.mongodb.com/blog/post/leaf-in-the-wild-leading-
soccer-streaming-service-fubotv-scales-its-business-with-
mongodb-docker-containers-and-kubernetes
• Case Study – Square Enix
https://www.mongodb.com/blog/post/leaf-in-the-wild-square-
enix-scales-tomb-raider-hitman-absolution-deus-ex-and-more-
on-mongodb
• “Enabling Microservices – Containers &
Orchestration Explained” white paper
https://www.mongodb.com/collateral/microservices-containers-
and-orchestration-explained
• “Microservices: The Evolution of Building Modern
Applications” white paper
https://www.mongodb.com/collateral/microservices-the-
evolution-of-building-modern-applications
Microservices were pioneered in the web and then mobile App worlds; at one time called micro-web-services. Now other enterprises are looking for the same benefits.
Microservice architectures implement applications as a series of small, self-contained, loosely coupled software components. Each has a specific and well understood role.
Benefits of microservices:
- Development Speed
- Rapid Iteration
Evolve quickly, continuous deployment
Isolate impact of changes to existing functions or just add a new one
Reactive development
Maintainable
Independent, empowered work teams
Monolith is like Spaghetti
Changing anything impacts everything else.
<= 1990s
Pre-SOA (monolithic)
Tight coupling
For a monolith to change, all must agree on each change. Each change has unanticipated effects requiring careful testing beforehand
Service Oriented Architecture is like a Pie
Easier to remove or change a piece but still need to make sure that it fits back together properly
2000s
Traditional SOA
Looser coupling
Elements in SOA are developed more autonomously but must be coordinated with others to fit into the overall design
SOA was billed as a way of delivering code re-use but people ended up designing for efficiency instead.
Microservices are like Cupcakes
Can add new ones with different flavors, remove ones that you no longer need, add more pink ones if there’s greater demand
Developers can create and activate new microservices without prior coordination with others. Their adherence to MSA principles makes continuous delivery of new or modified services possible
Greater modularity, looser coupling.
Started in the web and mobile app world, moving to Enterprise. Big in media and startups
Plan for flexibility rather than reuse
Each of the ovals represents a microservice.
Each source of social media feeds has its own microservice which is specialised in interfacing with the relevant API.
Each of those microservices passes messages to the ‘feed merge’ microservice which can then make them available for further microservices to work with.
Communication between the microservices is over the network – they can be local to the same machine or distributed.
Best practice is for each microservice to be stateless and to have its own database or schema
Individual microservices can be updated in isolation or even removed if their role is no longer needed
When a new role (or even a change to an existing one) appears, best practice is to implement a new microservice rather than extending an existing one.
When a new role (or even a change to an existing one) appears, best practice is to implement a new microservice rather than extending an existing one.
Microservices allow scale-out.
Each type of microservice can be scaled independently – add extra instances just for the functions that are being overworked.
Multiple instances of each service can provide High Availability
An alternate view is that each microservice is much larger – in this case User Account, Product Catalog, Inventory & Order. The key is to do what makes sense for your enterprise: which pieces need scaling independently, which would you like to upgrade independently, how does it fit into your organisation?
Functions are decoupled into four separate services (separate WAR files) and organized by business boundaries
Web pages, Classes, Config files to a service are grouped together
Services can evolve and iterate independently as each team can develop, test, and deploy code separately
Best practice is for each microservice to have its own database.
Melvin Edward Conway is a computer scientist, computer programmer, and hacker who coined what's now known as Conway's Law in 1967.
-Organizations design systems which copy the organization
-If the parts of the organization do not closely reflect the essential parts of the product, or if the relationship between organizations do not reflect relationship between product parts, than the project will be in trouble
-Make sure the organization is compatible with the product architecture
Best practice is for each microservice to be small enough that a single developer should be able to understand its entire codebase (think in hundreds rather than 10,000s of lines of code.
The code for a microservice should be owned by the organization responsible for that function; for example the marketing development team should own the microservice responsible for sending nurture track emails.
Netflix was one of the pioneers of Micrservices with their ”Cloud Native” approach – it was really all about being able to scale their development organisation.
To do useful work, microservices need a way of communicating – Apache Kafka
Kafka provides a flexible, scalable, and reliable method to distribute streams of event data from one or more **producers** to one or more **consumers**.
Examples of **events** (or **messages**) include:
A periodic sensor reading such as the current temperature
A user adding an item to the shopping cart in an online store
A Tweet being sent with a specific hashtag
A log entry generated for each click in a web application
Streams of Kafka events are organized into **topics**. A producer chooses a topic to send a given event to and consumers select which topics they pull events from. For example, a financial application could pull NYSE stock trades from one topic, and company financial announcements from another in order to look for trading opportunities.
Kafka actually stores all of the messages that it passes around – this makes it ideal for production microservice deployments
A microservice can be upgraded and then catch up on everything it missed
Or even apply its updated business logic to the full history of events
A new microservice can be added and it can be brought up to speed with everything that’s gone before
If one service is generating more work than another can keep up with then Kafka operates as a buffer
[Apache Aurora](http://aurora.apache.org/) – a highly scalable service scheduler for long-running services and `cron` jobs; it's used by Twitter. Aurora extends Mesos by adding rolling updates, service registration, and resource quotas.
[Chronos](https://github.com/mesos/chronos) – a fault tolerant service scheduler, to be used as a replacement for `cron`, to orchestrate scheduled jobs within Mesos.
[Marathon](https://mesosphere.github.io/marathon/) – a simple to use service scheduler; it builds upon Mesos and Chronos by ensuring that two Chronos instances are running.
Key Message here:
Containers were originally assumed to be stateless but there’s now a demand for running DBs in a container.
Kubernetes has been adding some features to help (e.g. persistent volumes)
Still some gotchas for MongoDB but we have a white paper explaining exactly how to build and deploy a replica set with Docker and Kubernetes
Because we’re using external IP addresses, we can instead create the replica set with nodes in different regions
DevOps & Continuous Delivery
Low impact & risk; update one container at a time
Replicating environments
Instantiate clones for development, QA, production, support…
Scalability
Add and remove containers based on demand
Accurate Testing
Confident your stack exactly matches what’s in production
Isolation
Safely run multiple environments on the same hosts
Performance
Minimal impact from container overhead
High Availability
Redundancy from multiple containers fulfilling a role
Faster Time to Market
Organisational alignment
Cost reduction
More efficient use of infrastructure
Fast is more important than elegant.
Change in the application’s functionality and usage is frequent.
Change occurs at different rates within the application, so functional isolation and simple integration are more important than module cohesiveness.
Functionality is easily separated into simple, isolatable components.
When you have the developer/DevOps skillsets.
Where development org boundaries match service boundaries.
Don’t forget that you’re building a distributed system -> complexity but there are precedents to read up on.
One argument is that you shouldn’t bother with microservices unless you need either:
- Scale your team
- Design for change
Sagrada Familia – designed by Gaudi; construction started on March 19, 1882. Expected to be finished in 2026.
Flexible data model
Fits in with the need to be agile
Monitoring & automation
You have lots of moving parts in a microservice architecture – need to monitor and automate as much as possible
Redundancy
MongoDB replica sets -> can perform online upgrades and easily cope with rescheduling
Scalability
MongoDB sharding lets your database scale just as easily as your stateless microservices
Remember web-scale?
Best practice for each service to have its own schema or database; MongoDB’s simplicity helps
GAP moved their purchase order system from a monolith architecture to microservices. Due to MongoDB’s flexible schema, it took just 75 days to build the new system. When requirements changed and they had to add new types of purchase orders, it took days instead of months.
FuboTV is a North American soccer streaming service. Using Microservices with Kubernetes, Docker & MongoDB. Isolation means that they can use a single cluster of machines (in Google Cloud) for dev, QA & production. Very birsty application – scalability lets them handle 100x increases in traffic.
Otto – the key was to have an architecture that fits with their organization. Microservices empower loosely couple development teams (business, project management, IT). This is all enabling Fast test & deployment + Iterative, Continuous Delivery
Backcountry.com is an online specialty retailer that sells outdoor clothing and gear. The driver to Microservices for them was a growing, distributed development team. As more and more developers joined and made contributions to the code, the schemas became convoluted and harder to maintain; contributing to 20% of the Scrum backlog. Taking advantage of MongoDB’s flexible data model, Backcountry was able to iterate faster, reduce development time, and mitigate technical debt.