News

We’re thrilled to announce that our first System Engineer has officially started working at Adfinis IT Australia Pty Ltd. Andrew Roffey will make our “Following-the-sun”-principle come true and relieve our swiss employees regarding the 24/7 SLA service, which they have previously mastered alone.

It’s time to meet Andrew!

Experience and skills

I am a Linux Systems Engineer and have been for around 5 years. Before that, I already had a background on Linux and for the most part, have been using it exclusively for nearly 8 years. Python is my scripting language of choice and have dabbled elsewhere, in Perl, PHP, JavaScript, and others.

Why I chose Adfinis

I started learning about open source and free software many years ago and became very drawn to its philosophy and advantages. I wanted to work for Adfinis because the company has Linux and open source at its core. I’d also like to learn, widen my skill set in the field, meet new people and get involved with the community.

What I’m enthusiastic about – besides IT

Some of my non-IT hobbies include gardening, camping, cycling, and generally being outdoors. Like many others, I enjoy travelling and spent 6 weeks in Europe in 2019. Most of my time was spent in the UK, Germany,  and the Netherlands. I did briefly pay a visit to Switzerland, in Lucerne. The most memorable experiences were of course the mountains, the old buildings and the jingling of the cow bells.

A fun fact about me

I started learning programming when I was relatively young, at 9 years old. I mostly did VBA, HTML, JavaScript and CSS, and PHP a few years later. Whilst learning web tech I discovered Firefox which I thought was such a fantastic idea and how I first got interested in FOSS

In this vlog, Robert shows you why Ansible and Terraform are such a good combination.

Maybe you’ve seen Terraform, Terraform is really good at spinning up or managing resources on any cloud provider. These can be many different types of resources, like volumes, load balancers, any kind of resources basically. Terraform is not really good at configuring these instances. Terraform can create the resources and that is about it. Ansible is really good at managing these resources. That’s why we should try to combine them. In this vlog Robert shows you how Terraform writes an Ansible inventory file.

Robert has prepared a very simple example. He will show you that Terraform will drop an inventory file that can be picked up by Ansible. The prepared Ansible Playbook then will make a mail server out of this instance. Of course, you can use any role and any task. This demo will show you that Ansible is much better in configuring the instance then Terraform is. Terraform has a few hooks that you can use, but is never as good as a configuration management system.

Conclusion

• Terraform is really good at spinning up resources
• Ansible is really good at managing those
• Terraform and Ansible work very well and seamlessly together

 

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:

• go-cfenv
• py-cfenv
• node-cfenv
• php-cfenv
• java-cfenv

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!