After the decision to move to the cloud and determining a cloud strategy, the next step is to carry out a demand analysis, create a system design, and finally set up and test the cloud infrastructure. This all sounds very trivial and is very similar to a dedicated hosting approach, but there are some special points to consider in a cloud environment.

Demand Analysis and Acquisition

In close consultation with the customer, it is necessary to clarify the customer requirements analysis within the scope of the demand analysis. One customer demand is always a high-performance, scalable system at good price conditions (see also the article, “Sustainable Cloud Strategy in e-Commerce”). In order to take this requirement into consideration during the later system design, it helps to use key figures from existing hosting (number of visitors, number of orders, high-performance and weak-performance time windows, etc.) If no hosting is being used or the data was not recorded, experience and a brave look into the crystal ball will help. In a cloud environment, this is easily done thanks to excellent scalability. You start with estimated values and can adjust the resources according to utilization. In the case of dedicated hosting, there is usually a minimum contract term for a defined service, prohibiting resource reduction of the infrastructure. Upgrade of the hardware is possible by purchasing components, sometimes complete servers, but is usually not economical.

In addition to the already existing and known requirements, future requirements must also be taken into consideration. The future requirements could be, for example, globalization of the store with an associated expansion into different countries. This should be taken into account in the system design and cloud instances should be planned in different regions (at different locations). It significantly speeds up access to the store if the server is directly in front of the customer’s front door and not at the other end of the world.

System Design and System Architecture

Once the first phase of the demand analysis and acquisition has been completed, the findings obtained must be summarized and meaningfully implemented into a system design.

Instances

As with traditional hosting with dedicated systems, cloud instances must be equipped with resources (CPU, memory, hard disk space). However, options for automatic scaling must be considered. If the instances are sized with plenty of memory and CPU power, then only a few more instances need to be generated during peaks load. During less busy times, however, these resources are unused and must be paid for. Equipment with little memory and CPU resources means that, as user numbers increase, new instances are generated very quickly. Once they have been generated, these new instances must be included in the load balancing. In sum, we are talking about maybe 20 to 30 seconds during which the store will be slow. If the number of visitors continues to grow, it is likely that the cloud service will not be able to keep up with the generation of new instances. However, there will be no unused system resources that are wasted. It is therefore crucial to find a healthy median between performance and economic efficiency.

Services

In addition to the instances, there are also services that can be used. For example, to provide a database for e-commerce hosting, you could create an instance, populate it with an operating system, and install a database. However, this contradicts the approach of a cloud. If the MySQL service failed, the database connection would hang and the store would become inaccessible. Thus, the store would not be fail safe. If, on the other hand, we use the Amazon AWS RDS service or the Microsoft Azure SQL service, the MySQL service will be provided by several systems. If the service fails on one system, a second system jumps in and takes over the service without downtime. What’s more, the Amazon service, unlike the instance, supports automated, vertical scaling (scale up). With Azure, the vertical scaling of an instance can be automated, but the virtual machine here is replaced as well with another instance in the background and finally destroyed. If the system resources of the database host are no longer sufficient, a new instance must therefore be created. Another advantage that can not be overlooked is that backups usually do not need to be scheduled. Data protection is usually taken care of by the provider of the offered services.

Local Distribution

Once the fundamental dimensioning of the entities and the use of services is defined, the division into regions and subnets follows. The required interfaces to service providers, any necessary connections via the Internet, and the administrative access to the instances and services must be taken into account. If the store is to be available on other continents, it may be worthwhile to provide the instances in different regions. In this case, the delivery of static data via a “Content Delivery Network” (CDN) should be considered. Of course, there are other factors, such large amounts of media data, that justifies use of a CDN.

Simple or Complex?

Once the system design has been completed and the required infrastructure is established, the selection of a provider can begin. For simple infrastructures and concepts, a provider, such as platform.sh, is certainly a good option. In this case, the provider will install an additional abstraction layer, i.e., a kind of toolbox to build a cloud infrastructure as simply as possible. An additional abstraction layer always means less effort through simplification, but at the expense of possible expansion depth of the infrastructure. A description language such as YAML provides a comprehensive description of the infrastructure and the required instances so that the provider can perform automated deployment. The advantage of such a solution is that even developers can make minor changes and don’t require a system administrator for every change. This simplicity comes at the expense of a limitation in complexity. Not all infrastructures can be mapped in this manner.

If more complex infrastructures are required, we need to choose a provider for so-called IaaS solutions (IaaS = Infrastructure as a Service). Here, too, you can automate sub-areas, but the parts of the structure of the infrastructure must be implemented manually and is much more complex. However, the possibilities are also more diverse. After selecting the hosting provider, we can create the system design in more detail and carry out the detailed planning. Monitoring of the infrastructure must not be forgotten. However, most providers offer corresponding services.

The roll-out of new versions of the application is also important and must be taken into account when designing the system. Since various instances and services may be distributed throughout the world, automatic detection and roll-out to all systems must be enabled. The new version must also be provided for every generated new instance. And finally, there must be a rollback strategy if a deployment fails.

Establishment and Testing of the Infrastructure

Once the system design has been completed and a hosting provider has been chosen, the infrastructure must be set up. If you have not chosen a provider with an abstraction layer, automation is recommended.

The last task, which is not to be neglected, is testing of the infrastructure. The expected number of visitors should be simulated to see how the system behaves under real conditions. Again, it is worthwhile using an additional cloud provider to provide the appropriate resources to simulate testing from an external source.

Conclusion

Cloud hosting offers far more options than dedicated hosting. However, this brings along an increase in complexity. This makes meticulous capturing of demand and system design that are as complete as possible and allow for plenty of configuration stages all the more important. If you work with a competent partner, you can conquer the whole world with your e-commerce launch.

You can find more about e-commerce strategies in the Magazine (in German).

This post was written for Atwix blog by Marc Becker, Director of IT, netz98 GmbH.