The document discusses the adoption of cloud computing, emphasizing the transition to cloud-native software and DevOps practices. It outlines key cloud computing characteristics such as on-demand self-service, resource pooling, and rapid elasticity, along with the importance of a shared responsibility model for data protection. The future of cloud computing is described as multi-cloud, leveraging industry examples like Netflix for best practices and emphasizing a cultural shift towards scalable, resilient, and automated application development.

1. Adopting the CloudAdopting the Cloud

2. Tapio RautonenTapio Rautonen
@trautonen
github.com/trautonen
fi.linkedin.com/in/trautonen
software architect
Enabling cloud superpowers in software development.

3. To unleash the full power of cloud infrastructure
you must see software systems from new perspective

4. Cloud native software is built on top of capabilities
not restricted by physical hardware

5. Cloud computing characteristicsCloud computing characteristics
On-demand self-service
Consumer can provision computing capabilities without requiring human interaction
Broad network access
Capabilities are available over the network and accessible by heterogeneous clients
Resource pooling
Provider's computing resources are pooled to serve multiple consumers dynamically
Rapid elasticity
Capabilities can be elastically provisioned and appear unlimited for the consumer
Measured service
Automatically controlled and optimized resources by metering capabilities

6. 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

7. 88 weeks ruleweeks rule
IDEA PRODUCTION

8. start small
persuade early adopters
let the disease spread like a plague
Cloud adoption strategyCloud adoption strategy

9. Dev Ops Analytics
time and infrastructure size
Fonecta cloud management evolutionFonecta cloud management evolution
Dev
Ops
onedevelopmentteam
buildsandrunseverything
fewcloudopsto
supportdevelopment
theteam
appliesdevops
practicesandoptimizes
cloudusage

10. You build it!
You run it!
Dev
Analytics
BizIT
Ops

11. Cloud migrationCloud migration
Cloud assessment
Technical and financial assessment of compatible infrastructure in the cloud
Proof of concept
Verify the highest risks of the migration and learn core technologies
Data migration
Replicate data to cloud provider and migrate to new sources
Application migration
Forklift applications to new infrastructure without further optimizations
Leveraging the cloud
Start using the advanced features and services of the cloud
Optimization
Analyze utilization patterns and optimize capacity and costs

12. 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

13. Shared responsibility modelShared responsibility model

14. The future is multi-cloudThe future is multi-cloud
Netflix Asgard
open sourced 2012
deployment automation for
Amazon Web Services
Netflix Spinnaker
open sourced 2015
deployment automation for
multiple cloud platforms
We are trying to understand a single cloud provider
while the world is moving fast towards a multi­cloud

15. 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.

16. 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.

17. 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?

18. 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.

19. 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.

20. 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

21. Distributed computing fallaciesDistributed computing fallacies
1. The network is reliable
2. Latency is zero
3. Bandwidth is infinite
4. The network is secure
5. Topology doesn't change
6. There is one administrator
7. Transport cost is zero
8. The network is homogeneous
Peter Deutsch / Sun Microsystems

22. Design for failureDesign for failure

23. 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 on­demand

24. The Twelve-Factor AppThe Twelve-Factor App
I. Codebase
one codebase tracked in revision control, many deploys
II. Dependencies
explicitly declare and isolate dependencies
III. Config
store config in the environment
IV. Backing Services
treat backing services as attached resources
V. Build, release, run
strictly separate build and run stages
VI. Processes
execute the app as one or more stateless processes
http://12factor.net/

25. The Twelve-Factor AppThe Twelve-Factor App
VII. Port binding
export services via port binding
VIII.Concurrency
scale out via the process model
IX. Disposability
maximize robustness with fast startup and graceful shutdown
X. Dev/prod parity
keep development, staging, and production as similar as possible
XI. Logs
treat logs as event streams
XII. Admin processes
run admin/management tasks as one-off processes
http://12factor.net/

26. 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

27. 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

28. 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

29. 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

30. 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

31. 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

32. 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

33. 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

34. 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

35. AWS reference architectureAWS reference architecture

36. 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

37. The sky is not the limitThe sky is not the limit
Thank youThank you