Upload
tapio-rautonen
View
305
Download
0
Embed Size (px)
Citation preview
Tapio RautonenTapio Rautonen
@trautonengithub.com/trautonenfi.linkedin.com/in/trautonen
software architect
Enabling cloud superpowers in software development.
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
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
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
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.
Cloud as a BusinessCloud as a Business
Monetize a cloud platform software
Plausible with a budget of Facebook, Google or Amazon. The trend is towards open source software.
Cloud as a BusinessCloud as a Business
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?
Cloud as a BusinessCloud as a Business
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.
Cloud as a BusinessCloud as a Business
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
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
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