I recently did a clean install of Windows 7 64-bit. It had been a really long time since I listed the current tools, SDKs, and frameworks that I’ve been using. Thus here’s my entourage of software that I use on a regular basis that is installed on my primary development machines.
In addition to these packages of software another as important, if not more important to my day-to-day software development includes these software services and cloud hosting services.
Tomorrow is the big day! So be sure to come check out CloudCamp Seattle! We’re going to have a lot of great attendees, some rock star lightning talks and more. Make sure to get registered ASPA (click on the CloudCamp image above).
Location:
Amazon HQ
426 Terry Avenue North (At South Lake Union)
2nd Floor Conference Room
Seattle, WA 98109
Final Schedule:
6:00pm Registration, Networking w/ Food & Drinks
6:30pm Welcome and Thank yous
6:45pm Lightning Talks (5 minutes each)
Tony Cowan – WebSphere CloudBurst/Hypervisor Editions
Mithun Dhar – Microsoft Azure
Steve Riley – Amazon Web Services
Sundar Raghavan – Skytap
Josh Wieder – Atlantic.net
Margaret Dawson – Hubspan
Patrick Escarcega – “Managing Fear – Transitioning to the Cloud
7:30pm Unpanel
8:00pm Begin Unconference (organize the unconference)
8:15pm Unconference Session 1
9:00pm Unconference Session 2
9:45pm Wrap-up Session
10:00pm Raffle Books: “Host your website in the cloud” by Jeff Barr
10:15pm Drinks at 13coins sponsored by Clear Wireless Internet
Alright, time for the battle o’ clouds to roll on. In this throw down I’m going to compare platforms from the infrastructure and platform perspective. Windows Azure takes a very distinctive, and unique, Platform as a Service (PaaS) model and Amazon Web Services takes a very Infrastructure as a Service (IaaS) model. Each of these things start at different architectural levels for applications and provide different architectural perspectives. Before jumping into the comparison let’s take a look at what a developer, IT, or network specialist has to consider when building and deploying an application into either environment. I’ve highlighted the following steps to the specific profession that each model would most likely involve.
PaaS, Platform as a Service development and deployment model
Steps to Begin Building a Web Application or Service Application
Start a Project in your preferred development environment.
Build the code base. (Such as a web application or service application)
Create the platform web or service role for hosting the web or service application.
Setup the project deployment with the role parameters.
Deploy the project to that location.
Setup an appropriate domain name and point it at the site via nameserver/DNS.
IaaS, Infrastructure as a Service development and deployment model
Steps to Begin Building a Web Application or Service Application
Start a Project in your preferred development environment.
Build the code base. (Such as a web application or service application)
Start the OS Instance of your choice.
Install and configure the environment for hosting (IIS, Apache, or otherwise).
Setup the project deployment with the role parameters.
Deploy the project to that location.
Setup an IP address or externally accessible addressing for the instance.
Setup an appropriate domain name and point it at the site via nameserver/DNS.
As one can see there are more steps, and with reason, more costs to IaaS than to PaaS. With IaaS more control and with PaaS less control, but with the lack of control comes lower costs and barriers for entry. This is most likely, as I’ve heard more than a few times, why Microsoft has pushed the PaaS instead of going IaaS.
So how do each play out in offering the Platform as a Service?
First off, I have to point out that Amazon Web Services doesn’t really offer a PaaS. So comparing them directly is almost impossible. In addition, by not offerring a PaaS it sets up AWS at a disadvantage in this realm. But that being the case, there are 3rd Party Software Companies that offer PaaS Solutions for AWS such as Makara and Heroku. In addition there is rumor that AWS may be heading for a PaaS Offering soon.
I’ve fought with this topic in regards to AWS & Azure. It all really comes down to what your point of view is. So that’s how I’m going to score each of the services. I’ll layout a point of view (POV), which will be a simple description of the team that is building the cloud software, what the end goal is from the business in generic terms, then layout what would be a higher or lower cost, and finally which would provide the fastest time to market with the least amount of cost. It’ll be complex on the back end, but I’ll work to lay it out as neatly as I can.
POV: A Small Business, less than 15 people, working toward a website style SaaS Product.
The team has enough experience and technical skills to develop the product from AWS’s IaaS or Azure PaaS.
The business wants the product out to market in 3 months.
The team & business knows which geographic regions they need to focus on specifically.
The team wants control over instances and has flexibility of server OS, preventing OS lock in. (i.e. they can use Windows or Linux)
Autoscaling must be robust as traffic is expected, hopefully, to skyrocket as the product becomes recognized and available.
In this situation, AWS wins because of items 1, 2, 3, 4, and especially 5.
POV: A small business, less than 15 people, working toward a website style SaaS Product.
The team has .NET and Windows deployment experience, but minimal experience around networking, hosting, or infrastructure experience.
The business wants the product out to market in 3 months.
The team & business don’t care what geographic region the website is focused in.
The team doesn’t care about server lock in, Windows is fine by them.
Autoscaling and controlling traffic bursts isn’t a high priority for the team or business.
In this situation, Azure wins hands down based on 1, 2, 3, 4, and 5.
POV: An enterprise team wants to create a high quality code base, utilizing SCRUM with test driven development practices.
The team knows .NET and Java very well and a little bit of networking, hosting, and infrastructure.
The enterprise wants a steady release cycle of tested, highly reliable code.
The enterprise isn’t worried about which OS the team uses. Windows or a *nix variant.
Autoscaling is irrelevant, as long as capacity can be brought up and down in a timely manner to extremely high counts exceeding 1000+ instances.
In this situation, AWS wins hands down on 1, 2, 3, and 4.
POV: An enterprise team wants to deploy regularly, maintain their existing .NET stack, and utilize existing SDKs to keep the ramp up time minimal.
The team wants to use a familiar stack based on .NET and use SDKs if available.
The team isn’t concerned heavily with testable code, mostly just have a framework to build around that is familiar.
The business just wants the team to maintain familiarity with what exists in the company already.
The team wants to provide a single sign on (SSO) security implementation, using the cloud if possible.
In this situation, Azure wins easily for reasons 1, 2, 3, and 4.
POV: A Development team is putting together a public facing SaaS application.
The team wants to use whatever product has the best price point.
The team wants a strong enterprise style message bus to provide application messaging.
The business wants to deploy frequently and as soon as possible.
The team doesn’t care if the code is PHP, Java, .NET, or otherwise.
The team will create high quality code, and will build their own testing mocks, stubs, and other elements if need be.
The team doesn’t intend to use the SDKs from either AWS or Windows Azure, they want to keep lock in minimal so are building to services using good design patterns.
This situation is unique, and causes a tie between Azure and AWS for reasons 1 and 2 combined, 3, 4, 5, and 6.
Windows Azure
Based on these scorings, things might be a little confusing. I’ll elaborate a bit on some key points in the next entry on AWS vs. Azure. For now, I’m going to hand the victory to Windows Azure. The reason is simple, the PaaS perspective, in a little more than 50% of situation where PaaS or IaaS can be used should go with Windows Azure. In situations where a PaaS is desired then Windows Azure is pretty much the only serious option out there these days. Simply, Windows Azure just offers a ton of really serious features via cloud services for a PaaS offering. Stay tuned for the next grand battle between the cloud giants!
I’ve had the pleasure of working with WCF on three specific projects that have brought me to this blog entry. I haven’t used WCF on only three projects, there are just three that have brought me to write this entry. I’ve used WCF a lot, since back when it was a beta. WCF is great when creating SOAP services and you aren’t too worried about the extra overhead. WCF is great for what it does, for the ideas behind what it does.
But writing RESTful web services doesn’t seem to be its strong point. On two huge projects WCF has basically been dropped, or so scaled back one really can’t honestly say that WCF is used, and either an alternate framework has been used or a LOT of custom code ends up being written.
The first time I used WCF to implement RESTful service was at Webtrends. Albeit, there is a single service that returns all types of awesome reporting goodness, however to implement basic auth, logging, polling, and a whole host of other Enterprise Scale needs we had to custom roll most of it. Keep in mind, when doing this the WCF REST capabilities were brand shiny and new, so there were a few issues to work out. Now, maybe WCF could be used and a lot of it would be built in. However as it was, we easily spent 60% of the time writing custom bits because WCF just didn’t have the right options with the right bindings.
But I digress, I recently implemented an architecture using RESTful services using WCF. But now I’ve come to find myself dropping WCF because of the back and forth and going with ASP.NET MVC controller actions to return JSON instead. With that, here’s to the lean mean controller actions rockin’ the JSON. Here’s what I’ve done to port everything from WCF to MVC.
To see what I had done, except on a smaller scale, check out my previous blog entry on ASP.NET MVC with a WCF project smack in the middle of it. This will give you an idea of what I was using the WCF services for, merely to provide JSON results via RESTful services to an ASP.NET MVC front end requesting data with jQuery.
This is how I’ve setup the controller to return JSON results via an action.
First start a new ASP.NET MVC Project and add a new controller. Cleanup the controller so that you have the following in the controller.
[sourcecode language=”csharp”]
using System.Web.Mvc;
namespace RestWebServicesWithMvc.Controllers
{
public class ServicesController : Controller
{
}
}
[/sourcecode]
Now create a testing project to create your test first. Remember to add the reference to the ASP.NET MVC project. From here we can create the first test.
[sourcecode language=”csharp”]
using Microsoft.VisualStudio.TestTools.UnitTesting;
using RestWebServicesWithMvc.Controllers;
namespace RestWebServicesWithMvc.Tests
{
[TestClass]
public class UnitTest1
{
[TestMethod]
public void TestMethod1()
{
var controller = new ServicesController();
var result = controller.GetBiz();
Assert.IsNotNull(result);
}
}
}
[/sourcecode]
Now fill out the basic skeleton of the action in the controller.
[sourcecode language=”csharp”]
using System;
using System.Web.Mvc;
namespace RestWebServicesWithMvc.Controllers
{
public class ServicesController : Controller
{
public ActionResult GetBiz()
{
throw new NotImplementedException();
}
}
}
[/sourcecode]
Now we should have a good red running on our test. Let’s create a business model class to return as our result next.
[sourcecode language=”csharp”]
namespace RestWebServicesWithMvc.Models
{
public class BizEntity
{
public string BizName { get; set; }
public string StartupDate { get; set; }
public int SalesThisMonth { get; set; }
}
}
[/sourcecode]
Now let’s return that object with some fake data. First add [AcceptVerbs(HttpVerbs.Post)] to the action in the controller. Then return a serializable object to the actual method as shown.
This is a quick starter. There are a few dozen other options around this capability including other verb usage. For many, this is all you need for your services, especially if their primary purpose is to communicate with a specific website and one doesn’t want the overhead of WCF.
I’ve been working through an architecture scenario recently. This is what I have so far. Multiple external web services, some SOAP and some REST, and some data sources in a SQL Server Database, Azure Table Storage, and flat files of some sort. All of these sources need to be accessed by a web site for read-only display. In the diagram below I’ve drawn out the primary three points of reference.
The services that are external; Contract, Table Store, Document, Search, and Help Desk Services.
The Website Web Services Facade, which would be an aggregated layer that then provides the various services via an internally controlled services layer.
On top of that will be the web site, accessing the services from the aggregated layer with jQuery.
Basic Three Tiers
After creating this to get some basic idea of how these things should fit together, I moved on to elaborate on the web services aggregation layer. What I’ve sketched in this diagram is the correlation to architectural elements and the physical environments they would prospectively be deployed to. Again, broken out by the three tiers as shown above.
Website and the respective jQuery, AJAX, and Market/CSS for display.
Web Services, which include the actual architecture breakout; Facade Interface, Facade Aggregation Component, Cache & Non-cached DTOs (Data Transfer Objects), Cache Database/Storage, Caching Process, Lower Layer Aggregation Component, and the Poller Process for polling the external services.
The cache is intended to use SQL Server, thus the red call out to the physical SQL Server cluster.
The last tier, which isn’t being developed, but just providing data is the External Services, primarily shown to provide a full picture of all the layers.
Aggregate Web Services
I primarily drew up these diagrams for discussion of the architecture, poke holes in it, or otherwise. Which speaking of, if any readers have input, question, or are curious please type up a comment and I’ll answer it ASAP.
As the effort continues there are some other great how-to write ups I will be putting together. Everything from unit testing, mocking (with moq), how to setup test services, test services, and other elements of the project. I’ll have all this coming, so keep reading & let me know what you think of the design so far, subscribe via e-mail (look to the metadata section below), or grab the RSS for the blog (see below also).
You must be logged in to post a comment.