Microservices:
Notes From The Field

Josh Ellithorpe - 2015

@zquestz

Shoulders of Giants

Why Microservices?

  • Nexus of business and technology forces including: 
    Mobile / Big Data / Social / Cloud / IOT

  • Organizational change to a DevOps workflow.

  • Leverage technology enablers in the open source space.

  • Containers make microservices easy to setup and deploy.

What is a Microservice?

​Culture

  • Development team structure and process must mirror the service design.

  • DevOps teams, tools, and processes must be in place.

Characteristics

  • An app deployed as a set of independent components each running in its own process.
  • Can be updated and deployed independently in an automated fashion.
  • Uses lightweight, async, and simple communication channel like REST.
  • Immutable. Externalizes data persistence and configuration.
  • Follow DDD (Domain-Driven Design) bounded context, avoid cross service transactions.

Benefits

  • Small independent teams deliver faster.

  • Can easily scale out by adding service instances.

  • Clear ownership – reduces risk and enables innovation.

  • Forces declarative dependency tracking.

  • Less dependencies an individual developer must track.

  • Automated testing and rollback increases resiliency.

  • Technology diversity – each team is free to use any language or platform.

Risks

  • Are my DevOps processes and tools mature enough to handle constant change?

  • Who will manage all the new dependencies – KV Store, Registration, Discovery, Registry, etc.

  • How do I secure and patch all these services?

  • How do I manage isolation and tenancy for thousands of service instances?

  • How do I track resource allocation and prevent zombies?

  • Eventual consistency is really hard.

  • Breaking down the monolith is risky and costly.

  • Does TDD impact developer productivity?

  • How do I manage service dependencies?

  • How to deal with persistence and database schema updates?

  • Debugging and monitoring is much more complex.

Best Practices

  • Each microservice must be owned by one and only one team.

  • Team structure should mirror system design.

  • Team size of 4 to 8 members.

  • Write tests, then code, then check-in and deploy.

  • Use feature toggles.

  • Abstract cross service calls through a standard library – focus on functionality.

  • Smart endpoints, stupid pipes.

  • Use circuit breaker, canary deploys and automated rollback.

  • Independent persistence layer for each service.

  • Be incremental and start with the Web tier.

  • Excellent logging, stats collection, and monitoring.

Building Blocks

  • Container Engine – Docker, LXC/LXD, RKT, Apcera.

  • Container OS – Redhat Atomic, VMWare Photon, CoreOS, RancherOS, Snappy, KurmaOS

  • Proxy/Load balancer – Nginx, HA-Proxy

  • Registry – Docker OSS, Docker commercial, CoreOS Quay, Jfrog Artifactory

  • Key Value Store – Zoo Keeper, ETCD, Consul

  • Service Registration / Discovery – Consul, SkyDNS

  • Blueprint / Policy – Apcera, Apache Brooklyn

  • API / Message Bus – Gnats, AKKA, Drop Wizard, Spring Boot

  • Persistence/Storage Services – ClusterHQ, ConvergeIO

  • Network – Libnetwork, Weave, OVN, Flannel 

Management Platforms

  • Nirmata – Netflix Docker manager, vSphere, AWS, OpenStack

  • Mesosphere DCOS – Aurora, Hadoop, Marathon (Beta)

  • Tutum – Docker-focused, AWS & Azure, CI.CD

  • Kubernetes – Tectonic, OpenShift V3

  • Deis (Engine Yard) – Docker-based PaaS

  • Cloud Foundry / Diego/ Garden / Lattice – Docker-like Microservice PaaS

  • Apcera Hybrid Cloud OS – Policy, multiple clouds and diverse workloads

We're Hiring!

Think microservices and containers are the future?

 

Interested in helping shape the future of enterprise IT?

 

Contact us at jobs@apcera.com

Microservices: Notes From The Field

By Josh Ellithorpe

Microservices: Notes From The Field

  • 737

More from Josh Ellithorpe