What we mean by DevOps and what we offer
- Building and maintaining the entire complex of CI/CD processes: Continuous Integration, Continuous Delivery and Continuous Deployment.
- Using the Infrastructure as Code (IaC) approach to formally describe the infrastructure that your application requires and integrate the infrastructure code with the application code, what provides a common CI/CD for them.
- Effective interaction with your team: support of constant communications between developers, QA-specialists, system administrators, managers.
- The readiness of our architects to share experience in Open Source-solutions operating and to recommend the best architecture for your application.
- Preparation for highload, including optimization from a low (hardware and system) level to application service configurations, carrying out load testing.
Table of Contents
#01
Who needs it?
- Companies that are developing using Agile principles with teams of any size will receive working and maintained CI/CD and IaC processes. If there is such a need, they will be supplemented by a dedicated team of specialists for continuous interaction.
- Companies that use the microservice approach for architecture building definitely need DevOps to easily deploy and maintain their applications.
#02
Why us?
- Our experience of highload operating includes servicing of leading information web-resources. It means not only support providing, but also design and implementation of the entire infrastructure architecture, scaling, technology consultations, etc.
- For several years, we have been using Docker and Kubernetes in loaded production and we know how to prepare it correctly in projects of various sizes.
- We serve (and have the necessary experience for this) various software platforms including PHP, Ruby on Rails, Python, Java.
- We have our own development department, which runs its GitHub projects and contributes to Open Source products such as Helm. We also have own experience Agile development.
- We create our own solutions for DevOps: werf, shell-operator, addon-operator, loghouse, grafana-statusmap, etc.
#03
What do we use?
- General principles and best practices — The Twelve-Factor App, Martin Fowler.
- Source code management — GitLab or GitHub.
- Automation of continuous integration (CI) — GitLab CI and Travis CI (less often — Jenkins, TeamCity).
- Containers — Docker.
- IaC (Infrastructure as Code):
- the application infrastructure is described in Chef (sometimes in shell) and is automatically assembled into Docker images by our collector;
- the basic infrastructure (hypervisors, virtual machines, applications outside of containers) are described in Ansible separate repository taking into account the specifics of Continuous Integration and Continuous Delivery.
- Platform (PaaS, Docker’s cluster, and Service Discovery) — Kubernetes.
- Convenient development environments and additional (temporary) contours — Vagrant.
- Interaction — Slack chats, merge/pull requests in GitLab/GitHub, Redmine (task setting).
#04
What do you get?
Basic infrastructure. To do this:
- we will calculate the needed number of servers and virtual machines, the requirements for them;
- if it is decided to use a private cloud, we will help you to choose equipment (for purchase or rental) and will advise providers and data centers. We will describe the rules for deploying hypervisors and combining them into a cloud, taking into account the necessary specifics. We will deploy the required number of hypervisors;
- we will deploy a system of statistics and monitoring, backup and other necessary components of the basic infrastructure.
Secondly, a full description of the IaC (Infrastructure as Code) methodology. In Chef (in chef-repo for your project), rules for deploying a common part of the application infrastructure will be created. They include:
- services that are not containerized: MySQL, MongoDB, RabbitMQ, Cassandra and Ceph;
- Kubernetes cluster (PaaS);
- usually, all the specific (and necessary for the functioning of the cloud) settings of virtual machines and hypervisors are also included here: VPN tunnels, iptables rules, routes, etc.
The code for each of your applications will describe the rules for:
- assembling of Docker images for front-ends, back-ends, workers and other layers with the description of such parameters as the version of PHP/Ruby/Python/Java, the list and version of system dependencies, the mechanism for installing application dependencies (composer, bundle, npm, pip, etc.), content of static configuration files, templates of dynamic configuration files, additional actions performed during assembly (for example, generation of assets);
- assembling of additional infrastructure used by the application: memcached, Redis and other containerized services;
- deployment and cross-service interaction.
Thirdly, the installation of GitLab (or another solution, if there is such a need) with imported data from the systems used (GitHub, Bitbucket, etc.). We will work together with you on the Continuous Integration and Continuous Delivery workflows by answering questions such as:
- What commits to collect?
- How, when and what tests to run?
- How many and what environments do you need (other than production)?
- Who rolls out, onto which environment, in what order?
The result will be the workflow described in your application code (in .gitlab-ci.yml).
Fourth, ready-to-go virtual machines (in your private or public cloud). They will be used to deploy components obtained in the previous stages in accordance with the rules of the workflow and in the required number of environments.
Fifth, smart technical support 24×7×365: constant support of development processes, timely changes to the infrastructure, assistance to developers and team leaders on related issues, architecture consultations.
Finally, the guarantees of fault tolerance and scalability of the created infrastructure architecture.
#05
How much does it cost?
The cost of supporting projects according to the DevOps technology is calculated individually, because it depends on many factors, such as the existing processes and infrastructure, the size of the project and the technologies that are used, the requirements for Continuous Delivery, development plans, etc.
#06
What else do I need to know?
- The infrastructure can be either deployed from scratch (from assistance in choosing a data center to launching the final application), or transferred (migration) from any existing hardware and software platform.
- We sign a service license agreement (SLA), under which we guarantee the desired level of availability (fault tolerance). Warranties are possible due to our vast experience in servicing and monitoring various applications in GNU/Linux, as well as the availability of round-the-clock technical support with streamlined interaction processes.
- We offer software and hardware flexibility, which implies wide possibilities for choosing hardware (own or for rent in any of the data centers), technologies (development languages, web servers, DBMS, NoSQL, etc.) and application scale.