Moving to the cloud

Databases

If you utilise any form of a database within the running of your business, these databases can be integrated into a cloud environment to boost speed and accessibility.

So, what is a database?

Good question. In most workplaces, a database can be defined as a stored collection of interrelated information, which can be easily accessed and managed by multiple parties.

A database can be used to store administrative information (for example, customer records or financial accounts) or to store specialised data such as engineering data.

A database facilitates quick retrieval of specific information from computer programs, in order to enable businesses and employees to perform their jobs more efficiently.

Your Human Resources department will likely have a database containing information about each employee: name, job title, seniority, responsibilities, annual leave entitlement, any disciplinary records, performance appraisals, and probably links to stored documents that relate to each employee.

Each machine in the HR department will also likely have a specific application installed, enabling them to access this data and edit it quickly and efficiently, as well as cross-reference other relevant information about your staff and organisation.

DATABASES IN THE CLOUD

There are many individual components within your IT system that might be identified as potential candidates for moving into the cloud. Databases and the applications that use those databases are likely to be foremost amongst those we examine for suitability.

But just because you can move something to the cloud, does that necessarily mean you should?

Whilst migrating all of your services to the cloud might be a money-spinner for us and entail extensive work for our design and migration teams, we flat-out refuse to recommend any course of action to our clients that won’t on balance be beneficial to them. 

That said, where it’s the right thing to do, we will certainly recommend a cloud solution.

Historically, databases tend to run on expensive on site SQL servers, that not only have a finite lifespan (and are costly to replace) but also present headaches when it comes to backup and maintenance.

Another common problem we encounter is overworked SQL servers, built to support a limited number of users and therefore struggling to cope with increased demand from a growing workforce.

The net result for many businesses can often be chronic slowness in operation and unjustified ongoing expense.

Sounds like a no-brainer? You may think so, but in reality there often comes a tipping point whereby the growing size of the database and the number of users connecting to it mean that it becomes an unviable option to move the database to the cloud. It’s a tricky equation and one that takes some careful consideration and no little experience to resolve.

TO MOVE TO THE CLOUD OR NOT TO MOVE TO THE CLOUD?

So why wouldn’t you move a database and a database dependent application to the cloud?

Well, here’s the thing about applications that use frequent database lookups: they tend to be hugely bandwidth intensive.

What we mean by this is that all of those database lookups, requests and write operations, coming from lots and lots of different end users, can stack up to equate to a pretty hefty amount of network traffic.

Where such traffic exceeds a certain threshold, it becomes unrealistic to expect your internet connection not to suffer in a scenario where this sizeable volume of network traffic needs to traverse your internet connection thousands of times per hour.

In such circumstances, it’s unfeasible to max out a company internet connection (or to scope a much higher cost internet connection just to cope with the heavy database traffic), when the database can be kept on your LAN (local area network), which has the increased capacity to cope with this demand.

Special Cases

Why pour vast amounts of water through a tiny straw to fill a reservoir (and likely cause a bottleneck), when your local river has sufficient capacity to suit your needs?

The truth is that many specialist pieces of software designed for specific industries (what we refer to as line-of-business software), simply haven’t been designed with cloud computing foremost in mind.

Where our clients rely on such specialist software, our job boils down to:

  1. Establishing the way such software packages currently work
  2. Ascertaining the software’s capacity for adaptability in the way it works (i.e., can the back end processes be modified to work in the cloud)
  3. Determining the knock-on effects to the network of moving the software to the cloud
  4. Determining the most suitable model to use, in terms of both performance and price, for our client

Alternatives

Where appropriate, we may look at the feasibility of implementing a hybrid cloud solution, whereby the database is kept local (to place less burden on the network), whilst the software itself is housed within the cloud. This solution is often referred to as ‘edge’ computing.

Another alternative option we might examine is the implementation of ‘thin clients’ for an organisation. Thin clients are very basic desktops with little grunt or processing power, whose sole job is to connect remotely to cloud environments where all of a business’ compute is processed. With thin clients, the end desktop functions more like a Chromebook than a fully spec’d computer, with the applications and database all living in a centralised cloud environment.

The price benefit of thin clients (which are typically inexpensive in terms of up-front hardware cost) needs to be weighed against the organisational needs of each specific business. Perhaps using thin clients is an impractical choice, for instance where there is a specific need for more processing power due to the nature of the client’s business.

A third option might be to migrate a business from its current, dated line-of-business software (with its intense database lookups and lack of scalability) to a more modern cloud-based alternative that not only costs less to run in the long run but also adds extra functionality beyond that of the incumbent application. One example of this might be moving from legacy financial packages to Xero, which comes with its own built in cloud capabilities.

There are many and varied considerations to take into account when it comes to planning the best possible architecture for a client’s business needs and no two customers are ever entirely alike.

Luckily, our cloud and edge consultants thrive on the challenge of providing the very best custom recommendations to suit each client’s specific circumstances.