Home Audience Developers Six Things to Consider for a DevOps Transformation to the Cloud

Six Things to Consider for a DevOps Transformation to the Cloud

0
4547

The COVID-19 reality has pushed the market towards faster adoption of remote access to IT by developers. Software vendors are therefore in a race to enable and expand cloud DevOps solutions. Increasingly, teams seek to adopt end-to-end DevOps platforms or tool bundles that decrease their reliance on multiple vendors and give them ownership of the tooling infrastructure. But what should an enterprise demand from cloud DevOps tooling, and what key differentiators should be considered?

Here are six things one should consider when engaging with any individual vendor for a DevOps digital transformation to the cloud.

End-to-end (E2E) solutions
Developers today are looking for an E2E solution and an all-in-one user experience. However this doesn’t mean that they will compromise on the ‘best of breed’ approach. Therefore, DevOps platform providers should offer a Class A tool stack as part of their platform, in addition to very strong ecosystem integrations and plugins to make developers’ lives easier, respecting the freedom of choice they want.

An E2E platform also requires a vendor commitment to allow a true ‘one-browser solution’ and not simply bundled tools that are integrated. This ensures that the user will have a full experience from a single UI that connects all services.

Universal package management
All of the metadata and dependencies in your myriad technologies must be supported (such as Docker, npm, Maven, PyPi, Golang, NuGet, Conan, etc – but also the 20+ more that you may find in your portfolios). Point solutions for single or limited technology types will only serve to frustrate your development teams and require the adoption of multiple solutions and repositories within your organisation. Large enterprises have not only myriad technologies, but also a long legacy of deployed, mission-critical applications that must be supported at scale with local, remote and virtual repositories.

Figure 1: Comparing cloud based end-to-end DevOps solutions

Both cloud and on-premise solutions need to be integrated 100 per cent
This isn’t about whether or not to have a cloud solution. Many companies that offer cloud solutions don’t have corresponding on-premise/self-hosted options, or vice-versa. More still have completely separate solutions that provide different features and methods that don’t talk to each other, requiring you to learn a new product, user experience and user interface. As you transition to a cloud environment, both cloud and on-premise solutions need to be able to function in the same way 100 per cent of the time to ensure a smooth transition. For instance, as you go through a cloud migration, you will need the same tools and functions in both places in order to keep the business running.

Multi-cloud
While you might think one cloud is enough, you should select a vendor that provides services across and between all major clouds. Keep your options open and your peace of mind intact by avoiding any vendor lock-in and providing maximum resilience.

Security
Security is an integrated part of the pipeline that supports all of your package types and it is now a line-item for many companies. Cloud DevSecOps tools should make it possible to block artifact downloads (or break builds) that contain vulnerabilities, requiring tight integration all the way into the repository. Security policies should be easy to define and manage across your repositories. And any cloud security solution should allow you to easily identify the impact of a vulnerability across the entire DevOps pipeline.

The world of containers also comes with a challenge. Your DevSecOps tools should be able to ‘open’ any container and scan several tiers in, and with all packages look for dependencies that include vulnerabilities.

A DevOps platform should always strive to be ahead of any hacker and secure all software packages in the pipeline from build-to-production.

Cloud-ready CI/CD
Traditionally, application development teams were responsible for creating localised CI/CD (continuous integration/continuous delivery) automation. This approach provides short-term gains for the individual teams but ends up being a constraint in the long run since enterprises get no economies of scale across their CI/CD implementations.

A modern CI/CD provider should support and scale enterprise-wide workflows (aka the ‘software supply chain’) that span all popular technologies and architectures of today as well as keep pace with technology evolution. It should provide a way to assemble pipelines from pre-packaged building blocks, rather than developing them from scratch. These pipelines can be templatised and shared as libraries across the organisation, thereby building a knowledge base that is constantly growing and improving. In other words, your CI/CD provider should give you economies of scale over time in the cloud, and help you ship code faster.

NO COMMENTS

LEAVE A REPLY

Please enter your comment!
Please enter your name here