Cloud Native Application Architecture

Dave Syer, 2015

Authors

Dave Syer,
@david_syer,
dsyer@pivotal.io

Cloud Native

  • What is it?
  • Why do we need it?
  • How do we do it?

Does This Sound Good?

  • Speed
  • Safety
  • Scale
  • Mobility

Not Monoliths…​

monoliths

Not Traditional (ESB-centric) SOA…​

esb soa

But Microservices!

death star

Is There Maybe Some Hype?

cat-with-unicorn

Microservice

Loosely coupled service oriented architecture with bounded contexts…​

@adrianco

If every service has to be updated in concert, it’s not loosely coupled.

If you have to know about the internals of surrounding services you don’t have a bounded context.

Monoliths

  • Modularity dependent on language / framework
  • Change cycle tightly coupled → obstacle to frequent deploys
  • Inefficient scaling
  • Intimidating to new developers (and for old ones)
  • Obstacle to scaling feature development
  • Requires long-term commitment to stack

Easy but Complex

Microservices

  • Modularity based on component services
  • change cycle decoupled → frequent deploys
  • Efficient scaling
  • Individual components easy to understand
  • Enables scaling development
  • Eliminates long-term commitment to stack

Simple but Hard

Wait, It’s Hard?

No such thing as a free lunch

  • Operations overhead
  • Devops skill shortage
  • Interface / context governance
  • Duplication of effort
  • Distributed system complexity
  • Asynchronous is difficult
  • Testability challenges

12-Factor Application Patterns

  • Optimized for speed, safety, & scale
  • Declarative configuration
  • Stateless/shared-nothing processes
  • Single binary distribution per process
  • Loose coupling to application environment

Microframeworks

dropwizard spring-boot

Spring Boot

  • http://projects.spring.io/spring-boot
  • Opinionated convention over configuration
  • Production-ready Spring applications
  • Embed Tomcat, Jetty or Undertow
  • STARTERS
  • Actuator: Metrics, health checks, introspection

No Microservice is an Island

island-house

Challenges of Distributed Systems

  • Configuration Management
  • Service Registration & Discovery
  • Routing & Load Balancing
  • Fault Tolerance (Circuit Breakers!)
  • Monitoring and Tracing
  • API Aggregation & Transformation

Spring Cloud

  • http://projects.spring.io/spring-cloud
  • Opinionated convention over configuration
  • Common patterns, pre-shaved yaks
  • Declarative distributed systems
  • Embed Netflix OSS and other popular tools (Zipkin, Kafka, Rabbit, Zookeeper, Consul, Hazelcast, Cloud Foundry)

Phew! Spring Saves the World

Q: There’s a technology solution to all those problems?

A: TL;DR Probably not

Process

cont-deliv
  • Deliver (Day One)
  • Continuously (Day Two and Beyond)

Sociology

inverse-conway

Some Practical Advice

Paraphrasing @adrianco:

Get out of the business of infrastructure and
automation (a.k.a. "undifferentiated heavy lifting")

 

  • Internet giants, ratio of app to infra developers = 10:1
  • Your business (= your apps) is special, your infrastructure is not
  • Don’t try to differentiate on something that is a commodity

You’re Going to Need a Platform

Platform features:

Infrastructure Application

Environment Provisioning

Distributed/Versioned Config

On-Demand/Automatic Scaling

Service Registration/Discovery

Failover Resilience

Routing/Load Balancing

Routing/Load Balancing

Service Integration

Data Service Operations

Fault Tolerance

Monitoring

Asynchronous Messaging

Anatomy of a Cloud Platform

spring-stack

What is Cloud Native?

If you make the rule that you own the code that you write, you soon get to know what #cloudnative means!

@david_syer

Links

← →

/