3 DevOps Strategies to Consider Now – InApps is an article under the topic Devops Many of you are most interested in today !! Today, let’s InApps.net learn 3 DevOps Strategies to Consider Now – InApps in today’s post !
Read more about 3 DevOps Strategies to Consider Now – InApps at Wikipedia
You can find content about 3 DevOps Strategies to Consider Now – InApps from the Wikipedia website
Henrik is Shipa’s COO. He’s a serial enterprise software entrepreneur, with four successful exits, including two to VMware.
After the rush to take advantage of cloud native application development and tools like Kubernetes, DevOps teams now have a lot more to think about. In many cases, DevOps adopted early continuous integration/continuous deployment (CI/CD) pipeline tools such as Jenkins, and are now attempting to apply them in cloud native scenarios where they aren’t the appropriate fit they once were. Cloud native pulls the developer down to infrastructure-related operations, and the current CD tools cannot help bring back the application-level context that developers once had before moving to a microservices architecture, hence, adding more complexity to the development workflow and observability of applications post-deployment. DevOps teams also face new challenges in application policy management, especially so in closely regulated industries, as they adapt their processes to establish trust and security in cloud native environments. At the same time, DevOps needs to reevaluate approaches to automation and strategies for eliminating human error, as cloud and Kubernetes deployments have ushered in a return of very manual and tedious efforts.
Here are three areas where DevOps must carefully consider their strategies, sooner rather than later, to prepare for a cloud native 2.0 future that enables cloud native environments to be wielded more efficiently and effectively.
1. CI/CD with Greater Interoperability and Composability
In a cloud native 2.0 context, selecting and implementing CI/CD tools has become more interesting considering the ever-broadening range of options now available. But it’s also a strategic challenge (or headache, depending on your perspective). Some tools provide advantages far to the left in the development pipeline, others to the right. From CI to CD to release automation (RA), DevOps teams need to examine potential tools and how they can be pieced together to assemble an elegant and harmonious pipeline. Unfortunately, as many DevOps teams well know, this is easier said than done. Some end-to-end solutions may also bring lock-in and other undesirable aspects with them, while some best-of-breed piecemeal solutions may not play well with each other.
It’s my hope and prediction that greater interoperability will emerge in the near future as part of cloud native 2.0, to the degree that CI, CD, RA, and even solutions for governance and compliance, are simply plug-and-play. At that point, DevOps will be able to choose the best-fitting solution for a particular need, and then it will just work.
For now, while we wait for that plug-and-play nirvana to arrive, composability is a crucially important aspect that DevOps should look for in solutions going forward. That ability for pipeline components to easily interact simplifies countless use cases as well as critical security and compliance issues. Enforcing policy-driven restrictions across a cloud native pipeline calls for a DevOps tool chain that can bring broad composability. Fortunately, many CI/CD systems do a good job of allowing extensions and plugins to make composability across the pipeline a reality.
2. Harness Application Policy Management
Policies must be in place across the application development and deployment lifecycle to ensure that important security and governance rules are followed. No step can be skipped that could introduce vulnerabilities. For DevOps teams working in cloud native environments, implementing these policies is made all the more difficult by the high complexity of Kubernetes and its alternatives.
As a strategy, DevOps should leverage tooling and frameworks that both 1) insulate developers from Kubernetes complexity and 2) protect them from risks. For example, if you deploy a build image to a Docker repository such as Docker Hub, it includes tools to detect and report vulnerabilities and other security failures. Internal source code scans can recognize vulnerabilities in pull requests. Tooling should enable collaboration and the sharing of crucial knowledge across teams as well. Structurally, it’s wise to embed DevSecOps in with the development team, to address security issues as part of your regular processes.
With adjacent DevSecOps and tools able to abstract away challenges like generating Kubernetes objects and maintaining the environment, developers can focus on code and solving business problems. That’s what they want to do, and that’s what they’re there for. Tools with powerful application frameworks should also be used to define and enforce DevSecOps-controlled policies that automatically disallow dangerous activities and errors. With the right application policy management framework, if a developer mistakenly tries to deploy a tainted image, they’re simply prevented from doing so. Such frameworks can impose security policies and resource limitations, enable or disable security scans, govern whether CVEs are flagged or ignored, and control team access to Kubernetes and services across the cloud native environment.
3. Balance Automation and Audits
Human errors in application development can equal lost productivity, at best. Usually the bigger concern is the increased security and compliance risk. Automation and audits have an interesting relationship: Automation reduces human errors, while audits allow humans to address errors made by automation.
Somewhat ironically, cloud native environments have precipitated a return to very manual processes, making new automation all the more essential for developer productivity. For example, raw Kubernetes with its Helm charts and YAML files requires significant scripting and manual effort to deploy. (In my own experience with Kubernetes, I believe that if I had to put a dollar in a jar every time I made a mistake writing YAML files, I’d … well, I’d have gone through a few jars. It was frustrations like these that led to the founding of Shipa.) Automation that abstracts away the nuts and bolts of Kubernetes that developers don’t care about is very welcome.
Automation is most appropriate for repeatable tasks that yield expected results, such as scans for security issues, checking that code uses safe and verified libraries, and so on. That said, auditing is crucial for empowering the human element. Effective automation isn’t set-it-and-forget-it automatic — it requires oversight and maintenance. For example, an automated system may flag CVEs that are actually harmless, requiring human judgement to refine the system. It’s entirely possible to automate bad processes that can’t be trusted and so ultimately only create more issues. The right strategy is to first develop manual systems worthy of trust, then automate as appropriate.
By leveraging composable CI/CD solutions and prudent policies to automate secure and simplified application development, DevOps can minimize the challenges of cloud native environments while enabling developer creativity and productivity to flourish.
InApps is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Docker.
Feature image via Pixabay.
Let’s create the next big thing together!
Coming together is a beginning. Keeping together is progress. Working together is success.