DevOps as a Service
We support development teams with infrastructure and operations know-how
Your development team has a full backlog of feature requests, chores and refactoring coupled with deadlines? We are familiar with that.
Having developers taking care of operations and all the associated tasks on their own is usually unrealistic - and also not economical. Simply handing over all the operations tasks isn't a good idea either, and usually doesn't work. Together for more stability, security, availability and scalability.
We see ourselves as part of your team. We provide know-how on all topics that web-based applications come into contact with. We know in detail how networks, routing or peerings work with everything that follows: IP, TCP, UDP, BGP, DNS, HTTP. We are experts in security, Linux, databases, containers, failover and high availability. We support you with this knowledge and together we ensure a relaxed and error-free hosting.
We have been developing web applications for over 12 years. In 2009, our first customer insisted that we also operate the developed application. Since then, the topic of operations has accompanied us. Over the years, we have built a team of experts to assist our developers and work with them to ensure smooth operations. In the meantime, we receive more and more requests from external developer teams, which we now support.
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”.
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.
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.
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.
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?
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.
Experience in complex use cases
When requirements become harder we support you with our experience from 12 years of building infrastructure.
Before larger web projects go live, so-called load tests are usually carried out. In order to provide a meaningful statement, load tests have to be planned: Which routes are called by visitors? At what frequency? How are the visitor flows distributed? During a load test, the target systems must be kept under close observation so that insights can be gained. We have conducted such tests several times and can help you go live with a good feeling.
If there's one thing you don't ever want, it's to be in the press because of a security incident. Together with your developers, we define necessary and feasible defense mechanisms. We work with various tools such as rate limits on certain routes, web application firewalls (WAF), reverse proxies and CDNs. In addition, we use patch management and regular updates to ensure that the components used are up to date and have no known security vulnerabilities.
Experience with security audits
Security audits in the form of security audits or penetration tests are often requested by customers and are due at the latest during a technical due diligence. We have experience in preparing the documentation, securing the systems and supporting the audits. For example, we ourselves have been TISAX-certified for a long time.
Building an AWS infrastructure for corify
Our task was to plan and implement an infrastructure on AWS and set up Continuous Integration and Continuous Deployment (CI/CD).