Pensi di essere pronto per i microservizi?

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T
Think you are ready for
Microservices?
Luca Bianchi
CTO
Neosperience
Federico Nebiolo
Technical Account Manager
AWS

What to expect from this session
> Key Business Drivers for Microservices Adoption
> Expectations & Challenges
> How to start, today? Best-Practices

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I TS U M M I T © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.
”services in a MSA are often independently
deployable processes that communicate
over a network to fulfill a goal using
technology-agnostic protocols”
Martin Fowler. "Microservices", 2014

Characteristics of Microservices

Monolythic Applications
• Functional teams are responsible for
different layers
• Business requirement involves
multiple layers, i.e. multiple teams
• Common deployment
• Quarterly or annually release cycles

Microservices & Small, Independent Teams
• Do one thing well – Requires knowledge
of a small, well-understood domain.
• Independent – Empowers small,
independent teams to move at their own
pace → shortening the cycle times
• You build it; you run it – Fully-
responsible incl. QA, deployment, and
production

Benefits & Challenges
Break-down the monolith along
meaningful domain boundaries
Do one thing well – Requires
knowledge of a small, well-
understood domain.
• Requires Cross-Functional Team
with all necessary skills
• Increased Architectural and
Operational Complexity
Independent – Empowers small,
independent teams to move at
their own pace → shortening the
cycle times
Requires different deployment
technics & operations model
You build it; you run it – Fully-
responsible incl. QA, deployment,
and production

Where to start?Youbuildit;
yourunit
• Continuous Deployment: CI/CD
pipelines
• Test Automation
Requires different deployment
technics & operations model
Doone
thingwell
Decompose into 2-3 services along
main business domains
Break-down the monolith
along meaningful domain
boundaries

How AWS can help?
Separation of Concerns
• AWS Features, e.g. Multi-Account Strategy
Continuous Deployment
• AWS Services for CI/CD
• On-Demand Resources & Infrastructure Automation
Architectural & Operational Complexity
• Managed Services, Serverless?
• Architecture Review by Solutions Architect

How can AWS help?
Workflow

Microservices & Innovation
Do one thing well – Vertical alignment with
the business owners
Independent – Fast-feedback loops
& low cost of failure
Decentral & Polyglot – freedom to choose
and replace the technology stack
individually (per domain)

Do one thing well – Vertical
alignment with the business owners
Independent – Fast-feedback loops
& low cost of failure
Synergy effects such as sharing
libs and people get lost
Decentral & Polyglot – freedom
to choose and replace the
technology stack individually
Cultural of experimenting &
failure tolerance needed
Cultural transformation, from
hierarchical decisions to empowered
teams

Where to start?Doone
thingwell
• Retreat governance structures
• Shift business model to product
strategy
Cultural transformation, from
hierarchical decisions to
empowered teams
Independent
• Identify business KPIs to measure
success / failure
• Embrace change & experiments,
evaluate the risks
Cultural of experimenting &
failure tolerance needed

How AWS can help?
Culture of Innovation - Learn from Amazon‘s experience
and culture: Working backwards, two-way doors
decisions, two-pizza teams, etc.
Technological Innovation - Benefit from the breadth of
AWS services and AWS pace of innovation
Experiment with low cost and risk – On-demand, pay-
per-use reduces the cost of experimenting with new ideas.

Microservices & Scalability
• Independent – Properly decoupled
services can be scaled horizontally and
independently from each other
• Decentral – leverage the optimal data
persistence solution per service
• Polyglot – appropriate and optimal
technologies for a specific service

Independent – Properly decoupled
services can be scaled horizontally
and independently from each other
• Put individual scalability
measures in place
• Identify scalability bottlenecks
in overall system
Decentral & Polyglot – leverage
the optimal technologies for a
specific service
Overall system scalability
difficult to understand

Where to start?Scalability
Drivers
• Identify & measure scalability
drivers
• Know your limits, perform
scalability tests
Make scalability tangible to
enable focused architecture
decisions
Classic
• If needed break monolith along
different scalability requirements
• Employ classical options for
horizontal scaling
Follow classical approach for
distributed systems

Monitoring microservices
Web service dashboard
• Local time and UTC
• Healthy, unhealthy, and
running tasks
• Latency average and
percentiles
• Number of requests
• CPU and memory utilization
(min/avg/max)
• Service errors by AZ
• ALB errors by AZ

How AWS can help?
AWS Services
• Auto-Scaling Features
• Monitoring & Automatic Response
• Amazon CloudWatch monitors more than 1 quadrillion (or 1015)
metric observations, triggers more than 3.9 trillion events, and ingests
more than 100 petabytes of logs per month [October 2018]
• Serverless?
• AWS Lambda processes trillions of executions every month [November 2018]

How can AWS help?
Technical

Microservices & Quality
• Do one thing well – Reduced complexity
• Independent – Leads to smaller deployments
& failure isolation, and allows graceful failure
handling
• You build it; you run it – Fully responsible
teams

Benefit & Challenges
Do one thing well – Reduced
Complexity
Increased infrastructure complexity
introduces new sources of failure
(Networking, etc.)
Independent – Graceful failure
handling
Graceful failure handling is not for
free

Where to start?Independent
Graceful failure handling is not
for free
Doone
thingwell
Increased infrastructure
complexity → introduces new
sources of failure
• Architect for Failure
• Build a Learning Organization:
e.g. Root Cause Analysis & Lesson
Learned process

How AWS can help?
• AWS Services for CI/CD
• On-Demand Resources & Infrastructure Automation
• Features for Deployment Strategies
such as blue/green, canary, etc.
• AppMesh

How can AWS help?

www.neosperience.com | blog.neosperience.com | info@neosperience.com
Neosperience
Empathy in Technology
Our road to microservices
AWS Summit Milano
March 12th, 2019

Safe Harbor Statement
Certain information set forth in this presentation contains “forward-looking information”, including “future oriented financial information” and “financial outlook”, under
applicable securities laws (collectively referred to herein as forward-looking statements).
Except for statements of historical fact, information contained herein constitutes forward-looking statements and includes, but is not limited to, the (i) projected financial
performance of the Company; (ii) completion of, and the use of proceeds from, the sale of the shares being offered hereunder; (iii) the expected development of the
Company’s business, projects and joint ventures; (iv) execution of the Company’s vision and growth strategy, including with respect to future M&A activity and global
growth; (v) sources and availability of third-party financing for the Company’s projects; (vi) completion of the Company’s projects that are currently underway, in
development or otherwise under consideration; (vi) renewal of the Company’s current customer, supplier and other material agreements; and (vii) future liquidity, working
capital, and capital requirements. Forward-looking statements are provided to allow potential investors the opportunity to understand management’s beliefs and opinions
in respect of the future so that they may use such beliefs and opinions as one factor in evaluating an investment.
These statements are not guarantees of future performance and undue reliance should not be placed on them. Such forward-looking statements necessarily involve
known and unknown risks and uncertainties, which may cause actual performance and financial results in future periods to differ materially from any projections of future
performance or result expressed or implied by such forward-looking statements.
Although forward-looking statements contained in this presentation are based upon what management of the Company believes are reasonable assumptions, there can
be no assurance that forward-looking statements will prove to be accurate, as actual results and future events could differ materially from those anticipated in such
statements.
The Company undertakes no obligation to update forward-looking statements if circumstances or management’s estimates or opinions should change except as required
by applicable securities laws. The reader is cautioned not to place undue reliance on forward-looking statements.

Luca Bianchi
Who am I?
Chief Technology Officer @ Neosperience
Board Director Member @ WizKey
Stuff that makes me happy:
• Discussing about Software Architectures
• Talking about Serverless
• Developing on Blockchain technologies
• Implementing Neural Networks
@bianchiluca
github.com/aletheia
https://it.linkedin.com/in/lucabianchipavia

Neosperience Cloud allows to create personalized, relevant experiences that strengthen
the relationship with the customer across touchpoints: web, app, platforms, point of sale
How Neosperience Cloud delivers digital experience innovation
The first digital experience
platform to establish empathic
relationships with customers
that takes into account their
uniqueness.
A set of application modules
condensing multi-disciplinary
skills: data scientists,
designers, software architects,
cognitive, behavioral and
social psychologists, to
unleash your brand’s
potential.
Increase customer engagement
• Tailor storytelling and call-to-action
• Grow the value of the customer
• Suggest the most suitable products
and services
• Accelerate on-boarding and increase
conversions
• Generate recurring revenues, evolving
loyalty into membership
• Send personalized notifications
• Delight the customer with gamification
• Make digital experiences come alive in
extended reality
• Nudge advocacy
01 Understand
Listen to customers
across channels
02 Engage
Deliver relevant
experiences at scale
03 Grow
Transform prospects
into customers for life

Best-in-class Customers
37
Consumer Products, Retail & Distribution, Communications & Media
Financial Services, Travel & Transportation, GovernmentAutomotive, Health, Industry & Services
Fashion, Luxury & Beauty

Neosperience IPO(Feb 20th, 2019)

our journey to microservices
starts in 2008…

Neosperience ( 2008 — 2012 )
The age of the monolith
• Multi-region deploy of SpringMVC / Java on Apache
Tomcat / JBoss
• Shared RDS database managed by Hibernate
• Autoscaling group for EC2 instances, Elastic IP
Pros
✓ Everything within a single package
✓ Simple CI workflow
✓ Easy services coordination
Cons
- Lifecycle: one change in code requires a full release of
Neosperience
- Scalability / Costs: planning autoscale for different
usages is not easy
- Everything is a REST endpoint

Neosperience ( 2012 — 2015 )
Separation of concerns
• Spring Boot/Cloud on Java Stack
• Docker image for each service within NGINX
• DynamoDB used as façade towards clients
• RDS managed through Spring Data
• Coordination service (Module Manager)
Pros
✓ Smaller services, same technology for everything
✓ Immutable deployments: from CI to Docker registry
✓ Easy services coordination
Cons
- Still paying for idle (database, instances)
- Manual provisioning of resources (through Beanstalk)
- Everything is a REST endpoint

Neosperience ( 2015 — now )
Here comes Serverless
• Triggers to Lambda functions
• Each service defines its own persistence
• Communication is handled through Kinesis
• Immutable deployments
Pros
✓ Many different packages
✓ Extremely fast release cycles (smaller changes)
✓ No servers to manage (woot-woot)
✓ Scalability at its best / Cost reduction
✓ There is no difference between
dev/stage/production
Cons
- Required a shift in team perspective towards
software development (there is no one size fits
all architecture)
- No support for dedicated hardware

Cloud resources are a commodity, provisioned through Cloudformation
Infrastructure as Code
CloudFormation stack for every service — every resource is created within service boundaries
(Lambda functions, Gateway endpoints, S3 buckets, Kinesis streams, etc.).
Infrastructure is versioned within code repository — a change could impact not only code but
also resources. CloudFormation handles updates / rollback through changesets.
Access to AWS resources — handled through IAM Roles assigned to functions
Project lifecycle management — handled through Serverless Framework and SAM
Functional tests — run in a dedicated AWS account managed by our CI system: resources are
created from scratch, filled with data, then dismissed after tests

New paradigms of service coordination arise from data flowing into our system
Data driven services
•Data is produced by clients and sent through managed services to Neosperience Cloud
•Received data triggers computation
•Functions act in term of data-in / data-out
•Smaller components only needs to know their inputs and outputs
•Complex systems can be tested at any point
•There is not only one workflow

Some key points we had to address while moving to Serverless and microservices.
The questions we faced
How micro is a microservice?
Decompose your system into domain specific computing units using Domain Driven Development (DDD) to bound pacakges and
repos. Use Lambda for HTTP methods.
Do we want to reinvent the wheel?
AWS provides a variety of managed services that can ease out software development, reducing time to market of orders of
magnitude. Every time we had to implement a new functionality we asked ourselves whether there was an AWS service for that.
How to deal with the outside world?
Neosperience is a B2B2C ISV vendor. Our product can be used SaaS by companies or integrated through API. We need to rely on
web standards REST and OAuth2
How about vendor lock-in?
Serverless does not lock you in. Data does. Moving from Lambda to other is easy compared to moving from Dynamo or other
managed service, of course. Faster release cycles is a wise choice over data lock-in. Let debate to philosophers. We, as engineers,
have to make things work.

Adopting microservices can really make our life as ISV better, with a number of benefits
The results
Business Domain Support
✓17 different business domains
✓5-10 microservices each domain
✓a dozen of support services (monitoring, maintenance,
OAuth2, Organization, multi-tenancy, etc.)
Serverless
✓100% Serverless except for ML model training
Lambda Functions
✓200+ functions
AWS Resources
✓400+ AWS resources
✓managed through a 15+ CloudFormation stacks
Time to market
✓improved from months to weeks
✓business features released every sprint
✓technical features released multiple times a week
Costs
✓reduced by an order of magnitude
Team
✓developers provision cloud resources
✓innovation in encouraged, failure impact is bounded
✓shifted from running after business requirements to
waiting for business requirements
Happiness
� Dev Team has full control on delivery
� Business Team has feature delivery

“in the past were bigger companies that
outcompeted smaller companies
now are faster companies
to outcompete slower companies”
— Marc Benioff

Thank you.
@bianchiluca
github.com/aletheia
https://it.linkedin.com/in/lucabianchipavia

www.neosperience.com | blog.neosperience.com | info@neosperience.com

«Remember, if you have a DevOps
Team, then you are absolutely not
doing DevOps»
Adam Drake, Enough with the
microservices, 2017

«If you can’t build a well-structured
monolith, what makes you think
microservices is the answer?»
Simon Brown, Modular Monolith, 2016

Summary
Microservices
• are technically demanding
• have impact on organization & people
• emerge / benefit from a certain company cultural

Pensi di essere pronto per i microservizi?

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Pensi di essere pronto per i microservizi?

Semelhante a Pensi di essere pronto per i microservizi? (20)

Mais de Amazon Web Services

Mais de Amazon Web Services (20)

Pensi di essere pronto per i microservizi?