As promised here is my sample pricing spreadsheet for estimating Azure costs and projecting revenue. Clearly, this has to be customized for each particular business situation and how you are employing each Azure feature but I hope this is helpful for getting you started. In a month or so you should look for an update on this, as I’ll be making some changes to make the spreadsheet more readable in general. In the meantime, enjoy and if you have any questions I’m happy to receive email on the subject.
Also an update, the lucene demo is now working with latest MVC 4. I’ll work to get that and other samples uploaded from the Tech Ed talk next.
First of all thank you all so much for attending the session. I’m glad I made it through with hardly any coughing after my bout with bronchitis right before Tech Ed…and I appreciate your following my son’s lead and laughing at me when I did cough…my son still thinks it is hilarious for some reason (he’s 4, I guess it doesn’t take much to make him laugh
).
I had a few machine issues with my Azure environment the day before my session, something I installed messed things up so I need to rebuild that environment with the latest Azure SDK and fix up the samples to work with that. I am on the job this week and plan on posting as things are ready.
Today, I plan to post the Azure pricing spreadsheet first. Stay tuned for that and thank you again for your patience! I had a lot of fun chatting with you all even though I could not show my fancy lucene demo given the environment issues…and I hope you had fun too.
Cheers and stay tuned later today for another post!
I did a tutorial on Windows Azure Platform last week. Here is the initial post with my slides. Will post all the code shortly.
VPR03: Windows Azure Platform for Developers: A Complete Look with a Practical Spin
Today, every developer must know how to develop for the Windows Azure Platform. Every company is in the hosting business today, thus they must either provide the infrastructure for global reach, or rent it to reduce up front capital costs, IT management overhead, and the ability to scale on demand. The Windows Azure Platform is Microsoft’s cloud computing initiative supplying an operating system in the cloud—hosted in Microsoft data centers—in addition to data storage and other infrastructure and application services. It provides businesses with on-demand hosting, storage and management features in fashion with utility computing. In this workshop, developers will get a top to bottom view of the platform with a practical look at each of the platform features. We’ll explore Windows Azure, Windows Azure Storage (tables, blobs, queues), look at Windows Azure AppFabric features and also SQL Azure. You’ll learn how to build and deploy applications and services to the cloud with familiar development tools; you’ll learn about storage options offered by Windows Azure Storage and how that compares to SQL Azure; and you’ll learn how to employ features of AppFabric including the Service Bus, Caching and Access Control. This workshop is intended to give developers a jump on Windows Azure with practical guidance and tips for each feature. It will get you up to speed with the platform and then some, while also preparing you for sessions at the conference that dive a little deeper into equally important aspects of the platform with a continued focus on practical guidance.
Interested in how a service level agreement can help you keep track of your overall health in the cloud? My session at Dev Connections reviewed the things you need to care about, even as developers, to help produce metrics that support a robust 24x7 operation. Building an SLA can help even if only used internally. For supporting code on diagnostics and performance counters you should look for my forthcoming post for my tutorial.
VWA03: The Cloud, the SLA and the Code
Here’s the thing...you need visibility into any cloud application. Rest assured someone at the top has their job on the line if things go wrong and you can’t foresee the issue or recover quickly. One of the best ways to gain visibility is to write your own Service Level Agreement (SLA) that captures the necessary performance and diagnostic statistics; process and escalation procedures; backup and recovery procedures; and much more. Of course you also want to leverage the capabilities of your provider since they also provide many aspects of these services. This session focuses on what developers can do to help produce information useful to the SLA to support the end goal. You’ll learn the must-do list for rigging your Windows Azure cloud applications with diagnostics, learn how to monitor that information, and see how it relates to the SLA.
Want to know how you can secure aspects of the Windows Azure Platform? I did a session on this at Dev Connections last week, here’s the description.
VS18: Security Architecture in the Cloud
Cloud computing offers a number of useful services including Software as a Service (Saas), Infrastructure as a Service (IaaS) and Platform as a Service (PaaS). Companies can leverage these services in different ways: they can go all-in hosting their applications and data in the cloud; they can leverage infrastructure services to compliment on-premise and cloud systems; and there are many hybrid solutions for combining on-premise and cloud services. The decision as to which assets are trusted to the cloud is highly dependent on the risk assessment for placing the asset in the cloud. Companies need to maintain adequate control and protection over each asset no matter where it is hosted. The architecture and design phase is also critical to determining where assets will be hosted (on-premise or in the cloud) and how each asset will be secured. You need a clear picture as to how each asset is accessed both from an administration and usage perspective, a risk assessment for those usage patterns, and options for mitigating those risks and securing your assets. This session will lay out popular architectural scenarios for leveraging the Windows Azure Platform including Windows Azure, Windows Azure AppFabric, and SQL Azure and for each scenario discuss security concerns at each tier – on-premise or in the cloud – and recommended techniques for securing relevant assets. Among security concerns to address will include identity and access management, transfer protection, data and content protection, key management, infrastructure security, auditing and compliance.
Azure pricing spreadsheet sample: pricing.xlsx
I delivered a session at Dev Connections (www.devconnections.com) last week called Pricing the Cloud. The session used a fictional sample to estimate various usage in Azure to plug in to the pricing tools online. The pricing tools don’t help you with application specific estimates that you plug in to the tools, such as how much bandwidth will you use, how much table storage, etc. This session walked you through how to estimate these things in general, and my link above shows you a pricing worksheet that can be used to show you the details that go into these estimates. Every company worksheet could look different, as your tables, media use, services and so forth will vary. Hope this helps to get you moving in the right direction!
In case you missed it, here is the abstract for my session.
VWA08: Pricing the Cloud
Michele Leroux Bustamante
By leveraging services in the cloud, startups can easily bootstrap their operations in a cost effective manner. Existing systems can also leverage the cloud in its entirety or for specific aspects of the system to reduce infrastructure management costs and to support potentially scale-out requirements as system usage increases. Windows Azure platform offers many services from application hosting, data storage and content delivery via Windows Azure, to relational data storage with SQL Azure, to infrastructure services related to messaging, caching and security with Windows Azure AppFabric. Pricing each of these services to estimate your costs requires some thoughtfulness around how you will use each service within your architecture, and some predictions about the number of users, payload traffic and number of transactions. How then can you estimate our costs, or price your own offering to customers when there are so many variables? Pricing is not a perfect science and each business will have its own level of tolerance for cost absorption vs. costs to be deferred to customers. In this session we will break down the pricing model of the cloud, look at ways to quantify your service using various architectural examples, and look at ways you can track usage, validate costs and ultimately collect your costs across the various Windows Azure platform properties to gain perspective on what you need to charge your customers for those services.
Updated 11/8/2011
I just had a “duh” moment. That’s different from a blonde moment in that it is not a momentary lapse in memory or thought process – in fact a “duh” moment is worse because it is the result of habit forming perspectives based on experience that cause us not to “think” about a subject until someone challenges your way of thinking.
Someone asked me about port sharing today and I gave my usual perspective on the subject which is that it is common practice (even recommended) that you (when self-hosting) have a different base address per ServiceHost. This way of thinking is the result of 5 years doing WCF where from the beginning port sharing options were not obvious, and the usual demo code does not use it since we can’t easily distribute the sample and have people run it without turning on port sharing, and the fact is most of my customers don’t self-host so the subject doesn’t come up, and for those customers who do self-host, they have never had issues with opening the required ports for each ServiceHost.
I was left thinking about my answer this evening and realized I’m an idiot. I wasn’t thinking on my feet so well when I answered the question so I stuck to the usual “yes, you can make it work but that is not common practice”. Then, I was haunted by my own answer. The funny thing is that this is such a small feature of WCF and usually I deal with bigger issues, but this little feature is actually really important. REALLY important.
Port sharing means that you can reduce the number of exceptions in the firewall rules. Lots of enterprises have issue with this. Considering each host environment:
- IIS provides port sharing for port 80 and 443 for HTTP/S communications, so we don’t have issues there.
- Windows Activation Service (WAS) allows port sharing for TCP across services as well.
- A windows Service may host multiple services, and we may have multiple windows services in the environment. These can also share ports if you enable TCP port sharing on the machine and for the binding. You should also be able to share HTTP port 80 or 443 with IIS from a self-hosted service, or TCP port 808 (or other port if configured differently in WAS),if desired.
In summary, if you use IIS or WAS you get port sharing (which is why I don’t usually think about this…most customers use IIS/WAS)…but if you self-host you can turn on the TCP port sharing service and share ports across all your services if desired. That includes sharing with IIS/WAS ports if both are present (though, unlikely you have both present otherwise why use a Windows Service?
Now, for the caveats.
- Your deployment of services must include automating or providing instructions to enable port sharing
- You may need to provide some custom configurations for the port sharing service to increase throughput
- Metadata endpoints can’t share the same endpoint address so rather than using /mex for each service you have to make the relative address unique such as /ServiceA/mex and /ServiceB/mex
- Sometimes other services cause the port sharing service to crash…so you need to be ready for that as we are adding a new dependency on the environment. If the service host fails to load you can see in the event viewer this error at times: “The Net.Tcp Port Sharing Service service terminated unexpectedly.” We don’t like that!
Here are a few examples of this last issue:
MY NEW AND IMPROVED RECOMMENDATIONS
- Try to use port sharing to reduce the number of firewall exceptions
- If you own the environment, ensure a predictable machine setup with no conflicting DLLs that could cause port sharing service to crash
- If you don't own the environment, brace yourself that some customers may have software that conflicts and in that case you can’t use port sharing.
- Make your service configuration flexible so that you can switch the deployment easily between port sharing or not and this way your service will work regardless of issues you encounter.
- Don’t hard code ports at client or service as the available port could change.
- Make sure clients are not depending on a single port since if port sharing doesn’t work, you’ll need to have each proxy hit potentially a different address.
This is a link to a GREAT blog post on port sharing including lots of links to other resources for education on the underlying technology, and lots of issues and workarounds. Must read if you want to know more.
http://blogs.msdn.com/b/andreal/archive/2009/04/05/net-tcp-ip-port-sharing.aspx Have a great day!
Here is a second dose of WCF tips, yeah, two blog posts in a row, I’m on a roll! Woo hoo!
Uh, yeah, I know, I have a lot of catching up to do on the blogging department. 
- Assembly Allocation
- At a minimum you will have separate assemblies for each logical group of services: data, business, and service assemblies
- Contracts and Entities are also good logical assembly separations
- Per logical group of services or shared if common
- Service Contracts
- Naming
- Always supply a Namespace for service contracts
- Optionally supply a value for contract Name to reduce refactoring risk
- That goes for service contract, operation contract, and message parameters
- WSDL
- Factor WSDL output carefully
- Hide internal endpoints from external clients by creating separate services (use a common base service implementation
- Data Contracts
- Don’t use POCO types, always apply data contract and data member attributes
- Data members should be public to avoid confusion
- In simple scenarios, use ServiceKnownType to specify hierarchy at the service contract tier
- Apply ServiceKnownType to service contract, not the service type
- In complex or more dynamic scenarios, use DataContractResolver
- This really only applies to applications where derivations of a base type are added dynamically or the number of types is unmanageable to decorate the service contract
- Explicitly provide IsRequired and Order for data members
- For versioning and to clarify expectations on the wire
- Optionally use data contract and data member Name to avoid refactoring issues
- When you own both sides, use a shared library for data contract
- Message Contract
- Use message contract for simple scenarios that require including headers in the WSDL
- Use message inspectors to add headers programmatically when you own both sides, bury details in the proxy and ServiceHost initialization code
- Avoid advanced features of message contract unless required by interop (protection level, wrapped/unwrapped messages)
- Do not provide namespace to message contract elements unless required for interop (will inherit from ServiceContract)
- IXmlSerializable
- Use IXmlSerializable when you must follow specific schema, do not use nasty object model produced by reverse engineering
- Include wrapper type in contracts library, not with entities (part of service contract just like message contracts are)
Two down…more to come…cheers!
As I am teaching our IDesign WCF Master Class in Brussels this week, I thought I would post some a simple summary of WCF tips that come to mind as we cover the vast landscape of WCF features. Here’s the first drop of tips to kick us off, enjoy! 
- SOA
- SOA is a good thing, service tiers are good for reuse but don’t overdo it.
- Try to keep to 2-3 service calls in single round trip (usually 2)
- Addressing
- Never hard code base address or endpoint address
- Provide base address in configuration
- Even better, use runtime configuration to simplify managing web farm configuration (custom code required)
- Hosting
- Use console host for initial testing unless hosting in IIS/WAS and this is available locally
- Always test in “real” hosting environment as well
- Try to use WAS with AppFabric whenever possible
- Use AppFabric for auto-start and visibility to exceptions (prefer custom diagnostics to centralize warnings, exceptions, debug and information trace logs)
- Windows services are useful for unknown deployment environments
- Using statement
- Ok for test hosts (console) since app domain shutting down
- Not ok for most other self-hosting environments (Windows service, worker role, windows client) so you must decouple Close() and on exception call Abort() to clean up resources
- Never use “using” for proxies
- You will typically provide a custom host for common behavior and endpoint initialization
- Requires a ServiceHostFactory for IIS/WAS endpoints
- Bindings
- You will always customize standard bindings
- Message and reader quotas
- Security
- You will often need <customBinding>
- To provide specific features not exposed by standard bindings
- Complete your overall system design first, then establish a pattern for bindings
- Includes security model
- You’ll likely come up with 2-3 bindings used throughout clients/services and other tiers
- Wrap these into reusable Binding types to be called at runtime or configured with custom configuration section
- Share binding code between clients and services (unless you can’t)
- Client version may differ slightly
- Endpoints
- Store endpoint requirements in shared code for both client and service if you own both sides
- dynamic aspects such as base address will come from respective configuration files
- Initialize endpoints programmatically (custom ServiceHost and proxy initialization code)
- Good for web farms, reduce effort to update multiple servers on change
- Not required for Windows Azure but still useful
- Proxies
- Use proxy generation only for testing or clients that don’t share your components
- Create a separate shared library for contracts (service contracts, message contracts, fault contracts) and entities (data contracts, custom serialization code)
- Always Close() explicitly and Abort() on exception
- Not likely to use ClientBase<T>, more control over channel factory and channel
More tips coming tomorrow (she says assuming jet lag doesn’t take over
)!
For some time now I have had time sucked out of my day, minutes at a time, every time I wanted to click a link to download or open and run a file from IE 9. It has been driving me nuts, almost literally.
The problem is that Open and Run commands in this discreet download toolbar stopped working at some point. It would tell me that the item downloaded and then the toolbar disappears before I can click it to open the file folder even.

I googled, I binged, but I could not find a solution to the issue. In a last ditch attempt before switching to another default browser I emailed my RD fiends and thanks to Mr. Scott Seely found the answer. Thought I would share in case others see this issue.
Scott said in his email to me:
This worked, thank you Scott and hopefully this can be found by other googling, binging, frustrated people with the same problem.
Cheers,
-Michele