It's easy to get caught up in the planning and building of your software. Naturally, that's where all the concentrated effort should be at the beginning of the process. But it's important to consider the process of turning what is built into a product that your market can engage with. This article is focused on the release process of the software lifecycle and specifically how WorkingMouse ensures that the software built is deployed and hosted effectively.
Cloud hosting is how we make your software available over the internet. Broadly speaking, there are two key types of hosting - private or public cloud hosting.
Public hosting companies like AWS and Azure provide servers where anyone can host their application (for a fee of course). While there is less control and customisations, the use of automation tools like Kubernetes and RDS (both referenced below) can help speed up the process of setting up a public cloud environment and reduce costs. WorkingMouse covers the cost of creating a standard environment on AWS and Azure.
The cost of releasing the software is comprised of setting up the cloud environment and the application release process. Let's ignore the application release process for now.
The question we're asking is how much does it cost to setup a secure, load balanced, distributed cloud environment. This is a loaded question and will depend entirely on the requirements of the environment. But for the purposes of providing an answer and not skirting around the question, we'll use our community server setup as an example.
The scope of the setup includes:
- 3x web servers - they handle HTTP(S) requests from the clients and serve up the web page/app.
- 3x file servers - a clustered file system containing both the source code of the application, as well as any application-specific files (eg uploaded profile photos).
- 3x caching servers - stores and returns frequently used bits of "information" so that the web servers don't need to constantly "re-evaluate" computationally complex tasks. (ie it can do it once, then save that in the cache).
- 3x database servers.
A very reasonable question would be why do we have three of each? For each group, you always have an odd number of servers. This is so that if one server goes down, all the remaining servers can form a majority "vote" on whether or not they think the downed server is actually down, and react accordingly. For redundancy, we need more than one. That means if one server fails, your application doesn’t fail.
Let's firstly assume we are doing this the traditional, manual way. If you have a developer that knows exactly what they're doing and knows every single command and configuration off the top of their head, it might take a couple weeks. At $1200 per day for a DevOps engineer, you're looking at around $12K. If you have a developer that has a pretty good idea of what they're doing, but needs to google some reference documentation around commands or certain configuration, it may take about 4-6 weeks ($24K-$36K). If the developer doesn't have any experience that timeframe may extend out to 2 months ($48K). Now remember, this is on top of the cost of developing the actual software.
For something this complex you also need a few maintenance scripts to keep everything in sync. On top of that, if a server goes down you'll need to spend time re-creating that server. We won't dive into this now but you can start seeing the magnitude of the work required.
As an experienced software development company, we have found more efficient ways of releasing software. Previously it was through the use of Remote Desktop Services (RDS) and currently it is through Kubernetes
. By using these technologies we have been able to automate what may have previously been a 4-6 week process into 1 day.
We also create scripts that allow us to easily re-create any servers that go down.
The process commences before development starts. In the majority of cases (where hosting does not require special consideration) the client will create their AWS or Azure account before development starts. That is shared with WorkingMouse and Rogue Two who create a beta and production environment during Iteration 0 (the first week of development). From that point on all beta and production releases are made to the clients environment.
For public cloud deployments to AWS or Azure, WorkingMouse covers the cost for our sister company Rogue Two to setup the server environment. This is significant benefit when the alternative could be spending 2 months setting up your production environment. For private cloud requirements or customised public cloud deployments, Rogue Two can be contracted on a time and materials basis.