DevOps and server infrastructure
DevOps and server infrastructure setup: builds, deployment, monitoring and backups arranged so that a release is routine rather than an event. We take it on as a single task or place an engineer inside your team.
Infrastructure gets remembered twice: when a deployment takes a whole day and when something falls over. In both cases the reason is the same: nobody designed how the product is built, deployed and observed, it simply took shape on its own.
Let us draw a line straight away, because the two are often confused. DevOps grew out of system administration, and that did not make them the same thing. DevOps is infrastructure as code and bulk provisioning through Terraform, Ansible and similar tools, the build and deployment pipeline, environments, monitoring and the way secrets are stored and passed around. It is needed where there is a lot of code and regular releases. A system administrator is a supporting unit: the servers and the systems on them, targeted tasks, granting and revoking access, keeping what already works running, and in companies without a dedicated security specialist that role as well. Many administrators practise some devops tasks too, but they answer for something else, and substituting one role for the other is expensive.
We bring infrastructure into a state that can be understood. It is described in code, so it can be read, reproduced and restored rather than kept in one person head. Builds and deployment are automated, so a release stops being an event. Monitoring is set up so that you learn about a problem from the monitoring system rather than from your clients, and so that you do not need to come to us with it: we learn about the incident from the same place.
Tools are chosen by scale rather than from a list of what is fashionable. We take Terraform where servers have to be raised fast and many at once. Ansible where the service has reached steady performance and new machines appear rarely: it calmly sets up a new service with all its keys and access. The same goes for builds: GitLab CI or GitHub Actions is usually enough, and for manual scenarios and complex pipelines we deploy Jenkins or TeamCity.
Updating without downtime is work of its own. During the migration of Silent Notary the containers were updated on the fly: a person could be in a section of the old version, click through to the home page and end up in the new system without noticing the transition. This can be done almost always, the question is only money and whether downtime is genuinely unacceptable for you.
One more conversation worth having early is cost. The cloud is convenient and grows unnoticed: unused disks, forgotten copies of environments, machines kept just in case. We cost the infrastructure alongside setting it up and show where it costs more than it brings.
Infrastructure runs alongside backend, server software and web development. The area can be handed over entirely under the outsourcing model, or an engineer can join your team under outstaffing. If it is unclear what is happening with a system that already runs, start with an audit. Infrastructure we built serves the wallet, the staking platform and the network explorer.
What the service covers
Any combination of the items below can be taken on its own.
Servers, networks, access and environments described in a repository. Terraform where machines have to be raised fast and in bulk, Ansible for targeted setup of services on settled infrastructure. A new environment comes up repeatably and identically rather than being assembled by hand again.
Automated builds, tests, one-click deployment and rollback in minutes. GitLab CI or GitHub Actions for ordinary work, Jenkins or TeamCity where manual steps and complex pipelines are needed. Separate environments for development, review and production.
There are two paths here. The simple one is Docker and Docker Swarm, which is enough for a product made of a few services. The complex one is Kubernetes, where the unit of deployment becomes a pod rather than a single container, with its own rules for placement, networking and storage. Such clusters are convenient to manage through Rancher. We choose the path by the number of services, the number of projects and the load.
When you need your own servers, we deploy Proxmox directly on the hardware. It is a Linux distribution based on Debian: nodes are joined into a cluster, and virtual machines or images run inside. This makes sense where the load is steady or the data carries confidentiality requirements.
Metrics, logs, traces and a sensible alerting setup. The value is in seeing the trend early: long-term logs show how the load changes and where a problem is building up, so a night call saying everything is down stops being the main way you learn the news.
Scheduled backups, storage in a separate location and regular verification that a backup actually restores. An unverified backup is not a backup.
Moving between platforms and clouds without losing data, access boundaries, secret storage, system updates and a review of the infrastructure bills.
How we work
We look at what is deployed, how it ships, what is monitored and where the bottlenecks are. The output is the picture as it stands and a list of risks.
The target setup, the order of work and an estimate by stage. We close what threatens downtime or data loss first.
Infrastructure as code, the build pipeline, environments, monitoring and backups.
Moving over in parts, testing recovery and running failure drills rather than describing them on paper.
Updates, response to alerts, on-call duty and incident reviews.
Stack and tools
Cases for this service
Frequently asked questions
DevOps is responsible for how the product is built, deployed and observed, for infrastructure as code and for how secrets are stored. It is needed where there is a lot of code and regular releases. A system administrator deals with the servers and the systems on them, with targeted tasks and with access. These are neighbouring roles, and one does not replace the other.
Yes, that is a common scenario. We work with your team and your code, put the infrastructure in order and hand it over together with its description.
Often not, and we will say so plainly. Kubernetes is justified with several services, noticeable load or frequent releases, and it comes with people who maintain it. A small product is usually well served by Docker and Docker Swarm.
We cost out both. The cloud wins at the start and under spikes of load. Your own servers win on steady load and where the data carries confidentiality requirements, and in that case the platform is convenient to build on Proxmox.
Almost always. It is a question of money and of how critical downtime is for you: backward compatibility, a rollback plan and switching over in parts cost more than an ordinary release. We discuss that before the work starts rather than halfway through.
Secrets are kept in a protected store, access is granted by name and at a minimum, and every action stays in the log. When the work ends our access is closed and yours remains.
Everything is set by the contract, and we put it in writing at the specification stage, before the work starts. Provider accounts are registered in your name and the description of the infrastructure lives in your repository. Once the project is closed, all materials and documentation are handed over to you together with the rights to them.
Yes, under a separate agreement: monitoring, response within an agreed SLA and an incident review afterwards.
Related services
Shall we discuss your task?
Tell us what needs to be done and we will come back with an estimate, the team composition and a plan for the first two weeks.