Jun 01, 2022
Jun 01, 2022|
4 min read
The first step to understanding includes taking a little detour to the “way things used to be.”
In the past few decades, with legacy hosting, all sites and apps were clustered together over the same underlying software. This meant that most sites - whether it was 5 or 50 - ran on the same software. So multiple sites depended on the exact same underlying infrastructure. For those who still use legacy hosting methods, this is still the case.
This doesn’t sound so bad - until it’s time to make a change or update to ONE site, but not all 15. It’s hard (or nearly impossible) to make changes or updates to just one site independently from the rest. As a result, most sites just generally wouldn’t be updated - because all the other sites would suffer outages and have to come down during the process. Because every single site is so tightly linked with one another, treating them as individuals was very complex.
Here’s why: All sites on one server would need to run the exact same version of PHP. To customize a setup that’s specific for one site under one set of all-encompassing infrastructure is basically impossible, using legacy hosting. It could technically be done, but it would take an enormous amount of effort and probably wouldn’t be worth it.
For a large organization like a university, trying to manage and oversee 500 individual sites, you can see why this would cause a massive headache.
When companies end up with one server that hosts too many sites, there's an enormous amount of risk involved with relatively benign processes like operating system updates and software updates. The coupled risk in these situations could impact every single site on the shared server.
Containerized applications were created specifically to solve this problem - keeping sites separate from one another, and making the updating process so much easier- because sites and apps can be treated as independent from one another. Frequent updates and proper versioning can occur with absolutely no risk to any other sites or apps since they are treated as individuals.
Containerized applications are actually firewalled from each other for easier container updating. Even if hundreds of different sites are running on the same infrastructure, it’s easy to make updates because the containers can be kept independently, and treated like individual properties when it comes to updates. Gone is that risk of accidentally impacting several other sites when you just meant to update one.
Everything an app needs is wrapped into its individual container, which creates an entirely unique environment within individual containers. A much higher level of customization is possible with containers vs. legacy hosting.
With containers, everything is much more automatable, and the risks of running different apps on shared infrastructure are minimized. In fact, it becomes far more possible and feasible to do so.
Containers are an obvious solution to the “problems of the past” (aka legacy hosting). In order to build a really successful WebOps approach, automation is a necessary component for building, testing, and deploying an application. And without containers, it’s very close to impossible.
A container orchestration system like Kubernetes makes it even easier to work with containerized hosting. We highly recommend both for any solid WebOps strategy.
Containers allow for an insane amount of flexibility and versatility, and they enable many of the core principles of WebOps - like automation (which really is impossible with legacy hosting). Containers also help keep companies from overspending on infrastructure.
Sites can be independently risk-managed - whereas with the “old way,” there was a necessary coupling of risk.
A problem that many organizations encounter with legacy hosting is the ability to scale: there are many things that just cannot be scaled with legacy hosting, like automation and application flexibility. Containers enable the ability to scale the way that companies want to by creating a functionality where that is possible.
And, as we mentioned, a container orchestration system like Kubernetes can provide the framework to automate your containers and manage all of their life cycles. Kubernetes makes sure that all applications run consistently in cloud environments by automating critical tasks, like deploying, scaling, load building, and more.
Kubernetes is made more possible and accessible to use when it’s a managed service, like amazee.io’s Dedicated Cloud offering.
Our team of Kubernetes experts manages thousands of workloads on Kubernetes clusters - it's truly where we excel.
If you’re interested in learning more about how containerized hosting and Kubernetes could work for your team, start a conversation with us. We’d love to hear from you.