News
Das Neuste aus der Welt von Adfinis SyGroup
What happened so far
In the last installment of this series we successfully deployed our demo app to the SUSE Cloud Application Platform Developer Sandbox.
Where should the application state be stored?
According to the point IV. of the Twelve-Factor App manifest we should treat backing services as attached resources. In our target environment, this is easy due to the fact SUSE Cloud Application Platform provides first-class tools to manage things like databases as resources.
We are going to build on the same example we used in the last blog post, but Cassperli has learned a new feature in the meantime. In its latest version it knows if it’s being deployed on CloudFoundry. If it is on Cloud Foundry and it also discovers a MongoDB database through the cfenv subsystem it will use the database to store a simple web page hit counter reminiscent of the page counters from times long gone.
How Cloudfoundry makes services accessible to applications
As part of the cfenv subsytem Cloud Foundry will set some VCAP_* environment variables that a Cloud Foundry native application may use to figure out if it is running on Cloudfoundry as well as to discover information regarding the services that have been bound to the app.
In the following example the existence of the VCAP_APPLICATION environment variable will help us figure out if we are running on Cloud Foundry and the VCAP_SERVICES environment variable will tell us what services are available to use.
These environment variables follow some simple rules and you can assume that the will follow the same basic structure on all major Cloud Foundry distros.
For most programming environments there are libraries that help you parse the variables in a consistent manner:
Using these helper libraries adds a programming environment-specific interface to the cfenv subsystem. Such libraries also isolate you from changes to the underlying cfenv spec.
Creating the backing store
You can create the MongoDB database through the web frontend of the SUSE Cloud Application Platform.
After logging into the sandbox you can create a service.
First you will navigate to “Services” in the application you deployed in the previous post.
Click the + button to create a marketplace service.
Choose the “mongodb” service and click “Next”.
Select the service plan needed by your application. In our case, we can use any recent MongoDB version that is available.
Since we started from the “Services” page on an application the app to bind to is already specified.
Call the service instance “mongodb” to the automatic configuration detection in Caasperli can discover the instance.
Wait for the service to be created and verify that it is bound to the app by looking at the service count on the application overview.
Deploying a new and improved Caasperli that uses the backing store
Next, we will update Caasperli to a version that supports using MongoDB and discovering a backing service on cloud foundry. Click on the three dots to the right of the firstmost commit in the list of commits and choose to Deploy from the menu.
Double check that the commit you are deploying is the given or a later one.
Press “Redeploy” to confirm that you want to roll out the next version of the Caasperli application.
After the service has been built by the buildpack and started. The logs will contain some output telling you that it is running on cloud foundry and that it detected the “mongodb” service.
You may now visit Caasperli at the route we deployed it to and find a happy new feature.
In the next installment of this blog series, we will be looking into other ways to deploy applications to the SUSE Cloud Application Platform.
In this video, Robert demonstrates how you can prevent cloud lock-in with Terraform. Terraform allows you to describe your infrastructure as code and lets you decide on what cloud you want to use.
In this vlog, Robert de Bock will give you a short explanation about what “Cloud Lock-in” is and how you can prevent it.
What is a Cloud Lock-In
Cloud Lock-in is the situation where you can’t get away from a cloud provider because you are using many resources that are specific to that cloud provider. By using those resources, you are not able to move your workload somewhere else. Although these cloud provider services are nice to use, you basically lock yourself into a specific Cloud provider by using them.
An Example
Robert shows you Cloud formation from AWS as an example. It is a solution for everything-as-code and infrastructure-as-code. So it is a descriptive language where you can describe all the resources you need, could be machines, could be load balancers. These examples are very specific to AWS. Works well, but in this case only specifically for AWS: You’re locked-in.
The Solution
Terraform is an alternative to that. Like AWS’ Cloud formation, you describe your infrastructure as code, but Terraform is independent of any specific cloud provider. You can use the services from all cloud providers. You can even mix. So, you could for example build a machine on one cloud provider and have the load balancer on another cloud provider, how fancy is this?!
The code of Terraform is a little different from the code of AWS’ Cloud formation, but maybe you recognize that some resources.
Do you also want to be independent of your cloud providers? We’ll help you!
We are happy to announce, that with Robert de Bock, a first Engineer joined our team in the Netherlands – Welcome a board!
Last week, our NL-team went on a roadtrip and made it all the way down to our offices in Basel and Bern. So we already got the chance to meet Robert and, of course, were very curious about his background, his goals and everything that makes him special. We are happy to share Robert’s interview and hope you can meet him some time soon.
Hi Robert, welcome at Adfinis! It’s so nice to have you on board and we are really looking forward to our joint future journey. We are very interested in getting to know you and therefore ask you to tell us a bit more about your background and where in IT you are specialized in.
Thank you very much, I am looking forward to it too. As for your question: I have a strong Linux background, which I sometimes do see as a problem, because I only can do Linux. But it also has its upsides to be specialized in something. Regarding technologies, I know Terraform and Ansible very well and all kinds of technologies, where you don’t have to do things manually anymore. I kinda moved to “everything as code”, because it is much more honest, as everyone can contribute and read how it works. This shift meets good with the culture of Adfinis.
So is that also why you wanted to start working at Adfinis?
Yes I like the core values, and that the work is very broad. If you work with many different technologies, you see much more of the market than with only a single product. I worked at a bank for five years, which really is a good place to work, but it is also narrow and therefore limiting. At Adfinis we can work with different technologies, which opens the mind and I see many possibilities and the chance to discover new things to focus on. I also really like learning new things, work with people, learn from others, broadening my portfolio and getting confronted with new technologies. That’s why I see in Adfinis lots of opportunities to grow.
A keen learner with a passion for technology, I like that. And what are your interests beside IT?
As almost every dutch person, I’m really fond of water. I like swimming, sailing and diving. I once used to be a diving instructor but with three kids, there is currently just not enough time to keep it up. Architecture is also something I’m interested in. It tells you something about the time. You can walk through the streets and can see the history in it.
What about your history? What is a characteristic or a fun fact that makes Robert – Robert?
That I do something daily. This “something” can be anything: writing, painting, coding. Important is that you are not doing it for your boss, not for money, but for yourself and every day.
So back in 2014 when I started, I made a photo everyday. After working off all the ideas I had in taking photos, I started questioning myself. Why do you do this? Why do you do the things, that you do in life? So I then had to realize that I like taking pictures, but that this won’t benefit my work. So after 3 years, I then decided to start writing code in a language I really wanted to master. So now I’m doing this also for almost 3 years already.
What have I learned? That I am a slow learner. My starting point might be a bit better than the average, but then others’ learning curve is just taking off, while I’m still learning quite slow. But if you are motivated and persist, you will get much better than the rest. You will master, whatever you do daily.
Thank you so much Robert, for these personal insights. We are really looking forward to working with you and I’m already thinking about what my “something daily” could be …
Want to learn more about Robert and his work? Feel free to visit his website.
Want to learn more about Adfinis Netherlands? Feel free to get in touch.
Vergangenes Jahr hat die Adfinis zur Optimierung des Ticketing Systems einen Vergleich unterschiedlicher Lösungen angestellt. Aus der Evaluation ist Zammad als Gewinner hervorgegangen. Eine moderne, von Grund auf neu konzipierte Ticketing Lösung, welche vor allem im Bereich User Interface sehr angenehmen zu handhaben ist. Des Weiteren punktet Zammad mit geringem Konfigurationsaufwand, einer verständlichen Dokumentation sowie Erweiterungspotential durch die offene API. Für ihre Lösung hat Zammad 2019 sogar den “Best Open Source Project” Award an der DINAcon gewonnen.
Während unserer Evaluation hat uns lediglich ein Feature gefehlt: Die Verknüpfung von ServiceNow und Zammad. Durch die fehlende Anbindung wurden Kommentare auf existierenden Service-Now Tickets nicht in die dazu bereits existierenden Zammad Tickets integriert, weshalb diese Zusammenführung manuell durchgeführt werden musste. Das Anliegen, diesen Merge zukünftig zu automatisieren wurde bei Zammad deponiert. Entsprechend wurde ein Use Case erarbeitet, um eine mögliche Anbindung von ServiceNow an Zammad zu eruieren. Die Evaluation des Uses Cases hat ergeben, dass die Implementierung des Features in das Kernprodukt am ehesten gewährleistet ist, wenn es von Zammad entwickelt wird. Die gemeinsamen Bestrebungen umfassen dementsprechend also nicht nur die initiale Entwicklung, sondern auch den langfristigen Unterhalt des Features.
Aus diesem Grund hat sich Adfinis dazu entschieden, mit Hilfe eines Feature-Sponsorings der Zammad GmbH die Eigenentwicklung zur Integration von ServiceNow in Zammad zu ermöglichen. Am 16. Juni 2020 durfte der Release der neuen Anbindungsmöglichkeit gefeiert werden und alle Zammad User können nun davon profitieren – von der Community für die Community.
Erste Zeichen, dass der Unterhalt des Features gewährleistet ist, beweist das Beheben eines nachträglich bemerkter Bugs, welcher innert wenigen Tagen behoben und veröffentlicht wurde. Eine auf ganzer Linie zufriedenstellende Zusammenarbeit!
Freie Software erlaubt es uns, ganz viel Aufwand einzusparen, denn mit ihr können sich Menschen auf der ganzen Welt die Arbeit teilen. Ansonsten müsste jede Firma oder Organisation jeweils Ihre eigene Software bauen. Dieses Prinzip funktioniert hervorragend bei allgegenwärtigen Projekten wie beispielsweise dem Linux Kernel. Bei kleineren Projekten gibt es jedoch oft Engpässe, die man mit Geld nicht so einfach lösen kann.
Heutzutage ist die Infrastruktur für Free Software jedem zugänglich – es gibt kostenloses Git-Hosting, kostenlose Continuous Integration und kostenlose Kollaborationsplattformen. Somit stellt bei solchen kleineren Projekte Geld selten ein Problem dar. Manchmal gibt es zwar einen Software Maintainer der sich über Spenden finanziert, aber die meisten Menschen ziehen es dennoch vor, einem gesicherten Job nachzugehen. Am meisten fehlt es somit schlichtweg an Manpower. Zusätzlich erschwerend gestaltet sich der Einstieg in Projekte, denn dazu braucht es Monate in denen stetig Erfahrung gesammelt werden. Aus diesem Grund wäre es für Firmen durchaus sinnvoll, Mitarbeitenden einige Stunden pro Woche zur Verfügung zu stellen, um die Free Software die sie nutzen, auch zu pflegen.
Ich befinde mich momentan in genau dieser Situation. Ich musste feststellen, dass die Entwicklung von Graphql-Python 3.0 ins Stocken geraten ist und habe deshalb innerhalb der Adfinis um finanzielle Unterstützung für das Projekt Graphql 3.0 gebeten – und diese auch erhalten. Das Projekt ist von hoher Relevanz, da Graphql die Basis von Caluma ist und wir im Backend auf Graphql 3.0 wechseln können müssen, da die Frontends früher oder später die Version 2.0 nicht mehr unterstützen werden.
Das Graphql-Python Projekt beinhaltet somit folgende Subprojekte:
- Graphql-Core ist eine direkte Portierung der Referenzimplementation
- Graphene bietet High-Level APIs für Graphql-Core
- Graphene-Django integriert Django in Graphene
Mittels der durch Adfinis zur Verfügung gestellten Unterstützung konnte ich erreichen, dass es für Graphene-Django eine 3.0 Beta Version gibt. Es gab mehrere Pull-Requests von unterschiedlichen Leuten, die versucht haben, Graphen-Django auf die 3.0 Abhängigkeiten zu heben. Leider hat jedoch keiner der Pull-Requests das ganze Bild abgedeckt. Mein Ziel war es demnach, einen v3.0 Branch zu erstellen, in welchem alle bisherigen Bemühungen zusammen fliessen. Auch hatte ich mir zur Aufgabe gesetzt, die Commits aller Beteiligten so zu rebasen, dass jeder für seine Arbeit Anerkennung bekommt – denn Anerkennung ist gewissermassen der Lohn in der Entwicklung freier Software.
In einem nächsten Schritt müsste nun der v3.0 Branch auf Releasequalität gebracht werden. Hier stellt sich mir allerdings das Problem der mangelnden Erfahrung in den Weg. Da ich nicht weiss, wie ein Graphene-Django 3.0 auszusehen hat, müsste ich mich in die Referenzimplementation einarbeiten, und dafür fehlt mir wiederum das Budget. Die Caluma Test-Suite ist hier meine Rettung. Caluma besitzt eine umfassende Test-Suite in höchster Qualität. Ich lasse also Graphene-Django 3.0 mit der Caluma Test-Suite laufen und eruiere so für jeden Fehler, ob sich Caluma an die 3.0 Spezifikation hält oder ob es sich um einen Bug in Graphql handelt. Dieses Vorgehen hat einen Synergieeffekt – Caluma wird auf Graph-Python 3.0 portiert und die Fehler in Graphql 3.0 werden behoben.
Und so sieht ein Lauf der Caluma Test Suite aus:
Adfinis versteht Open Source als die Zukunft der Technologie und macht sich stark für eine Welt, in der Software freizugänglich, qualitativ hochwertig und allen zugänglich ist. Demgemäss engagiert sich die Adfinis für: Offenheit, Transparenz, nachhaltigen Lösungen ohne Vendor Lock-In und die Kraft der Open Source Community.
