Monoliths, Myths, and Microservices - CfgMgmtCamp
1 like2,296 views
The document discusses microservices architecture, emphasizing its characteristics, complexities, and common myths, including misconceptions that microservices solve all problems or can be adopted by any organization. It highlights the importance of modern practices like continuous integration and the need for a well-managed data tier. Additionally, it introduces Habitat as a solution for building and managing applications across various environments, focusing on automation and operational responsibility.
Monoliths, Myths, and Microservices - CfgMgmtCamp
- 1. Monoliths, Myths, and Microservices Michael Ducy - Chef @mfdii
- 2. A quick refresher • Let’s define microservices: The term "Microservice Architecture" has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data. http://www.martinfowler.com/articles/microservices.html
- 5. Myth #1: Simpsons Did It
- 7. I did that in 2005, yawn
- 8. Stop, It’s not SOA • Services tend to have smaller concerns than SOA Services • Architectural Concepts incorporates Innovations: – In Infrastructure – In Automation – In Continuous Delivery – In Development – In Monitoring http://www.martinfowler.com/articles/microservices.html
- 9. Myth #2: MicroServices Only Need Apply
- 10. Myth #2: Microservices Only Need Apply “Microservices is the only architectural pattern we need” • Microservices introduces complexity in operations – Pay down the complexity first? – Pay it down later (technical debt) • What if your idea doesn’t work? • What if your project is scrapped?
- 11. Myth #2: Microservices Only Need Apply • Be Lean in your thinking • Often faster to start developing in a non microservices architecture – Componentize your application – Split later • You don’t have a scaling problem, yet – But you might later, then look at microservices
- 12. Myth #3: Everything’s solved by containers and microservices
- 14. Myth #3: Everything’s solved by containers and microservices • Containers fit very well with the microservices model – Serverless might fit even better! • Great for your Application Logic • Stateless!
- 15. Myth #3: Everything’s solved by containers and microservices http://www.martinfowler.com/articles/microservices.html
- 16. Myth #3: Everything’s solved by containers and microservices
- 17. Myth #3: Everything’s solved by containers and microservices • Great for your Application Logic • Not (always) great for your data • Data tier needs to be managed – VMs, Config Management – StatefulSets (Kubernetes) – Mesosphere (more than Containers) – Cloud Services • Data tier need to be “Self Service” – Like AWS RDS, etc
- 18. Myth #4: Anyone can do Microservices
- 19. Myth #4: Anyone can do Microservices • Anyone except your organization • Have you adopted: – Continuous Integration? – Continuous Delivery? – Infrastructure As Code? – Modern Monitoring and log aggregation? – Cloud? – Fiction-less Change Management?
- 20. Myth #4: Anyone can do Microservices Microservices won’t fix: – Your broken culture – Your lack of modernization – Your broken process – Your ineffective org chart
- 23. Myth #5: I shouldn’t do microservices
- 24. Myth #5: I shouldn’t do microservices
- 25. Myth #5: I shouldn’t do microservices • What got you here won’t get you there. • Forcing function to modernize – Continuous Integration – Continuous Delivery – Infrastructure As Code and Automation – Modern Monitoring and log aggregation – Cloud – Containers – Fiction-less Change Management
- 26. Guiding Microservices Principles • Componentization via Services • Intelligence in the end point • Decentralization • Automated deployments
- 27. Modern/Cloud Native Arch ● Reduces developers concerns of underlying infrastructure ● Follows principles of Twelve-Factor applications ● Automation designed to handle deployment, scaling, and failure scenarios
- 28. Enter...Habitat
- 29. Stateless vs Stateful STATELESS APPLICATIONS ● Great for PaaS or Containers ● Application instances are “Ephemeral” ● Relies on backend services via an API for data storage ● Operational logic built into the application code STATEFUL APPLICATIONS OR SERVICES ● Provides persistent storage ● Provides required services for stateless applications ● Operational logic handled at OS/infrastructure layer
- 30. For new and legacy applications. For stateless and stateful applications No matter the runtime environment Habitat’s Approach The solution should be the same: ● Applications: portable & responsible for their own automation ● Small OS serves the application ● Make application components aware of each other over a network ● Continuous deployment without traditional “ARA”
- 31. Habitat’s technology ● Describes how to build the software ● Explicit about dependencies ● Includes what is configurable about the application ● Built in service discovery ● Self-organizes into topologies ● Handles inter-service discovery through binding ● Has no single point of failure BUILD DEPLOY MANAGE ● Encrypted, authenticated run-time configuration ● Automatic, safe, atomic software updates ● Dynamic topology updates
- 32. SERVICE SUPERVISOR SERVICE SUPERVISOR SERVICE SUPERVISOR SERVICE SUPERVISOR USER ARTIFACT How we do it Packaging Applications Running Applications PLAN DEPOT DEPOT ARTIFACT BARE METAL CONTAINERS AMI VM
- 33. How we do it LEADER INITIALIZER STAND ALONE Topologies Update StrategyRunning Applications SERVICE SUPERVISOR SERVICE SUPERVISOR SERVICE SUPERVISOR SERVICE SUPERVISOR SERVICE SUPERVISOR SERVICE SUPERVISOR “ALL AT ONCE” ARTIFACT DEPOT SERVICE SUPERVISOR
- 34. SERVICE SUPERVISOR SERVICE SUPERVISOR SERVICE SUPERVISOR SERVICE SUPERVISOR SERVICE SUPERVISOR SERVICE SUPERVISOR How we do it Security PUB KEY SYMMETRIC ENCRYPTION LOAD BALANCER Build Service BUILD SERVICE USER SECRET PAYLOADS SERVICE SUPERVISOR SERVICE SUPERVISOR SERVICE SUPERVISOR SERVICE SUPERVISOR SERVICE SUPERVISOR SERVICE SUPERVISOR ARTIFACTPLAN DEPOT
- 35. What the modern application team gets ▪ Runs the same way in any environment ▪ Management travels with the application; no drift ▪ Autonomous and self-organizing ▪ Legacy and Greenfield ▪ Lets the enterprise modernize without re-writing the world ▪ Faster to build, easier to deploy, safer to manage ▪ Easiest way to deploy containers and microservices in production ▪ Developers can focus on building great applications ▪ Systems Administrators can focus on how those applications should behave ▪ Gives both a language they can share, with clear boundaries Simplification Acceleration Empowerment
- 36. Habitat + Containers ● Container formats recreate the traditional model of infrastructure and applications. ● Poor at abstracting the Build + Run aspects of Applications Libraries Operating System Application Application & Libraries ● Habitat builds containers from the application down ● Small lightweight OS included ● Embedded Supervisor for Application Management Application Libraries OS
- 37. Demo!
- 38. CfgMgmtCamp Talks Monday ● Containers 14:00 - Monoliths, Myths, and Microservices ● Containers 16:20 - An upside-down Exploration of App Automation with Habitat Tuesday ● Main Track 14:00 - Operating Systems are Assholes ● Future Tooling - 14:40 - Now That I Have Choreography, What Can I Do With It?
- 39. Come contribute! • Write a plan for an application https://github.com/habitat-sh/core-plans • Contribute to Habitat https://github.com/habitat-sh/habitat • Docs https://www.habitat.sh/docs/overview/ • Tutorial https://www.habitat.sh/tutorials/ • Tweet at me: @mfdii