Busy Microsoft .NET Developer’s Guide to the Microsoft Cloud

1. DEV351 Busy Microsoft .NET Developer’s Guide to the Microsoft Cloud Ted Neward Neward & Associates http://www.tedneward.com | ted@tedneward.com

2. Credentials Who is this guy? • Principal, Architect, Consultant and Mentor ask me how I can help your project or your team • Microsoft MVP (F#, C#, Architect) • JSR 175, 277 Expert Group Member • Author Professional F# 2.0 (w/Erickson, et al; Wrox, 2010) Effective Enterprise Java (Addison-Wesley, 2004) C# In a Nutshell (w/Drayton, et all; OReilly, 2003) SSCLI Essentials (w/Stutz, et al; OReilly, 2003) Server-Based Java Programming (Manning, 2000) • Blog: http://blogs.tedneward.com • Papers: http://www.tedneward.com/writings • Twitter: @tedneward

3. Overview "Cloud! Cloud! Cloud!" great, we have it--now what do we do with it? and why is or isn't this "same story, different day"? "But building Cloud apps is just like building any other .NET app, right?" Alas, not quite Developers trying to build cloud apps without realizing the pitfalls run a major risk

4. Five-Minute Rule What this talk is not: • an introduction to developing Cloud apps • an introduction to Microsoft Azure • an introduction to converting Cloud apps What this talk is: • a discussion of how Cloud apps differ from self-hosted apps • some cautionary tales • some generalized advice (but not "best practices")

5. Review: The Fallacies of Enterprise Systems They hold for cloud apps, too

6. The Fallacies of Enterprise Computing • "Essentially everyone, when they first build an enterprise application, makes the following 10 assumptions. All turn out to be false in the long run and all cause big trouble and painful learning experiences." 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 9) The system is monolithic 10) The system is finished

7. "The network is reliable" • Hardware fails • Routers go down, wires are cut (sometimes catastrophically), power spikes, hurricanes, ... • Sometimes it's even as simple as "who turned off the server?" • Software fails • Processes throw exceptions when they shouldn't need to, or hang, or ... • ... or sometimes you get hacked • Physics fails • Not very often (we hope), but signal just doesn't travel the wireless airwaves like it should

8. Don't assume reliability • Assume that at any point during remote communication, the network can simply "go away" for no reason • Code appropriately: timeouts, retries, backups, and so on

9. "Latency is zero" • Bits take time to move through the networking layers and physical hardware • And remember, they need to do it lots of times (once per intermediary)! • Even fast networks are orders of magnitude slower than slow PC buses

10. Count the network time • Be frugal in passing data across the network; the more data passed, the longer it'll take for it all to get there • Remember, TCP/IP tries to "guarantee" delivery of all of those packets, which grows steadily more difficult with a larger number of packets

11. "Bandwidth is infinite" • A T-1 line's "phat pipe" gets saturated pretty quickly in the face of VOIP, streaming video, music downloads, graphic-heavy websites, ... • Once we throw Web services into the mix, assume the bandwidth demands double or triple • Once "everything goes over one wire", expect the available bandwidth for your application to be a fraction of what it is now • Remember, laying down new wire (fiber-optic) is an exercise in digging up your street... • Developers frequently write code on small lightly-congested LANs or standalone machines/laptops • But Production looks different than a dev laptop...

12. Don't send more than you need to send • Be frugal with the amount of data you send across the wire; send only that which can't be cached • Ironically, this argues against the browser-based application, since half the data sent is presentation information; hence the rise of the "smart client"

13. "The network is secure" • "Developers are competent" • Not always... how much do you know about security? • How about your coworkers, including Harvey The Intern? • "Remote data can be trusted" • TCP/IP packets themselves can be source-spoofed • Major impetus for IPv6 and other 'next-gen' efforts • "Remote system can be trusted" • Even if it could at one point, how do you know it hasn't been hacked since then? • "It'll never run outside of our firewall" • Lots of people carrying laptops, phones, Blackberrys... • Lots of wireless networks going up...

14. Assume insecurity • Remember that any application listening to the network has at least two client front-ends to it: the one you wrote, and Telnet, the hacker's best friend • If you assume that every byte that comes in off the network has to go through a 12-step recovery program before being used anywhere in your program, that's a good start • If you find yourself arguing crypto key bit size with another developer, you're arguing over the size of the vault door on your tent • If you find yourself trusting firewalls to take care of your security needs, please don't work for my company

15. "Topology doesn't change" • Topological changes sometimes happen without planning • Hardware failures, software failures, natural disasters, ... • The code could run on a laptop (or smartphone!) that gets carried from hotel to hotel • The network could be a wireless one, where nodes are constantly coming & going • or worse, it's a combination of wired & wireless • The code could also be "upgraded" to run in an entirely different environment

16. Make use of layers of indirection • Networking frequently makes available "layers of indirection" to keep physical hardware topology somewhat hidden; use it • This means DNS, NAT, and so on • Some programming models provide one (JNDI) • Consider peer-to-peer tools (WS-Discovery, UDP/IP, Multicast, ...) to help keep track of topological changes

17. "There is one administrator" • "... and he will never quit, get hit by a bus, or take a vacation" • Believe it or not, even hard-core sysadmin geeks like to get away from the computer once in a while • Maybe even date! • "But we control both ends" • For now, perhaps, but what happens if your app is wildly successful? Or your company buys a competitor? Or is bought? Or partners up?

18. Make the system administrator-friendly • At any point, a relatively competent system administrator should be able to use standard tools and services to install and/or monitor and/or diagnose the system • Make use of O/S management facilities • Build in the management/administrative functionality that isn't otherwise handled (adding/removing users, finding "lost" records, and so on)

19. "Transport cost is zero" • Pointers don't travel well • So networking stacks spend a lot of time shuffling bits into a stream of bytes that can be sent across the wire • Process is called marshaling, and it's not a free action Both Java and .NET Remoting use Serialization to do the marshaling Web services have to marshal/unmarshal to XML REST services marshal/unmarshal to XML, JSON, ...

20. Know what you're sending, and its costs • Measure the full cost of sending data across the wire by measuring the full cost of marshaling • Either recreate the marshaling (by serializing all the parameters and back) • Or watch the data go across the wire • Or measure with a profiler

21. "The network is homogeneous" • Not even my home network is homogeneous--Linux, Windows & Mac OS/X • Most (all?) companies are also a mixture • Originally an argument for "why Java" • But along came .NET... and Ruby... and ... • Never mind legacy C/C++, COBOL, ... • Even if it is today, there's tomorrow • And the inevitable partnerships, buyouts, mergers, and other corporate activities • You can run, but you can't hide

22. Build systems that don't assume platforms • When designing systems, never assume it will always be "X" at both ends • Stick to well-known technologies at the edges of your component boundaries • When you do interop, prefer to do so at remoting & component boundaries

23. "The system is monolithic" • "Oh, sure, we can make that change; we just have to roll out new stubs..." • Even if you control both ends today... • ... tomorrow brings corporate change • "What do you mean, I broke your mission-critical app? Who are you again?" • Remember that databases take on a life of their own, as well; you will not own your database instance (or its schema) after release

24. Clearly delineate your component boundaries • Design the system to make it explicit which parts are tightly-coupled and would need to evolve atomically; keep the network out of those atoms as much as possible • If the component doesn't straddle the network, it's much easier to control • Ask yourself, "How do we react if the schema and code need to evolve independently?" • Prefer to define contracts, not shared types • Prefer to define loose contracts, not strict ones "Be strict in what you send, liberal in what you accept" --Postel's Maxim

25. "The system is finished" • The only time a system is "finished" is when the server is shut down, the source code is deleted and the programmers that worked on it are all Terminated--With Extreme Prejudice! • Otherwise, systems will be "reborn" in another project because "we need something that does just what XYZ does, only..." • Even if you've left the company, the code you wrote takes on a life of its own

26. Build systems to last • Create systems with "hook points" that allow future programmers to slip in variation without significant rip-and-tear across the codebase; eschew today's "flavor of the month" technology • Keep designs simple and interface- or protocol-based

27. Cloud Considerations Things to think about on a cloudy day

28. Cloud definition What is the Cloud to you? virtualization of resources? opportunities for outsourcing? faster development due to quicker server spin-up? an automated failover system?

29. Considerations Cloud doesn't eliminate the fallacies, just changes the concerns a bit • Tenancy and instancing • Resource elasticity • Geo-distribution • Customer relationships • Recoverability and fault-tolerance • Cost structures • Data storage and retrieval • Testing • Upgrades and deployments • Flexibility • Diagnostics, debugging and monitoring

30. Tenancy and instancing 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

31. Resource elasticity "Resource elasticity" it's about quickly spinning servers up, true it's also about spinning them down But be careful how easy servers spin up load-testing DDoS attacks the non-technical components of the business

32. Geo-distribution • Geo-distribution is the ability to regionalize servers • 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!

33. Customer relationships Your customers are not Cloud customers • Your customers are your customers • ... and you are a Cloud customer Be very clear about these two relationships • write SLAs accordingly • examine legal and regulatory requirements carefully

34. Recoverability and fault-tolerance When you own the server, recoverability is your problem... and under your control • 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 When you build a Cloud app, take that into account • build architectures that minimize dependencies • build "watertight compartments" • build the Cloud app as the back-end, not the front-end

35. Cost structure Cloud apps cost differently than self- or commercially-hosted ones • ... and contrary to popular opinion, it's rarely cheaper! • 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

36. Data storage and retrieval BLOBs vs Tables: Who's right? • 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

37. Testing You were planning on unit-testing this thing, right? • 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

38. Upgrades and deployments Deploying new versions to the Cloud is a little different than your own server • 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? Keep an eye on the effects of new code on: • OS version, .NET Framework version • Virtual machine size • Application configuration settings • and so on

39. Flexibility "[CouchDB/MongoDB/XMPP/whatever] is hot! We need it!" Great--does your Cloud provider support it? Cloud providers are interested in creating instances they can support • custom bits on those instances resists that strategy • this may completely screw up your Cloud strategy

40. Debugging • Debugging a cloud app isn't quite like debugging a Production app • For starters, you're not sitting in front of the machine • Consider: • 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

41. ACK! This is all too much to remember!

42. Simplified David Chapell simplifies this down to three rules: • A Windows Azure App... • is Built from One or More Roles • Runs Multiple Instances of Each Role • Behaves Correctly When Any Role Instance Fails • Isn't that easier?

43. Summary Cloud programming is similar to plain ol' enterprise development ... 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

44. Summary Cloud programming is similar to plain ol' enterprise development ... 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

45. Resources Books "Release It!" by Michael Nygard; Pragmatic Bookshelf "Developing Applications for the Cloud" (p&p guide) by Betts, Densmore, et al; Microsoft Press

46. Questions ?

47. DEV Track Resources • http://www.microsoft.com/visualstudio • http://www.microsoft.com/visualstudio/en-us/lightswitch • http://www.microsoft.com/expression/ • http://blogs.msdn.com/b/somasegar/ • http://blogs.msdn.com/b/bharry/ • http://www.microsoft.com/sqlserver/en/us/default.aspx • http://www.facebook.com/visualstudio

48. Resources • Connect. Share. Discuss. http://northamerica.msteched.com Learning • Sessions On-Demand & Community • Microsoft Certification & Training Resources www.microsoft.com/teched www.microsoft.com/learning • Resources for IT Professionals • Resources for Developers http://microsoft.com/technet http://microsoft.com/msdn

49. Complete an evaluation on CommNet and enter to win!