The Rise of Microservices
•Download as PPTX, PDF•
1 like•285 views
Overiew of the history of Microservices and how they can be used today.
Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (20)
Similar to The Rise of Microservices
Similar to The Rise of Microservices (20)
More from Joe Drumgoole
More from Joe Drumgoole (20)
Recently uploaded
Recently uploaded (20)
The Rise of Microservices
- 1. The Rise of Microservices Jim Blackhurst Senior Solutions Architect
- 3. Margret Hamilton, being awarded the Presidential Medal of freedom – November 2016
- 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.
- 8. 1990s & Earlier Monolithic Cross-Team Tight Coupling Small Change Huge Impact System Retests
- 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
- 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
- 16. Container Security Opportunities • Isolation • Constrain resources • Narrow roles • Keep images/containers current
- 17. Orchestration Automated deployment, connecting, and maintenance of multiple containers • Provision hosts • Containers • Instantiate • Reschedule • Link • Scale Out/In • Expose services
- 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
Editor's Notes
- 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