Microsoft TechEd North America 2012-Day 3

 

An Overview of Managing Applications, Services, and Virtual Machines in Windows Azure - Karandeep Anand

In this session Karandeep walked us through the new portal. The new portal does not include Service Bus endpoints like queues or topics and also does not include caching… yet.  I am told that Microsoft is hoping to have this functionality in the portal by end of the year.  However, they have enabled single sign on so you should be able to toggle back and forth between the old and new portals quite easily.

Within the portal we can get the state of:

• Virtual Machine
• Websites
• Cloud Services (Web roles/Worker roles etc)
• SQL Databases
• Storage
• Networks

Below I have taken a screenshot of the Azure portal.  I only have one SQL Database in the production portal but you can get a sense of the new look and feel.

You also have the ability to add new assets by clicking on the “+ New” link.

You can then specify the type of service that you would like to provision.  In the case of Virtual Machines, you need to sign up for the preview before you can actually provision a VM.

 

Scripting Management Support

Using the VM portal is not the only way to manipulate services in Azure.  There is first class support for scripting in Windows, MAC and Linux.  In the case of Windows admins will find comfort knowing that there is first class support for PowerShell.  These PowerShell command lets will take advantage of the same underlying REST APIs that the portal is using

 

High Availability and Service Level Agreements

Having a third party, such as Microsoft, host IT services for your organization may create some concerns within your organization.  What if your services go down?  What “skin” does Microsoft have in the game.  To put it bluntly, they have some skin in the game.  Perhaps not as much as some would like but Microsoft will be reimbursing organizations for their usage should they fail to live up to their commitments.

Here is a, very, loose break down of Microsoft’s SLA policy:

• 99.95 uptime – monthly SLA
• 4.38 hours of downtime per year for multiple role instances
• 99.9 for single role instances
• 8.75 hours per year
• What’s included?
• Compute Hardware failure (disk, CPU, memory)
• Datacenter failures – network failure, power failure
• Hardware upgrades, software maintenance – HOST OS updates
• Planned downtime – 6 day notice, 6 hour window, 25 minute downtime

What is not included?

• VM container crashes, Guest OS failures

Monitoring and Auto-Scaling applications

Now this was cool!  A company called AppDynamics demonstrated their monitoring solution for Azure.  Some of the features included:

• Application performance management dashboard.  This included a graphical representation of your distributed solution and provided the latency that exists between each component.
• You also had the ability to interrogate the stack level trace to get very granular
• The tool also supported the ability to auto scale your application based upon different criteria sets including
• CPU
• Message through-put
• errors
• specific business hours
• critical conditions

Since Azure supports a “Pay as you go” model I found this tool to be extremely intriguing.  Not only did it look nice, but it provides functionality can can allow you to reduce costs when your app is not very busy and also auto scale to ensure of a good user experience when your site is busy.  To read more about this company and their product for Azure, please read the following press release.

 

Building HTTP Services with ASP.Net Web API – Daniel Roth

The other session that I wanted to talk about was the Building HTTP Services with ASP.Net Web API.  For the past couple months I have been playing with MVC3, JQuery and AJAX so this session was rather timely.

What is Web API?

• An Http Service
• Designed for broad reach
• browsers
• phones
• devices
• set top boxes
• Uses HTTP as an application protocol, not a transport protocol.  So what this really means is it takes advantage of existing verbs GET, POST, PUT, DELETE

Why build Web APIs?

• Reach More Clients
• Scale with Cloud
• Embrace HTTP – simplify things
• use existing verbs
• Web API Requirements
• Need a first class HTTP Programming model
• Easily map resources to URIs and implement the uniform interface
• Rich Support for formats and HTTP Content negotiation
• separate out cross cutting concerns
• Light weight
• ASP.NET WebAPI is the end result

WebAPI description

If you like self documenting APIs, then WebAPI has some built in features to support this type of functionality.

• Use the IApiExplorer Service to expose “contract”
• Provides runtime description of WEB API
• Renders content in a useful way
• Shows request and response formats
• XML, JSON, url-encoded

Hosting

• Many options – self host(console), IIS, Azure roles, other web servers
• MSDN code gallery and NuGet Code packages are available

Other

• ASP.NET Web API is available as part of MVC4
• Is part of the recent open source movement that Microsoft has been involved in
• Product team accepts 3rd party contributions
• Unprecedented transparency
• When Microsoft  devs check in code, you have access to code through  GIT repository
• Asp.net mvc4 and web api is included in Visual Studio 2012 RC
• WebAPI is now a Visual Studio project template
• Can also create a unit test project
• New  MVC like map route for WebAPI
• api/{controller}/{id}
• JSON, XML and form-url-encoded supported out of the box for HTTP Request
• JSON and XML natively supported for HTTP Response
• Validation is run on the data from every request
• Check ModelState.IsValid to see if you have a valid request
• Support for ODATA queries
• return IQueryable<type> Get()
• decorate method with QueryAble

Conclusion

I realize that the release of this technology has been highly contested.  There have been people using the WCF stack that are now in a tough spot to migrate away from this technology to WebAPI.  For me, as someone new to this space I really liked how you organize your project and have clean separation from controller to controller.  You can quickly expose services without the need for heavy WSDL type contracts.

I also like how most of Daniel’s presentation was run from Fiddler.  Like he mentioned several times, WebAPI at its root is really just HTTP.  So what better tool to craft requests than Fiddler.

In closing, I do a lot of System Integration.  Primarily with BizTalk and must admit, I like contract based development where you are defining a firm contract upfront.  I have never been a big fan of loosely based lightweight services as things can quickly to to hell when doing this type of stuff for EAI.  However, I have woken up and seen the light.  I really do feel there are good use cases for this type of technology for light weight application based services.  I don’t necessarily think that this technology is a great fit for EAI, but for applications that may be surfaced using a variety of clients (mobile, web) I think this is a great way to expose back end services to front end client.

 

Stay tuned for Day 4 as I expect to have some encouraging BizTalk news to report!