aws summit auckland - smaller is better - microservices on aws

© 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

Craig S. Dickson, Solutions Architect, Amazon Web Services

John Sullivan, Product Development Manager, Online SME and Practice Solutions, MYOB

Australia

Smaller IS Better – Exploiting Microservices on

AWS

Technical 201

Business

101 Technical

201 Technical

301 Technical

401 Technical

Session Depth

Presentation Takeaways

When you leave today, you will be able to answer the

following questions:

• What are Microservices?

• What do they look like on AWS?

• What problems can you address using a Microservices

Architecture?

• Is there a Customer Success Story I can Leverage?

• How do I get “Microserviced”?

Who Are You?

• Architect

• Developer

• SysOps / Server Admin / Networking

• Development Manager

• CTO

What is a Microservice?

Google has been Getting a Workout …

https://www.google.com/trends/explore#q=microservices

High Expectations …

Microservices

https://www.gartner.com/doc/3102217/hype-cycle-application-architecture-

“Microservices are the first post

DevOps revolution architecture”

– Neal Ford

(Director, Software Architect, and

Meme Wrangler at ThoughtWorks)

Image: http://nealford.com/bio

Why does everyone

hate me?

Image: 1869/ptwo/license

What’s Wrong with a Monolith?

Self Contained Tightly Coupled Lacks Modularity

A Definition of Microservices

“… is an approach to developing a single application as a suite of small

services, each running in its own process and communicating with

lightweight mechanisms, often an HTTP resource API. These services

are built around business capabilities and independently deployable by

fully automated deployment machinery. There is a bare minimum of

centralized management of these services, which may be written in

different programming languages and use different data storage

technologies.”

- Martin Fowler (Chief Scientist, ThoughtWorks)

- James Lewis (Principal Consultant, ThoughtWorks)

“Say hello to my micro friend!”

- Tony Montaña

(Cuban Software Architect)

Image: http://www.amazon.com/Scarface-Limited-Edition-Blu-ray-Digital/dp/B0019N94X6

Umm, isn’t this just SOA?

SOA Microservices

Smart pipes, dumb endpoints Simple pipes, smart endpoints

Centralised governance (ESB) Minimal governance

Proprietary standards Open standards

Services provide myriad functions Services are single purposed

Distributed monoliths?

A Well-Architected Microservice on AWS

1. Cannot be made any smaller

• has a single functional purpose

• has minimised total lines of code, architecture components, etc.

• is cost optimised

2. Is vertically isolated

• runs in its own process

• uses the best fit-for-purpose architecture (app. & infra.)

• uses the best fit-for-purpose programming language

• uses the best fit-for-purpose persistance option(s)

A Well-Architected Microservice on AWS (2)

3. Has a well defined interface (API)

• can be versioned

• provides SDKs & documentation for clients

• no backdoors

4. Is automatically and independently deployed

• first deploy and all updates

• to all environments, not just test and dev.

5. Is automatically tested thoroughly

• functional, integration, performance, etc.

• baseline metrics collected and evaluated

A Well-Architected Microservice on AWS (3)

6. Is operationally mature

• horizontally scalable

• self healing

• metrics & logs collected centrally

• elegantly handles failures of downstream services

7. Is managed by a small team (2 pizzas?)

• co-located & cross-functional

• back-end devs, UX, ops, DBA, etc.

• with cradle-to-grave responsibilities

Microservice Patterns on AWS

The Poor-Man’s Microservice

Clients

Elastic IP

RDS

HTTP

REST

Running EC2

Instance

Auto Scaling Group

AZ-A

AZ-B

Min = 1, Max = 1

Future EC2

Instance

The Traditional Microservice

ClientsRDS

HTTP

REST

EC2

Instance

Auto Scaling Group

AZ-A

AZ-B

Min > 1

Elastic Load

Balancing

EC2

Instance

AWS

OpsWorksAWS Elastic

Beanstalk

And don’t forget …

.

That’s nice, but can we

make it smaller?

Image: http://www.nowverybad.com/honey-i-shrunk-the-kids-1989/

The Elastic Container Service Microservice

ClientsRDS

HTTP

REST

ECS Fleet

AZ-A

AZ-BElastic Load

Balancing

Servers? Where we’re

going, we don’t need

servers

- Doc Brown

(Early Cloud Adopter)

Image: http://memorydelta.wikia.com/wiki/Emmett_Brown

“No server is easier to

manage than no server”

- Werner Vogels

(CTO, Amazon.com)

Image: 20081108 DDP Werner_Vogels/Guido van Nispen/license

The Serverless Microservice

Clients

HTTP

REST

AWS

Lambda RDS

Never pay for idle!

The Serverless Microservice API

Amazon API

GatewayClients

HTTP

REST

AWS

Lambda

Amazon

S3

Amazon

DynamoDB

Amazon Machine

Learning

Amazon

SNSAmazon

SQS

Amazon

Kinesis

Lambda

Blueprints

The Hybrid Microservice API

Amazon API

GatewayClients

HTTP

REST

Amazon

EC2

AWS

Lambda

Lambda

Blueprints

Amazon ECS

Elastic Load

Balancing

The Micro-Microservice API

Clients

Amazon API

Gateway

Free

Amazon API

Gateway

Premium

Amazon API

Gateway

Partner

Amazon API

Gateway

Experimental

Amazon

EC2

Amazon ECSAWS

Lambda

Lambda

Blueprints

Exploiting Microservices to

Address Business Problems

• Product Management has a great idea

• Even better: Product Management has many

great ideas, but are not sure which ones are

winners

• Takes weeks, months or worse to get them in

front of a customer

• A massive barrier to innovation

Problem: Long Feature Cycle Times

• Create an architecture that enables rapid change, inherently

supports agility and encourages innovation

Exploit Microservices to …

Conway’s Law

“organizations which design

systems ... are constrained to

produce designs which are copies

of the communication structures of

these organizations”

- Melvin Conway

Image: https://twitter.com/conways_law

• Large pieces of software, require large teams

• Increased inertia, lack of agility

• Hard to integrate work from other teams

• Many problems are actually people problems, not

technology problems

Problem: Large Teams

• Create an architecture that encourages smaller

software components

• Better align team size and responsibilities to

services


“Being woken up at 3am every

night by your pager is certainly a

powerful incentive to focus on

quality when writing your code.”

- Martin Fowler

Image: https://en.wikipedia.org/wiki/Martin_Fowler

• Monoliths lead to “shared” responsibilities

• Focus is on project deliverables, not full lifecycle

Problem: Lack of Ownership

• Create small teams working on small pieces of

functionality

• Provide an opportunity for cradle-to-grave

ownership

• Foster a “You build it, you run it” philosophy


• Geographically, Temporally, Organisationally

• Burden of orchestration

Problem: Distributed Teams

• Provide a mechanism to divide work up so that

only co-located teams have to collaborate heavily

• Define service level APIs that allow distributed

teams to move at different velocities


• Upskilling takes time

• Unable to make use of temporary resources

Problem: Inelastic Human Capacity

• Reduce the surface area that individuals need to

understand at any one time

• Enable temporary resources to work quickly and

integrate easily


Netflix slide

• Lack of Availability = Loss of Revenue

• Small issues rendering whole applications

unusable

Problem: Availability

• Encourage a design-for-failure attitude

• Enable individual services to implement

appropriate fall-back plans and continue to

provide value to customers


• Cannot create à la carte application offerings to

users

• Cannot easily get feedback about new ideas

before investing large resources

Problem: Product Management

• Enable flexibility for product management and

increase innovation

• Quickly test ideas by combining strategies such as

Feature Toggling and A/B Testing


Exploiting Microservices to

Address Technical Problems

"I suppose it is tempting, if the only tool you have is

a hammer, to treat everything as if it were a nail.”

- Abraham Maslow (1966)

Maslow’s Hammer

Image: DSC_1607/Justin Baeder/license

“Give a small boy

a hammer, and he

will find that

everything he

encounters

needs pounding.”

- Abraham

Kaplan (1964)

Image: Thor and his hammer/tenthousandcubans/license

• Different teams forced to use/learn technologies

that they are not effective with, just because it is

“the standard”

• Inability to adopt different or emerging

technologies

Problem: Single Technology Syndrome

• Encourage a polyglot attitude

• Allow the best solution for each problem to be

selected


• Fear of deployments due to assumed risk

• Large deployment sizes due to dependencies

Problem: Constrained Delivery Velocities

• Allow different parts of applications to move at

different speeds for development and deployment

activities

• Minimise risk by reducing the deployment sizes

down to single services


• Large functional surface area

• All potential failure scenarios are hard to define

• Long running tests delay feedback

Problem: Lack of Testability

• Provide well defined APIs that can be deployed in

isolation

• Allow for quicker, yet more complete testing


• Standardising onto limited EC2 instance types

• Using generic scaling strategies

• Scaling every thing, every time

• Failing to use existing AWS services

Problem: Inefficient Scaling

• Allow the correct scaling option for each service to

be selected

• Scale services independently

• Quickly adopt new AWS services


• Inability to easily/safely try new algorithms or

patterns

• Inability to quickly adopt disruptive technologies

Problem: Lack of Technical Innovation

• To encourage vertical decoupling of components

• Evolve individual services quickly without

interfering with other parts of an application


© 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

John Sullivan – Product Development Manager, Online SME and Practice Solutions, MYOB Australia

MYOB’s Journey to Microservices

An AWS Customer Success Story

MYOB & Microservices?

“Why Microservices” came

together like a puzzle:

• Move to online

• Demand for feature richness

• Functionality reuse

• Skills reuse

• Hosting products

Microservices: The Tool not The Destination

Safety Gear

Evolving to Microservices

Microservices may not be

the right choice for you.

Image: http://insec.in/blog/2015/01/09/discounts-ethical-hacking-course-in-kolkata/shocked-woman-1/

Before Adopting Microservices

• Are you are a startup?

• Is this a brand new green field project?

• Do you have a deep understanding of the domain?

• Is your organisational structure compatible?

• Have you adopted DevOps practices?

Consider these questions …

“A microservices-first approach for a

brand new project that we didn’t fully

understand the domain for led to a

lot of unexpected complexity. We

are however, having great success

on another project refactoring an

existing monolithic service into

microservices.”

- Mark Bond

(Group Architect, Dominos Pizza Enterprises)

Mo’ services, mo’ problems

The Notorious B.I.G.

(Influential East-Coast Software Architect)

Image: http://www.neontommy.com/news/2014/03/notorious-big-top-ten-songs

Focus on DevOps and Automation

• Even a medium scale microservices architecture (10s or

100s of services) is difficult to manage by hand

• Invest in automating EVERYTHING

• Code builds and testing (CI)

• Code deployments to all environments (CD)

• Operational monitoring

• CloudWatch Metrics, CloudWatch Logs, custom dashboards etc.

• A/B testing, function toggling

Focus on Your Organisation

• Evolve team sizes and responsibilities

• Moving towards smaller, cross-functional teams

• With cradle-to-grave responsibilities

• Integrate Product Management, QA, Ops, etc.

Focus on Your Services

• Business capability, rather than technical function

• Everything fails, all the time

• retry, fail-over and service down scenarios

• the circuit-breaker pattern

• Netflix Hystrix

• Centralised metrics and logging collection

Conclusion

µSummary

7 Tenets

7 Architecture Patterns 8 Business Problems

6 Technical Problems 1 Great Customer Story

1 Big Warning 3 Tips for Evolving

13 Awesome Jokes (at least)

What You Should Do Next

µAWS Lambda Amazon API Gateway Identify problems

Hunt MonolithsChampion Microservices Get Help

Resources

• Microservices – Martin Fowler & James Lewis

• http://martinfowler.com/articles/microservices.html

• Introduction to Microservices – Chris Richardson

• https://www.nginx.com/blog/introduction-to-microservices/

• Are You Well Architected? – AWS Blog

• https://aws.amazon.com/blogs/aws/are-you-well-architected/

• Netflix Hystrix

• https://github.com/Netflix/Hystrix

http://martinfowler.com/articles/microservices.html

https://www.nginx.com/blog/introduction-to-microservices/

https://aws.amazon.com/blogs/aws/are-you-well-architected/

https://github.com/Netflix/Hystrix

AWS Training & Certification

Intro Videos & Labs

Free videos and labs to

help you learn to work

with 30+ AWS services

– in minutes!

Training Classes

In-person and online

courses to build

technical skills –

taught by accredited

AWS instructors

Online Labs

Practice working with

AWS services in live

environment –

Learn how related

services work

together

AWS Certification

Validate technical

skills and expertise –

identify qualified IT

talent or show you

are AWS cloud ready

Learn more: aws.amazon.com/training

https://aws.amazon.com/training/

Your Training Next Steps:

Visit the AWS Training & Certification pod to discuss your

training plan & AWS Summit training offer

Register & attend AWS instructor led training

Get Certified

AWS Certified? Visit the AWS Summit Certification Lounge to pick up your swag

Learn more: aws.amazon.com/training

https://aws.amazon.com/training/

Thank you!