Building a fully managed service on Kubernetes

Consider a team working on a new cloud product, say, a complex B2B application that aims to help enterprises operate more efficiently. Kubernetes would be an ideal choice for deploying and managing the core application business logic.

Arthur Berezin

By ARTHUR BEREZIN

Launching a new software product requires a lot of research, planning, and decision making. Product managers have to decide what runtime platform, and deployment strategies to employ.

Consider a team working on a new cloud product, say, a complex B2B application that aims to help enterprises operate more efficiently. Kubernetes would be an ideal choice for deploying and managing the core application business logic.

Kubernetes is open-source container management and orchestration tool that was originally created by Google. It is now part of the Cloud Native Computing Foundation(CNCF). Kubernetes provides a unified API surface that allows developers to manage, scale, and deploy applications on cloud resources.

Kubernetes offers a number of benefits including improved scalability, faster development and deployment, lower IT infrastructure costs, multi-cloud flexibility, and improved availability.

Kubernetes offers a number of benefits including improved scalability, faster development and deployment, lower IT infrastructure costs, multi-cloud flexibility, and improved availability.

cloud-native

Architecture: Shared vs Isolated

Next, the product manager or the architect of the project will have to decide on what type of architecture to utilize. There are a few options to consider, and two common design patterns to choose from: a shared architecture or an isolated architecture.

In a shared architecture, single application runtime and database is used to serve multiple tenants. Shared architecture, also known as multi-tenancy at the software level, is often used when developing B2C products with lots of users. It’s a very cost-effective approach when dealing with multiple tenants but it’s also less secure than the isolated architecture.

An isolated or multi-instance multi-tenancy architecture is one where each tenant gets a dedicated instance of the software in an isolated environment. Here, every customer’s data and resources are isolated in a container. As a result, an isolated architecture offers more robust security than a shared architecture.

A third option is the hybrid model, where some services are shared across multiple tenants while others are isolated and deployed per customer. Of course, the type of architecture chosen will depend on and influence the complexity, size, and implementation of the application being built.

multi-tenancy

Kubernetes namespaces can be used for segregation between tenants in multi-instance multi-tenancy. Namespaces are used to implement isolation and divide cluster resources in environments with multiple tenants.

Namespaces provide the scope for names of pods, services, and deployments in a cluster. They’re also used to assign network policies to pods contained in the cluster.

In Kubernetes, pods are non-isolated by default. Thus, they can receive connections from other pods in the cluster. To isolate a pod, you’ll need to configure and define network policies.

Network policies are specifications that define how pods and groups of pods are permitted to communicate with each other. These policies are used to prevent network traffic between namespaces.

Database: Managed vs Self-Hosted

When it comes to databases, you could choose to host the database on your own or utilize a managed database service such as AWS DynamoDB, Microsoft Azure Cloud SQL, and Google’s Cloud SQL.

Of course, each approach has its pros and cons. Managed databases, for example, have a lot of features that make getting a database up and running much easier and faster. You can set up and configure a managed database in just a few minutes.

Automation is also a strong point of managed databases. Administrative tasks such as creating backups, running migrations, scaling, and performing updates are all handled in an automated manner.

Cloud-based database solutions are also more easily scalable than self-hosted ones. If you expect rapid growth in the number of customers using your service or see a lot of seasonal variation in usage, a cloud-based managed database is the better option. You can scale up on demand and scale down just as easily.

When it comes to security, most cloud providers offer very high levels of security protection. Such levels of security are often quite expensive and more complex to implement if you choose to go with a self-hosted database.

Nonetheless, there are still legitimate concerns to be had. Many organizations prefer the greater level of control that self-hosted databases provide. Others worry about the risk of a data breach leading to the loss of sensitive data.

Fully Managed Service Back-Office, Logging, Monitoring

Once you’ve decided on your deployment system, architecture, and database, you’ll need the means to manage important behind-the-scenes operations such as billing and subscription management.

Managing SaaS

You would also need a custom stack for monitoring and logging. Monitoring logs is essential for understanding what’s going on in your application’s backend. This will make it easier for developers to troubleshoot and rectify any issues that may arise while the program is running.

JovianX is a cloud application platform for SaaS applications that enables you to easily build and manage your SaaS product. JovianX provides SaaS back-office management services including Cloud Management, Subscription Management, Monitoring and Logging, Application Life-cycle Management, among others. JovianX is the ideal platform for companies looking to build and manage SaaS offerings in a quick and efficient manner.

Spread the word

Share on linkedin
Share on twitter
Share on whatsapp
Share on facebook

Get started with JovianX Platform Today

Self-service of your app is a click away