Organisations are building their applications around microservice architectures because of the flexibility, speed of delivery, and maintainability they deliver. In this session, the concepts behind microservices, containers and orchestration was explained and how to use them with MongoDB.
4. Punch Cards and Paper
Margaret Hamilton, (Director of S.Eng) with the
source code to the Apollo Guidance Computer
• Computer programming used to be done
individually or in small teams.
• Programs could only be as big as one person
could understand.
5. The Software Crisis
• 1965 - 1985 is known as the time of the
Software Crisis.
• Quality of Software was appalling. Bugs and
Crashes everywhere.
• Creating reliable software was very hard
6. Source Control
• Enabled Monolithic Architecture.
• Quality went through the roof!
• But software quickly grew beyond the ability for
any one developer to understand it all.
7. The Monolithic Folly
• Expensive to Build
• Difficult to Maintain
• Risky to extend
• Software is only safe and reliable if it can be
understood at the human scale.
11. Why Use Microservices?
Team = Components
No committees
Empower
Build MVP quickly
Speed
Simple components
Isolated impact
Maintain
Rapid iterations
React to market
Change
Product
Team
Scale
12.
13. The Persistence Layer
• Data access patterns have changed
• No time for slow ETL processes
• Flexibility of deployment
14. Why MongoDB is a Good Fit For Microservices
Scalability
Monitoring
&
Automation
Redundancy
Flexible
Data
Model
Simplicity
15. Microservice Architectures Built on Containers
Containers prevent your Ops team
from going postal.
• Well defined APIs
• Independent languages & libraries
• Modular: easy maintenance + reuse
• Fault tolerant
• Scaling, upgrading
18. In Conclusion
• Monolithic application development is no longer a
relevant, reliable or safe architecture.
• Microservices lower risk, increase developer
productivity, and provide a faster time to market.
• MongoDB powers the data layer that Microservices
depend on for security, resiliency and elasticity.
19. References
• Enabling Microservices – Containers & Orchestration Explained
https://www.mongodb.com/collateral/microservices-containers-and-
orchestration-explained
• Microservices: The Evolution of Building Modern Applications
https://www.mongodb.com/collateral/microservices-the-evolution-of-
building-modern-applications
Notes de l'éditeur
Margret Hamilton. NASA Director of Software Engineering, and Chief software engineer on the Apollo program.
50 Years Later!
22nd November
The highest award that can be given to a civilian.
The last of Obama’s Presidency
Yes, that’s Bill in the background.
Developed the Apollo flight computer, which got Neil Armstrong and Buzz Aldran to the moon, and saved their lives in the process.
NASA’s Apollo program was some of the most complex software development projects ever, because of the need to co-ordinate many software developers.
During the 1970s and 1980s Only NASA / IBM / HP/ and even Microsoft scale operations could afford the process and management overhead that big monoliths required
People were getting killed, property was getting damaged.
But then something changed, and software evolved.
Then, in the early 90’s ‘Version Control” solutions started to appear, notably BitKeeper and Sun’s Teamware
which allowed developers to collaborate on projects, and Peer review each others code
Early examples include Linux, which now has nearly 10,000 developers representing the interests of over 1,000 different companies.
The difference between Windows 3.1 and Windows 95
Writing Monolithic applications became comonplace, even easy
But Monolithic Architecture poses some significant problems:
How many of you run mission critical applications built by developers who are no longer on your team?
…
This is the genius of Margret Hamilton, Grace Hopper and all the others of their time. They knew what it took to build software that you can stake your life on.
Spaghetti Code
Reverse engineer?
No one understands entire code base
Change one line of code, impacts scores of other, unexpected places
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
Easier to remove or change a piece but still need to make sure that it fits back together properly
SOA was billed as a way of delivering code re-use but people ended up designing for efficiency instead.
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.
Add a new flavor independently.
Chef making chocolate knows that well but need not know the others
Blueberry goes out of fashion, remove them
Need more green cakes, add them
Improved pink frosting, throw out the old ones and the new ones.
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
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
Modern Architectures need modern data stores
The implication of many discrete services making up an application is a change in data access patterns.
ETL is an archaic process, born out of a time when data could only be stored in tables. It’s not needed any more.
If ETL is a critical part of your application, you are storing your data the wrong way.
Flexibility to deploy
-on prem
-in cloud, or hybrid
-or completely managed.
Moving parts; Orchestration doesn’t monitor
Agility
DB per microservice
Monitoring & automation
You have lots of moving parts in a microservice architecture – need to monitor and automate as much as possible
Flexible data model
Fits in with the need to be agile
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
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
Normal rules still apply
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
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