Where do we help?

Our services are individual - just like our customers. We don't have a standard process that we have to follow strictly.

You already have a running infrastructure and are looking for support with monitoring or are wondering whether your backup strategy is sufficient for a disaster case? Are you looking for temporary support to relieve your developers or to build up your own infrastructure team?
We are happy to help.

Dimensioning the infrastructure architecture

The question of what infrastructure is actually needed often arises before the start of a project. Where should the deployment take place? With what? When is autoscaling needed? On which metrics should scaling be based? How do you avoid errors and high infrastructure costs? How do you create a fast "spin-up" of new capacities? What do developers need to be aware of when trying to autoscale the infrastructure? What are the pitfalls?

We also help with technology decisions in this regard. According to your wishes and project requirements the application can run on classical VMs, in Kubernetes or use a vendor-specific cloud service such as Amazon's “Elastic Container Service”.

Infrastructure setup

When setting up a hosting infrastructure, we recommend using Infrastructure-as-Code (IaC). Why? Because this allows the systems to have a uniform, reproducible configuration and all changes are stored in a version management system such as git, including the history. So years later you can still find out why something was done and by whom. For example, we often use Puppet for the target systems and Terraform and Cloudformation for defining the infrastructure at cloud providers.

Deployment

Today, code is copied and rolled out to application servers in an automated way - we have many options for this ranging from Capistrano to CI pipelines with GitLab or GitHub actions. Of course we also work with classic application layouts or containerized infrastructure. We discuss which solution is best for you and help with the introduction of automated deployment.

Debugging

In productive environments, there are always challenges that require an understanding of the application and the underlying infrastructure. These are for example Content Delivery Networks (CDNs), DNS, third-party systems connected via APIs or the own database, which does not behave as you are used to on your own developer computer.

Such errors are often found much more quickly if a developer works together with an infrastructure expert.

Monitoring

Typical infrastructure monitoring involves monitoring resources such as RAM or CPU. While these parameters are undoubtedly important to keep an eye on, good monitoring should go a step further and ensure that the software stack is actually working. This includes a complete sweep of the application from the load balancer to the database. Good monitoring alerts early before SSL certificates expire and checks asynchronous job queue systems. Beyond that, of course, the most important thing is: Does anyone react when the monitoring turns red? And how quickly? And does the person know what to do?

Backup

Errors do happen. Therefore, we create backup concepts together with the developers and implement them for all data stores. This applies to relational databases (PostgreSQL, MySQL/MariaDB), but also to Redis, ElasticSearch or CouchDB - as long as relevant data are stored within them that are not trivially recoverable. We also consider the frequency with which backups are created, how we avoid locks or performance problems during creation, and also where we store the data: we often encrypt backups and copy the data to a physically separate location, sometimes even at a second, independent provider. At a minimum, however, the data must be in separate fire backup sections.

But the best backup is of no use if it is not tested during regular disaster recovery exercises.

Migration from own data center to AWS

For a large German corporate group, makandra supported the migration of many applications to AWS.