Tech

How we manage 100+ Web Application Firewalls

26. Jun 2020

This is about how we manage large numbers of ModSecurity WAF deployments, including CRS and custom rules.

ModSecurity CRS Berne Meetup

At VSHN we’re not only 100% committed to Free and Open Source software, we also collaborate actively with the communities of the software we use, deploy and enhance. This June, we had the pleasure to join the OWASP ModSecurity Core Rule Set Berne Meetup group online who had asked us back in November at yet another Meetup to showcase the way we use ModSecurity and the Core Rule Set (CRS).

(mehr …)

peter.bittner

Continuous delivery for a living.

Kontaktiere uns

Unser Expertenteam steht für dich bereit. Im Notfall auch 24/7.

Kontakt
Allgemein

Zukunftstag mit Adriano

15. Nov 2019

Zukunftstag bei VSHN

Am Nationalen Zukunftstag, vergangenen Donnerstag, den 14. November 2019, war Adriano bei uns zu Gast. Er hatte einen Tag lang die Möglichkeit, unser doch sehr herausforderndes Umfeld kennenzulernen.

Adriano’s Bericht

„Es ist ein sehr schöner Tag gewesen. Ich habe gelernt zu programmieren und es ist voll cool gewesen. Ich habe sehr viele Sachen gelernt auf dem Computer. Zum Beispiel vom Programmieren, Dinge die ich noch nie davor gehört hatte. Ich habe gelernt, mit HTML, CSS und JavaScript umzugehen. Ich habe gesehen, wie ein Programmierer arbeitet. Es ist schön gewesen, bei VSHN zu arbeiten. Es war ein schöner Zukunftstag.“

Adriano hat auch gelernt, virtuelle Maschinen selbst zu installieren, von A bis Z manuell und vollautomatisch mit Vagrant. Sein Tagesprogramm kannst Du auf dem VSHN GitLab-Account einsehen: https://gitlab.com/vshn/one-day-at-vshn
Schön, dass es Adriano gefallen hat! Uns hat es auch Spass gemacht, DICH bei uns zu haben.
Wir freuen uns aufs nächste Jahr! (Hoffentlich auch mit ein paar Mädchen, denn DevOps ist für girls & boys!)

peter.bittner

Continuous delivery for a living.

Kontaktiere uns

Unser Expertenteam steht für dich bereit. Im Notfall auch 24/7.

Kontakt
Tech

The Art of Writing Deployment Pipelines

15. Aug 2019

This post comes late after my EuroPython 2019 talk on „Modern Continuous Delivery“ in Basel. But there is no need to worry: Advice on writing software that outlasts hypes on modern computing has no hurry to appear on stage.

What a great time!

Deployment automation, cloud platforms, containerization, short iterations to develop and release software—we’ve progressed a lot. And finally it’s official: Kubernetes and OpenShift are the established platforms to help us do scaling and zero downtime deployments with just a few hundred lines of YAML. It’s a great time.
Can we finally put all our eggs into one basket? Identify the cloud platform that fits our needs, and jump on it? That could well backfire: Vendor lock-in is the new waterfall, it slows you down. In future you’ll want to jump over to the next better platform, in a matter of minutes. Not months.
So, how do we do that? What’s the right approach?

The definition of Continuous Delivery

What does modern software development look like?

A modern software development project does:

  1. Immutable infrastructure („containerization“)
  2. Container orchestration (e.g. Kubernetes, Docker Swarm)
  3. Version control and automation (CI/CD, „pipelines“)
  4. Cloud-native applications (resilient apps that scale)

Nothing new. You’ve heard this before.

Vendor lock-in is the new waterfall

Software development has become complex. So complex that there are numerous services popping up almost daily that help us getting things done. Most notably, these are application delivery platforms nowadays (Amazon AWS, Microsoft Azure, Google Cloud — just to name a few). When we use offerings across several such providers, which is becoming increasingly popular, we speak of multi-cloud dependencies.

While all offerings are choices they typically entail a lock-in, because we don’t have standards and tooling yet that allow us to effortlessly switch from one solution provider to another. And when there are reasons to make a switch, lock-ins make it inherently difficult to move fast. This is a problem.

What can we do about vendor lock-in?

Software development is not about „using <technology>“ or „using <platform>“. As engineers we must think in terms of „problem to solve“ (requirements) and applying proper development practices (engineering). If we rely on platforms to solve problems for us we’re doing it wrong. Engineers must learn to follow principles of good software design, to write and maintain „clean code“.

Responsibility layers  

One of those principles you learn as an engineer is to maintain boundaries between systems. In a modern software development project you’ll see four of such „layers of responsibility“ that define boundaries:

  1. Application
  2. Development
  3. Deployment
  4. Automation

Think in terms of technologies and tools, or services and environments you use in each to understand why we have those.

  1. The application layer is like how you did software development 15 years ago. It’s just concerned with getting things running locally. Add the 12factor app methodology and you get an application that is prepared for potential target environments.
  2. The development layer is concerned with supporting the development in the application layer. Developer tooling that gets the project running with a single command, a test infrastructure setup and QA tooling, which should also be easy to handle.
  3. The deployment layer reuses that part of the development layer that made the developer deploy the application locally, for development. It also houses configuration files used only in productive target environments and deployment configuration that describes the entire productive setup.
  4. The automation layer is only concerned about automating the steps you would otherwise perform manually to deploy your application.

Clean separation and interfaces

Now we have layers. What do we gain?
Note how the layers use an interface to talk to the next layer above. This allows us to address them separately. In other words,

  • When you want to use a different CI service (e.g. switch from Bitbucket Pipelines to GitLab CI) you only refactor the implementation in the automation layer (i.e. the CI configuration).
  • When you want to change your container orchestration (e.g. switch from OpenShift to Kubernetes) you only refactor your implementation of the deployment layer (e.g. use Kustomize instead of OpenShift templates and Ingress instead of Routes, etc.). You may also have to change some of the deployment tooling in the automation layer as a consequence (e.g. use kubectl instead of oc), but it’s all cleanly separated.

This is the power of separation of concerns.
Also note that for this to work well you need to make your interfaces simple and stable.

  • For development use a task runner to turn your common tasks into single commands or simple one-liners (in JavaScript you may use gulp, in Ruby rake, in Python tox).
  • Don’t design for target environments in your application layer! Design with features in mind and only combine them to environment configurations in your deployment layer.
  • Stick to standard procedures and established tooling (instead of proprietary or self-invented solutions) for the technologies you use. This is typically more stable as an interface, will save collaborators from learning how to work with your setup and make it unnecessary to add extensive instructions to the README.

The more you invest in this flexibility and clean separation the easier your task will be when the day comes to make a change.

Working code samples to your rescue

What is better than starting to investigate late and working on refactoring under time pressure? Knowing your possibilities and turning to working code samples when you need them!
That’s where the Painless Continuous Delivery Cookiecutter comes into play. It’s a project template generator covering many of the most popular combinations of public service offerings you may be working with. At VSHN AG we’re working on extending it—for your independence. Try it out, let us know if you find it useful, and contribute if you feel like!
For the start you may want to take a look at one of the generated setups on GitLab, the live demo for the EuroPython talk. Enjoy!


EuroPython 2019: Modern Continuous Delivery for Python Developers


Slides of this talk are available from SpeakerDeck.
This article has originally been published on Peter’s personal website.

peter.bittner

Continuous delivery for a living.

Kontaktiere uns

Unser Expertenteam steht für dich bereit. Im Notfall auch 24/7.

Kontakt
Interne

Suada Mirgadirova: My experience at VSHN

1. Jul 2019

It is difficult to have a clear idea about what to expect from a job you would like to have in the future without ever being immersed in the work environment beforehand. Therefore, after coming across the website of VSHN – The DevOps Company, I decided to contact the company and ask for a two-day long introduction to the job. Luckily, shortly after I received an approval from Aarno Aukia, who happened to have graduated from the same school I am visiting now. I was informed that I could come to the company and learn from the software engineers Dimitri Wessels and Peter Bittner about the job. I was happy to find out that both were very much into Python, which I am learning to use for my school project.

On the first day I was working with Dimitri Wessels. In the beginning he introduced me to dictionaries in Python and later to the usage of API’s. It was fascinating to see how the needed information could be successfully extracted from a website in a matter of minutes. After lunch, I was asked to do an analogical exercise with a different dataset. I had to overcome several errors, but the program worked in a reasonable amount of time, and the results were very satisfactory. Later, we discussed the use of classes and how data could be sorted in an elegant way. I was also shown some things that software engineers do, like fixing errors caused by server’s activity, communicating with customers and writing programs. In the end of the day I left the office with new gained knowledge in python and many other things.

Next day I spent working with Peter Bittner. This time I was learning to do something completely different, namely exploring the use of virtual machines. For this purpose, a software called VirtualBox had to be installed that would help me run virtual machines on my laptop. The first thing we tried was installing Windows 10 as a virtual machine, which took hours. However, after lunch we viewed another way of creating a virtual machine, this time Linux, with a help of a USB drive, which took significantly less time. It needed another program and some knowledge in the usage of terminal which was impressive since I have never seen this before. Later I explored the use of Linux and its difference in comparison with other operating systems. Inspired by its practicality and advantages I asked Peter if it would be possible to install it on my computer as well. I appreciate that Peter was willing to spend his time to show me how to dual boot Linux on a computer with the operating system Windows 10, since it was not harmless and needed a lot of time and effort.

I am very grateful that I had an opportunity to immerse myself in this great professional environment. All the VSHNeers were nothing but nice and welcoming to me. Both Dimitri and Peter did not hesitate to answer my questions, were they about the job, programming, machine learning, university or computers in general. My experience was very positive, and I believe that I have learned a lot of things that will help me in the future. I feel more inspired to pursue the career in software engineering now, that I know what to expect.

Suada Mirgadirova

peter.bittner

Continuous delivery for a living.

Kontaktiere uns

Unser Expertenteam steht für dich bereit. Im Notfall auch 24/7.

Kontakt
Interne

Finn Schunk: Mein Schnuppertag bei VSHN

1. Apr 2019

Mein Schnuppertag bei VSHN

Ich wollte einmal richtig Programmieren lernen, deshalb hab ich ein Mail an Aarno Aukia geschrieben und gefragt, ob ich mal zu einem Schnuppertag vorbeikommen darf. Er schrieb mir sehr schnell zurück und wir machten einen Termin aus. Ich erhielt noch genauere Informationen am Telefon von meiner Begleitperson Peter Bittner. Er erklärte mir das Programm und machte mir einen Computer parat.
Als ich ankam wurde ich herzlich begrüsst und in die Firma eingeweiht. Peter hat mir meinen Arbeitsplatz gezeigt und ich konnte sofort starten. Er zeigte mir, wie ich einen Computer im Computer machen kann („virtuelle Maschine“). In der Mittagspause hat Dimitri mit mir Pizza geholt und ich wurde eingeladen. Nach dem Essen gingen wir zurück an den Arbeitsplatz und ich programmierte ein kleines Spiel. Als ich HTML kennenlernte, war ich schon ein bisschen erstaunt, wie kompliziert Programmieren sein kann. Aber auch positiv begeistert, denn ich wusste, dass meine zukünftige Arbeit sehr abwechslungsreich sein wird.
Leider war danach der Tag auch schon fertig und ich musste nach Hause gehen.
Vielen Dank an die VSHNeers!
Finn 

peter.bittner

Continuous delivery for a living.

Kontaktiere uns

Unser Expertenteam steht für dich bereit. Im Notfall auch 24/7.

Kontakt
Interne

Willkommen, Peter!

16. Mai 2018

Ich bin schon ein alter Hase. Ich meine alt. Alt und störrisch. Perfektionistisch veranlagt. Alles muss funktionieren, auch Humor, Spass, die Kommunikation, Freundschaften, der Speed und gegenseitige Unterstützung. Bei VSHN sind alle ein bisschen so, habe ich das Gefühl. Alles ausser alt. Sonst aber alles. Das gefällt mir hier.
Was habe ich vor VSHN gemacht? Auf meinem Dossier steht „Continuous Delivery Coach“, das ist ein Hybrid zwischen Change Manager, Agile Coach und DevOps Engineer, also ein Programmierer mit Herz für Mensch und Maschine. In den 7 Jahren, die ich in der Schweiz lebe, war ich bei vielen erfolgreichen Marken, Agenturen, Portalen, Start-Ups (HolidayCheck, DACHCOM.DIGITAL, Notch Interactive, Guuru, Jung von Matt, comsolit) als Team Lead, Head of Software Development, Python/Django Developer, Change Manager, Agile Coach, CTO, Automation Engineer und einfach nur Freund, Kollege und Gesprächspartner.
Ursprünglich komme ich aus Klagenfurt am Wörthersee (AT), habe an der Technischen Universität Graz (AT) Technische Mathematik und an der Aston University Birmingham (UK) Computer Science studiert (akademischer Abschluss Dipl.-Ing., equiv. Master of Science / Applied Mathematics & Computer Science) und 7 Jahre mit meiner Frau und 3 kleinen Kindern in Wien gelebt, bevor es uns an den Bodensee gezogen hat.
Wenn ich nicht bei VSHN bin, lebe ich für meine Familie und meine zahlreichen Free Software (Open Source) Projekte, halte Vorträge an Konferenzen und versuche Jugendliche für Python und GNU/Linux zu begeistern (z.B. am SBW Talent-Campus Bodensee). Hätte ich einen Monat Zeit zur freien Verfügung, würde ich das Hochziehen einer Office- und Development-Infrastruktur für Start-Ups und SMBs voll durchautomatisieren. Damit der Weg von der Idee zur erfolgreichen Umsetzung in Zukunft noch kürzer ist. Als freie Software natürlich!
Ich freue mich, bei VSHN meinen Betrag dazu leisten zu dürfen, dass die Software Development Industrie aus der Steinzeit herauswächst und nur mehr qualitätsgetrieben an Lösungen für eine bessere Zukunft gearbeitet wird. Mit IoT, AI und conversational interfaces. Mensch und Maschinen, die resilient, fehlertolerant und rücksichtsvoll sind, sich gerne haben und respektieren.
„Beam me up, Scotty!“ 

peter.bittner

Continuous delivery for a living.

Kontaktiere uns

Unser Expertenteam steht für dich bereit. Im Notfall auch 24/7.

Kontakt