Microservices: Why Should Businesses Care?

© 2015 Akana., Inc All Rights Reserved.

Microservices

Why should business care?


What are Microservices?

• Microservices are a new way to build applications by breaking them up into

small, independent services

• No specific language

• No heavy middleware

• Mostly open-source

Loosely coupled service oriented architecture with bounded contexts - Adrian Cockcroft

Small autonomous services that work together - Sam Newman


Microservices Architecture

Mic

roserv

ice

Registry Health and Resiliency

Client

Mic

roserv

ice

Mic

roserv

ice

Mic

roserv

ice

Mic

roserv

ice Convention

Whatever you

want

Mic

roserv

ice

Load Balancing

Autogen


What defines a Microservice?

SOA + DevOps + Containers


What is DevOps?

• The developer interacts with the infrastructure directly

• Need fewer Operations staff – saves money

• Increases agility by removing roadblocks

Develop Test UAT Operate

IDE BuildTools TestSuite

DevCloud

Blueprint

WebServers

AppServers

DatabaseServers

LoadBalancer4

Firewall

Master Slave

QACloud

Blueprint

WebServers

AppServers

DatabaseServers

LoadBalancer4

Firewall

Master Slave

LoadBalancer

ReleaseManagement

BlueprintWebServers

AppServers

DatabaseServers

LoadBalancer

Firewall

Master Slave

ReadyforProduc on

CommonApplica onPla ormITOpera ons


What is Containerization?

• Easier to use

• More efficient

• Smaller – hence

suited to

Microservices


Are Microservices different to SOA?

• Vendor-driven SOA gave us SOAP and ESBs

• Microservices are a reaffirmation of SOA principles and a reaction to

vendor-driven SOA

– defacto standards/frameworks

– dovetail in agile

– dovetail in devops

– dovetail in containerization

• Microservices is unabashedly anti ESB

https://blog.akana.com/microservices-esb-anti-pattern/


What are SOA, APIs and Microservices used for

• SOA – is about reuse

– Building services that support multiple different applications

• APIs – is about supporting web and mobile applications – its about

integration

– Geared towards easier and better consumption of services

• Microservices – is about agility and scale

– Services enabling scalability and rapid feature cadence for a specific application


Why are Microservices so popular?

• Unscalable• Hard to manage• Hard to learn• Slow to deploy

• Scalable• Easier to manage• Easier to learn• Quick to deploy


How hard is it to adopt Microservices?

• Requires 4 things:

– Maturity of ops (need DevOps, Containerization)

– Willing to re-architect entire app

– Willing to invest in the App – must be strategic

– App must need to scale


Additional Guidance

• Two-pizza teams

• Microservices are highly focused on providing one capability - micro means

singly focused, not size

• Lightweight communication protocols

• Right tool for the job

• Microservices should have their own datastore separate from other

microservices

• A Microservice owner is responsible for its lifecycle (incl deploy and

operations)


Why should business care?

• Benefits

– Improved agility

– Better reliability, elasticity

– Global scalability

• Challenges

– Restructuring the IT organization – Agile, DevOps

– Investments in new frameworks & platforms

– Greenfield vs. Re-architecting

– New skills development

• Design

• Development

• Testing


Re-Architecting an Application

Monolithic

ApplicationMonolithic

Application








New Skills: Microservices Principals (Fowler)

1. Componentization via services [best technology for the job, common interface (restish)]

2. Organized around Business Capabilities

3. Products not Projects [Conway’s law of organizational slippery slope]

4. Smart endpoints dumb pipes [choreography vs. orchestration; choreographer leads]

5. Decentralized Governance [built into the service - share useful patterns via libraries; less overhead; consumer-focused service contracts]

6. Decentralized Data Management [domain driven design bounded context, etc.]

7. Infrastructure Automation

8. Design for Failure

9. Evolutionary Design


Design

• Traditional design oversight is out the window -

everyone will use the best tools available to create

the microservice – Control the interface

• Facilitate a design-time review of available services

and a ‘request for service’

• Adopt convention - interface must provide for

health/resiliency information

• Design for failure - services should provide health

status

• Design for robustness - services can self-proxy

• Distributed data design - domain-driven design

patterns


Development

• Development team must know about other available services, etc. - tooling

• Development team must know what libraries, strategies, patterns will

provide for resiliency, health, bulkheads, alternatives

• Development team will get to know a lot more about the SDLC before them

and after - full lifecycle responsibility

• Development team – agile with QA intimately involved

• Distributed data management requires eventual consistency

accommodation


Testing

• Unit, Integration and Component level

testing still exists but have nuances specific

to microservices

• End-to-end and Integration testing will have

to account for new paradigms for

microservices - registry, health dashboard -

and build in these scenarios


Questions

www.akana.com

Microservices: Why Should Businesses Care?

Internet

microservices different

containerization microservices

microservices microserviceswhy

soa devops containers

specific application

business care

moneyincreases agility

reusebuilding services