To achieve such a requirement there were plenty of tools on the table, like Openshift, like VMware, HyperV, etc. But all of those were limited in one way or another and Visma understood that the platform must be able to provide as much as possible different services, products and options. And also be as much as possible technology advanced, which could help for old or more conservative teams move more easily into DevOps and Cloud based thinking.
Therefore Azure Stack Hub was chosen. It brings compute capabilities, like Virtual Machines, Storage, Network options like VMware or AKS, Containers and ACR registries like Openshift and much more which can’t be brought from any of others. All these services can run in your DC, and be fully connected or disconnected from the internet and act like your small private Azure Cloud where you have full control on your data. Of course it can’t bring all the possible services you can find on Public Azure, but it brings main and we have possibilities to add our own custom services, like DBaaS running on MS SQL or MySQL servers or Rubrik for backup solutions, or AppServices running on infrastructure we create to support for it.
It would seem that having Azure Stack Hub in your DC is so easy, because it comes as an Appliance built on partner rented hardware and you have just minimal options to change something or operate it as administrator. But challenges come when you understand that it is just another configuration item in our big organisation and must have all the proper relationships and integrations with existing services, like AAD, Centralised logging systems, networks, backups, VMware infrastructure, monitoring tools like SCOM, JIRA and billing (and something we forgot to mention).
Although Microsoft prepared this product very well and most routes for standard integrations are open and clear, through specific tools and APIs. Difficult times come because Visma is not just a standard 🙂 Visma use their own created billing system, like myit and we are running many different teams with their project on Azure Stack Hub with their own cost centres, R2 codes. So we need to manage that, split costs, cover maintenance expenses, allocate resources and be as much as possible transparent and granular for our customers so they can see the full picture and be able to better plan and save if needed . So just having an API in place does not solve all these issues. But when you have a challenge and a need you solve it and now we are fully integrated, our teams can see their expenses per resource in our billing system.
A similar example can be a backup solution. Although if you run your environment DevOps way, like having infrastructure as a code you don’t necessarily need old fashion backups 😉 But some teams are just starting that journey, so backup is an essential thing in their environment. And here we have options, like use Azure Backups (which is obvious most of our teams don’t want to), build dedicated solution inside Azure Stack Hub customer subscription, buy Azure Stack Hub supported backup solutions or somehow integrate what we already have and use in Visma – Rubrik. So with a small baby steps we are moving that way and already have basic solutions for VM data backups. This allows us not just to save money, by not buying new tools, but also allows us to use tools our customers already know.
These are just two short examples (because more paper is needed to write a whole story) of what kind of interesting journey we have together with Azure Stack Hub in Visma.
Not everything is perfect, but we love challenges and we are moving forward to expand the usage of Visma Private Cloud Azure service to our customers and their specific needs.
