Managed Services vs PaaS: Pros and Cons
The cloud market is trending towards simplifying solutions for end users. The most compelling evidence is PaaS, estimated to experience a 20-30% revenue growth over the past year. However, it's not a panacea at the moment.
Today, cloud users are neither able nor willing to spend much time to deploy the necessary infrastructure for business tasks on their own. Many customers think of Platform as a Service (PaaS) as an out-of-the-box solution that will make all infrastructure problems simply disappear overnight. The truth is it doesn't really work that way for large business. Let's take a closer look at Kubernetes as a Service, a PaaS mostly requested by IT developers.
All key providers, CROC Cloud Services included, offer pre-installed Kubernetes for multi-container orchestration. The service is user-friendly indeed, as you need just three to five minutes before it's up and running in the cloud. There are some limits, though, particularly as regards the project scale and the depth of customization that customers crave. Due to its nature, PaaS provides the same capabilities for everyone, which means you can't just get into its brain and customize it anyway you like.
This brings us to a plethora of cases, when traditional cloud-based Kubernetes services can’t do the job or do it ineffectively:
- fine-tuning of the OS kernel or container runtime in line with international security standards such as OpenSCAP or CIS Benchmark
- installation of a CNI plugin that is different from the one offered by the cloud provider
- configuring the forwarding of internal traffic through an information security node (firewall, for example)
- setting up integrations with company’s external services or container environment security systems (technically, this is doable in PaaS, but often brings you nothing but pain and suffering)
- accessing master nodes to collect statistics and logs (usually, master nodes are not available for customers using PaaS, as they can access worker nodes only)
- customer simply cannot use public clouds, but at the same wants to enjoy Kubernetes as a service (yes, sometimes this happens as well)
Don't forget that if something fails in the cloud provider's PaaS, customers may often become a victim of circumstance, being unable to handle the problem beyond their control. The only thing to do is to wait until the provider recovers the service.
Quick recap: PaaS is a great concept and a service that has been growing exponentially to have less and less flaws with time. However, it's not a panacea at the moment. If you need a custom solution and complex integrations or have higher information security requirements, PaaS is probably not your best choice.
Does that mean that pre-installed Kubernetes won't actually work for most large businesses? Not at all. A Managed Kubernetes service is a way to have it out-of-the-box and customized at the same time, avoiding mundane infrastructure configuration. Naturally, it costs you more, because it requires additional expertise from the provider. Think of it as bespoke tailoring and mass market clothing. The product and its purpose are the same, but certain aspects – material, accessories, silhouette – are obviously different.
Managed Kubernetes based on a dedicated installation in the cloud gives you an opportunity to design an infrastructure like no other that satisfies every customer's requirement and desire for general functionality, security, and external integrations. This concept is provider-agnostic, and therefore customers are free to choose the solution best suited to their tasks, not necessarily being those out-of-the-box offerings. Moreover, Managed Kubernetes is more secure than pure PaaS as it can be fine-tuned in line with internal security requirements and regulations, whether it's bringing Kubernetes clusters into compliance with security standards (CIS, OpenSCAP, PCI/DSS) or implementing additional security measures as per Russian Federal Law on Personal Data (152-FZ). It can also be integration with specific security tools for containerized environments, such as Aqua Security and Prisma Cloud, or deployment of a firewall at the edge of Kubernetes and configuration of internal traffic forwarding. And having all the above at once is a pretty common case.
Key point here: working on such projects, the provider delivers documentation that the customer can rely on later if deciding to improve the infrastructure for IT development on its own. However, PaaS puts a limit on this, because infrastructure documentation will have to reflect every nuance of the provider's service. If the customer wants to change a PaaS provider in six months or even migrate the application to in-house Kubernetes, they will have to face fine-tuning problems.
General advice to those working with Kubernetes: if you need a standard service that can be deployed quickly, go for PaaS. If the project requires customization, security compliance, deep and fine integrations, and finally, a dedicated support team that you can always count on, get Managed PaaS from a trusted provider.
There is, however, another way. Only bold and confident will opt for this. You can deploy on-premise infrastructure and maintain it using your own effort, but all this will get more difficult every year, as the number of specialists you need skyrockets, while the quality of their training goes down. We have seen poorly optimized infrastructures, where it was much easier to build them from scratch than to fix, as well as DevOps engineers who didn't have full set of competences needed to keep end services up and running in a reliable and secure manner. We assume that as the service model evolves, such in-house IT development automation projects will become history, because recruiting and retaining relevant specialists will cost too much. In contrast, outsourcing of IT development will become even more popular.