What We Can and Cannot Do

We Can

Help client to decide which server hosting and virtualisation to use

We can operate with:

Bare metal dedicated servers and VPS provided by

Virtual Machines and Containers

Virtual machines on dedicated servers – KVM
Linux containers on dedicated servers or VPS
Virtualisation clusters like Proxmox VE or LXD
Docker, Kubernetes, Nomad and other containerisation solutions

Cloud Instances

Most common option our clients take is the Hetzner dedicated server + Linux containers. We also recommend this setup because of the best value for performance with sufficient flexibility. But in general, choosing hosting provider depends on the actual and planned workload.

We recommend to use Clouds only when their usage is justified: programmatic scalability, multi-tenancy on demand, multi-regional requirements etc. In our opinion Clouds are not the best option for the simple setup like Internet portal or shop with steady load: it will cost more and perform worse. People tend to use Clouds wrong.

After making the decision on what to use we help client to sign up for the service. Often client shares with us access to the hosting management service. We keep client’s access secrets safe with private instance of password vault.

Install Operating System and Connect to Microdevops toolset

We always try to minimise the part of server setup performed by hands. We have strong experience in Ubuntu and Debian and develop tool packages and configuration management code for them. As soon as the OS is installed, preferably also with automated provisioning, we continue the server setup declaratively with the code.

Deploy own Infrastructure

Some even small clients require having their own DevOps stack infrastructure because of regulations, safety considerations etc. That is why we’ve developed our approach with multi-tenancy in mind. So on client’s wish we can deploy client’s own GitLab instance, SaltStack server etc and practice the same approach as in our own infrastructure, but operating client’s own services. Of cause client has much more control on core components if they are of his own. As long as we operate client’s own infrastructure servers they all still require Microdevops licenses.

Deploy Applications

We have experience in deploying and configuring applications like:

nginx/php Websites
nginx/python Websites
nginx/ruby Websites
nginx static Websites
MySQL (Percona flavor)
PostgreSQL
MongoDB
RabbitMQ
Kubernetes cluster
Softether, Wireguard, OpenVPN VPN
GitLab

And many other. The list of apps we deploy with the code is available here.

Long Term Support

We like solutions that keep running for many years. We have been supporting some of server setups for our clients for more than 10 years now, migrating through the machines, upgrading OSes and applications. We develop our tools to unify monitoring and backups, that are required for the long term support.

Provide high-quality engineering

We work with rather small setups. The idea of Microdevops is in providing advanced technology stack as a service for the small clients, help them understand and utilise it’s advantages.

Manage Access Policies

All servers we manage utilise closed Firewall policy. By default all private service incoming ports, like SSH and databases, are closed from the Internet. With the help of Infrastructure as Code we manage access lists of static IP addresses allowed to connect. We use private VPN servers if static IP addresses are not available to the client.

Manage Configurations

We use specific Configuration Management solution – SaltStack. Actually, we spend most of our time writing universal and reusable open source code – SaltStack formula and client-specific variables (pillar) and files that are utilized by formula code to configure servers. We define and configure client infrastructure (IaC), apps, users, IP addresses, monitoring endpoints and thresholds, databases, backup sources and targets etc. We try to automate everything we can with the help of config management because it documents infrastructure and gives repeatability, reliability, safety and many more advantages.

Consult

Not all software engineers are of full-stack breed and have DevOps experience. Staying focused on some slice of technology is also good. It allows to dive deeper and to know better. We consult and assist small dev teams on how to use DevOps (Git, Docker, Kubernetes, Repositories, Registries, CI and Pipelines, Automation) with specific products we know best of all: GitLab, SaltStack, Ubuntu.

We can provide dev teams with the setup of dynamic dev application environments, which are automatically created and deleted for Git branches or tags within Kubernetes cluster using GitLab pipeline and Rancher cluster visual access. It is similar to GitLab Auto-DevOps, but Auto-DevOps has more constraints. Also, we do not keep stateful data in Kubernetes clusters – we setup databases and storage only on classic infrastructure.

We can consult on these technologies proper usage:

DNS (Cloudflare)
SSL certificates (Let’s Encrypt automation using acme.sh, CertBot)
Anti-DDOS (Cloudflare, Nginx)
Git branches, tags, sub-modules, flow
MySQL (Percona), PostgreSQL fine-tuning
Server performance
Backup
Monitoring
Other server sysadmin tasks

We Cannot

Support other Legacy Architecture

We can and wish to long term support of architecture we’ve made. But if the client’s infrastructure was built by someone else using different approach we lose all advantages of IaC, automation etc. We can migrate applications from foreign systems and even try (if possible) to perform hotfixes on legacy systems while in the process of migration, but only as an exception and only if client has a commitment to build new infrastructure.

Compromise our Principles

For example, we never agree to give up closed Firewall policy on client’s server. This principle may be very inconvenient for the developers and they try to sabotage it. But this approach has so many advantages from the point of security, so we cannot do another way. We always notice the client that we cannot do specific task because it compromises our approach.

Use Whatever Technologies

We are strong in our own architecture and we wish to focus on some specific technologies we prefer. We cannot give client a commitment to operate any technology he or she wishes. For example, we will not setup Jenkins and its Pipelines because its ideology is foreign to us, we use mainly GitLab for now. We will not use Ansible, Puppet or Chef because 100% of our configuration management experience is in SaltStack.

Substitute Client’s Developers

Even though we can cover major part of the requests regarding client’s servers and infrastructure we cannot substitute all other needed engineering specialities. We always try to provide client with the information regarding our abilities and whether the task fits our approach or not. For example, we cannot write client’s application code, fix WordPress themes, update plugins etc.