DevOps, DevOps & more DevOps – are you sick of hearing it yet? I’ve heard a few different definitions of this but at a high level I’d describe it as bringing together development environments, physical environments and processes to enable apps to be delivered quickly! … it’s containers that is facilitating this!
I won’t go into detail on what containers are here as there’s plenty of resources out there… When we think about the benefits that containers bring, we have app portability, we have consistent behavior, no need to troubleshoot environment issues, lightweight (enabling near instantaneous starting of apps compared to minutes with a VM) and greater efficiency (ability to run 5-10 times more containers than VM’s). All of this sounds amazing and truly enables business agility!
So containers solve everything right? Unfortunately not! As always there are always many considerations and some of those I’ve read/heard/discussed include:
- Security: I have read mixed reviews and comments on this, the concept of a container is inherently secure as they are isolated and logically separated (using Linux kernel features cgroups to logically isolate the resource and namespaces for process isolation) but at the time of writing this the Docker daemon requires root privileges which could have a significant security threat if not managed correctly as Docker can be used to share underlying system resources with any container without limiting the access rights meaning that it could then modify files or attributes of the host OS (for more info take a look at the Docker daemon attack surface section in this article: https://docs.docker.com/articles/security/
- Management & control: Containers provide all the control to a developer! Operations teams no longer have control over the environment and this isn’t going to work in an enterprise organization… Ops still need to know, manage and plan for resource requirements, have visibility of where apps are and what they are doing etc.
- Logging to support audit / compliance requirements: Although Docker supports logging it needs to be specifically enabled/configured which would means it may not be consistent across the whole environment (again also controlled by developers)
- Skillset: This technology although powerful is widening the skillset of a developer, potentially pulling them away from their core competency. As this technology is still relatively new in the market it can also be difficult to find enough resources with the required skillsets, or require significant investment in training.
This is where enterprise PaaS solutions (such as Pivotal Cloud Foundry) can help! It’s built using containers so will reap all the benefits of containers whilst providing control back to operations teams and removing the complexity from developers.
Of course a lot of the capabilities above have been developed within the opensource community but it’s still up to the developer to find, integrate & manage. There are also opensource tools for management (for example Mesos and Kubernetes) but I would describe this as ‘build your own PaaS’ requiring time and effort to set-up, integrate and support on an on-going basis. This is why enterprise PaaS solutions (such as PCF) are being adopted. Here is an example of some of the enterprise ready capabilities that PCF offers:
- Buildpacks: PCF will dynamically examine code and work out what runtime and middlewear is needed then build a secure container based on the content!
- Automatic scaling: Ability to monitor app performance and then automatically scale up and down (number of instances, memory)
- Dynamic routing and load balancing: If an instance were to go down, it will auto re-direct to a running instance to prevent any downtime
- Health: PCF will monitor the environment comparing the expected state to the actual state, in the event of a mismatch it will send alert and request for the controller to fix it!
- Services: It’s possible to provision data services such as Redis Cloud, ClearDB (MySQL) and many more! It’s also possible to have custom data services that might connect back to an on-premises database. It’s like an app-store where services can be requested and provisioned from within PCF GUI or CLI.
- Users and tenants: PCF uses RBAC (you can read more here)
- Logging and auditing: Centralized logging from apps and cloud foundry components, it’s also possible to drain these logs to a 3rd party log management system
- Security: Could write a whole post on this…! In a nutshell all components run on a VM which exists on a VLAN to automatically provide isolation, all internal traffic is over NAT meaning that we don’t have to expose a public route.
and much more… but I won’t go into everything here! All of this can be deployed and ran on a choice of IaaS stack including VMware, Openstack, Amazon EC2, Google and now Azure (currently in Beta), meaning there is no lock-in providing the opportunity to leverage cloud economics with the ability to very easily move to a different provider in the event of price changes. No code changes are required, simply stand up another PCF instance within another cloud provider and push apps here instead.
PaaS solutions won’t replace stand alone containers, this is because PaaS solutions require applications to be written in a cloud-native format (see 12 factor app) and not every app will meet these requirements meaning that organizations are likely to adopt both capabilities to support their wide range of workloads…
In a nutshell PaaS offers simplicity (hides complexity from developers and provides control to Ops) where as containers provides granular control and flexibility.