We continue with the essay on comparison of Kubernetes with platform as a service framework. Kubernetes requires applications to conform to its model. Most of the applications can be leaner on a container framework than on a PaaS platform because they can focus on business logic while assuming additional functionalities to be provisioned via optional plug-ins. Containers are cheaper and faster to spin up and these are sometimes necessary considerations for auto-scaling and load balancing.
Writing APIs is a breeze if we have the framework already. We can just publish, manage, secure and analyze our APIs in minutes. We secure the API with Active Directory, single sign-on and OAuth and generate client-proxies or APIs in the language of our choice. Similarly enterprise API can be mashed up and integrated with API management and Logic Apps. Both PaaS and container framework provide the ability to write these API but deployers prefer one over the other when their deployments have to span clouds.
Both applications and services can take benefits of CloudFoundry and PaaS. They are not restricted to the same physical machine that they were once deployed on. With these software, the applications and services can be rolled from one host to another seamlessly without any loss of functionality. They don't require any updates either to code or configuration when they are rolled between hosts.
API software usually exposes an http/https endpoint and port for connectivity. While it may involve authentication, encryption and use of api-keys, all of these are done over basic authentication scheme or OAuth, they are contained to api implementations and external service consolidators such as a gateway. A user interface on the other hand may have to integrate with an identity provider and authentication mechanism such as SAML or OAuth external and probably central to an organization and not necessarily within the control of the applications and services framework. Fortunately these are facilitated with a route from the PaaS. The application merely has to handle the redirects from the said authentication mechanisms and the redirects are to specific name:port that can be ported between PaaS hosts as routes. The external ip address of the host and port can be retrieved in code as CF_INSTANCE_ADDR and CF_INSTANCE_PORT
PaaS may be called out as being restrictive to applications, dictating choice of application frameworks, restricting supported language runtimes and distinguishing apps from services. Kubernetes, on the other hand, aims to support an extremely diverse variety of workloads. As long as the application has been compiled to run in a container, it will work with Kubernetes. PaaS provides databases, message bus, cluster storage systems but those can run on Kubernetes. There is also no click to deploy service marketplace. Kubernetes does not build user code or deploy it. However it facilitates CI workflows to run on it.
We also have integration with Open-stack for linux containers. The plugin allows the hosts to be compute nodes while the container takes on the workloads from the user.
Writing APIs is a breeze if we have the framework already. We can just publish, manage, secure and analyze our APIs in minutes. We secure the API with Active Directory, single sign-on and OAuth and generate client-proxies or APIs in the language of our choice. Similarly enterprise API can be mashed up and integrated with API management and Logic Apps. Both PaaS and container framework provide the ability to write these API but deployers prefer one over the other when their deployments have to span clouds.
Both applications and services can take benefits of CloudFoundry and PaaS. They are not restricted to the same physical machine that they were once deployed on. With these software, the applications and services can be rolled from one host to another seamlessly without any loss of functionality. They don't require any updates either to code or configuration when they are rolled between hosts.
API software usually exposes an http/https endpoint and port for connectivity. While it may involve authentication, encryption and use of api-keys, all of these are done over basic authentication scheme or OAuth, they are contained to api implementations and external service consolidators such as a gateway. A user interface on the other hand may have to integrate with an identity provider and authentication mechanism such as SAML or OAuth external and probably central to an organization and not necessarily within the control of the applications and services framework. Fortunately these are facilitated with a route from the PaaS. The application merely has to handle the redirects from the said authentication mechanisms and the redirects are to specific name:port that can be ported between PaaS hosts as routes. The external ip address of the host and port can be retrieved in code as CF_INSTANCE_ADDR and CF_INSTANCE_PORT
PaaS may be called out as being restrictive to applications, dictating choice of application frameworks, restricting supported language runtimes and distinguishing apps from services. Kubernetes, on the other hand, aims to support an extremely diverse variety of workloads. As long as the application has been compiled to run in a container, it will work with Kubernetes. PaaS provides databases, message bus, cluster storage systems but those can run on Kubernetes. There is also no click to deploy service marketplace. Kubernetes does not build user code or deploy it. However it facilitates CI workflows to run on it.
We also have integration with Open-stack for linux containers. The plugin allows the hosts to be compute nodes while the container takes on the workloads from the user.
No comments:
Post a Comment