The Rise of Microservices

Editor's Notes

• #3: Margret Hamilton. NASA Director of Software Engineering, and Chief software engineer on the Apollo program.
• #4: 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.
• #5: 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
• #6: People were getting killed, property was getting damaged. But then something changed, and software evolved.
• #7: 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
• #8: 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.
• #9: 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
• #10: 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.
• #11: 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
• #12: 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
• #14: 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.
• #15: 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
• #16: 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
• #17: 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
• #18: 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