Transitions to the Cloud

From on-premise software to ‘Software as a Service’

During the past decades, technology – both infrastructure and software – has evolved tremendously, guiding the information industry forward. As such, choosing the right way to run your application has become a challenge that you can solve by taking a multitude of factors into account.

Looking back at how it started, companies that develop and run software would host everything they had in a self-hosted environment. Then the concepts of IaaS, PaaS, and SaaS came along, which usually offered more beneficial solutions, and the general tendency has been to try and move applications towards them.

But now this brings us to the next step: what choices do you need to make and which one will bring your business the most value? We will try to cover some of the key aspects of this article.

 

The type of software

Before starting our analysis, we must consider several possibilities – specifically on the kind of software and how it is run.

Desktop applications installed directly on customers’ physical machines is one situation that we have encountered. The customer can only use the software from that desktop.

This raises another common problem; not only a client but also server-side applications need to be configured manually, which can imply additional costs when having to perform on-site installations. On the other hand, applications in a self-hosted environment can also have this problem if there’s no automated way of handling their configuration.

 

Moving to a hosting provider

The first natural step would be transitioning to a hosting provider, which comes with some cons:

• Healthy and secure infrastructure. Because hosting providers don’t offer IaaS in its pure form, maintaining the infrastructure will usually involve additional sets of tooling and time invested in keeping the infrastructure healthy from both operational and security perspectives.
• Scalability. A derivative from the IaaS standpoint is that scalability is harder to achieve as there are no automated ways to manipulate the hardware.
• Internal Tooling. You will need to work around what hosting providers don’t offer, and the internal tooling may start with “it’s just a small script” but will eventually lead to “we have too many code repositories for our internal stuff.”
• High Maintenance Costs. When it comes to costs, self-hosted environments come with a drawback: overcommitment of resources. Not only are resources wasted on too many machines being run in general, but without proper assessments, the tendency is to allocate more resources than needed to systems. On top of that, we also need to consider the time invested in internalizing tooling and maintenance.

 

Virtual Machines

Next in line in the infrastructure timeline is implementing an abstraction layer over the physical hardware, which is what data centers do. So, the natural transition means moving from physical to virtual machines. It will bring more simplicity, but in the end, it only reduces – just a bit – the fundamental problems of physical hardware.

Some data centers do implement ways to automate the provisioning / cleanup of hardware. While it provides advantages and gets you as close to IaaS as you can, it also means more development time to ensure compatibility between automation tools and the virtualization layer.

 

Where our customers got on their own

The need to automate processes has brought our customer base to achieve milestones on their own. While some of them managed to automate deployment processes through existing tooling, some also implemented their own internal tooling for this purpose. Others went on to automate the configuration process of virtual machines, but it all goes to show you that there isn’t anyone out there that managed to do it all and do it optimally.

 

Where we want to end up

As in the ideal world, everything would be fully automated. We are, therefore, the proud supporters of the IaC (Infrastructure as Code) concept. It perfectly satisfies the “pets versus cattle” metaphor where machines should not be treated as an individual but rather as a group that needs to fulfill a role in the architectural landscape. While the initial development time investment is relatively large, in the long run, it will drastically reduce maintenance time.

Companies often neglect configuration management, and it is also one of the most misunderstood topics. Companies often use configuration management software for other processes than for which it has been designed, such as automating deployment processes. If you do your configuration management correctly, you will apply alternatives for those processes not covered by configuration management software.

Since both IaC and Configuration Management turn your infrastructure into declarative code, it also needs to be tested. It is imperative at this stage to implement and have healthy CI/CD pipelines to automate every process within your infrastructure.

 

Clouds, Tools, and Conclusions

Moving away from self-hosted solutions or data centers that don’t provide IaaS means moving your data onto a Cloud. Be it public, private, or hybrid, there are scenarios you need to consider. Summarizing what we have so far:

• Hybrid Clouds – A mix of public cloud with on-premise is the best solution where you can’t just give up on the on-premise machines as they’re a key component in the architecture. While the public cloud has you covered in terms of automation tools and maintenance, tools like Puppet or Ansible can help with deployments and configuration management for machines outside the Cloud.
• Public Clouds – They provide a complete suite of tools and features to get your applications running, but they make it somewhat harder for you to switch providers unless you’re doing it right from the start! We used Terraform for provisioning our infrastructure, which brought us the flexibility of switching providers since it is compatible with all the major public cloud players on the market. On top of that, Terraform gives you the added value allowing you to write your own custom providers to integrate with other infrastructure providers as well. You do need to pay attention to the type of data in your application. From a legal standpoint, the situation may arise that a particular piece of information is not allowed to leave the borders of the country from which it originates. Since public clouds don’t have data centers in all the major countries (yet), this may be the critical turning point why you would opt out of using this type of service.
• Private Clouds – While private clouds don’t provide the automated tooling that public clouds do, they offer you the flexibility to choose amongst many. There are a number of tools you can use, and that work well with private clouds. If you are to transition to a public cloud – which is always a possibility – these tools can handle that with very little maintenance involved. Such tools could be Terraform for infrastructure provisioning or Kubernetes/Helm for container orchestration.

In conclusion, while there are many options available on the market to which you can turn, there are some providers that still need to adapt to the current trends. And while Clouds are on the rise, opting for the public, private, or hybrid Cloud becomes less of a choice. It mostly depends on how your application was designed to reach your customers.

By Alex Coman, DevOps Engineer