Get In Touch
Menu
Get In Touch

It's all Linux

Dec 22, 2020 1:10:08 PM

From hardware to cloud: a story of IT evolution

The IT landscape has evolved significantly over the past decades. Local physical servers were migrated to local virtual machines, and later became locally clustered hypervisor infrastructures. Businesses formed providing hosted virtual machines, which isolated users from hardware. Some of these businesses grew into providing compute and other services of an entire datacentre in a global shared infrastructure which we now know as “the cloud”.

Most IT systems at present have a mix of systems and applications, from on-prem physical and virtual machines to cloud-hosted solutions using VMs, containers and serverless.

Click here to read how you can convert your RHEL-like systems to RHEL 

Traditionally, application services ran locally on one server, or across two in active-standby mode. Eventually, these were clustered and were then virtualised into operating system-level containers. These containers are now being orchestrated while running on physical, local virtual or cloud infrastructure.

The chances are that your IT environment has now become a mixture of the above; some (potential legacy) physical systems, one or more locally hosted physical hypervisors running various guests, some systems in the cloud, and maybe some containers running on top of them all. Maintaining consistency across mixed environments may seem like a daunting task.

Linux hasn’t changed

However, when it comes to Linux based systems, I would like to argue that the core principles of a well-maintained Linux infrastructure haven’t changed. They still apply to any of these systems across these platforms, since configuration management and automation can be applied in the same way – primarily because of one thing - it’s all Linux.

Linux infrastructures still use the same base OS, libraries and system resources, these have simply been abstracted to different layers. It doesn’t matter if you are running Linux services on physical systems, Virtual Machine Guests, KVM/Xen Hypervisors, AWS, CentOS, RHEL, Machine Images for cloud providers, Docker Containers, or Kubernetes… it’s still Linux under the hood. Here again, the fundamentals to maintain your infrastructure remain the same and can be applied in a consistent fashion across your environment.

For example, you still want consistent patching applied across your environments. And so the list goes on. Consistent application configurations. Consistent remote logging across all environments. Consistent security standards (e.g. hardening and credential management) across all servers. Consistent application health monitoring regardless of where the application is hosted, etc.

Admittedly, machine images in the cloud require a different setup to VM templates on a hypervisor, or to a kickstarted physical server, for example. But it is just that: a slightly different Linux system configuration. Nothing more. The base OS configuration and setup is much the same regardless of being physical, VM or cloud image. Fortunately, automation toolkits are already widely available to enable you to do this easily. More importantly, these tools can be applied across any Linux environment regardless of where your Linux systems and services run.

Maintaining consistency

So with this in mind – what is an easy way to apply consistency across our systems in different environments while still being able to customize some specific parts?

How can we ensure that for example our security configuration baseline is the same across any Linux system regardless of where it runs? How can we easily build, rebuild and potentially even migrate systems and services without re-inventing the entire process?

It all starts off with a Configuration Management (CM) tool like for example Ansible or Puppet. It is necessary to keep your system, service deployments and configuration consistent, to establish your security baseline and to enable you to quickly rebuild a system. Configuration management can be applied across physical, local VMs, cloud-managed pets, and in the build process for containers and system images / templates (golden images).

This configuration management code can be reused in different environments to achieve consistency with slight customisations where necessary:

  • To manage single servers or VMs, CM tools like Ansible or Puppet can help you establish a consistent configuration for services, a security baseline and general settings.
  • To employ golden images or Virtual Machine templates, for example in your VMware farm, CM tools in combination with Packer will create, deploy and configure these for you to establish new systems within minutes – pre-configured, ready to use, with the same settings you applied to existing systems baked in by default.
  • To create customised machine images in the cloud, use Ansible and Packer together.
  • Your entire infrastructure as code can be deployed using tools like Terraform. It can make use of the golden images/templates from above to build an entire consistent infrastructure within minutes – reusing the same configuration baseline with minor environment-specific changes where required.
  • And for containers, Ansible will automatically configure, deploy and orchestrate these for you to the physical machines you manage, to the VM templates you created, or to the cloud images you deployed.

From here, the possibilities are endless. You can consider automated patching, security audits and hardening, deployment of monitoring systems and version control for starters, etc.

In the end, it’s all Linux.

Learn more about OSS Group Managed Services

You May Also Like

These Stories on Platforms

Subscribe by Email

No Comments Yet

Let us know what you think