ErikSterck - A DevOps Story

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 though. I think most people are aware of the shift that has been happening, away from hardware or even hypervisor-based focus to a more application based focus and suddenly everyone gets bombarded with terms like DevOps, DevSecOps, DevInsertSomethingElseOps, agile, lean and so on.. This all with the purpose to increase time to market and also shorten the time for feedback from the end customer, because that is where the money is, right? Selling applications people want while adapting to the market in a reasonable amount of time. With this the focus shifts more and more towards developers, to provide them with the tools they need and they don’t care about on what hardware or hypervisor the software runs on, as long as it is fast, and they can consume it on the go. I guess this is why most of them love the clouds, 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 realised that we also need to change if we want to stay successful, 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 they were looking for. This also meant that once the container-based infrastructure is up and running, they 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). This also meant that 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 maintain all the new tooling required for it. This is completely different to what is required for the more traditional hypervisor / VM model and you can probably guess how many experienced people are available in this space? (yes... stuff all) This is where Erik Sterck GmbH comes in, we managed to form a strong partnership with Rancher 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 therefore decided internally that we need change our solution, away from customer specific templates, frameworks with a vendor lock in and static configurations to a much more generic approach that supports all platform and can be 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 void all our current issues.. after lots of good Germany 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, there we could re-use the existing components we liked and worked, while at the same time change the parts, we weren’t happy with. The idea was to move away from the current framework and support multiple platforms using Terraform, this would also take away the management of multiple different APIs as we only have to worry about the Terraform Providers and they are maintained by others – win, win! We then created our own front- and backend which is running in containers, this makes the update process very simple, slammed a setup Wizard on top of the appliance and of 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, 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 it is configured all the magic happens by clicking “Launch FramES” and the customer can then configure SSH Keys and Providers who dynamically load all the endpoint specific settings. A few more input fields, drop downs and clicks and the customer is able to 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 the 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 ubuntu cloud image into the Nutanix Image Services or VMWare content library, this then 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 makes sure that 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 on the market. It was also amazing to see how a small company can change from a re-seller to suddenly creating and managing their own product, I would call this proper agility!