Monoliths, Myths, and Microservices

Michael Ducy - Chef@mfdii

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

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

Myth #1: Simpsons Did It

I did that in 2005, yawn

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

Myth #2: MicroServices Only Need Apply

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?

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

Myth #3: Everything’s solved by containers and microservices

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

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!

Myth #3: Everything’s solved by containers and microservices

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

Myth #3: Everything’s solved by containers and microservices

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

Myth #4: Anyone can do Microservices

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?

Myth #4: Anyone can do Microservices

Microservices won’t fix:– Your broken culture– Your lack of modernization– Your broken process– Your ineffective org chart

Because Conway’s Law

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

Because Conway’s Law

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

Myth #5: I shouldn’t do microservices

Myth #5: I shouldn’t do microservices

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

Guiding Microservices Principles

• Componentization via Services• Intelligence in the end point• Decentralization• Automated deployments

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

Enter...Habitat

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

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”

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

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

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

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

USERSECRET

PAYLOADS

SERVICE

SUPERVISOR

SERVICE

SUPERVISOR

SERVICE

SUPERVISOR

SERVICE

SUPERVISOR

SERVICE

SUPERVISOR

SERVICE

SUPERVISOR

ARTIFACTPLAN DEPOT

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

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

Demo!

CfgMgmtCamp TalksMonday

● 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?

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