Contents tagged with General Software Development

  • I moved my Web sites to Azure. You won't believe what happened next!

    TL;DR: I eventually saved money.

    I wrote about the migration of my sites, which is mostly CoasterBuzz and PointBuzz, from a dedicated server to the various Azure services. I also wrote about the daily operation of the sites after the move. I reluctantly wrote about the pain I was experiencing, too. What I haven't really talked about is the cost. Certainly moving to managed services and getting out of the business of feeding and caring for hardware is a plus, but the economics didn't work out for the longest time. That frustrated me, because when I worked at Microsoft in 2010 and 2011, I loved the platform despite its quirks.

    The history of hosting started with a site on a shared service that I paid nearly $50/month for back in 1998. It went up to a dedicated server at more than $650, and then they threatened to boot me for bandwidth, so I started paying a grand a month for a T-1 to my house, plus the cost of hardware. Eventually the dedicated servers came down again, and for years were right around $200. The one I had the last three years was $167. That was the target.

    Let me first say that there is some benefit to paying a little more. While you won't get the same amount of hardware (or the equivalent virtual resources) and bandwidth, you are getting a ton of redundancy for "free," and I think that's a hugely overlooked part of the value proposition. For example, your databases in SQL Azure exist physically in three places, and the cost of maintaining and setting that up yourself is enormous. Still, I wanted to spend less instead of more, because market forces being what they are, it can only get cheaper.

    Here's my service mix:

    • Azure Web Sites, 1 small standard instance
    • Several SQL Azure databases, two of which are well over 2 gigs in size (both on the new Standard S1 service tier)
    • Miscellaneous blob storage accounts and queues
    • A free SendGrid account

    My spend went like this:

    • Month 1: $204
    • Month 2: $176
    • Month 3: $143

    So after two and a half months of messing around and making mistakes, I'm finally to a place where I'm beating the dedicated server spend. Combined with the stability after all of the issues I wrote about previously, this makes me happy. I don't expect the spend to increase going forward, but you might be curious to know how it went down.

    During the first month and a half, only the old web/business tiers were available for SQL Azure. The pricing on these didn't make a lot of sense, because they were based on database size instead of performance. Think about that for a minute... a tiny database that had massive use cost less than a big one that was used very little. The CoasterBuzz database, around 9 gigs, was going to cost around $40. Under the new pricing, it was only $20. That was preview pricing, but as it turns out, the final pricing will be $30 for the same performance, or $15 for a little less performance.

    There ended up being another complication when I moved to the new pricing tiers. They were priced that any instance of a database, spun up for even a minute, incurred a full day's charge. I don't know if it was a technical limitation or what, but it was a terrible idea. You see, when you do an automated export of the database, which I was doing periodically (this was before the self-service restore came along), you incurred the cost of an entire day's charge for that database. Fortunately, starting next week, they're going to hourly pricing starting next month.

    I also believe there were some price reductions on the Web sites instances, but I'm not sure. There was a reduction in storage costs, but they're not a big component of the cost anyway. Honestly, I always thought bandwidth was my biggest concern, but that's because much of what I used on dedicated hardware was exporting backups. On Azure, I'm using less than 300 gigs out.

    So now that things have evened out and I've understood how to deal with all of the unknowns from previous months, coupled with a lot of enhancements the Azure team has been working in, I'm in a good place. It feels like it should not have been so difficult, but Azure has been having an enormous growth and maturity spurt in the last six months or so. It's really been an impressive thing to see.

    Read more...

  • You have a people problem, not a technology problem

    [This is a repost from my personal blog.]

    Stop me if you've heard this one before. Things are going poorly in your world of software development, and someone makes a suggestion.

    "If we just use [framework or technology here], everything will be awesome and we'll cure cancer!"

    I like new and shiny things, and I like to experiment with stuff. I really do. But every time I hear something like the above statement, it's like nails on a chalkboard. You know, most of the NoSQL arguments over the last few years sound like that. It's not that the technology isn't useful or doesn't have a place, but when I'm looking at it from a business standpoint, I have a perfectly good database system, that happens to be relational, that could do the same thing, is installed on my servers, will scale just fine for the use case, and I employ people who already know how to use it. Maybe I have something in production that uses it wrong, but that isn't a technology problem.

    I'm sure we're all guilty of this at various points in our career. We've all walked into situations where there is an existing code base, and we're eager to rewrite it all using the new hotness. It's true, there are often great new alternatives that you could use, but I find it very rare that the technologies in play are inadequate, they're just poorly used. That kind of thing happens because of inexperience, poor process, transient consultants or some combination of all of those things.

    The poor implementation is only a part of the people problem. There is a big layer of failure often caused by process, which is, you know, implemented by people. For example (this is real life, from a previous job), you've come up with this idea of processing events in almost-real-time by queuing them and then handing them off to various arbitrary pieces of code to process, a service bus of sorts. So you look at your toolbox and say, "Well, our servers all run Windows, so MSMQ will be adequate for the queue job." Shortly thereafter, your infrastructure people are like, "No, we can't install that, sorry." And then your release people are like, "Oh, this is a big change, we can't do this." You bang your head against the wall, because all of this kingdom building, throw-it-over-the-wall, lack of collaboration is 100% people problems, not technology. Suggesting some other technology doesn't solve the problem, because it will manifest itself again in some other way.

    What do you do about this? Change itself isn't that hard (if you really believe in the Agile Manifesto), but people changing is hard. If you have the authority, you remove the people who can't change. If you don't, then you have to endure a slower process of politicking to get your way. It's slow, but it works. You convince people, one at a time, to see things in a way that removes friction. Get enough people on board, and momentum carries you along so that everyone has to follow (or get off the boat). I knew a manager at Microsoft who was exceptionally good at this, and his career since has largely been to convince teams that there was a better way.

    At a more in-the-weeds level, you get people engaged beyond code. One of the weakest skills people in the software development profession have is connection with the underlying business. Mentor them so that they understand. Explain why the tool you use is adequate when used in the right context and will save the business time and money, compared to a different technology that has more cost associated with learning new skills, licenses or whatever. It's like the urge to buy a new phone every year to have the new hotness... It's fine when it's your money, but not so much when it comes at the cost of your employer.

    As technologists, yes, we want to solve problems with technology. Just don't let that desire obscure the fact that the biggest problems in our line of work are rarely technological in nature.

    Read more...

  • Suppressing FormsAuth redirect when using OWIN external logins

    This is probably the most specific post I’ve written in a long time, but given how long I let it fester, and how much debugging it took to figure out, I figure it’s worth saving someone the time. Last fall you might recall that I did a little bit of reverse engineering, and some cutting and pasting of source code, to use the OWIN-based external authentication stuff, decoupling it from ASP.NET Identity. This was a pretty exciting win for me because I was completely not interested in using yet another auth system in POP Forums, when the one I had was already pretty simple and embedded in some of my own projects.

    Read more...

  • The indie publisher moving to Azure, part 2: operation

    About a month ago, I wrote all about my experience migrating my sites off of dedicated hardware and into Azure. I figured I would wait awhile before writing about the daily operation of those sites, so I could gather enough experience to make a meaningful assessment. As I said in the previous post, this is a move that I was looking forward to make for a good three years or so, when I actually worked with Azure from within Microsoft. The pricing finally came down to a point where it made sense for an indie publisher, and here we are.

    Read more...

  • First impression: Xamarin 3

    Almost a year ago, I started to be a lot more interested in Xamarin, since I already was something of a Mac guy writing software for the Microsoft platform. I've been working in Windows VM's via Parallels for years. At work, the firm we were working with to build out our mobile apps was using Xamarin too. For me, it wasn't just about being able to use C# to write apps for iOS and Android, it was the idea that you could share a lot of code. That's pretty exciting.

    Read more...

  • The ugly evolution of running a background operation in the context of an ASP.NET app

    If you’re one of the two people who has followed my blog for many years, you know that I’ve been going at POP Forums now for over almost 15 years. Publishing it as an open source app has been a big help because it helps me understand how people want to use it, and having it translated to six languages is pretty sweet. Despite this warm and fuzzy group hug, there has been an ugly hack hiding in there for years.

    Read more...

  • The indie publisher moving to Azure, part 1: migration

    I've been a big fan of cloud-based infrastructure for a long time. I was fortunate enough to be on a small team of developers who built the reputation system for MSDN back in 2010, on Microsoft's Azure platform. Back then, there was a serious learning curve because Azure was barely a product. At the end of the day, we built something that easily could handle millions of transactions per month without sweating, and that was a sweet opportunity. Most people never get to build stuff to that scale.

    Read more...