microservices vs. mini vs. monoliths: winner takes all? · •ideally no inter-service...

JRebel by Perforce © 2019 Perforce Software, Inc.

Microservices vs. Miniservices vs. Monoliths: Winner Takes All? ROD COPE, CTO

jrebel.com 2 | Akana by Perforce © 2019 Perforce Software, Inc.

Rod Cope Bio: • CTO for Rogue Wave Software (now

Perforce) and the Founder and CTO of OpenLogic

• 25+ year software career includes IBM, IBM

Global Services, General Electric, and Anthem Blue Cross/Blue Shield.

• Worldwide event speaker, including: JavaOne, OSCON, Embedded World, ApacheCon, Strata/Big Data, LinuxCon, and API World.

Which is better?


Option A: Monolith


Option B: Microservices


Option C: Miniservices

Monolith


Component Interaction

http://serena-yeoh.blogspot.com/2014/01/layered-architecture-components.html


Three-Tier Architecture

www.SoftwareTestingMaterial.com


martinfowler.com


Monolith: culture 1

Traditional command and

control

One big team (or devs vs DBAs)

Waterfall-ish

Big design up front, integration

testing

Slow deployment cadence

Vertical scalability


Monolith: culture 2

Agile or scaled agile

Feature teams

Frequent, automated integration testing

Horizontal scalability


Versioning issues

Latency

Monolith: Advantages


Monolith: Advantages 2


Monolith: Advantages 3

One

Code base

Set of artifacts

Build process

Language

Platform

Toolchain


Monolith: challenges

• No small changes

• Technology lock-in

• Scale all or nothing

• Heavyweight deployment

• Version coordination

• Bug affects entire app

• Container concerns


Monolith: Best Practices

• Agile

• DevOps

• Layers and modules

• Horizontal scaling

• Development accelerators

Services


SOA: Service-Oriented Architecture

• Service:

• Logical business activity

• Self-contained

• Black box for its consumers

• Distributed, separately-maintained and deployed

• Not SOAP, WS-*, heavy process, central control, vendor lock-in

Microservices


Microservices in a Nutshell

UNIX PHILOSOPHY: “DO ONE THING AND DO IT WELL”

SOA FOR DISTRIBUTED TEAMS IN A WORLD OF DEVOPS

BOUNDED CONTEXT AND DOMAIN-DRIVEN DESIGN (DDD)


martinfowler.com


Microservices: Characteristics

Processes talking over network

Maybe IPC like shared mem Maybe same process like OSGi

bundles (like Akana)

Independently deployable

Easy to replace Organized around

capabilities (UI, suggestions, billing)

Independent implementation

(language, platform, data)

Small, message enabled, context bounded,

autonomously developed, decentralized

Built and released with automated

processes

Elastic, resilient, composable, minimal, and

complete


• Cannot share data storage

• Ideally no inter-service communication via REST/HTTP

• No synchronous communication to prevent cascading timeouts • All async messaging

• Eventual consistency

• Compensating operations

Loosely Coupled


SOA manifesto (2009) Microservices philosophy

Business value Technical strategy




Strategic goals Project-specific benefit





Intrinsic interoperability Custom integration






Shared services (reuse) Specific-purpose implementation







Flexibility over optimization Flexibility over optimization








Evolutionary refinement Evolutionary refinement


Microservices: Advantages

SMALL PROBLEMS

SMALL TEAMS SMALL SOLUTIONS

BEST TOOLS FOR THE JOB


Microservices: decisions

Service mesh / proxy

Communication

State management

Coordination

Deployment

Operations


Microservices: challenges

Distributed computing

01 Cognitive load

02 Service explosion

03 Team dynamics

04


Fallacies of Distributed Computing

1. Network is reliable

2. Latency is zero

3. Bandwidth is infinite

4. Network is secure

5. Topology doesn’t change

6. There is one administrator

7. Transport cost is zero

8. Network is homogenous


Microservices: culture

Automation

True DevOps

Embrace Failure


Microservices: Best Practices

• Extreme automation

• Service mesh

• API management

• Monolith first


Security

Mediation Transformation Orchestration Traffic

management Analytics

API service

API service

API service

API management

Security

Policies Traffic management Telemetry

Control plane

Service mesh

Microservice

Sidecar

Microservice

Sidecar

Microservice

Sidecar

• External focus

• Central/one

• Security

• Stability

• Internal focus

• Decentral/many

• Availability

• Flexibility


Microservices, Service Mesh, and MASA

• Microservice: Bounded context,

independent data store

• Service mesh: Internal

implementation fabric,

coordination

• Gartner MASA: Mesh App and

Service Architecture Gartner


martinfowler.com


API & Service Mesh Summary

• API management & service mesh address different needs

• Both critical for microservice architecture

• No one-size-fits-all solution

• Current best of breed:

Commercial API management Open source service mesh

ZUUL

Miniservices


Miniservices

• One function

• Bundle of microservices

• Fat container

• Relaxes some constraints • Data store sharing • Sync & HTTP


Miniservices: advantages

Less culture shock

Business value over architectural purity

Traditional web communication

Best tool for the job


Grok: Mono/ Macro

Mini Micro

Code

Architecture

?

?

✕

Reuse ✕

Change ✕ ?

Deploy ? ?

Versioning ? ✕


Conclusion

•One-size-fits-all is wrong

•Consider your needs • Your problem

• Your team

• Your timeframe


Questions?


Talk to our experts about securing your services of

any size and get a free security-first API strategy

assessment!

Are Your APIs Secure?

Stop by Booth #129

microservices vs. mini vs. monoliths: winner takes all? · •ideally no inter-service...

Documents