Guest Post by Ivan Lukianchuk
Ivan Lukianchuk is a seasoned startup founder and award winning pitch artist turned consultant who currently runs Strattenburg Inc. He’s a full stack .NET developer who has done a lot of work with Azure over the years building entire solutions from the ground up for clients ranging from independent professionals, to funded startups to $50MM organizations.You can follow Ivan on twitter: @Chronos or contact him via email at email@example.com
My name is Ivan Lukianchuk and I’m an entrepreneur, startup guy and consultant. While working with the Developer Experience team at Microsoft Canada as an evangelist with real world experience, I’ve been asked to share some of that with you here today. In years gone past I founded and led a gaming startup called Will Pwn 4 Food. We made fast action 3D games that you could play directly in the web browser for actual cash and prizes (and legally to boot!).
Our infrastructure involved many different AWS services spanning EC2, IAM, S3, RDS, Route 53, CloudFront, Elasticache, and SQS. It took a long time to set these up and to get them to talk to each other properly and securely, and we had 3 different environments: Test, Staging, and Live which needed frequent updating and synchronization. We had a team of around 7 people working together to build out the components and to make sure it all ran together fine. We chose AWS because at the time it was the largest and most well-known offering around, Azure only being in its infancy. We also had $10k in AWS credits courtesy of HYPERDRIVE.
When it came to our most basic setup for playing games, we needed to make sure we had a web server and database setup and running to host the site and to handle all of the game/user data. We ran EC2 with IIS for the web server and we switched back and forth between EC2 running SQL Server and RDS for our DB. If I remember correctly, we could never quite get RDS to work quite right and ended up with just running a separate EC2 instance for the DBs by the end of it, but not without a lack of trying to get it to work. As a .NET shop, RDS seemed to promise a much easier time managing and running our databases, but we just could never quite get it to work right or properly communicate with SQL Server Management Studio. This may have been improved in the many years since then, but it’s one of the reasons why Azure SQL as a service was intriguing (you’d think it should actually work easily and well if you are already a .NET shop, but more on that later). While, I’m not here to bash on AWS, it had its moments where frustration ran as king, and there was a lot of work when it came to managing entire EC2 systems when all we really wanted was ultimately what Azure provides with their web app solution. I could never figure out or quite understand elastic beanstalk or how we would migrate over.
When it came to running the backend of our scalable multiplayer system, we had a tools instance running which ran special console apps we designed which were always watching the database for updates. The MasterServer system would respond to a player creating a new lobby instance by spinning up a new AWS EC2 machine (if one wasn’t already up) and booting up the TaskMaster on it, initializing it with a new game server instance that would be the authoritative system through which all players would connect and play. As players joined the lobby, they would be added to the TaskMaster’s list of expected clients, and when the countdown begun it would prepare for incoming connections. We relied heavily on SQS to send messages internally back and forth between a set of tools to coordinate the game servers, and to manage the tasks performed after a game was completed like updating statistics and processing payouts to the winners. Each EC2 machine with a task master could have several game server instances running on it at once and it was the TaskMaster’s job to keep track of their state, player lists, and to shut them down as load dropped off.
Throughout this interconnected system we had security policies layered and special stored procedures built in to make sure that there were no breach points. Alongside these policies and strategies we had to make sure our machines were always patched and up to date as to not let any vulnerabilities unchecked. This added extra strain and work to an overly exhausted team who had more business focused goals to spend time on. So how did we get to BizSpark Plus and did we actually migrate the beastly system over completely? Yes we did. It wasn’t quick or easy for a project of this size, but when we were burning 2-3k a month on server costs alone, our AWS credits dried up fast and a year at 5k a month seemed like a really solid opportunity. We were burning cash quickly with so many people and we had a lot to prove in short order, so it wasn’t an easy decision on if pulling the trigger was worth the delays as there was a lot of technical risk involved.
As a .NET guy, I was always intrigued by Azure and I had the hopes that if you had already built on Microsoft’s technologies, then using their hosting should be even easier than in any other situation, although I had been burned by this thinking before and was cautious (you’d think a new Asus video card would work great or at least post in a new Asus mobo, but you’d be wrong there!).
After much deliberation and looking into our future billing costs, I made the call to do the switch. As the CEO, lead developer and architect, I ended up doing most of the work myself, so I can tell you firsthand how it went down. I’ll preface this by saying that Azure has gotten A LOT better since those old, early days (which I believe was 2 portal versions ago). There was definitely some frustration with the tools, and some confusion and learning hurdles to jump going from IaaS to PaaS, but ultimately once we got there, it worked great and was a bit easier to manage overall.
At the time, when setting up new instances for the VMs, if you made a mistake in policy, name, setting, or put something in the wrong cloud service, you couldn’t edit it and had to do the entire thing over, and sometimes it wasn’t clear that you missed a step or a security setting until after it was done and you had setup things on the VM as well. While I haven’t done VM work since (lovin’ the PaaS), I believe this has been improved. Some of the nice things which we still enjoy today on Azure is the initial screen after you create any service, which gives you quick access to RDP sessions, gives you links to add your IP to the firewall, gives you connection strings, or download stub projects, etc. This felt (and still feels) like pure magic compared to the AWS experience (which may have changed since I last used it).
Once I got the hang of publishing machines that I couldn’t RDP into, via the web apps, I’ve never looked back and have about 6 different clients on Azure all using web apps and Azure SQL. On that note, getting Azure SQL working was a bit of a pain to figure out, and for some reason you couldn’t do any actions on it with SQL Server Management Studio, but if you used the built in SQL management system in Visual Studio, you could suddenly do everything again. I think this is still the case, at least without the newest version of SSMS, and it was 500% frustrating to figure out as the web tool for administrating is cryptic and has horrible UX (and I believe it’s still the same today). These are some of the things you have to figure out on your own or with a lot of Googling, but once working, it was nice. The security settings seemed far easier to setup on Azure, but were much less powerful and customizable. Switching from SQS over to ServiceBus wasn’t too hard and we were able to reuse a lot of code as well as try a bunch of new features that didn’t exist with SQS. Going from S3 to Blob storage wasn’t too bad, just took a bit to figure out how to manage it, and what tools were easiest to use. Going from CloudFront to CDN wasn’t a big deal either, just a bunch of replacement lines in our web code and we were good to go. All in all it took about a month and a half to really move everything over and to get it working properly. There was a lot of learning, rewriting code, and the occasional bang-your-head-on-the-wall moments. The lack of any equivalent of Route 53 sucked as we still had to keep AWS on for something, but I hear that is coming soon (it’s still something I wish for all the time).
Currently as a consultant who builds entire web apps and system on .NET, I live by Azure and its ease of deployment straight from Visual Studio. Building and deploying MVC sites and DBs is incredibly quick and easy (when nothing goes wrong anyway!) and I’ve never had the urge to look back to AWS since. In terms of the portal and a lot of the little frustrations within, those have improved greatly since then as well. While I bare no ill-will towards AWS and it was a solid offering, I’m an Azure guy now and with BizSpark it’s really easy to deploy and test with any new startup I create. It’s cool to see how quick and easy it is to do the stuff you need to do with Azure, and you can really notice the effort put in to make each little step go that much faster with a simple and great UX online. There are still quirks and frustrations here and there, but I almost feel like things just work with a lot less futzing, maybe how Apple users feel, so big props to MS on their offerings so far.