Moving from a monolithic based architecture to a more microservices architecture can be fraught with challenges. We'll talk about some of these challenges and some common myths associated with trying to strangle the Monolith. We'll also talk about config management and automation's critical role in helping you move to a microservices architecture, and how our monolithic approach to automation changes in the new world.

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

4. 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

13. http://www.martinfowler.com/articles/microservices.html

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

21. Because Conway’s Law
http://www.martinfowler.com/articles/microservices.html

22. Because Conway’s Law
http://www.martinfowler.com/articles/microservices.html

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