How to Create a Unified Container Strategy When Your Developers Have Gone Rogue
- August 26, 2020
If you’ve paid any attention to press releases or marketing from any major cloud vendor in the last year, you’ve noticed a major focus on multi-cloud capabilities. This is a significant new focus because modern enterprises leveraging container orchestration often have applications running in a number of different environments, and enterprises not yet at this stage often have a number of different infrastructure types to manage. Fortunately, there are options for IT teams to bring rogue developer teams under one umbrella in a way that’s both convenient and increases productivity.
No VP, CIO or leader of an IT organization wants to invest in technology to make developers' lives easier only to have them ignore it. So it’s critical to ensure your approach makes things easy for developers across business units. A lot of solutions offer some type of container orchestration, and depending on the maturity and diversity of an organization, you may have several different solutions which fit your needs.
Organizations looking at implementing enterprise-wide Kubernetes typically have a few requirements:
A few options for accomplishing a unified cloud strategy include Public Cloud, PaaS, DIY Open Source, and Open Source Container Management. Each has its advantages and disadvantages with regard to the five requirements:
We hope this has helped. Please get in touch with our team if you have more questions.
No VP, CIO or leader of an IT organization wants to invest in technology to make developers' lives easier only to have them ignore it. So it’s critical to ensure your approach makes things easy for developers across business units. A lot of solutions offer some type of container orchestration, and depending on the maturity and diversity of an organization, you may have several different solutions which fit your needs.
Organizations looking at implementing enterprise-wide Kubernetes typically have a few requirements:
- Flexibility: It is common for different business units to use different tooling for various aspects of their CI/CD pipeline. Enterprises should seek a platform that integrates seamlessly with most available tools for code creation, packaging, security and release. PaaS solutions seem convenient, but can be too opinionated, and force too much of an overhaul across diverse business units.
- Portability: Working with some PaaS or IaaS solutions can create a lock-in scenario where, although easy to manage in the near-term, an enterprise faces great costs should they change direction. Solutions like this can also box in individual business units who want to try different approaches.
- Ease of management: It is, of course, possible to leverage open-source technology to create an enterprise-wide pipeline that accomplishes flexibility and portability, but the complexity of management can create an expensive and time-consuming process to get systems up and running.
- Scalability: How easy is it to spin up multiple clusters across different teams? As you grow your presence within the cloud, this will absolutely be a necessity.
- Security: How secure is the platform, and how well does it facilitate compliance and demonstrability during audits?
A few options for accomplishing a unified cloud strategy include Public Cloud, PaaS, DIY Open Source, and Open Source Container Management. Each has its advantages and disadvantages with regard to the five requirements:
- Public Cloud: Public Cloud can be a great way to ensure your developers have a consistent platform experience, especially given the number of services and offerings available from each of the Big 3 public cloud providers. Developers are likely to find anything they could possibly need or want within a public cloud platform. So should you find that AWS, for example, has services which meet ALL of the developer, financial and regulatory requirements for your enterprise, this could be the way to go. Having said this, leveraging public clouds also creates some limitations, specifically in terms of giving your developers access to the best tooling for various use cases. It’s entirely possible, for example, that AWS might release better tooling for AI use cases one year, and Azure might have better tooling for Edge in the same year. If an adventurous developer uses her own credit card to purchase another platform for a specific service, it can be both expensive and time consuming to recreate infrastructure that was already available on the platform owned by central IT. This can also lead to unpleasant bills for application owners who receive unexpected (sometimes massive) expenses. Because of this, implementing strict cost controls is a requirement for budget-conscious enterprises on Public Clouds.
Public cloud scores high on Ease of Management and Security, but lower on Flexibility and Portability, and while it’s highly Scalable, this comes at a significant cost. - PaaS: For infrastructure teams trying to limit the amount that developer teams go off the grid, PaaS may seem on the surface like the best option, and for some use cases, it is. The advantage of using a PaaS solution revolves around the fact that developers are limited in terms of freedom of choice, and developer workflows can be tightly controlled by central IT.Problems arise with PaaS when you go beyond those convenient use cases, so it can be disadvantageous to limit flexibility of developer teams. A good example of this situation would be Edge use cases, which are very popular in the Telecommunications industry. It’s not typically possible to deploy platforms like Red Hat OpenShift on every edge cluster, and this can introduce inconsistencies between the platform and clusters. PaaS, like Public Cloud, scores highly on Ease of Management and Security, but will poorly on Portability and Flexibility.
- DIY Open-source: Kubernetes is an extremely flexible framework, and by now, more than 6 years after it’s inception, we have the advantage that it’s extremely hardened and reliable. Some enterprises opt for building and managing kubernetes in house, but this comes with inherent challenges as well. The Kubernetes ecosystem contains enough integrated tooling that enterprises need to have a devoted team, or experts on open-source, in order to stitch it all together. Even the simple process of provisioning a Kubernetes cluster for a specific development team can require significant experience on behalf of central IT. On the plus side, home-built Kubernetes gives you virtually unlimited flexibility and zero lock in, as long as you have expertise in house. Unlike the first two options, DIY Open-Source does not score so well on Ease of Management, but the Flexibility and Portability are virtually limitless. Security and Scalability depend on the set up you choose, and the capability of your in-house team.
- Open-source Container Management: If enterprises lean toward DIY open source options, it’s normally for cost reasons. Perhaps they already have capable IT teams in house with all (or most) of the skills they need, and the bandwidth to build and run an open-source platform.For enterprises who need to have a platform up and running quickly, or who don’t have the experience/bandwidth to stand up a platform themselves, leveraging a commercially provided framework provides all of the advantages of home-built, without the stress of building and managing a platform. Mirantis, as one example, has a K8s platform that is flexible and enables automated cluster deployment across AWS and Azure, OpenStack and Bare Metal, but in addition to this platform, also has a wide range of services, so that enterprises can choose how much control they would like to have for themselves.One common approach with enterprises leveraging such a framework is to have the platform managed by the provider for the first year or two, and as your internal capabilities increase, open-source platforms offer the advantage of easy management transfer to the customer.
We hope this has helped. Please get in touch with our team if you have more questions.
