Designing and implementing an online store infrastructure on Magento requires good cooperation between DevOps (the person responsible for software development) and SysOps (the system operator managing the infrastructure). Are you wondering what the different stages of these processes look like? What are the best practices when performing outsourced activities? How should the cooperation between both parties proceed?
Based on our long-standing experience, we have prepared several principles of SysOps best practices that you should follow while cooperating between dedicated hosting and software house in the process of preparing infrastructure for Magento-based eCommerce. Read on to learn them and then apply them in your daily work!
Principle 1: Accurate and detailed requirements gathering
Magento best practices? In the first place - documentation! Are you operating on a store currently hosted by another provider? Documentation of the current environment is an invaluable help in preparing the infrastructure for Magento migration to another hosting provider. Reliably prepared and updated on an ongoing basis, it definitely makes it easier to implement the specifics of a given project. It helps to understand the dependencies between the various services and draws a scheme of communication between the services. Moreover, it points out potential bottlenecks that can be managed already at the stage of designing a new environment.
Well-prepared documentation contains information concerning, among others, resources allocated to particular virtual machines, versions of services that are located on them, and the application itself (what it requires and how it works). It is also useful to know the specifics of the traffic - whether it is evenly distributed on a monthly/yearly basis, or whether there are sales peaks (promotions, special campaigns, etc.). Such data allow us to better plan the final shape of the infrastructure and its ability to scale, and thus - choose the most suitable technological solutions.
A significant simplification in the process of preparing the infrastructure is also obtaining SSH (secure shell) access to the current infrastructure along with the appropriate permissions (sudo/root). This allows for a detailed analysis of all processes, dependencies, and configurations. Consequently, it significantly improves the whole "flow" of the broadly understood migration and planning process. In an ideal situation, apart from the accesses, we also have the above-mentioned documentation. In its absence, the analysis of the environment will be much more time-consuming and may turn out to be less accurate (omission of details), especially in the case of non-standard configurations and complex environments.
A third, extremely useful piece of the puzzle in the environment design process is access to statistical data of a currently existing online store on Magento or traffic projections (in the case of a new implementation). Data includes:
- SKU,
- Page Views (PV) on a daily and monthly basis,
- Unique Users (UU) on a daily and monthly basis,
- number of transactions on a daily and monthly basis,
- database size,
- the size of the media embedded in the store,
- external integrations (e.g. ERP),
- sales peaks (their magnitude relative to normal traffic and information on how often they occur),
- the frequency of planned marketing activities.
Note that an environment designed based solely on the above statistics and projections (without documentation and SSH access), may underestimate or overestimate computing power requirements. The development agency should also provide information about the technology stack on which it plans to base its application. Then the migration of Magento to another hosting as part of Dev-Ops collaboration will be done in the best possible way.
Principle 2: The three steps of the Magento implementation path
After gathering as much information about the project as possible, the environment preparation stage begins (implemented in accordance with the requirements and strictly based on them). If any uncertainties appear at this stage, they should be consulted with programmers on an ongoing basis. The environment preparation process itself should be as automated as possible - in a way avoiding any human errors - and carried out with the support of popular tools (such as Jenkins, Ansible or Puppet).
After the environment is prepared, it is handed over to developers along with documentation and comments. SSH accesses for application machines are also created. The period after handing over the environment is the time for possible corrections, configuration "tuning" and implementation of additional functionalities. The hosting provider should make every effort to prepare the environment in such a way, that its later expansion is simply a formality. In other words - we try to make them as scalable as possible, flexible in terms of changes, and well-thought-out.
Once the environment has been picked up by the development agency and enters the development phase, the hosting provider should maintain vigilance, monitor the machines, and exhibit readiness in a task-based model of cooperation with the agency. A helpful tool in catching up on fixes is direct contact between SysOps and developers via a dedicated chat room, which allows for real-time answers to infrastructure questions and quick-win tasks. More advanced issues should be implemented in the ticket system - due to the need for strict documentation of individual stages and changes made. The combination of these two communication channels minimizes the reaction time, increases responsiveness, and accelerates task completion on both sides.
Principle 3: Test, be vigilant, be responsive
Prior to the production start, it is recommended to carry out the so-called stress tests, which will allow estimating the capabilities of the infrastructure - that is to check how much simultaneous traffic it is able to handle and to catch possible bottlenecks. For this purpose, it is necessary to choose the right software (such as Locust, JMeter, Gatling) and preparing a test scenario by the development agency. It is also necessary to specify which elements of the website built on Magento will be tested (e.g. shopping cart, search engine, product categories). The tests themselves are carried out on an agreed date and indirect contact, usually via internal messenger.
The results of the load tests determine further actions. If the obtained results are satisfactory and no bottlenecks in the infrastructure were detected, you can proceed to set a date for launching the store built on Magento. Otherwise, further tests and optimization work are necessary.
After the production start, an increased observation of the state of the infrastructure takes place. Monitoring includes the load and performance of physical and virtual machines, network utilization, and the behavior of individual services.
When starting up a production environment, it is necessary to have the support of a dedicated administrator or a team of administrators who are in "stand-by" mode while the store is open to traffic from the Internet. Such action is intended to provide developers with the comfort of work, a knowledge base in the field of SysOps, and DevOps support.
Principle 4: Continuous readiness and care of Magento infrastructure
It is also a good practice for every newly implemented project on Magento to have its own dedicated rapid support team - a project manager and a technical lead, as well as a second line of technical support. By proceeding this way, you can call up the team at any time to work on solving specific issues, and if necessary, perform urgent configuration fixes in a short period of time.
Magento deployments and collaboration between dev and ops - now much simpler
The process of designing and implementing an efficient infrastructure for Magento requires proper collaboration between SysOps, DevOps and Developer. Conscientious requirements gathering, analysis, efficient communication, and testing - all lead to minimized risks at launch, reduced stress levels in the teams, and, most importantly, end-customer success and the launch of a new eCommerce on Magento.
Authors:
- Paweł Kędziora, Customer Project Manager
- Dominik Błaszczyk, Systems Engineer
