Adrian Cockcroft on his top predictions for the cloud computing industry in 2015 and beyond, as well as how cloud-native applications, continuous-delivery and DevOps techniques, will speed the pace of innovation and disruption. For more about Adrian be sure to check out his page on Battery Ventures: https://www.battery.com/our-team/member/adrian-cockcroft/ Follow Adrian on Twitter: @adrianco

1. Cloud Trends, DevOps
and Microservices
Adrian Cockcroft @adrianco
Technology Fellow - Battery Ventures
July 2015
See www.battery.com for a list of portfolio investments

2. Previous Cloud Trends
GigaOM Structure May 2014
Pacific Crest Summit Aug 2014
1

3. Cloud Adoption
@adrianco’s job at the
intersection of cloud
and Enterprise IT,
looking for disruption
and opportunities.
%*&!”
By Simon Wardley http://enterpriseitadoption.com/
2014
2009
Example: Docker
wasn’t on anyone’s
roadmap for 2014. It
was on everyone’s
roadmap for 2015.

4. 1
Public
IaaS
2
Cloud
Technologies
3
Enterprise
SaaS

5. Enterprise IaaS Concerns
Staying Power
Support
Scale
Location
1

6. Safe Bets

7. The Global Land-Grab
Azure
AWS
GCE
17 Regions
11 Regions
3 Regions
?
?
?
?
?
?
http://aws.amazon.com/about-aws/global-infrastructure/
http://azure.microsoft.com/en-us/regions/
https://cloud.google.com/compute/docs/zones#available
http://www.google.com/about/datacenters/inside/locations/index.html

8. Questions we keep
hearing about cloud
Do you need $Billions
to compete in IaaS?

9. Simplicity for Developers
May 2013 10,000
May 2014 200,000
May 2015 500,000 http://trends.netcraft.com/www.digitalocean.com
8th 2nd

10. Cloud Technologies
Agility
Functionality
Cost savings
2

11. Questions we keep
hearing about cloud
Who will win the
PaaS battle?

12. Docker All The Things…
Container
Communications
Orchestration
Policy

13. Questions we keep
hearing about cloud
Who is challenging
VMware for in-house
cloud automation?

14. Battle for the Private Cloud
Stability
Functionality
Total Cost of
Ownership

15. Vendors will co-opt and
fragment OpenStack

16. SaaS3
Everything
Enterprise
Everywhere

17. This is the year that
Enterprises finally
embraced cloud.

18. Future
Disruption

19. Open Source Disruption
Follow developers not dollars
Replacing expensive with
free leads to an extreme case
of Jevon’s Paradox
0
25
50
75
100
Ignore Ignore Worry Dead
% Open source adoption by new installations
% Incumbent revenue

20. “You build it, you run it.”
Werner Vogels 2006

21. 2014 was the year that Enterprises
finally embraced cloud and DevOps.

22. Key Goals of the CIO?
Align IT with the business
Develop products faster
Try not to get breached

23. Security Blanket Failure
Insecure applications
hidden behind firewalls
make you feel safe until
the breach happens…
http://peanuts.wikia.com/wiki/Linus'_security_blanket

24. What needs to
change?

25. Developer responsibilities:
Faster, cheaper, safer

26. Operator responsibilities:
API driven platform automation

27. Product
Development
Processes

28. Assumption:
Process prevents
problems

29. Organizations build up
slow complex “Scar
tissue” processes

30. Observe
Orient
Decide
Act
Land grab
opportunity Competitive
Move
Customer Pain
Point
Analysis
JFDI
Plan Response
Share Plans
Incremental
Features
Automatic
Deploy
Launch AB
Test
Model
Hypotheses
BIG DATA
INNOVATION
CULTURE
CLOUD
Measure
Customers
Continuous
Delivery

31. Breaking Down the SILOs
QA DBA
Sys
Adm
Net
Adm
SAN
Adm
DevUX
Prod
Mgr
Product Team Using Microservices
Product Team Using Monolithic Delivery
Platform Team
DevOps isn’t the new name for QA, it’s a Re-Org!
A
P
I
Product Team Using Microservices
Product Team Using Microservices
Product Team Using Monolithic Delivery

32. Release Plan
Developer
Developer
Developer
Developer
Developer
QA Release
Integration
Ops Replace Old
With New
Release
Bugs
Bugs
Monolithic service updates
Works well with a small number
of developers and a single
language like php, java or ruby

33. Use monolithic apps for small teams,
simple systems and when you must,
to optimize for efficiency and latency

34. Developer
Developer
Developer
Developer
Developer
Old Release Still
Running
Release Plan
Release Plan
Release Plan
Release Plan
Deploy
Feature to
Production
Deploy
Feature to
Production
Deploy
Feature to
Production
Deploy
Feature to
Production
Bugs
Deploy
Feature to
Production
Immutable microservice deployment
scales, is faster with large teams and
diverse platform components

35. DeveloperDeveloper Developer
Run What You Wrote
Micro
service
Micro
service
Micro
service
Micro
service
Micro
service
Micro
service
Micro
service
Developer Developer
Manager Manager
VP
Engineering
Site
Reliability
Monitoring
Tools
Availability
Metrics
99.95% customer
success rate

36. Change One Thing
at a Time!

37. What Happened?
Rate of change
increased
Cost and size and
risk of change
reduced

38. Low Cost of Change Using Docker
Fast tooling supports continuous delivery of many tiny changes
Developers
• Compile/Build
• Seconds
Extend container
• Package dependencies
• Seconds
PaaS deploy Container
• Docker startup
• Seconds

39. Disruptor:
Continuous Delivery with
Containerized Microservices

40. Microservices

41. A Microservice Definition
Loosely coupled service oriented
architecture with bounded contexts
If every service has to be
updated at the same time
it’s not loosely coupled
If you have to know too much about surrounding
services you don’t have a bounded context. See the
Domain Driven Design book by Eric Evans.

42. Coupling Concerns
http://en.wikipedia.org/wiki/Conway's_law
●Conway’s Law - organizational coupling
●Centralized Database Schemas
●Enterprise Service Bus - centralized message queues
●Inflexible Protocol Versioning

43. Speeding Up Deployments
Measuring CPU usage once a minute makes no sense for containers…
Coping with rate of change is the first challenge for monitoring tools.
Datacenter Snowflakes
• Deploy in months
• Live for years
Virtualized and Cloud
• Deploy in minutes
• Live for weeks
Container Deployments
• Deploy in seconds
• Live for minutes/hours
AWS Lambda Events
• Respond in milliseconds
• Live for seconds

44. Inspiration

45. Challenges for
Microservice
Platforms

46. Managing Scale

47. A Possible Hierarchy
Continents
Regions
Zones
Services
Versions
Containers
Instances
How Many?
3 to 5
2-4 per Continent
1-5 per Region
100’s per Zone
Many per Service
1000’s per Version
10,000’s
It’s much more challenging
than just a large number of
machines

48. Flow

49. Some tools can show
the request flow
across a few services

50. But interesting
architectures have a
lot of microservices!
Flow visualization is
a big challenge.
See http://www.slideshare.net/LappleApple/gilt-from-monolith-ruby-app-to-micro-service-scala-service-architecture

51. Failures

52. ELB Load Balancer
Zuul API Proxy
Karyon
Business
Logic
Staash Data
Access Layer
Priam Cassandra
Datastore
Simple NetflixOSS
style microservices
architecture on three
AWS Availability Zones
Zone partition/failure
What should you do?
What should monitors show?
By design, everything works
with 2 of 3 zones running.
This is not an outage, inform
but don’t touch anything!
Halt deployments perhaps?
Challenge: understand and
communicate common
microservice failure patterns.

53. Testing

54. Testing monitoring tools at scale
gets expensive quickly…

55. Simulation

56. Simulated Microservices
Model and visualize microservices
Simulate interesting architectures
Generate large scale configurations
Eventually stress test real tools
See github.com/adrianco/spigo
Simulate Protocol Interactions in Go
Visualize with D3
ELB Load Balancer
Zuul API Proxy
Karyon
Business
Logic
Staash
Data
Access
Layer
Priam Cassandra
Datastore
Three
Availability
Zones

57. Definition of an architecture
{
"arch": "netflixoss",
"description":"A very simple Netflix service. See http://netflix.github.io/ to decode the package names",
"version": "arch-0.0",
"victim": "homepage",
"services": [
{ "name": "cassSubscriber", "package": "priamCassandra", "count": 6, "regions": 1, "dependencies": ["cassSubscriber", "eureka"]},
{ "name": "evcacheSubscriber","package": "store", "count": 3, "regions": 1, "dependencies": []},
{ "name": "subscriber", "package": "staash", "count": 6, "regions": 1, "dependencies": ["cassSubscriber", "evcacheSubscriber"]}
{ "name": "login", "package": "karyon", "count": 18, "regions": 1, "dependencies": ["subscriber"]},
{ "name": "homepage", "package": "karyon", "count": 24, "regions": 1, "dependencies": ["subscriber"]},
{ "name": "wwwproxy", "package": "zuul", "count": 6, "regions": 1, "dependencies": ["login", "homepage"]},
{ "name": "www-elb", "package": "elb", "count": 0, "regions": 1, "dependencies": ["wwwproxy"]},
{ "name": "www", "package": "denominator", "count": 0, "regions": 0, "dependencies": ["www-elb"]}
]
}
Header includes
chaos monkey victim
New tier
name
Tier
package
Region
count: 1
Node
count
List of tier
dependencies

58. Why Build Spigo/Simianviz?
Generate test microservice configurations at scale
Stress monitoring tools display capabilities
Eventually (i.e. not implemented yet)
Dynamically vary configuration: autoscale, code push
Chaos monkey for microservice, zone, region failures
D3 websocket dynamic browser interface

59. Simulated Game Day
Testing and Training…

60. Conference Driven Development…
OSCON Microservices Workshop

61. What’s Next?

62. Developer Concerns
Agile, Lean & Rugged
(Faster, Cheaper and Safer)
See GOTO London Sept 2015

63. Forward Thinking

64. Q&A
Adrian Cockcroft @adrianco
http://slideshare.com/adriancockcroft
Technology Fellow - Battery Ventures
July 2015
See www.battery.com for a list of portfolio investments

65. Security
Visit http://www.battery.com/our-companies/ for a full list of all portfolio companies in which all Battery Funds have invested.
Palo Alto Networks
Enterprise IT
Operations &
Management
Big DataCompute
Networking
Storage