Microsoft Azure for Dummies – or for Smarties?
What Is Microsoft Azure?
I'm going to attempt to explain Microsoft Azure in "normal Web person" language. Like many of you, I am more familiar with Linux/open source type solutions, and like many of you, my first forays into cloud computing have been with Amazon Web Services. It can often be hard for people not steeped in Redmondese to understand exactly what the heck they're talking about when Microsoft people try to explain their offerings. (I remember a time some years ago I was trying to get a guy to explain some new Microsoft data access thing with the usual three letter acronym name. I asked, "Is it a library? A language? A protocol? A daemon? Branding? What exactly is this thing you're trying to get me to uptake?" The reply was invariably "It's an innovative new way to access data!" Sigh. I never did get an answer and concluded "Never mind.")
Microsoft has released their new cloud offering, Azure. Our company is a close Microsoft partner since we use a lot of their technologies in developing our company's desktop software products, so as "cloud guy" I've gotten some in depth briefings and even went to PDC this year to learn more (some of my friends who have known me over the course of my 15 years of UNIX administration were horrified). "Cloud computing" is an overloaded enough term that it's not highly descriptive and it took a while to cut through the explanations to understand what Azure really is. Let me break it down for you and explain the deal.
Point of Comparison: Amazon (IaaS)
In Amazon EC2, as hopefully everyone knows by now, you are basically given entire dynamically-provisioned, hourly-billed virtual machines that you load OSes on and install software and all that. "Like servers, but somewhere out in the ether." Those kinds of cloud offerings (e.g. Amazon, Rackspace, most of them really) are called Infrastructure As A Service (IaaS). You're responsible for everything you normally would be, except for the data center work. Azure is not an IaaS offering but still bears a lot of similarities to Amazon; I'll get into details later.
Point of Comparison: Google App Engine (PaaS)
Take Google's App Engine as another point of comparison. There, you just upload your Python or Java application to their portal and "it runs on the Web." You don't have access to the server or OS or disk or anything. And it "magically" scales for you. This approach is called Platform as a Service (PaaS). They provide the full platform stack, you only provide the end application. On the one hand, you don't have to mess with OS level stuff - if you are just a Java programmer, you don't have to know a single UNIX (or Windows) command to transition your app from "But it works in Eclipse!" to running on a Web server on the Internet. On the other hand, that comes with a lot of limitations that the PaaS providers have to establish to make everything play together nicely. One of our early App Engine experiences was sad - one of our developers wrote a Java app that used a free XML library to parse some XML. Well, that library had functionality in it (that we weren't using) that could write XML to disk. You can't write to disk in App Engine, so its response was to disallow the entire library. The app didn't work and had to be heavily rewritten. So it's pretty good for code that you are writing EVERY SINGLE LINE OF YOURSELF. Azure isn't quite as restrictive as App Engine, but it has some of that flavor.
Azure's Model
Windows Azure falls between the two. First of all, Azure is a real "hosted cloud" like Amazon Web Services, like most of us really think about when we think cloud computing; it's not one of these on premise things that companies are branding as "cloud" just for kicks. That's important to say because it seems like nowadays the larger the company, the more they are deliberately diluting the term "cloud" to stick their products under its aegis. Microsoft isn't doing that, this is a "cloud offering" in the classical (where classical means 2008, I guess) sense.
However, in a number of important ways it's not like Amazon. I'd definitely classify it as a PaaS offering. You upload your code to "Roles" which are basically containers that run your application in a Windows 2008(ish) environment. (There are two types - a "Web role" has a stripped down IIS provided on it, a "Worker role" doesn't - the only real difference between the two.) You do not have raw OS access, and cannot do things like write to the registry. But, it is less restrictive than App Engine. You can bundle up other stuff to run in Azure - even run Java apps using Apache Tomcat. You have to be able to install whatever you want to run "xcopy only" - in other words, no fancy installers, it needs to be something you could just copy the files to a Windows PC, without administrative privilege, and run a command from the command line and have it work. Luckily, Tomcat/Java fits that description. They have helper packs to facilitate doing this with Tomcat, memcached, and Apache/PHP/MediaWiki. At PDC they demoed Domino's Pizza running their Java order app on it and a WordPress blog running on it. So it's not only for .NET programmers. Managed code is easier to deploy, but you can deploy and run about anything that fits the "copy and run command line" model.
I find this approach a little ironic actually. It's been a lot easier for us to get the Java and open source (well, the ones with Windows ports) parts of our infrastructure running on Azure than Windows parts! Everybody provides Windows stuff with an installer, of course, and you can't run installers on Azure. Anyway, in its core computing model it's like Google App Engine - it's more flexible than that (g00d) but it doesn't do automatic scaling (bad). If it did autoscaling I'd be willing to say "It's better than App Engine in every way."
In other ways, it's a lot like Amazon. They offer a variety of storage options - blobs (like S3), tables (like mySQL), queues (like SQS), drives (like EBS). They have an integral CDN. They do hourly billing. Pricing is pretty similar to Amazon - it's hard to totally equate apples to apples, but Azure compute is $0.12/hr and an Amazon small Windows image compute is $0.12/hr (Coincidence? I think not.). And you have to figure out scaling and provisioning yourself on Amazon too - or pay a lot of scratch to one of the provisioning companies like RightScale.
What's Unique and Different
Well, the largest thing that I've already mentioned is the PaaS approach. If you need OS level access, you're out of luck; if you don't want to have to mess with OS management, you're in luck! So to the first order of magnitude, you can think of Azure as "like Amazon Web Services, but the compute uses more of a Google App Engine model."
But wait, there's more!
One of the biggest things that Azure brings to the table is that, using Visual Studio, you can run a local Azure "fabric" on your PC, which means you can develop, test, and run cloud apps locally without having to upload to the cloud and incur usage charges. This is HUGE. One of the biggest pains about programming for Amazon, for instance, is that if you want to exercise any of their APIs, you have to do it "up there." Also, you can't move images back and forth between Amazon and on premise. Now, there are efforts like EUCALYPTUS that try to overcome some of this problem but in the end you pretty much just have to throw in the towel and do all dev and test up in the cloud. Amazon and Eclipse (and maybe Xen) - get together and make it happen!!!!
Here's something else interesting. In a move that seems more like a decision from a typical cranky cult-of-personality open source project, they have decided that proper Web apps need to be asynchronous and message-driven, and by God that's what you're going to do. Their load balancers won't do sticky sessions (only round robin) and time out all connections between all tiers after 60 seconds without exception. If you need more than that, tough - rewrite your app to use a multi-tier message queue/event listener model. Now on the one hand, it's hard for me to disagree with that - I've been sweating our developers, telling them that's the correct best-practice model for scalability on the Web. But again you're faced with the "Well what if I'm using some preexisting software and that's not how it's architected?" problem. This is the typical PaaS pattern of "it's great, if you're writing every line of code yourself."
In many ways, Azure is meant to be very developer friendly. In a lot of ways that's good. As a system admin, however, I wince every time they go on about "You can deploy your app to Azure just by right clicking in Visual Studio!!!" Of course, that's not how anyone with a responsibly controlled production environment would do it, but it certainly does make for fast easy adoption in development. The curve for a developer who is "just" a C++/Java/.NET/whatever wrangler to get up and going on an IaaS solution like Amazon is pretty large comparatively; here, it's "go sign up for an account and then click to deploy from your IDE, and voila it's running on the Intertubes." So it's a qualified good - it puts more pressure on you as an ops person to go get the developers to understand why they need to utilize your services. (In a traditional server environment, they have to go through you to get their code deployed.) Often, for good or ill, we use the release process as a touchstone to also engage developers on other aspects of their code that need to be systems engineered better.
Now, that's my view of the major differences. I think the usual Azure sales pitch would say something different - I've forgotten two of their huge differentiators, their service bus and access control components. They are branded under the name "AppFabric," which as usual is a name Microsoft is also using for something else completely different (a new true app server for Windows Server, including projects formerly code named Dublin and Velocity - think of it as a real WebLogic/WebSphere type app server plus memcache.)
Their service bus is an ESB. As alluded to above, you're going to want to use it to do messaging. You can also use Azure Queues, which is a little confusing because the ESB is also a message queue - I'm not clear on their intended differentiation really. You can of course just load up an ESB yourself in any other IaaS cloud solution too, so if you really want one you could do e.g. Apache ServiceMix hosted on Amazon. But, they are managing this one for you which is a plus. You will need to use it to do many of the common things you'd want to do.
Their access control - is a mess. Sorry, Microsoft guys. The whole rest of the thing, I've managed to cut through the "Microsoft acronyms versus the rest of the world's terms and definitions" factor, but not here. "You see, you use ACS's WIF STS to generate a SWT," says our Microsoft rep with a straight face. They seem to be excited that it will use people's Microsoft Live IDs, so if you want people to have logins to your site and you don't want to manage any of that, it is probably nice. It takes SAML tokens too, I think, though I'm not sure if the caveats around that end up equating to "Well, not really." Anyway, their explanations have been incoherent so far and I'm not smelling anything I'm really interested in behind it. But there's nothing to prevent you from just using LDAP and your own Internet SSO/federation solution. I don't count this against Microsoft because no one else provides anything like this, so even if I ignore the Azure one it doesn't put it behind any other solution.
The Future
Microsoft has said they plan to add on some kind of VM/IaaS offering eventually because of the demand. For us, the PaaS approach is a bit of a drawback - we want to do all kinds of things like "virus scan uploaded files," "run a good load balancer," "run an LDAP server", and other things that basically require more full OS access. I think we may have an LDAP direction with the all-Java OpenDS, but it's a pain point in general.
I think a lot of their decisions that are a short term pain in the ass (no installs, no synchronous) are actually good in the long term. If all developers knew how to develop async and did it by default, and if all software vendors, even Windows based ones, provided their product in a form that could just be "copy and run without admin privs" to install, the world would be a better place. That's interesting in that "Sure it's hard to use now but it'll make the world better eventually" is usually heard from the other side of the aisle.
Conclusion
Azure's a pretty legit offering! And I'm very impressed by their velocity. I think it's fair to say that overall Azure isn't quite as good as Amazon except for specific use cases (you're writing it all in .NET by hand in Visual Studio) - but no one else is as good as Amazon either (believe me, I evaluated them) and Amazon has years of head start; Azure is brand new but already at about 80%! That puts them into the top 5 out of the gate.
Without an IaaS component, you still can't do everything under the sun in Azure. But if you're not depending on much in the way of big third party software chunks, it's feasible; if you're doing .NET programming, it's very compelling.
Do note that I haven't focused too much on the attributes and limitations of cloud computing in general here - that's another topic - this article is meant to compare and contrast Azure to other cloud offerings so that people can understand its architecture.
I hope that was clear. Feel free and ask questions in the comments and I'll try to clarify!
A Case For Images
After speaking with Luke Kanies at OpsCamp, and reading his good and oft-quoted article "Golden Image or Foil Ball?", I was thinking pretty hard about the use of images in our new automated infrastructure. He's pretty against them. After careful consideration, however, I think judicious use of images is the right thing to do.
My top level thoughts on why to use images.
- Speed - Starting a prebuilt image is faster than reinstalling everything on an empty one. In the world of dynamic scaling, there's a meaningful difference between a "couple minute spinup" and a "fifteen minute spinup."
- Reliability - The more work you are doing at runtime, the more there is to go wrong. I bet I'm not the only person who has run the same compile and install on three allegedly identical Linux boxen and had it go wrong somehow on one of 'em. And the more stuff you're pulling to build your image, the more failure points you have.
- Flexibility - Dynamically building from stem cell kinda makes sense if you're using 100% free open source and have everything automated. What if, however, you have something that you need to install that just hasn't been scripted - or is very hard to script? Like an install of some half-baked Windows software that doesn't have a command line installer and you don't have a tool that can do it? In that case, you really need to do the manual install in non-realtime as part of a image build. And of course many suppliers are providing software as images themselves nowadays.
- Traceability - What happens if you need to replicate a past environment? Having the image is going to be a 100% effective solution to that, even likely to be sufficient for legal reasons. "I keep a bunch of old software repo versions so I can mostly build a machine like it" - somewhat less so.
In the end, it's a question of using intermediate deliverables. Do you recompile all the code and every third party package every time you build a server? No, you often use binaries - it's faster and more reliable. Binaries are the app guys' equivalent of "images."
To address Luke's three concerns from his article specifically:
- Image sprawl - if you use images, you eventually have a large library of images you have to manage. This is very true - but you have to manage a lot of artifacts all up and down the chain anyway. Given the "manual install" and "vendor supplied image" scenarios noted above, if you can't manage images as part of your CM system than it's just not a complete CM system.
- Updating your images - Here, I think Luke makes some not entirely valid assumptions. He notes that once you're done building your images, you're still going to have to make changes in the operational environment ("bootstrapping"). True. But he thinks you're not going to use the same tool to do it. I'm not sure why not - our approach is to use automated tooling to build the images - you don't *want* to do it manually for sure - and Puppet/Chef/etc. works just fine to do that. So if you have to update something at the OS level, you do that and let your CM system blow everything on top - and then burn the image. Image creation and automated CM aren't mutually exclusive - the only reason people don't use automation to build their images is the same reason they don't always use automation on their live servers, which is "it takes work." But to me, since you DO have to have some amount of dynamic CM for the runtime bootstrap as well, it's a good conservation of work to use the same package for both. (Besides bootstrapping, there's other stuff like moving content that shouldn't go on images.)
- Image state vs running state - This one puzzles me. With images, you do need to do restarts to pull in image-based changes. But with virtually all software and app changes you have to as well - maybe not a "reboot," but a "service restart," which is virtually as disruptive. Whether you "reboot your database server" or "stop and start your database server, which still takes a couple minutes", you are planning for downtime or have redundancy in place. And in general you need to orchestrate the changes (rolling restarts, etc.) in a manner that "oh, pull that change whenever you want to Mr. Application Server" doesn't really work for.
In closing, I think images are useful. You shouldn't treat them as a replacement for automated CM - they should be interim deliverables usually generated by, and always managed by, your automated CM. If you just use images in an uncoordinated way, you do end up with a foil ball. With sufficient automation, however, they're more like Russian nesting dolls, and have advantages over starting from scratch with every box.
Agile Operations
It's funny. When we recently started working on an upgrade of our Intranet social media platform, and we were trying to figure out how to meld the infrastructure-change-heavy operation with the need for devs, designers, and testers to be able to start working on the system before "three months from now," we broached the idea of "maybe we should do that in iterations!" First, get the new wiki up and working. Then, worry about tuning, switching the back end database, etc. Very basic, but it got me thinking about the problem in terms of "hey, Infrastructure still operates in terms of waterfall, don't we."
Then when Peco and I moved over to NI R&D and started working on cloud-based systems, we quickly realized the need for our infrastructure to be completely programmable - that is, not manually tweaked and controlled, but run in a completely automated fashion. Also, since we were two systems guys embedded in a large development org that's using agile, we were heavily pressured to work in iterations along with them. This was initially a shock - my default project plan has, in traditional fashion, months worth of evaluating, installing, and configuring various technology components before anything's up and running. But as we began to execute in that way, I started to see that no, really, agile is possible for infrastructure work - at least "mostly." Technologies like cloud computing help, but there's still a little more up front work required than with programming - but you can get mostly towards an agile methodology (and mindset!).
Then at OpsCamp last month, we discovered that there's been this whole Agile Operations/Automated Infrastructure/devops movement thing already in progress we hadn't heard about. I don't keep in touch with The Blogosphere (tm) enough I guess. Anyway, turns out a bunch of other folks have suddenly come to the exact same conclusion and there's exciting work going on re: how to make operations agile, automate infrastructure, and meld development and ops work.
So if you also hadn't been up on this, here's a roundup of some good related core thoughts on these topics for your reading pleasure!
- Automated Infrastructure enables Agile Operations
- Virtualized/Abstracted Administration
- Agile Manifesto Co-Author On Agile Operations
- Agile Web Operations Blog
- DevOpsdays - one coming to the US in 2010, they say.
- Building an Automated Infrastructure
- Agile Manifesto - if you're not a developer and only have a vague impression of what "agile" is
- Extreme Automated Infrastructure
Enterprise Systems vs. Agility
I was recently reading a good Cameron Purdy post where he talks about his eight theses regarding why startups or students can pull stuff off that large enterprise IT shops can't.
My summary/trenchant restatement of his points:
- Changing existing systems is harder than making a custom-built new one (version 2 is harder)
- IT veterans overcomplicate new systems
- The complexity of a system increases exponentially the work needed to change it (versions 3 and 4 are way way harder)
- Students/startups do fail a lot, you just don't see those
- Risk management steps add friction
- Organizational overhead (paperwork/meetings) adds friction
- Only overconservative goons work in enterprise IT anyway
- The larger the org, the more conflict
Though I suspect #1 and #3 are the same, #2 and #5 are the same, and #6 and #8 are the same, really.
I've been thinking about this lately with my change from our enterprise IT Web site to a new greenfield cloud-hosted SaaS product in our R&D organization. It's definitely a huge breath of fresh air to be able to move fast. My observations:
Complexity
The problem of systems complexity (theses #1 and #3) is a very real one. I used to describe our Web site as having reached "system gridlock." There were hundreds of apps running dozens to a server with poorly documented dependencies on all kinds of stuff. You would go in and find something that looked "wrong" - an Apache config, script, load balancer rule, whatever - but if you touched it some house of cards somewhere would come tumbling down. Since every app developer was allowed to design their own app in its own tightly coupled way, we had to implement draconian change control and release processes in an attempt to stem the tide of people lining up to crash the Web site.
We have a new system design philosophy for our new gig which I refer to as "sharing is the devil." All components are separated and loosely coupled. Using cloud computing for hardware and open source for software makes it easy and affordable to have a box that does "only one thing." In traditional compute environments there's pressure to "use up all that CPU before you add more", which results in a penny wise, pound foolish strategy of consolidation. More and more apps and functions get crunched closer together and when you go back to pull them out you discover that all kinds of new connections and dependencies have formed unbidden.
Complication
Overcomplicating systems (#2 and #5) can be somewhat overcome by using agile principles. We've been delving heavily into doing not just our apps but also our infrastructure according to an agile methodology. It surfaces your requirements - frankly, systems people often get away with implementing whatever they want, without having a spec let alone one open to review. Also, it makes you prioritize. "Whatever you can get done in this two week iteration, that's what you'll have done, and it should be working." It forces focus on what is required to get things to work and delays more complex niceties till later as there's time.
Conservatism
Both small and large organizations can suffer from #6 and #8. That's mostly a mindset issue. I like to tell the story about how we were working on a high level joint IT/business vision for our Web site. We identified a number of "pillars" of the strategy we were developing - performance, availability, TCO, etc. I had identified agility as one, but one of the application directors just wasn't buying into it. "Agility, that's weird, how do we measure that, we should just forget about it." I finally had to take all the things we had to the business head of the Web and say "of these, which would you say is the single most important one?" "Agility, of course," he said, as I knew he would. I made it a point to train my staff that "getting it done" was the most important thing, more important than risk mitigation or crossing all the t's and dotting all the i's. That can be difficult if the larger organization doesn't reward risk and achievement over conservatism, but you can work on it.
OpsCamp Debrief
I went to OpsCamp this last weekend here in Austin, a get-togther for Web operations folks specifically focusing on the cloud, and it was a great time! Here's my after action report.
The event invite said it was in the Spider House, a cool local coffee bar/normal bar. I hadn't been there before, but other people that had said "That's insane! They'll never fit that many people! There's outside seating but it's freezing out!" That gave me some degree of trepidation, but I still racked out in time to get downtown by 8 AM on a Saturday (sigh!). Happily, it turned out that the event was really in the adjacent music/whatnot venue also owned by Spider House, the United States Art Authority, which they kindly allowed us to use for free! There were a lot of people there; we weren't overfilling the place but it was definitely at capacity, there were near 100 people there.
I had just hears of OpsCamp through word of mouth, and figured it was just going to be a gathering of local Austin Web ops types. Which would be entertaining enough, certainly. But as I looked around the room I started recognizing a lot of guys from Velocity and other major shows; CEOs and other high ranked guys from various Web ops related tool companies. Sponsors included John Willis and Adam Jacob (creator of Chef) from Opscode , Luke Kanies from Reductive Labs (creator of Puppet), Damon Edwards and Alex Honor from DTO Solutions (formerly ControlTier), Mark Hinkle and Matt Ray from Zenoss, Dave Nielsen (CloudCamp), Michael Coté (Redmonk), Bitnami, Spiceworks, and Rackspace Cloud. Other than that, there were a lot of random Austinites and some guys from big local outfits (Dell, IBM).
You can read all the tweets about the event if you swing that way.
OpsCamp kinda grew out of an earlier thing, BarCampESM, also in Austin two years ago. I never heard about that, wish I had.
How It Went
I had never been to an "unconference" before. Basically there's no set agenda, it's self-emergent. It worked pretty well. I'll describe the process a bit for other noobs.
First, there was a round of lightning talks. Brett from Rackspace noted that "size matters," Bill from Zenoss said "monitoring is important," and Luke from Reductive claimed that "in 2-4 years 'cloud' won't be a big deal, it'll just be how people are doing things - unless you're a jackass."
Then it was time for sessions. People got up and wrote a proposed session name on a piece of paper and then went in front of the group and pitched it, a hand-count of "how many people find this interesting" was taken.
Candidates included:
- service level to resolution
- physical access to your cloud assets
- autodiscovery of systems
- decompose monitoring into tool chain
- tool chain for automatic provisioning
- monitoring from the cloud
- monitoring in the cloud - widely dispersed components
- agent based monitoring evolution
- devops is the debil - change to the role of sysadmins
- And more
We decided that so many of these touched on two major topics that we should do group discussions on them before going to sessions. They were:
- monitoring in the cloud
- config mgmt in the cloud
This seemed like a good idea; these are indeed the two major areas of concern when trying to move to the cloud.
Sadly, the whole-group discussions, especially the monitoring one, were unfruitful. For a long ass time people threw out brilliant quips about "Why would you bother monitoring a server anyway" and other such high-theory wonkery. I got zero value out of these, which was sad because the topics were crucially interesting - just too unfocused; you had people coming at the problem 100 different ways in sound bytes. The only note I bothered to write down was that "monitoring porn" (too many metrics) makes it hard to do correlation. We had that problem here, and invested in a (horrors) non open-source tool, Opnet Panorama, that has an advanced analytics and correlation engine that can make some sense of tens of thousands of metrics for exactly that reason.
Sessions
There were three sessions. I didn't take many notes in the first one because, being a Web ops guy, I was having to work a release simultaneously with attending OpsCamp 
Come To OpsCamp!
Next weekend, Jan 30 2009, there's a Web Ops get-together here in Austin called OpsCamp! It'll be a Web ops "unconference" with a cloud focus. Right up our alley! We hope to see you there.
Book Review: Smart & Gets Things Done, by Joel Spolsky
Joel Spolsky is a bit of an internet cause célèbre, the founder of Fog Creek Software and writer of joelonsoftware.com, an influential programming Web site.
The book is about technical recruiting and retention, and even though it’s a small format under 200 page book, it covers a lot of different topics. His focus is on hiring programmers but I think a lot of the same principles apply to hiring for systems admin/Web systems positions. Hiring has been one of the hardest parts of being a Web systems manager, so I got a lot out of the book and tried putting it into practice. Results detailed below!
The Book
The first chapter talks about the relative effectiveness of programmers. We often hire programmers and pay the good ones 10% more than the bad ones. But he has actual data, drawn from a Yale professor who repeatedly teaches the same CS class and assigns the same projects, which shows something that those of us who have been in the field for a long time know – which is that the gap in achievement between the best programmers and the worst ones is a factor of ten. That’s right. In a highly controlled environment, the best programmers completed projects 3-4 times faster than the average and 10x faster than the slowest ones. (And this same relationship holds when adjusting for quality of results.) I’ve been in IT for 15 years and I can guarantee this is true. You can give the same programming task to a bunch of different programmers and get results from “Here, I did it last night” to “Oh, that’ll take three months.” He goes on to note other ways in which you can get 10 mediocre programmers that cannot achieve the same “high notes” as one good programmer. This goes to reinforce how important the programmer, as human capital, is to an organization.
Next, he delves into how you find good developers. Unfortunately, the easy answers don’t work. Posting on monster.com or craigslist gets lots of hits but few keeps. Employee referrals don’t always get the best people either. How do you? He has three suggestions.
- Go to the mountain
- Internships
- Build your own community
“Go to the mountain” means to figure out where the smart people are that you want to hire, and go hang out there. Conferences. Organizations. Web sites. General job sites are zoos, you need venues that are more specifically spot on. Want a security guy? Post on OWASP or ISSA forums, not monster.
We do pretty well with internships, even enhancing that with company sponsored student sourcing/class projects and a large campus recruiting program. He has some good sub-points however – like make your offers early. If you liked them as an intern, offer them a full-time job at that point for when they graduate, don't wait. Waiting puts you into more of a competitive situation. And interns should be paid, given great work to do, and courted for the perm job during the internship.
Building a community – he acknowledges that’s hard. Our company has external communities but not really for IT. For a lot of positions we should be on our our forums like fricking scavengers trying to hire people that post there.
Dang, People Still Love Them Some IE6
We get a decent bit of Web traffic here on our site. I was looking at the browser and platform breakdowns and was surprised to see IE6 still in the lead! I'm not sure if these stats are representative of "the Internet in general" but I am willing to bet they are representative of enterprise-type users, and we get enough traffic that most statistical noise should be filtered out. I thought I'd share this; most of the browser market share research out there is more concerned with the IE vs Firefox (vs whoever) competition aspect and less about useful information like versions. Heck we had to do custom work to get the Firefox version numbers; our Web analytics vendor doesn't even provide that. In the age of more Flash and Silverlight and other fancy schmancy browser tricks, disregarding what versions and capabilites your users run is probably a bad idea.
- IE6 - 23.46%
- IE7 - 21.37%
- Firefox 3.5 - 17.28%
- IE8 - 14.62%
- Firefox 3 - 12.52%
- Chrome - 4.38%
- Opera 9 - 2.20%
- Safari - 1.95%
- Firefox 2 - 1.27%
- Mozilla - 0.48%
It's pretty interesting to see how many people are still using that old of a browser, probably the one their system came loaded with originally. On the Firefox users, you see the opposite trend - most are using the newest and it tails off from there, probably what people "expect" to see. The IE users start with the oldest and tail towards the newest! You'd think that more people's IT departments would have mandated newer versions at least. I wish we could see what percentage of our users are hitting "from work" vs. "from home" to see if this data is showing a wide disparity between business and consumer browser tech mix.
Bonus stats - Top OSes!
- Windows XP - 76.5%
- Windows Vista - 14.3%
- Mac - 2.7%
- Windows NT - 1.8%
- Linux - 1.8%
- Win2k - 1.5%
- Windows Server 2003 - 1.2%
Short form - "everyone uses XP." Helps explain the IE6 popularity because that's what XP shipped with.
Edit - maybe everyone but me knew this, but there's a pretty cool "Market Share" site that lets people see in depth stats from a large body of data... Their browser and OS numbers validate ours pretty closely.
Oracle + BEA Update
A year ago I wrote about Oracle's plan on how to combine BEA Weblogic and OAS. A long time went by before any more information appeared - we met with our Oracle reps last week to figure out what the deal is. The answer wasn't much more clear than it was way back last year. They do certainly want some kind of money to "upgrade" but it seems poorly thought through.
OAS came in various versions - Java, Standard, Standard One, Enterprise, and then the SOA Suite versions. The new BEA, now "Fusion Middleware 11g" comes in different versions as well.
- WLS Standard
- WLS Enterprise - adds clustering, costs double
- WLS Suite - adds Coherence, Enterprise Manager, and JRockit realtime, costs quadruple
But they can't tell us what OAS product maps to what FMW version.
There is also an oddly stripped down "Basic" edition which noted as being a free upgrade from OAS SE but it strips out a lot of JMS and WS stuff; there's an entire slide of stuff that gets stripped out and it's hard to say if this would be feasible for us.
As for SOA Suite, "We totally just don't know."
Come on Oracle, you've had a year to get this put together. It's pretty simple, there's not all that many older and newer products. I suspect they're being vague so they can feel out how much $$ they can get out of people for the upgrade. Hate to break it to you guys - the answer is $0. We didn't pay for OAS upgrades before this, we just paid you the generous 22% a year maintenance that got you your 51% profit margin this year. If you're retiring OAS for BEA in all but name, we expect to get the equivalent functionality for our continued 22%.
Oracle has two (well, three) clear to dos.
1. Figure out what BEA product bundles give functionality equivalent to old OAS bundles
2. Give those to support-paying customers
3. Profit. You're making plenty without trying to upcharge customers. Don't try it.
Velocity 2009 – Best Tidbits
Besides all the sessions, which were pretty good, a lot of the good info you get from conferences is by networking with other folks there and talking to vendors. Here are some of my top-value takeaways.
Aptimize is a New Zealand-based company that has developed software to automatically do the most high value front end optimizations (image spriting, CSS/JS combination and minification, etc.). We predict it'll be big. On a site like ours, going back and doing all this across hundreds of apps will never happen - we can engineer new ones and important ones better, but something like this which can benefit apps by the handful is great.
I got some good info from the MySpace people. We've been talking about whether to run our back end as Linux/Apache/Java or Windows/IIS/.NET for some of our newer stuff. In the first workshop, I was impressed when the guy asked who all runs .NET and only one guy raised his hand. MySpace is one of the big .NET sites, but when I talked with them about what they felt the advantage was, they looked at each other and said "Well... It was the most expeditious choice at the time..." That's damning with faint praise, so I asked about what they saw the main disadvantage being, and they cited remote administration - even with the new PowerShell stuff it's just still not as easy as remote admin/CM of Linux. That's top of my list too, but often Microsoft apologists will say "You just don't understand because you don't run it..." But apparently running it doesn't necessarily sell you either.
Our friends from Opnet were there. It was probably a tough show for them, as many of these shops are of the "I never pay for software" camp. However, you end up wasting far more in skilled personnel time if you don't have the right tools for the job. We use the heck out of their Panorama tool - it pulls metrics from all tiers of your system, including deep in the JVM, and does dynamic baselining, correlation and deviation. If all your programmers are 3l33t maybe you don't need it, but if you're unsurprised when one of them says "Uhhh... What's a thread leak?" then it's money.
ControlTier is nice, they're a commercial open source CM tool for app deploys - it works at a higher level than chef/puppet, more like capistrano.
EngineYard was a really nice cloud provisioning solution (sits on top of Amazon or whatever). The reality of cloud computing as provided by the base IaaS vendors isn't really the "machines dynamically spinning up and down and automatically scaling your app" they say it is without something like this (or lots of custom work). Their solution is, sadly, Rails only right now. But it is slick, very close to the blue-sky vision of what cloud computing can enable.
And also, I joined the EFF! Cyber rights now!
You can see most of the official proceedings from the conference (for free!):