ted@tedneward.com | Blog: http://blogs.tedneward.com | Twitter: tedneward | Github: tedneward | LinkedIn: tedneward
great, we have it--now what do we do with it?
and why is or isn't this "same story, different day"?
Alas, not quite
Developers trying to build cloud apps without realizing the pitfalls run a major risk
an introduction to developing Cloud apps
an introduction to anybody's Cloud offering
an introduction to converting Cloud apps
a discussion of how Cloud apps differ from self-hosted apps
some cautionary tales
some generalized advice (but not "best practices")
like most IT terms, it's ridiculously vague
my "cloud" and your "cloud" are almost guaranteed to mean different things
Consumer cloud vs. Developer cloud
vs. IT cloud vs. Management cloud vs ...
industry has established a few core terms...
... but they're consistent only at very vague/strategic levels
"it's not your problem"
third-party providers take IT load off your shoulders
this can be hardware, infrastructure, whatever
"economies of scale"
cloud providers can afford to invest in infrastructure
you wouldn't (or couldn't)
"Fire them!"
cloud providers take IT costs off your shoulders
... including people and their associated costs
"Get more!"
acquiring additional resources is trivial
cloud providers will already have a pool to draw from
pool will be installed and ready to go
"Maintain it!"
cloud providers handle maintenance/upgrades/etc
cloud providers handle monitoring, recovery, etc
... and more along these lines
Let's come to agreement on a few terms
Without this, we're shooting past each other
These are my accepted definitions
but it's my talk, so deal with it
More importantly, this gives us a starting point
Important foundataional terms
"dirt": literally, who owns the ground on which the servers reside
"hardware": the actual computing machinery
"commodity": no difference between same offering from more than one vendor
"elasticity": ability to scale up/down
"as-a-service": "It's not directly under your control"
Cloud "models"
Public cloud
it's hosted on the cloud provider's dirt on their hardware
older versions were called "hosting"
Community cloud
shared by several organizations in support of a single community
typically a particular-purpose public cloud with costs shared
Private cloud (or "enterprise private cloud")
adds cloud-like support (virtualization, etc) on-premises
it's hosted on your dirt on your hardware
this also used to be called "server rooms"
Cloud "models"
Virtual private cloud
private to you
hosted on cloud provider's dirt on their hardware
Hybrid cloud
a combination of private and public cloud
Co-location
your hardware, their dirt
Vendor platform
a vendor extends their app/tool/etc into the cloud space
typically through the public release of an API
Cloud "models"
PaaS: Platform-as-a-Service
hardware, OS
IaaS: Infrastructure-as-a-Service
compute, storage, networking,
SaaS: Software-as-a-Service
generic term covering anything specific "as-a-Service"
"verticals": very specific niche services
authentication, databases, functions, etc
Cloud "services"
Compute
CPUs, processing, etc
Storage
SQL, NoSQL, all modes in between
Communications
Messaging-oriented middleware, REST, etc
Networking
physical and virtual connections
Acquisition
bringing up more hardware resources
Cloud "platform services"
Analytics
big data, big data analytics
Deployment
putting "stuff" into where it needs to go
Management
dashboards, statistics, trend analysis
Mobile-specific services
sync, push notifications
widely-believed falsehoods
incorrect assumptions
lovingly-endorsed "alternative facts"
mistakes that are all too easy to repeat
"anti-patterns"
"Essentially everyone, ... makes the following assumptions.
"All turn out to be false in the long run and all cause big trouble and painful learning experiences."
... once you know about them, you can avoid them
... "Everyone makes these assumptions"
largely because they're easy to make
and they help us avoid hard truths
and painful realizations/pain points
What is the Cloud to you?
virtualization of resources?
opportunities for outsourcing?
faster development due to quicker server spin-up?
an automated failover system?
Cloud doesn't eliminate the Fallacies of Distributed Computing, just changes the concerns a bit
Tenancy and instancing
Resource elasticity
Geo-distribution
Customer relationships
Recoverability and fault-tolerance
Cloud doesn't eliminate the Fallacies of Distributed Computing, just changes the concerns a bit
Cost structures
Data storage and retrieval
Testing
Upgrades and deployments
Flexibility
Diagnostics, debugging and monitoring
Fundamental models of Cloud apps:
Single-tenant, single-instance
(AKA "big honkin' server")
Multi-tenant, single-instance
Single-tenant, multi-instance
(AKA instance-per-tenant)
Multi-tenant, multi-instance
it's about quickly spinning servers up, true
it's also about spinning them down
load-testing
DDoS attacks
the non-technical components of the business
do you care?
lots of server apps written without concern to topology, or assuming a single fixed topology
remember that Cloud providers can move machines around without telling you
how does this change your programming model?
remember that latency is not zero!
Your customers are your customers
... and you are a Cloud customer
write SLAs accordingly
examine legal and regulatory requirements carefully
Cloud providers usually admin the server better than you...
... but when the servers go down, it's a BFD
... and usually it's not just a "reboot the server" fix
build architectures that minimize dependencies
build "watertight compartments"
build the Cloud app as the back-end, not the front-end
... and contrary to popular opinion, it's rarely cheaper!
Cap-ex vs Op-ex
be aware of tax breaks, budget structures, etc
Be aware that lots of different costs come up:
uptime
receiving a request
sending a response
dropping a message in a queue
writing to a BLOB
writing to a table
More importantly, how would your app's costs change if the pricing model changed?
Do the math! $.12 doesn't sound like much, but it adds up
and keep an eye on the dashboard to avoid surprise end-of-the-month costs
BLOBs offer some schema flexibility
Pro: no more database upgrades!
Con: no more database validation!
Tables offer more support and interoperability
Pro: less complicated code!
Con: schemas! schemas aren't yours anymore!
Keep OLAP and OLTP separate
Note that "unit" testing takes on a whole new complexity here
do yo mock out the cloud, or just use it?
Unit-testing the components on the developer machine may result in subtle differences
Judicious use of mocking here can help eliminate surprises
Whole-application-testing/acceptance-testing should be done in another cloud environment (not a dev environment) provisioned similarly
In other words, treat testing exactly as you would for Production servers
When upgrading, does your upgrade require...
restarted instances?
reprovisioning the instances?
changing the instance mappings (DNS, etc)?
... and if so, how will it be handled?
OS version, platform (JVM, .NET Framework, etc) version
Virtual machine size
Application configuration settings
and so on
Great--does your Cloud provider support it?
custom bits on those instances resists that strategy
this may completely screw up your Cloud strategy
For starters, you're not sitting in front of the machine
Never use the console or other home-grown mechanisms
Practice debugging the app while it's in the Cloud
Instrumenting the app with your own instrumentation
... but not identical
... and the differences are subtle
Remember, cloud requires developers to think about considerations (costs) that traditionally we've been able to ignore
"Release It!"
by Michael Nygard; Pragmatic Bookshelf
"Developing Applications for the Cloud" (p&p guide)
by Betts, Densmore, et al; Microsoft Press
Who is this guy?
Architect, Engineering Manager/Leader, "force multiplier"
Co-founder, Solidify US
http://www.solidify.dev
Principal -- Neward & Associates
Author
Professional F# 2.0 (w/Erickson, et al; Wrox, 2010)
Effective Enterprise Java (Addison-Wesley, 2004)
SSCLI Essentials (w/Stutz, et al; OReilly, 2003)
Server-Based Java Programming (Manning, 2000)
See http://www.newardassociates.com