Now that Azure’s pricing model is starting to take shape, we’re starting to see what Microsoft meant when they said Azure would be priced “competitively”. This week, Oakleaf Systems compared Azure to Amazon’s cloud offerings, highlighting costs for developers to gets started on these platforms (Amazon Undercuts Windows Azure Table and SQL Azure Costs with Free SimpleDB Quotas).
I believe Microsoft may be able to get away with pricing at a slight premium to Amazon and GAE, in large part because SQL Azure is an absolute killer feature because of its compatibility with existing SQL Server code. Nevertheless, Azure pricing has to be aggressive, or the value proposition for Azure starts to look weak. I think it’s especially important to make the platform available to developers at a free or near-free price point, or Microsoft just won’t be able to build the mind-share and experienced developer base it needs to grow, so I’ll continue to keep an eye on this space.
Logging is one of those “system” components that always seems to either be left out or way over-engineered (glares at Microsoft’s Enterprise Application Blocks). Today, I’d like to introduce you to a logging framework that’s everything it needs to be and nothing it doesn’t.
The .Net Logging Framework from The Object Guy is powerful enough to handle any of your logging needs, but simple and painless to use. Here’s a relatively complicated example — we’re going to log to three logging sources to demonstrate how easy it is to set up. In most cases, of course, you’ll log to only one or two sources:
/* first instantiate some basic loggers */
Logger consoleLogger = TextWriterLogger.NewConsoleLogger();
Logger fileLogger = new FileLogger("unit_test_results.log");
Logger socketLogger = new SerialSocketLogger("localhost", 12345);
/* now instantiate a CompositeLogger */
logger = new CompositeLogger();
/* add the basic loggers to the CompositeLogger */
logger.AddLogger("console", consoleLogger);
logger.AddLogger("file", fileLogger);
logger.AddLogger("socket", socketLogger);
/* now all logs to logger will automatically be sent
to the contained loggers as well */
/* logging is a one-liner */
logger.LogDebug("Logging initialized.");
When you download this logger, you’ll get all the source code, including a socket reader to catch the logs thrown by the socketLogger in the example above. Extending the logger is a piece of cake, too, so you could build yourself a WCF Logger, for instance, in no time flat.
You’ll note the lack of config file-driven settings in the example above — this is purely intentional. You can decide if you want to make any of these settings configurable, and do so in the format you’re comfortable with, so you don’t need to try to get your config files to conform to whatever format your logger insists on using. This small simplification can be a big time-saver for simple apps, debugging / test harness apps, and so on.
My first reaction was to share in the shock and horror of it all — after all, how could Microsoft issue a sample app so obviously riddled with problems, but as I thought about it some more, the real issue became obvious:
Real-world apps deal with this sort of coding all the time.
You see, very few apps evolve in environments that are conducive to crafting museum-quality code throughout the entire application. Very few software teams, in fact, are comprised entirely of developers who are capable of crafting this sort of code. Our development teams have imperfections, and so do our systems.
Maybe Microsoft should have been held to a higher standard because (a) they’re Microsoft, and (b) this is a sample application where the primary deliverable is the source code itself. That’s valid, but what’s more interesting to me is that this brand-spanking-new framework is so damned easy to mangle and abuse!
As architects and managers, one of the most valuable long-term effects we have on the software we develop is to leverage good ideas across our teams and our code. It’s not sufficient that we can dream up the perfect architecture and the perfect solution if it stays in our heads. The real measure of effectiveness is how well we can project these good ideas across the entire breadth of code in all of our systems, and this is where our current tools fall short.
Developers love C# because you can do anything with it. It’s a fabulously-flexible tool. Architects try to impose order by mandating the use of standards, frameworks, and constraints. It’s a perpetual tug of war. We’re supposed to be working together like an orchestra, but in most cases, we’re still a bunch of soloists who just happen to be on the same stage.
In Kobe’s case, the mere fact that people are opening up this code and recoiling in shock because the code doesn’t look the way they expected is proof that we’re not where we need to be — on many levels.
Microsoft and Google have each announced syncing tools for Windows Mobile phones recently, but based on what I’m seeing, I’m sticking with a service you’ve probably never heard of.
Microsoft announced “My Phone” last week, and today announced that it will be available for free. At present, it’s in limited beta, but I’d expect it to be unleashed on willing participants pretty soon. This service looks to be pretty limited, though — it looks to be a great way to back up your phone, but not too much beyond that.
Today, though, Google announced plans to support syncing for contacts and calendars to a bunch of phones, including Windows Mobile. Woot! A closer look at the fine print, though confirms that this (like all new Google features) is a beta feature, and may not be completely baked yet. Two-way sync, in particular, seems to be iffy for Windows Mobile devices.
Image via Wikipedia
So who needs these services, anyway? WinMo phones already synch to Outlook just fine, don’t they?
Personally, I want something like this because I don’t use Outlook anymore.
A few months ago, in a fit of Vista-inspired digust, I loaded Ubuntu on my home desktop, and vowed never to be stuck on a single desktop OS again. I’d been using Outlook, and this was the only way I’d been able to sync contacts and calendars to my Windows Mobile phone, and so began a long quest for a wireless sync option for my phone. I was amazed at how difficult this actually turned out to be, but I ended up using a service that I’ve been pretty happy with.
One of the most impactful things I saw at CodeMash wasn’t on the schedule. I’d dropped in to check out Jeff Blankenburg’s presentation on Azure & Windows Live Mesh, but it was clear that the demo gods weren’t about to smile on Jeff that day.
The CodeMashers had sucked up the hotel’s WiFi bandwidth like it was free beer, and Jeff’s demo was sucking wind. Now, truth be told, I’d seen a similar demo under more favorable conditions, and the demo rocks. I’m not trying to indict the demo, or even the technology.
What I do question, though, is whether we’re collectively thinking about all the architectural implications of the cloud computing movement.
There’s a giddy excitement about cloud computing, because scalability in the cloud is super-simple and all but free. You just twist a knob, and you’ve got more capacity. Really — that’s what all the marketing folks tell us, isn’t it?
But most of us won’t build enterprises entirely in the cloud. Most of us (or our clients) have systems running on internal networks, and we’re going to move portions of our systems to the cloud, or we’re going to expand into the cloud for new applications. That means integration — not only are we going to drive more traffic through our Internet gateway because we’re accessing applications running on the ‘Net, we’re also going to need to integrate our cloud apps to our enterprise and our enterprise apps to the cloud — again, all passing through the Internet gateway, and all using relatively fat HTTP requests.
Is your network ready for this extra stress?
Image via Wikipedia
I’ve seen enterprises operating with chronically poor network performance. I’ve seen internal apps running slowly, and I’ve seen the same apps slow to a crawl when accessed from the Internet. I’ve seen the baffled looks on IT Managers’ faces when they weren’t sure how to attack the problem of network performance. Networking problems are scary, because it takes a completely different skill set to identify and fix these problems than the skills we’ve developed as application developers.
Do you have a network engineer that you trust as completely as you trust your DBA’s?
Consider what you’re going to do the next time your office experiences a “slow internet day”. Now, you’re no longer talking about slow Google searches and interruptions to webcasts. Now, you’ve enterprise applications that aren’t working. Is your enterprise ready to handle that call?
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=149980d2-c57b-4438-b7a6-a25467bec41d)
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=79b514a7-5183-443d-8dff-f02d5901f21f)
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=98ece6e0-97e7-4e44-a196-8b05717e58e8)
