Web service infrastructure does matter

Why does the infrastructure of web services matter?

Marko Korhonen
Marko Korhonen

A fair amount of the workload allocated to software development is consumed by working on various development and server computers and setting up their applications and settings. This is what is generally called the "environment".

Normally at least three different environments are set up: development, testing, and production environments. Additionally, every developer taking part in the project sets up their own environment on their computer. These typically have a lot in common and are updated frequently throughout the project and during the further development phase. Because the optimization of repetitive work saves money for the client, we've developed our own platform for it.

Up to 97% savings on time consumption

Standardized environments are cost effective. They save plenty of our working time, which means they save plenty of our client's money. Using standardized environments and quick setups also permits flexibility in our resourcing; schedules are not jeopardized by one member of the team being bedridden, because another developer can promptly install the environments on their computer and begin work on the development within the hour.

Without a standardized infrastructure that works as a basis for easily constructing environments for different needs, it is not uncommon to have to spend a couple of days working on creating the environment. The time saved on setting up the environment is reflected on two places in the client's invoice:

  • At the start of the project, the architect clones a copy of Druid's infrastructure template for use in the project. This template contains all the most commonly used components and settings. The copy is edited to match the needs of the project: sometimes the project may call for a Solr server for setting up diverse search features, sometimes something completely different.
  • Time is also saved when putting up new environments. In the beginning each developer installs the environments on their computers, then a shared test environment is created, and at some point it will become necessary to set up a production environment. All of these environments can be built over and over again with a few key strokes, and, most importantly, completely error-free due to standardized environments.

Convergent environments

Using standardized environments lessens the amount of danger and errors. When looking for a potential web service provider, it behooves the client to ask which tech stack the services would be built on, and would the wheel be reinvented for each new project. In best cases the server configurations and application server versions are saved as a part of the application's code template: Infrastructure as Code (IaC) allows for the comprehensive documentation and versioning of the environment's code, which makes squashing bugs faster. In addition, the IaC model enables the automatic testing of the infrastructure.

Unlike in most of the solutions we know about, our infrastructure template is "multi-environment, multi-site". This means that our client can have multiple sites in the same infrastructure, and each site may have multiple environments. Sharing the use of the infrastructure between different sites saves money.

Flexible, independent, and client-specific

The operating system for our infrastructure is either Ubuntu or CentOS 7. The solution doesn't limit the use of data center services – the environments slip comfortably into cloud services, such as Amazon AWS, Microsoft Azure and Digital Ocean, or into the client's own local server systems. The environments are installed to the software developer's computer with the Vagrant virtual machine tool.

For our clients, our infrastructure is a part of the bargain. It's only natural that the customization of the basic package for the project, and possible maintenance tasks and the necessary testing require some work, but because of our infrastructure model, the costs are minimal when compared to the savings. And should we ever part ways, the client can take their Druid infrastructure with them or set up their own environments themselves.

Add new comment

Plain text

  • No HTML tags allowed.
  • Lines and paragraphs break automatically.
  • Each email address will be obfuscated in a human readable fashion or, if JavaScript is enabled, replaced with a spam resistent clickable link. Email addresses will get the default web form unless specified. If replacement text (a persons name) is required a webform is also required. Separate each part with the "|" pipe symbol. Replace spaces in names with "_".
  • Web page addresses and email addresses turn into links automatically.