Yonder, the organization, is powered by a couple of laptops and some nice, big monitors. Despite the complexity of our application, these simple pieces of hardware are all we have. That's not to say that there isn't some heavy duty machinery operating behind the scenes. Servers, databases, queues, cloud storage, multiple applications, backups, redundant servers, high-bandwidth connections, so on and so forth. It's just not our heavy duty machinery. We have embraced virtual services to their fullest extent, and it has allowed us to scale up a full-blown, consumer-ready platform with minimal investment and overhead. However, it hasn't been all peaches and roses or whatever the metaphor is.
To provide some backstory, Yonder decided in the early days that we were going to utilize virtual services for our business wherever possible. Yes, there were days that were earlier than this. To be honest, it wasn't even much of a discussion. When you are a fledgling startup, most questions are answered by "What's the least amount of money that we can spend right this very moment?" Is that optimal? Not always. But you play the hand you're dealt. And I feel like it has served us well thus far.
Part of answering that question was deciding what things we needed to buy vs. what things that we could employ someone else to host. And as we looked at that list, it became overwhelmingly clear that there was practically nothing that we needed to own and/or host ourselves. Email, chat, project management, source control, servers. All of the things necessary to operate a business. All of it could be virtual. We could rely on "The Cloud".
A question that I get asked far too often is, "What is 'The Cloud' exactly?" And my answer always starts with 'marketing'. 'The Cloud' is a product of marketing. Then I follow that up with 'the Internet'. This is the point where I get the look as though I'm just being a wise-ass. There is an element of truth to that as well.
To be more specific, it began with a symbol that was used to illustrate the Internet in network diagrams. Each computer on the internal network would be represented by a box, while the Internet would be represented by a cloud to illustrate that it was a nebulous collection of interconnected computers. Then someone got the bright idea to brand themselves as harnessing the power of "The Cloud".
With that in mind. I simply tell people that when they hear "The Cloud" they should interpret that as "someone else's computer that is connected to the Internet". Less catchy, no doubt, but technically more correct. So when Dropbox tells you that you are storing your files in "The Cloud", you are storing it on Dropbox's computer that is connected to the Internet. It steals some of the magic, I know. But as my Dad used to tell my Mom when she asked questions about how much partying was going on when I was in college, don't ask questions that you don't want the answer to. Also, I'm loads of fun to take to a magic show.
Now that we have that out of the way, let’s talk about specifics. What services do we use? Here is the current list, which will probably change before I hit publish on this blog post:
- Email: Office365
- Chat: Slack
- Source Control: Visual Studio Online
- Project Management: Visual Studio Online
- Application Hosting: Microsoft Azure
Needless to say, launching a tech startup nowadays has many more options available than it did just 5 years ago. And when you are in these early stages of launching a business, the positive sides of this approach are numerous.
The Good Stuff
Cost is king when bootstrapping your startup, and at this stage, going virtual makes the most sense. Here are a few things we did not have to buy as a result of our decision to go virtual.
- A server and/or group of servers to host our application.
- A database server to host our database.
- A backup server to host our backups of the servers mentioned above.
- A server to host our source control.
- A backup server for our source control.
- A Microsoft Exchange license for email/calendaring/whatever-the-hell-else it is you do with Exchange and Outlook. ('’m not really an Outlook power user).
- An internet connection that has the necessary bandwidth to support our app.
- A backup internet connection in case the primary one goes out, which never happens because this is the modern world. On second thought, maybe that should be two backup internet connections.
Probably the most interesting thing when it comes to being virtual is related to scaling. If I buy a server or co-locate a server (rent a server from someone else), I have to buy the server that supports my peak load. If my server needs to support 100k members for 2 hours a day, and averages only 2k for the rest of the day, I have to buy the server to support the 100k, and my servers spend the majority of their day just chilling. It’s like having a second CEO! Zing! (I kid. I would never disparage Leslie this way because she writes my paycheck is the hardest working individual in our organization).
However, with the decision to virtualize, whether you choose Amazon, Microsoft, Rackspace or any number of other providers, you have an array of tools at your fingertips that let you add and remove computing resources as you need them. So I only pay for the resources to support that 100k of members for that window, and then I can scale it back.
Not only that, but as we grow, we can add more resources with a simple flick of a switch to increase the amount of horsepower we need driving the app. So if CNN happened to publish an article on how we are the next big thing (CNN employees who happen to be reading this can take this as a hint), and we received an influx of unexpected traffic, there is no need to sweat it, we can just scale up our services on the fly.
As we have constructed Yonder over the last couple of years, one of the things that we have greatly benefited from is the ability to try different approaches for different things and see what fits best. Going virtual has given us the freedom to do just that.
Maybe we need to try building a piece of functionality utilizing the database. Maybe it should use a series of queues instead. What about storing it in a document database? By having these types of virtual resources that we can add on the fly, it has given us the freedom to try something out quickly, see what works and what doesn't and move on. Because of the fact that we have all of these various services available at any time, it has also allowed us to create a heterogeneous mix of technologies with each one custom fit to the problem it is trying to solve.
The Internet is a hostile place. If you don’t believe me, hop on over to Twitter, tweet something innocuous like "Gosh, rainbows sure are nice." And then brace yourself for the pure vitriol that gets directed your way. If you are building an app that is going to be open to the public Internet, security has to be an early consideration, because people love to hate on things connected to the Internet.
By going virtual, we offload at least part of that. For example, since we are using Azure, they take care of keeping the machines patched and secure on their end. I don't have to worry about whether we've got the latest updates. We can just focus on building (and securing) our app. And while I still have to worry about my own security, I don't have to worry about the security of the server itself.
Here's a little insider knowledge. As someone whose background is in the engineering/programming side of things, our ability to manage the network is about as good as our ability to build good looking ad campaigns. And just like you don’t want us developers designing your logo, you will need someone to take care of those servers that you dropped that cash on. So this is another mark in the column for virtualization, as it eliminates the need for this dedicated person.
The Bad Stuff
So by now you must be thinking, "It's amazing! It's utopia! Why doesn't everyone just drop their infrastructure and go virtual?!?" Because as Aristotle once said, "Everything that is awesome, has some sides of it that suck." I may have paraphrased that. My point still stands though. Even bacon causes heart disease.
What was good in the beginning may not be good forever. When you need just a few resources, no doubt about it, being virtual lets you pinch some pennies. As you get larger however, you will need to begin to analyze exactly how much scaling out is costing you. Like most everything, there is a point of diminishing returns and sometimes you will encounter items that are just more cost-effective for you to handle yourself.
Even in the beginning, you will need to always have an awareness of how much a service is going to cost before you sign up. Do you need three separate databases, or do you have to go back to the drawing board? Do I need to pay for the document db service to hold one set of objects, or do I need to change my storage approach?
Also, if someone can explain exactly what the hell a DTU is, that would be great.
If you are going to live in a cloud provider's world, you are going to have to play by their rules. And this can get frustrating. Unless you are dealing purely in virtual machines, there are times when you think "but I just want to log some stuff and see the files." Other times it may be, "why can’t I FTP in and just change the image?" In exchange for them handling all of this great functionality for you, you have to agree to interact with the service on their terms, and oftentimes that can be limiting.
If your CEO walks in and says "Is the site up and running", and you've got a server on premises, you just turn around and look for the blinky lights and reply "Yep." (Because all CTO's are supposed to work in a server closet, right?) If it's virtual, you are going to be checking numerous places to see what the health of your application is. There's probably a "Dashboard" involved somewhere, and the whole act of figuring out where the problem lies becomes much more complicated, because there is a third party in the mix now.
The Learning Curve
While the web itself is based on standardized technologies, each cloud provider has their own way of doing things. And most of them are these mammoth collections of services and products. Trying to learn how to use the services, what the technologies involved are and how they fit within your application is a daunting task. Then trying to get your app to use these services once you've enabled them is another challenge in and of itself.
Let's not forget that the cloud providers are improving and "enhancing" their services all of the time as well. Many of these changes are breaking changes, so now you've got to sift through the release notes with a fine-toothed comb to make sure that upgrading from 2.3 to 2.4 of the SDK doesn't render your precious app useless.
But don't worry. You've got all that free time that they freed up since you don't have to manage the security and infrastructure. You can now use that time to read the documentation on how file storage works. Yay!
Like everything in life, pros and cons abound when going virtual. For Yonder, the pros grossly outweigh the cons. Is it a panacea? No. Are there days that I hate dealing with it? Yep. Is it right for everyone? Not yet. But every day it's getting to the point where I feel it makes less and less sense for businesses to focus on providing all of these separate silo's of infrastructure.
I really want to be focusing on building new features into Yonder and expanding the capabilities of our service. Things that hopefully someday soon folks will like enough to give us money to use. I certainly don't want to spend that time troubleshooting why my emails are getting stuck at the mail server. Cloud providers are helping us get there. It has enabled Yonder to hit the ground running with very little up-front expenditures, and gives us a clear path with how to grow our service. I'm definitely a fan of virtual services.