We decided to build our next-generation cloud platform using VMware Cloud Foundation (VCF) because when it comes to running enterprise-grade applications in both containerized and traditional formats, VCF is the industry’s most advanced and complete set of software-defined services for compute, storage, networking, security, and cloud management. Schuberg Philis is proud to be a VMware Cloud Verified Partner.
To better understand how VCF has enabled us to build a resilient, predictable, and secure hybrid-ready cloud, we interviewed our sbp.cloud tech leads Thijs van Leeuwen and Onno van den Berg. From their answers, we learn about how VCF helps drive our cloud’s success and, as a result, the success of our customers’ business.
Why did you choose VMware Cloud Foundation (VCF) as the framework for sbp.cloud?
Thijs: First, a bit of history: we have two decades of experience running private cloud solutions. When Schuberg Philis was founded, we designed dedicated customer environments with private racks and hardware. In 2014, we decided to build our own first mission-critical cloud (MCC), which allowed us to deliver services to our customers faster and more cost-effectively while still being able to offer the flexibility of both shared and dedicated environments. At the time, providing a private cloud for mission-critical applications was ahead of the tech curve. Whereas MCC was based on open-source software, in 2021, we decided to revamp our platform and move back toward VMware. So we began by gathering more knowledge about running mission-critical workloads. This knowledge was then translated into requirements, which marked the start of our selection process. And VMware met enough of those requirements – this vendor gives us all the tools we need to deliver our 100% promise to our customers and customer teams.
Onno: VCF allows us to deliver a resilient and flexible cloud solution, and we chose to use VCF for three main reasons. First, we wanted to focus on delivering more features and capabilities to our customers through standardized off-the-shelf solutions. This provides us with even more flexibility, security, and roadmap standardization while enabling us to deliver more value to our customer teams who manage the customer environments. We noticed a lot of teams who were spending a lot of time on infrastructural components that we really wanted to deliver as a service, which is possible through VCF combined with VMware Cloud Director. Second, we considered scaling knowledge and ability to both use and run the platform. VMware products are widely known across the IT market, which makes it easier to bring new colleagues up to speed. In addition, there is a large ecosystem of third-party solutions available, which makes it easier for us and our customer teams to implement new solutions or deliver integrations with other application stacks. Finally, our customers often already use VMware to run their workloads, thus making migrations simpler, less risky, faster, and with reduced lock-in.
Within the sbp.cloud team, how do you organize the work?
Thijs: We are all responsible for keeping our functional uptime at 100%. It’s not like we have separate departments responsible for the cabling and other departments responsible for network configuration. It’s a combined effort. Our single team runs and reruns it. There’s nobody in between to do these things outside of our cloud team. That’s how the network layer is set up. Within all seven OSI model layers, we have complete redundancy, predictability, and resiliency. I see it as playing chess on seven boards at once. If we change something in layer one, it could trigger a change in layer two, layer three, and maybe layer six or seven. Multidimensional chess players: that’s the mindset that we search for in the engineers we hire to build this kind of platform and keep our infrastructures predictable.
While it’s our responsibility to make sure the platform remains up and stays connected, we give the customer teams a playground environment. There they can autonomically choose how they want to build their environment and how they want to shape the journey for their customers. The customer teams decide how to fulfill the Schuberg Philis promise of 100% customer satisfaction. That platform is one our team has built based on desired state infrastructure and CI/CD, but then it’s up to the customer teams to use tooling and coding to build up their environment, network, VM, disks, and everything else. And why do we build everything based on code? By documenting the infrastructure in code we safeguard two important things: the desired state of our platform and predictability of our changes over multiple environments.
To what extent are the VMware products used in the solution off-the-shelf and/or customized?
Onno: VCF is a bundle of software products such as SDDC Manager, vCenter, ESXi, and NSX. On top of that, we leveraged a few more VMware products, such as an operational suite to do the monitoring of our VCF stack and underlying hardware components. Another off-the-shelf product we added is VMware Cloud Director, which is the cloud service delivery portal through which our customer teams can consume all services. We chose it because it is user-friendly and will have more features and capabilities being added over time. We customized it to a certain extent and gave our customer teams the tools to be able to autonomically build environments for our customers on top of our cloud. They can start spinning up VMs and do everything on their own.
How did you fulfill Schuberg Philis’ high security standards when incorporating VCF into sbp.cloud?
Thijs: We added a lot of segmentation at the network level to restrict all communication flows except for legitimate ones and to reduce risk. If something were ever compromised, the impact would be limited. This segmentation also creates a perimeter around each part of the stack running under sbp.cloud, and in doing so, we are in complete control of all data flows.
Onno: Everything we do needs to incorporate the Schuberg Philis security principles. So, we constantly monitor the score and fire a list of security measures on the systems that we use. Those measures make sure nothing gets compromised, but if ever it were to be, then at least we would know and be able to trace.
How does a third datacenter location fit into the VCF framework?
Onno: VCF is built on a standard VMware Validated Design architecture, thereby ensuring quick repeatable deployments while mitigating the risk of misconfigurations. The standard VCF designs allow two availability zones, but we got VMware to sign off on our design with three. The first two availability zones are meant for active customer workloads and the third zone is the witness zone that we use in case any failure should happen in one of the two datacenters. N + 1 redundancy is not enough for our customers. So, we use N + 2.
Thijs: In fact, we simulate these failures while performing maintenance. Generally, people believe in the framework they use and manage and assume that the cloud will most likely work. But that’s not good enough for us. On receiving a maintenance announcement, we go right into the datacenter and say: “Let’s do the maintenance now. Pull out the power! Release the brakes!” In a non-drill scenario, that would be horrible. But doing this gives us time to learn about and fix any issues. Again, that’s our mindset. We actually try to break stuff to ensure that our customers’ workloads will not be impacted. And we do this quite often. So, in the end, we make everything predictable and leave nothing to chance.
Want help managing your mission-critical assets? Read more content in our series about sbp.cloud or get in touch.
