Saturday, November 29, 2008
Worker Trampled to Death in Wal-Mart Sales Stampede
Two armed men shoot and kill each other at a Toys-R-Us
Wednesday, November 26, 2008
ARCast.TV - Mickey Williams and David Pallmann of Neudesic on the Impact of Cloud Computing
Friday, November 21, 2008
One of the greatest gifts you can give yourself is self-improvement. Our shortcomings may be obvious to all around us but we can be blind to them. If you can recognize your shortcomings you can do something about them, and if you really work at it you can make some amazing and lasting changes in yourself.
One of my shortcomings is the sin of verbosity: taking too many words to say something. That is, using a much larger number of words to express something that really could be said in a much shorter and clearer way. Coupled with this is repetition, needlessly repeating what has already been said which is unnecessary because it has already been said. Do you see what I mean?
What's so bad about being verbose? It's just a few extra words after all. In fact, the driving force behind verbosity (at least in my case) is the desire to be precisely understood. To me it's always seemed downright dangerous to just say a few words: they might be understood incorrectly or incompletely. I now know that notion is completely backwards. Verbosity does not aid clarity, it impairs it.
Some people just downright hate verbosity. When my book Programming Indigo came out, one of the first reviews rather unnecessarily went to great lengths to trash the book. While I think the attack was way overblown (many have told me they appreciated this book), it was clear the reviewer was mostly offended by verbosity and repetition. And to that I plead guilty.
When I worked at Microsoft, my superiors had little tolerance for verbosity, or for me. :) While there I learned a great deal about how to take raw information and distill it into its essence and communicate it in a concise way with clarity. This takes work. Whoever said "if I had more time, I would have written a shorter letter" knew what they were talking about: brevity with clarity requires effort and refinement. It may come naturally to a precious few, but the rest of us have to work at it. Especially the great unwashed, verbozos like me. Brevity of course is right in line with the larger concept of Less is More.
Am I over my verbosity? No way, I'll need to consciously work at it for the rest of my life. But as an ongoing student of brevity, I'm getting better at it. I sometimes take 30 minutes to compose an email, not to make it long but to make it short--and clear. And I was able to reduce this blog posting from its original 1000 words down to 460. That says a lot.
Wednesday, November 19, 2008
Local Debugging. First off, the general hope is that you'll catch and fix problems on your local box long before you place anything into the cloud. Locally you can use familiar tools such as the Visual Studio debugger and event logs and other tools to get to the root of problems.
Application Logs. However, it's possible to have an app that works locally that doesn't work when deployed to the cloud. What do you do then? You look at the logs for your application, that's what you do. Unfortunately this is something of an involved process today:
- You have to first find the Copy Logs button, which is lurking under your Configure button on the Azure portal. This hasn't been obvious to everybody.
- Clicking Copy Logs will copy your logs to your storage account.
- Lastly you need to run a program to read your logs out of cloud storage so you can view them. There is a sample in the Azure SDK called CloudDrive that does this. It is an exension to PowerShell. There is some work involved to configure, build it, and get it going the first time around.
No doubt this will become more streamlined over time, but it's what we have to work with today. Benjamin Day has written an excellent post that gives a blow-by-blow account of exactly what you need to do, including screen captures. You can also instrument your application to write to those logs using the RoleManager.WriteToLog method.MSDN Forums. MSDN has a very good set of forums set up with several Azure categories. I've mostly been interacting with the Windows Azure forum, and I've found it to be a great place to go to get answers or help others. Moreover, Microsoft personnel have been fantastically responsive and helpful. So if the above methods don't help, post your problem to the appropriate forum. Between Microsoft and the community you'll likely get some help.
Tuesday, November 18, 2008
Is cloud computing just hosting, re-branded? The answer is no. And yes. Really, it's hosting++. Let's dig in and see how cloud computing is like and unlike hosting.
- Automatic Provisioning and Deployment. Like standard hosting, cloud computing gives you a place to run your applications and store your data in a managed data center. Unlike standard hosting, you aren't required to remotely connect to a specific set of machines and configure them yourself. Instead, you provide the data center with your code and metadata about what its needs are. The data center takes care of virtualization, provisioning, deployment, and load balancing for you--completely automatically. You never get involved in installing software or configuring servers. In Windows Azure, this is all controlled through a well-designed portal at Azure.com.
- On-Demand Scaling. Like standard hosting, your cloud computing code and data is maintained on servers and storage devices. Unlike standard hosting, the scale-out of your code and data happens automatically, on-demand. If traffic levels increase, so does the instancing. If traffic levels drop, the number of active instances goes down. You can grow anytime, without having to requisition new hardware. Azure never wastes your money or the data center's hardware.
- No Long Term Commitments. Like standard hosting, cloud computing costs something. In the case of Azure at least, you aren't required to make a long term commitment or sign a contract for a specified period of time such as one or more years. You pay for what you use, and you can stop anytime without penalty. It's computing done right.
- Pay as You Go. Standard hosting often charges you for keeping machines and storage available regardless of the extent to which they are actually used. In Windows Azure cloud computing, you only pay for what you use. If you use more, you pay more. If you use less, you pay less. Just like how your electric or water bill works.
- Additional Services. Standard hosting doesn't generally provide any new software capabilities, it's just an alternative place to run code and store data. Windows Azure does provide new software capabilities, and they are both numerous and compelling. Live Services allows you to tap into the Windows Live identity and contacts services. Geneva technology allows you to support enterprise customers and let them use their native security system; and you can even federate a mix of enterprises and security mechanisms simultaneously. SQL Services provides database services with new scalability options not available in the enterprise. .NET Services gives you a service bus, which allows for business-to-business publish/subscribe communication that is firewall friendly. .NET Services also lets you run workflow in the cloud. Windows Azure really is an operating system for the cloud, and Azure Services really provide applications with a fresh set of capabilities that are also easy to get at and combine.
- Available, Scalable, Reliable. In the enterprise, some of the hardest things to do well are high availability, dynamic scalability, and high reliability. These things come "for free" with the cloud any time you use it.
Hosting is to cloud computing like radio is to color TV. There's nothing wrong with hosting, but the next generation is upon us.
Saturday, November 15, 2008
Concern about storing data in the cloud is one of the first objections to cloud computing that is raised by some who work in the enterprise. Usually the expression of concern is followed by a gentle but firm explanation of how vital, proprietary, and utterly irreplaceable this information is. The message is clear: the data is critical to the operation of the business; the data must be protected; and maintaining its integrity and availability is paramount. The enterprise goes to great lengths to ensure this.
The first thing I will say about this is, you may be right in some cases. Some data does belong in the enterprise, depending on the nature of the data and the organization and the regulations it is subject to. But that's a far cry from saying no enterprise data should ever go into the cloud. That's why I think Microsoft's vision, called Software + Services, makes a great deal of sense for the enterprise. S + S is all about recognizing that some software and data is best kept local, while other software and data is best placed in the cloud. Rather than dictating what the split should be, S + S says you are in the best spot to make that determination. Dr. McCloud likes to call this writing your own prescription.
We can use the existence of the hosting industry to demonstrate the idea of putting your data "out there" can work for businesses. The idea is neither new or unproven and is used successfully today by businesses of all sizes. For sure, you need to have a strong comfort level about the vendor, the storage practices, the fail-safes, the data protection policies, the service level commitment, the security arrangements, and the degree of control you have. Dr. McCloud prefers sound methods of treatment and so do his patients.
Learning more about how the cloud infrastructure handles storage should also encourage you. Let's look at Windows Azure specifically. When you store something in the cloud, it gets simultaneously written to several different places, each in a different fault domain. SQL Services and cloud blob/queue/table storage are designed to scale supremely and automatically. Many things that are commonly needed in the enterprise are also very difficult, expensive, and time-consuming to get right, such as high availability, sufficient scalability, disaster recovery, and dynamic adjustments to changes in traffic levels. These things come "for free" with the cloud platform every time you use it.
One last point, putting data in the cloud does not necessarily mean it vanishes from the enterprise. We'll likely be seeing some interesting patterns develop for synchronizing and safeguarding data that lives in more than one place.
Cloud storage is a good thing, and you don't have to feel like you're taking some tremendous risk to try it out as long as you exercise a little common sense. Dr. McCloud thinks this makes for an excellent prognosis.
If you're not running SQL Server Express, you'll need to change two values in the DevelopmentStorage.exe.config file which resides in C:\Program Files\Windows Azure SDK\v1.0\bin to have the correct SQL Server instance name (shown in red below).
- The first is the DevelopmentStorageDbConnectionString value in the connectionStrings section.
- The second is the dbServer value in the developmentStorageConfig section's third Service entry (the one named Table).
<add name="DevelopmentStorageDbConnectionString" connectionString="Data Source=.\SQLEXPRESS;Initial Catalog=DevelopmentStorageDb;Integrated Security=True" providerName="System.Data.SqlClient" />
<add key="ClientSettingsProvider.ServiceUri" value="" />
<service name="Blob" url="http://127.0.0.1:10000/"/>
<service name="Queue" url="http://127.0.0.1:10001/"/>
<service name="Table" url="http://127.0.0.1:10002/" dbServer="localhost\SQLExpress"/>
Note that the first entry uses "." to indicate local machine while the second uses "localhost."
"Fear of clouds" existed before cloud computing ever came on the scene, and is known as nephophobia. Interestingly, there are quite a few parallels between this real-world phobia, the fear of clouds, and its newer cousin, the fear of cloud computing:
- In nephophobia, the patient can experience breathlessness, excessive sweating, nausea, dry mouth, feeling sick, shaking, heart palpitations, the inability to speak or think clearly, a fear of dying or losing control, a sensation of detachment from reality or a full blown anxiety attack. A select few seem to exhibit many of the same symptoms when confronted with cloud computing.
- In nephophobia, the patient has to come to grips that they are fearful of something that poses no actual danger. The same is true of cloud computing: whatever area you're concerned about (data, security, reliability, management) is potentially done better in the cloud computing environment, and with less personal headache to you and your organization. Granted, some of this is true today and some of it will come as cloud computing platforms mature.
- Treatment for nephophobia centers around "reality therapy", finding false constructs in the patient's mind and dealing with them, in effect reprogramming the subconscious. Likewise, a reality adjustment is a good treatment for fear of cloud computing: the more you understand about what it really is and how it works, the higher your comfort level is likely to be.
Fear of the cloud can take many forms, including fear of cloud storage, fear of cloud security, and fear of cloud reliability. In future posts we'll look at these aspects individually.
Dr. McCloud is here to put you at ease. Now sit back and relax so I can examine you with my nephoscope... aha, there's your problem!
Friday, November 14, 2008
- Service Management - technologies immature
- Scalability - parallel processing, no problem; sequential processing, different story
- Costs - economies of scale only go so far, unless customer is willing to trade data or advertising views for services
- Culture - trust, chargeback, sharing
- Connection - only as good as the Internet, unless you pay to harden your connection
- High Availability - for workloads that are stateless, no problem; for stateful workloads, same issue as enterprises
- Customization - difficult - at least with monolithic applications
Gartner is of course talking about the state of cloud computing generally as they see it. I thought it would be interesting to analyze whether these points ring true or not--and how deeply--with Windows Azure specifically in mind. Here's my take on it:
- Service Management - technologies immature. It's true many of the technologies are immature, this is just the start of a big wave with many implications. A good example is SQL Services compared to SQL Server in the enterprise, the enterprise version is far more capable today. However, in the case of Windows Azure not everything is immature. Microsoft has been doing online for some time now, growing in the scale and variety and reliability of what they offer--and some of these properties have been using the data center infrastructure. In other words, the cloud platform Microsoft is offering is also used by Microsoft itself.
- Scalability - strong parallel processing story, poor sequential processing story. This may be true of cloud computing offerings in general but here I think Azure has a very good story. One of the .NET Services in the platform is the Workflow Service. That would seem to address any kind of processing you have in mind, whether sequential, parallel, or a mix.
- Costs - economies of scale go only so far. I'm not sure what they're getting at here, they might mean that there's only so much cost savings to be realized. Well, so what? It's still a refreshing set of new choices, and no one's taking the traditional choices away. Cloud computing--at least in the Microsoft vision of Software + Services, is not about abandoning the enterprise and traditional ways of doing things. The whole idea is have some software local and some software in the cloud. The beauty of the S+S approach is that each organization is free to make their own determination about what makes sense local and what makes sense in the cloud. Obviously, cloud computing going to have a stronger appeal for some more than others.
- Culture - trust, chargeback, sharing. I do hear from some folks that they think the whole idea of putting software or data in the cloud is unrealistic, at least for their organizations. I guess my answer to that is threefold: 1. You may well be right, in your individual case. Some things just belong in the enterprise. 2. Secondly, the existence of a hosting industry testifies that some organizations are perfectly willing to put software and data "out there" as long as they can be satisfied about the security arrangements. 3. You might well change your mind down the road. Similar to web services, there are going to be the pioneers and the settlers in this new space. Not everyone's gong to be a pioneer, but the wave will likely hit everyone eventually one way or another.
- Connection - only as good as the Internet. True enough. But in case no one's noticed, we're all becoming very dependent on the Internet. That includes how customers interact with your business.
- High Availability - applications must be stateless. Well, that's true. The load balanced, virtualized, automatically provisioned nature of the platform needs stateless software to do well. But stateless has been a recognized best practice for some time now, especially in SOA, so this doesn't seem like a terrible restriction to me. And there are ways to pass state around even in nominally stateless applications.
- Customization - difficult - at least with monolithic applications. Once again I'm a little unclear as to what's being said here. In the case of Azure, I can't think of any customization restrictions the platform forces on you as compared to using .NET on premise. There are, in fact, some very nice customization capabilities in the platform including the ability to simultaneous support different security systems through federated security.
Putting it all together, I think Azure stacks up quite well against where the rest of the industry is in cloud computing. No one's pretending platform maturity, but what does exist is already compelling and competitive.
Monday, November 10, 2008
By David Pallmann, Director, Custom Application Development, Neudesic
I'm making it official and declaring that we are now in the midst of a major revolution in computing, perhaps with overtones that extend beyond technology. I'm calling it The "Less is More" Revolution. It amounts to a major refactoring of how we do things, ...of how we do everything.
When I say "Less is More", you probably think instantly of Apple, one of the great success stories in applying less is more as a design principle to hardware and software. If you're not a proponent of less is more, spending 10 minutes with an iPhone or an iPod will likely make a believer out of you.
But "Less is More" didn't start with Apple, nor does it end there. The phrase has actually been around since the 19th century. One of the founders of modern architecture who used the phrase often and believed deeply in simplicity of style was Mies Van Der Rohe, who dabbled in both architecture and furniture design. So less is more isn't new, but it is coming into full bloom.
"Less is More" certainly makes sense as a UI approach. The 80/20 rule frequently applies: you may find you can provide the important 80% of possible functionality with a mere 20% of the UI that you would need to cover everything. Not that this comes easily or automatically. It's not hard to make a simple interface that does simple things, nor is it particularly hard to make a detailed interface that does many things--but who wants to use either? What takes work and validation and refinement is finding the sweet spot where a simple and pleasing UI yields the most power for the user. That outcome is worth the extra effort it takes to get there.
Social networking web sites such as Facebook also demonstrate less is more. I and just about everyone else I know are on Facebook or similar sites constantly, and the primary activity is to update our "what are you doing right now?" status and view the status of others. From a computer science perspective, this is not exactly rocket science. From a social perspective, it's huge: I actually feel closer to friends and family today, many of whom are thousands of miles away, than ever. I feel more a part of their lives. It's a little thing with big implications. It's less is more.
The Agile Manifesto and accompanying interpretations are a good example of less is more in software development methodology. By focusing on what's important and reducing emphasis on the less important, you measurably accomplish more by doing less. In other words, less is more can be applied to process. This has great implications for improving business process itself as well as the technologies that support business process such as workflow engines.
"Less is More" has been popping up as a principle in web technologies as well. The influence of REST, an approach to simplifying the way data and resources are exposed on the web, is phenomenal. When I worked at Microsoft during the time when WCF was being developed, I don't think I heard the term "REST" once. Today, not only can WCF do REST, support for REST seems to permeate just about everything Microsoft is doing. Don't believe me? Search MSDN for "REST" and you'll get close to 500,000 hits.
"Less is More" and REST are both utterly pervasive in Windows Azure, Microsoft's cloud computing platform. Just about anything you could want to do with the cloud computing platform can be invoked or accessed as an HTTP REST URL. That includes database storage and queries with SQL Services. At the recent PDC convention in LA, Don Box and Chris Anderson showed the attendees just how much they could accomplish using just REST and simple web HTTP requests. You can watch the video here.
In the cloud computing case, the "Less is More" effect is quite pronounced. As Microsoft extends its enterprise platform into the cloud, with new capabilities and new business models, you might well expect increased complexity in designing, implementing, and deploying software. Instead, there's less work involved. Things are just a lot simpler to get at and work with and combine and deploy, thanks to some great design decisions. I do have to admit "less" also rings true in another sense: there is less functionality available to you. Because the platform is so young, there are lots of things you give up. The cloud offerings aren't anywhere close to what the enterprise technologies give you, today, but they do give you the most important things. I'll readily admit SQL Services in the cloud appears to give me only a fraction of the functionality of SQL Server in the Enterprise in its present form. Of course that will change over time. The interesting point is, it doesn't matter. I'm going to happily use it anyway, because the "more" the platform gives me more than makes up for the "less": the way the platform is put together is so radically empowering that it's worth it to put up with functional omissions.
I'm thinking less is more is now a firmly entrenched and warmly embraced concept in the minds and hearts of consumers, meaning there's going to be more and more demand for it in everything from web applications to kitchen appliances. A growing portion of the public knows the difference between overengineering and elegant design now from firsthand experience, and everything I'm observing indicates people will flock to refreshing alternatives in droves at every opportunity--even when there's some additional cost involved.
"Less is more" is sometimes defined as "minimalism", but I'm not sure I like that word as it suggests "doing without" or some sort of monastic asceticism. When less is more is done well, you don't feel like you've given up anything. Rather, you feel highly empowered and effective. When you encounter less is more engineering in your daily life on a regular basis, the sun shines a little bit brighter, the sky is bluer, and the birds are singing more loudly and cheerfully than ever. It's a good thing, and when you enter that zone you don't ever want to leave it.
Is less is more a discipline for designers, or is it a something to be mastered by every developer? I say it needs to be both. We clearly won't get less is more pervasively unless designers lead the way with this as a foremost principle, but less is more extends far beyond design, as we've already illustrated. Developers need to practice less is more every time they create a class, implement a function, or design an interface. Remember, less does not automatically lead to more: that result is never an accident. Rather, it's a by-product of conscious intent. For this reason, all developers need a firm understanding of the principle. Fortunately, excellent groundwork has been laid by Martin Fowler and others in advocating refactoring. Less is more fits in with refactoring quite nicely.
What makes me think I'm right about this? These influences have been going on for some time, but my recent foray into Cloud Computing with Microsoft's Windows Azure platform is what brought it all into sharp focus. Exposure to elegance is contagious and addictive. Try it, you'll like it.
In the film Castaway, there is a moment when Tom Hanks finally is able to get a fire built. Beating his chest, he proclaims to the world, "I HAVE MADE FIRE!" That's exactly how you will feel when you get your first cloud app running and deployed, no matter how simple your first effort is.
Last week, I made fire. Who knows what this week will bring!
Saturday, November 8, 2008
"Whatsup" is a simple version of the "what are you doing right now" functionality you find on Facebook and other sites. Whatsup lets you post your name and status and view the statuses of others. Here's what it looks like.
When you access the page, you see the recent status of others. If you enter your name and status and click Post, the page updates to show your status top most.
Obviously this isn't a terribly sophisticated program, but it does make a nice transition from "Hello, Cloud" to something more substantail. You can actually build this app from scratch in front of an audience and deploy to the cloud in 30-45 minutes which makes this great for user groups and training sessions.
Thursday, November 6, 2008
1. In Solution Explorer, right-click the cloud project and select Publish.
2. The publish folder for your application will open in Windows Explorer, showing a package file and a config file. You'll need those in a moment.
3. The azure.com cloud portal will open up in your web browser (you have signed up and received your cloud account, right? If not, go to http://www.azure.com right now and take care of it).
4. Either create a new project on the portal or select an existing one. You'll then be at the page shown below, which I'll refer to as the Environment Page. On the left is a Production environment, and on the right is a Staging environment.
5. If you have a Deploy button under the Staging environment, proceed to Step 6. Otherwise, click Delete to delete the previous deployment. After that a Deploy button should be visible.
6. Click the Deploy button under Staging and you'll get this Staging Deployment page.
7. Now click the first Browse button and select the .cspkg ("cloud service package") file from the Publish folder that opened up in Step 2. Then click the second Browse button and select the .cscfg ("cloud service config") file. Lastly, enter a label for the deployment, such as a version number.
8. Click Deploy and the process will begin. It may take a little while.
9. Once deployment is complete, you'll be back at the Environment Page and will have new buttons under Staging. Click Run to start your app running in the staging environment.
10. To access your app, click on the Website URL link (in red, contains a GUID). Your app will open in a browser window. Try it out and make sure it's working as you expect. You can repeat this entire process as many times as necessary if you need to make changes to your project.
11. Once you're happy with your app in the Staging environment, you can switch it over to Production. Just click the Promote button (blue circle with white arrows).
12. After a brief wait, your app has been moved to Production. It can now be accessed at its intended URL. You're done!
Sunday, November 2, 2008
Azure, most people know, means blue. But which blue? Wikipedia somewhat unhelpfully first tells us the precise hue that azure is, then does an about face and admits it can be a synonym for blue in general, often sky blue or United Nations Blue.
In some color systems, azure is defined more specifically. In the X11 color system which became a standard for early Web colors, azure is a pale blue color. "United Nations blue", as it's called by the United Nations, is the light blue color of the Flag of the United Nations and of the helmets worn by the United Nations peacekeeping forces.
And then there's the matter of how to pronounce Azure. Is it "az'URE" (rhymes with "bonJOUR"), or "AZ'ure" (rhymes with... nothing). I fully expected when I checked dictionary.com to find both pronunciations listed, but it turns out only the latter pronunciation (emphasis on first syllable) is correct. So it's AZ'ure (āzh'ər). It may well have a different pronunciation in some other languages.
Hue and pronunciation aside, Windows Azure is an exciting cloud computing platform. At least, that's how I see it. And say it.