At vshosting~, we make it our mission to not only provide our clients with top-notch hosting services but also to advise them well. In the 14 years that we’ve been on the market, we’ve seen quite a lot already. Therefore, we have a pretty good idea about what works and what spells trouble. One of the key (and very costly) issues we see time and again is a shared infrastructure for both development and production. This tends to be the case even with large online projects that risk losing enormous amounts of money should something go awry.

Considering how big a risk shared dev and production environment poses, something going awry is a matter of time. Why is this so dangerous? And how to set up your infrastructure so that you eliminate the risks? We put together the most important points. 

Development vs. production environment 

Development (and testing) environment should just and only serve new software and feature development or its testing. This encompasses not only the changes in your main application but also e.g. updates of your software equipment on the server. In the dev environment, developers should be able to experiment without worrying about endangering production.

The production environment, on the other hand, is where the app runs for everyone to see. For instance, an online store, where customers browse and search for items, add them to carts and pay for orders. Production is simply all that is visible for your average user plus all the things in the background that are key for app operation (e.g. databases, warehousing systems, etc.).

But most importantly: the production environment is where the money is made. Therefore, we should keep our distance from it and play it soothing classical music. As any problem in production rapidly translates into lost revenue.

Risks posed by A shared infrastructure

If you don’t separate development from production, it can easily happen that your developers will release insufficiently tested software, which will in turn damage or break the entire application. In other words: your production will go down. Should you be sufficiently unlucky, it will take your developers several hours or even days to fix the app. If your app is a large online store, this translates into tens of thousands of euros in lost revenue. Not to mention the extra development expenditures.

Such a situation becomes especially painful if it occurs during a time of high traffic on your website. In the case of online stores, this is typically the case before Christmas – take a look at how much would just an hour-long outage cost you. It’s not just Christmas, though – take any period of time you spend investing in e.g. a TV commercial. This is a very expensive endeavor and cannot be simply turned off because your online store is down.

Unfortunately, we’ve witnessed way too many nightmarish situations like this. This is why we recommend all our clients develop software in a separate environment and only after testing it in a testing environment release it into production. The same can be said for expanding the software equipment of their production servers. Only by thoroughly testing outside of production can you avoid discovering a critical bug in production on a Friday night just before Christmas.

Inside a separated development environment, you can deploy new app versions (e.g. an update online store) risk-free. There you can also test everything well before deployment to production. It will also allow you to update server components to their new versions (DB, PH, etc.) and test their compatibility and function. Only when you are certain everything works the way it should, can you move it to production. All in all, you’ll save yourself lots of trouble and cut costs to boot.

How to separate development from production

When choosing a hosting solution, take the issue of separating development and production into consideration. Ideally, you should run development and testing on a separate server and production should “live” on another one (or on a cluster of servers). At vshosting~, we’re happy to offer you a free consultation regarding the best solution for your project – just drop us a line.

We’ll help you design appropriate configuration for your development and testing environment so that it fully reflects that of production but at the same time doesn’t cost you a fortune in unused performance you don’t need. As the development environment receives little traffic, it doesn’t have to be as robust. For example, if your production consists of a cluster of three powerful servers, one smaller virtual one will likely be just enough for your development purposes. We recommend using the cloud for development because it’s typically the most cost-efficient option.

If you opt for one of our managed hosting services, we’re even happy to create the development environment for you. Simply put, we’ll “clone” your production and adjust it in such a way, that the environment remains identical but its performance is not unnecessarily high. That way, you’ll get all the benefits of separating development from production and save time and money while at it. Then, you’ll be able to make all your changes in development and, only after successful testing, transfer them to production.

“That hosting partner of ours isn’t worth much – our website even goes down a few times a year – but most of the time, everything works somehow. Most importantly, we don’t want to migrate anywhere!”

The biggest obstacle to switching from the current hosting provider to a better one is almost always migration. The dreaded data transfer from one hosting solution to another is without exception accompanied by an outage and quite a few risks. Moreover, it is often the case that when contemplating migration, the necessity to make changes to the client’s application is discovered, without which the migration cannot move forward (i.e. the application wouldn’t work properly after migrating it to the new solution).  All in all, web migration is no picnic. 

But what about the risks that go along with not migrating? Many don’t even consider them since “everything works” but these invisible dangers are often much larger and their potential consequences much more severe.

Let’s take a look at the main anti-migration arguments, how we address those at vshosting~, and what dangers go along with preserving the status quo at all costs. 

Application or technology changes 

The number one factor deterring from web migration is most often the necessity to make application or technology changes. This is a usual requirement for migration given the current application runs on outdated technology or is incompatible with the new hosting solution. 

The necessity of such change unequivocally presents extra workload for the client’s development team that needs to update the app or learn to work with a different technology.  This might be further complicated by the fact that some clients don’t have a development team at their disposal which happens to be quite common among smaller projects. 

On the other hand, the outdatedness or inadequacy of the technologies used is in no way merely an obstacle to migrating to another hosting provider. It is also, and perhaps more importantly, a hindrance to further growth of the internet project, a risk for its security and more.  Therefore, it is advisable to implement the recommended applicational and technological changes regardless of migration. After they have been put in place, switching over to virtually any provider will have become a piece of cake.  

Outdated technologies

An application using a no longer supported or utterly obscure technology often proves to be an obstacle to migration. For example,  an app written in PHP 5.2 is essentially un-migratable because it lacks compatibility with virtually any of the current technologies. It is, therefore, necessary to update it to a more recent, fully supported version. 

Application changes are no picnic, that’s for sure, and they cost a lot of developer time. On the other hand, running an application using outdated technology is exceptionally dangerous – migration or no migration. For instance, PHP 5.2 is no longer supported and eligible for neither security updates or bug fixes. Aside from incompatibility with modern hosting solutions, such application is then vulnerable to various security attacks and hacks. Considering the current GDPR legislation, this presents a risk of fines that can be catastrophic for the business (fine value of up to 4 % of revenue). Besides, outdated applications don’t tend to be prepared to deal with a significant rise in traffic so if you wish to further grow your business, updating your app is unavoidable either way. 

Simply put: if an application cannot be migrated, it pays off to thoroughly consider why that is and to fix the problem. Since with extremely high probability, something is terribly wrong. Regardless of migration and hosting, serious risks endanger your business. 

Compatibility with the hosting solution

Another common scenario is the necessity to shift towards a new technology that will be compatible with the newly selected hosting solution. This typically happens in the event of a client deciding to migrate from simple, non-redundant infrastructure to a cluster or if he aims to move towards a scalable solution but his application is not prepared for scaling.

An example would be migration from a single database server to a database cluster, where we recommend to our client to switch to Galera from a single node to ensure ideal functionality. Galera is the perfect solution for a cluster and will prove to be an advantage for the client in the long run. However, his developers will have to learn to work with a new technology, which is rarely a welcome situation. 

Service windows and other inconveniences

A further source of worry when it comes to migration is the necessity of a certain service window, where the client’s app simply doesn’t run. This step cannot be circumvented and in the case of large projects can even encompass an entire night. Even the toughest e-shoppers feel distressed by the idea.

At vshosting~, we do everything in our power to make the outage as short as possible. Unfortunately, the entire process has its technological limitations that are set in stone. For this reason, it is key to schedule the service window so that the impact on the client’s business is as small as possible. Furthermore, we thoroughly test the new hosting solution before the migration itself to prevent the emergence of complications that would prolong the out-of-operation period. 

What if something goes wrong?

Migration is a complicated process and there is a lot of room for making mistakes. In consequence, it is important to only switch over to providers who have extensive migration experience. Those can minimise the potential risks via thorough analysis and diligent testing of the new hosting infrastructure. And should something go sideways nonetheless, they’re capable of rapidly solving the situation. 

A good example can again be the migration from a single node database to e.g. a 3-node one. Should the balancing among the nodes not work perfectly after migration, experienced administrators are able to temporarily direct the database solution to a single node. As a result, the application can function without any issues and the administrators have time to get to the bottom of the balancing issue in the background. When all is resolved, they switch the database over to the 3-node solution.

In emergency cases, there is always the option of doing a rollback, that is returning everything to its original, pre-migration state. Based on our experience, however, it is more effective to try and solve the given problem as quickly as possible (e.g. by an emergy change of server settings as in the database example above) and finish migrating. The problem, which tends to be of the application sort, can be addressed after that. Unsurprisingly, even here we recommend choosing an experienced hosting provider who is capable of dealing with such unexpected situations in an agile manner. 

At vshosting~, you don’t need to fear migration 

Migration to vshosting~ is no reason for concerns – we have an experienced team of professionals directly in our datacentre who migrate internet projects on a daily basis. When it comes to very large migrations, we conduct dozens of those each year. Thanks to our extensive know-how, we are able to prevent the vast majority of potential risks and make sure everything runs smoothly. 

Before the migration itself, we thoroughly analyse and test the application – we are, among other things, able to evaluate the performance of the entire solution using specialised tests. Based on the initial analysis, we provide recommendations regarding application changes to the client and point out what to pay attention to, what to change, and what to steer clear of. 

Moreover, we design hosting solutions individually and customise them to the needs of each application. The new solution is then thoroughly tested including its compatibility with the client’s app and its synchronisation with all implemented systems (e.g. the warehousing system, CMS, redaction system, etc.). Thanks to that, the new solution gets tweaked to perfection before we even start with the migration.

In specific cases, for instance, when the client has no IT team of his own, we are even capable of conducting the entire migration process for him (although only in cases where no application changes are necessary). The client then needs to put in only minimal effort: to test the functionality of the new solution, to agree to migration start and so on.

To minimise the impact of migration on the client’s business, we carefully plan its date and time together with him. Because our experienced administrators and technicians are present in the datacenter nonstop, we have no problem whatsoever with conducting the migration in the middle of the night, any day of the week.

Should complications arise, preventative measures notwithstanding, we very quickly identify their causes and solve the problem because our experts monitor dozens of the web’s parameters, 24/7.