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
Microservice
Registry Health and Resiliency
Client
Microservice
Microservice
Microservice
Microservice
Convention
Whatever you
want
Microservice
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 Build Tools Test Suite
Dev Cloud
Blueprint
Web
Servers
App
Servers
Database
Servers
Load Balancer4
Firewall
Master Slave
QA Cloud
Blueprint
Web
Servers
App
Servers
Database
Servers
Load Balancer4
Firewall
Master Slave
Load Balancer
Release
Management
Blueprint
Web Servers
App Servers
Database
Servers
Load Balancer
Firewall
Master Slave
Ready for Produc on
Common Applica on
Pla orm
IT Opera 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

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
Application
Monolithic
Application

Re-Architecting an 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?

More Related Content

What's hot

Similar to Microservices: Why Should Businesses Care?

More from Akana

Recently uploaded

Microservices: Why Should Businesses Care?

Editor's Notes