Erik Sterck GmbH, Guest Blog: A DevOps Story

• Erik Sterck GmbH identified the application-centric trend in their customer base
• Realized the need to shift their own focus to capitalize on the opportunity
• Identified and focused on the need for a high degree of automation in helping their customers deliver container-based infrastructure, particularly high availability K8s clusters
• Developed a deployment tool, FramES, to greatly simplify Rancher High Availability (HA) cluster deployment and ongoing management
• Are transforming themselves beyond a traditional IT services provider company by providing a software solution they created to capture new revenue streams

Guest blog author: Stefan Scharlott, DevOps & Automation Solution Architect, Erik Sterck GmbH

Erik Sterck GmbH has always been a very successful “System House”, as we call it in Germany, mostly focused on reselling products and software from the big hardware and software vendors. A few years ago, this started to change. I think most people are aware of the shift away from hardware or even a hypervisor-based focus to a more application-based focus. And suddenly, everyone gets bombarded with terms like DevOps, DevSecOps, Dev<InsertSomethingElse>Ops, agile, lean and so on. This all with the purpose to speed time to market and shorten the customer feedback loop because selling applications people want while adapting to the market in a reasonable amount of time is where the money is. Right?

With this, the focus shifts more and more towards developers and delivering tools they need while removing the consideration of what hardware or hypervisor on which the software runs… as long as it is fast and they can consume it on the go, we’ve hit the mark. I guess this is why most of them love the clouds which provide all the tools they need and unlimited resources. Of course, they also don’t see the bill that comes at the end of every month.

This is where Erik Sterck GmbH realized that we also need to change if we want to stay successful.

We needed to not only talk to the “infrastructure guys”, but also talk to the developers and understand what they want, how they operate and how we can make them more successful. Here we identified a very strong shift towards container-based development and application workloads as this provides the agility and speed developers were looking for.

This also meant once the container-based infrastructure is up and running, developers can just consume it without having to deal with the OS, hypervisor or infrastructure silos (cross-functional teams is also one of those new fancy words worth mentioning here). However, those silos suddenly had to deal with a completely new world — providing scaling, container-based infrastructure for developers and testers while keeping it secure, up to date and also maintaining all the new tooling required. This is completely different than what is required for the more traditional hypervisor / VM model and you can probably guess how many experienced people are available in this space.

This is where Erik Sterck GmbH comes in. We developed a strong partnership with Rancher Labs and used our existing partnership with Nutanix to release FramES 0.9, a Nutanix CALM based product to roll out Rancher HA clusters with just a click of a button (from a customer’s point of view anyway). We also developed our own internal “Rancher management container” to deal with day 2 operations like updating RKE or Rancher, all this to enable the more traditional teams and give them the tool to meet the new demands.

Once the Rancher HA cluster is deployed, we supported them in setting up templates, node and CSI drivers so they can roll out Kubernetes clusters as required. Pretty cool right? Kind of, we still saw a lot of manual processes and no one likes those, especially once the customer base grows. We needed to change our solution away from customer specific templates, frameworks with a vendor lock-in and static configurations, to a much more generic approach supporting all platforms and being completely controlled by variables.

This was the moment where FramES 1.0 was born, or at least the idea for it.

We all met up, locked the door and decided to find a solution that would solve all our current issues… after lots of good German bakery food, a Greek lunch and a few liters of coffee we came up with a way forward.

We decided to create our very own appliance. In doing so, we could reuse the existing components we liked and worked, while at the same time changing the parts with which we weren’t happy. The idea was to move away from the current framework and support multiple platforms using Terraform to remove management of multiple API sets and only worry about Terraform providers maintained by others – win, win! We created our own front- and backend running in containers. This makes the update process very simple. We slammed a setup Wizard on top of the appliance and off we went! Ha, I wish… writing your own appliance isn’t as easy as it sounds and it took a lot of testing with different customer environments before we had a stable 1.0 release, but we got there!

We are now using internal GitLab pipelines to build our FramES containers on code change and even build the appliance automatically on updates. The pipeline then publishes the new version on a web server to make it available for download. The appliance is also so generic that every customer can download the same version and the setup wizard does the rest of the configuration once the OVA file of the appliance has been imported. We even managed to add support for fancy things like proxies, root CAs, repositories, Docker registries and more. Once configured, all the magic happens by clicking “Launch FramES” and the customer can then configure SSH Keys and providers which dynamically load all the endpoint specific settings. A few more input fields, drop downs and clicks and the customer can roll out a fully functional Rancher HA cluster!

Hold on, it gets even better – Rancher clusters can be loaded and adjusted, and we also implemented Day 2 operations like RKE or Rancher updates, all by pressing a single button in the GUI.

We decided this wasn’t enough because nobody wants to manage OS templates for Rancher or Kubernetes nodes. I mean, why would you? Patching and logging into Linux are a thing of the past, right? We automatically load the latest Linux cloud image we’re using into the Nutanix Image Services or VMware content library which gets updated automatically via the appliance every other week (let’s not mention dark side environments… we preload the image onto the appliance, but the updating gets a bit more complicated here). This ensures all Kubernetes clusters use a standard image which is tested by a rather large community.

And here we are, FramES 1.0 is already running at two rather large customers and the next two have scheduled their install. Our roadmap… well let’s say it will most likely last us until mid-next year. We are working hard to stay ahead of the market and evolve FramES in a way to keep it unique.

It was also amazing to see how a small company can change from a reseller to suddenly creating and managing their own product. I would call this proper agility!

For more information, visit: https://www.eriksterck.de/it-infrastruktur/

Bio: Stefan Scharlott – DevOps & Automation Solution Architect

Linkedin: https://www.linkedin.com/in/stefan-scharlott-752b6440/

Stefan Scharlott has been working in the Open Source space for the last 20 years. He worked in NZ for IBM and Westpac and for Nutanix and Erik Sterck GmbH in Germany. His passion is with anything in the DevOps and Agile space or anything that has to do with automation, with the ultimate focus on making people more awesome, because they are the most important resource.