adopting the cloud

Adopting the CloudAdopting the Cloud

Tapio RautonenTapio Rautonen

@trautonengithub.com/trautonenfi.linkedin.com/in/trautonen

software architect

Enabling cloud superpowers in software development.

To unleash the full power of cloud infrastructureyou must see software systems from new perspective

Cloud native software is built on top of capabilitiesnot restricted by physical hardware

Cloud computing characteristicsCloud computing characteristics

On-demand self-serviceConsumer can provision computing capabilities without requiring human interaction

Broad network accessCapabilities are available over the network and accessible by heterogeneous clients

Resource poolingProvider's computing resources are pooled to serve multiple consumers dynamically

Rapid elasticityCapabilities can be elastically provisioned and appear unlimited for the consumer

Measured serviceAutomatically controlled and optimized resources by metering capabilities

CaseCase

● Migration to Amazon Web Services started late 2011● Quite small multi-vendor team with a greenfield project● In four years the cloud usage has risen almost to 100%

Experiment

Evaluate

Deploy

88 weeks rule weeks rule

IDEA PRODUCTION

start small

persuade early adopters

let the disease spread like a plague

Cloud adoption strategyCloud adoption strategy

Dev Ops Analytics

time and infrastructure size

Fonecta cloud management evolutionFonecta cloud management evolution

Dev

Ops

one

deve

lopm

ent t

eam

build

s an

d ru

ns e

very

thin

g

few

clo

ud o

ps to

supp

ort d

evel

opm

ent

the

team

app

lies

devo

ps

prac

tices

and

opt

imiz

es

clou

d us

age

You build it!You run it!

Dev

Analytics

BizIT

Ops

Cloud migrationCloud migration

Cloud assessmentTechnical and financial assessment of compatible infrastructure in the cloud

Proof of conceptVerify the highest risks of the migration and learn core technologies

Data migrationReplicate data to cloud provider and migrate to new sources

Application migrationForklift applications to new infrastructure without further optimizations

Leveraging the cloudStart using the advanced features and services of the cloud

OptimizationAnalyze utilization patterns and optimize capacity and costs

Data protectionData protection

● Regulations and laws affecting the data– verify compliance of the platform– cloud adoption is most often restricted by prejudice

● EU Data Protection Directive– in October 2015 Safe Harbour regime was ruled invalid

● Know where the cloud provider stores the data– responsibility models– customer data vs data used by managed services

Shared responsibility modelShared responsibility model

The future is multi-cloudThe future is multi-cloud

Netflix Asgardopen sourced 2012deployment automation forAmazon Web Services

Netflix Spinnakeropen sourced 2015deployment automation formultiple cloud platforms

We are trying to understand a single cloud providerwhile the world is moving fast towards a multicloud

Cloud as a BusinessCloud as a Business

Create your own public cloud

It's all about economy of scale. Without a massive infrastructure unit costs will never be competitive.


Monetize a cloud platform software

Plausible with a budget of Facebook, Google or Amazon. The trend is towards open source software.


Monetize a cloud platform ecosystem

Tools are all available, but the problem is to get partners abroad. If IBM and Pivotal are struggling with 3rd party services, then how about you?


Monetize software as a service

Transform a succeeding service or tool into a cloud service. Fulfill a demand from your customers. Or simply create the next Facebook or Slack.


Sell cloud consultancy and expertise

There are plenty of platforms to choose from. Specialize in single platform or pick a few based on your customers' needs.

from capital expedinture to operational expedinturefrom capital expedinture to operational expedinture

infrastructure is never again the bottleneckinfrastructure is never again the bottleneck

cultural change of software systems developmentcultural change of software systems development

Distributed computing fallaciesDistributed computing fallacies

1. The network is reliable2. Latency is zero3. Bandwidth is infinite4. The network is secure5. Topology doesn't change6. There is one administrator7. Transport cost is zero8. The network is homogeneous

Peter Deutsch / Sun Microsystems

Design for failureDesign for failure

SaaS architecture methodologySaaS architecture methodology

● Declarative formats for setup and runtime automation● Clean contract with infrastructure for maximum portability● Cloud platform deployments, obviating the need for ops● Tooling, architecture and dev practices support scaling

Modern software is delivered from the cloud to heterogeneous clients ondemand

The Twelve-Factor AppThe Twelve-Factor App

I. Codebaseone codebase tracked in revision control, many deploys

II. Dependenciesexplicitly declare and isolate dependencies

III. Configstore config in the environment

IV. Backing Servicestreat backing services as attached resources

V. Build, release, runstrictly separate build and run stages

VI. Processesexecute the app as one or more stateless processes

http://12factor.net/

The Twelve-Factor AppThe Twelve-Factor App

VII. Port bindingexport services via port binding

VIII.Concurrencyscale out via the process model

IX. Disposabilitymaximize robustness with fast startup and graceful shutdown

X. Dev/prod paritykeep development, staging, and production as similar as possible

XI. Logstreat logs as event streams

XII. Admin processesrun admin/management tasks as one-off processes

http://12factor.net/

Cloud Native ApplicationCloud Native Application

An Idea in the Morning, is Running in Production by the Evening

Cloud Native means building reliable systems from unreliable components. Designing for failure means a cloud native approach must provide structured automation of components with predictable scaling and failure characteristics. This includes automation that embraces the realities of scale and the lessons of cloud native companies like Netflix and Amazon.

Pivotal Software, Inc pivotal.io/cloud-native

Service discoveryService discovery

● Services need to know about each other– inexistence of centralized service bus– smart endpoints and client side load balancing

● Service registry is the new single point of failure?– value availability over consistency

● Provides a limited set of well defined features– services notify each other of their availability and status– cleaning of stale services– easy integration with standard protocols like HTTP or DNS– notifications on services starting and stopping

Ephemeral runtime environmentsEphemeral runtime environments

● Short lifetime of an application runtime environment– scaling, testing and materializing ideas– requires highly automatized infrastructure

● Nothing can be stored in the runtime environment– logs, file uploads, database storage files, configuration

● Results stateless services– optimal for horizontal scaling– integrates to State as a Service

● Must be repeatable and automatically provisioned

Metrics and loggingMetrics and logging

● Ephemeral and dynamic systems– require central awareness of state

● Gain understanding how the services are used– plan for future requirements– gather scaling metrics– bill customers for usage (pay-per-use)– detect faulty behavior

● Balance between value provided and cost of collecting– robustness of the metering system impacts on profitability– collect end-to-end scenarios rather than operational factors

AutoscalingAutoscaling

● Adapting to changing workloads– optimize capacity and operational cost– increase failure resilience

● Requires key performance metrics capturing– response times, queue sizes, CPU and memory utilization

● Decision logic based on scaling metrics– when to scale up and down– prevent scaling oscillation

● Application must be designed for scaling– stateless, immutable, automatically provisioned

Asynchronous messagingAsynchronous messaging

● Key strategy for services to communicate and coordinate– decouple consumer process from the implementing service– enables scalability and improves resilience

● Basic messaging patterns– sender posts a one-way message and receiver processes the

message at some point in time– sender posts a request message and expects a response

message from the receiver– sender posts a broadcast message which is copied and

delivered to multiple receivers● Numerous implementation concerns

– message ordering, grouping, repeating, poisoning, expiration, idempotency and scheduling

Data consistencyData consistency

● All instances of application see the exact same data– strong consistency

● Application instance might see data of operation in flight– eventual consistency

● Distributed data stores are subjected to CAP theorem– consistency, availability, partition tolerance– only two of the features can be implemented

● Recovering from failures of eventually consistent data– retry with idemponent commands– compensating logic

Configuration managementConfiguration management

● Externalize configuration out of runtime environment– repeatable, versioned

● Runtime reconfiguration– application can be reconfigured without redeployment or restart– minimize downtime, enable feature flags, help debugging– thread safety and performance is a concern– prepare for rollbacks and unavailability of configuration store

● Local configuration pitfalls– limits to single application– hard for multiple instances

Software erosionSoftware erosion

● Slow deterioration of software leading to faulty behavior● Fighting erosion is more expensive than usually admitted● Erosion-resistance comes from separation of concerns

– application – infrastructure● Clear contract of services provided by infrastructure

– change in infrastructure does not break the contract– application can change within its respected realm

● Solutions against software erosion– Platform as a Service– container virtualization

AWS reference architectureAWS reference architecture

Pitfalls of cloud adoptionPitfalls of cloud adoption

● Application development becomes easy– distributed systems are never easy to develop

● Distributed computing fallacies– they are valid in the cloud too

● Premature optimization– optimization increases unbearable complexity

● Network topologies and security issues cease to exist– hardware becomes programming interfaces

● Use the cloud for virtual servers– can be cost effective, but most of the advantages are lost

The sky is not the limitThe sky is not the limit

Thank youThank you