The importance of a robust DevOps solution
IBM DataPower leverages over 20 years of innovation and it's battle-tested in mission-critical environments to provide the most resilient, feature-rich, performant, and secure gateway platform in the market. Today, IBM presents a deep dive with DataPower expert, Andrew White.
Andrew White is an engineer for Worldwide Solution Engineering - IBM Technology Expert Labs. He works with a wide range of multinational companies designing, developing and deploying complex integration scenarios to meet their performance and security needs. Andrew is an IBM DataPower expert through his in-depth knowledge of API security along with the design and development of continuously available systems.
Let’s get started!
What are some of the most common DevOps activities in a DataPower project?
Build, package, test, and deployment! There are a few approaches you can take to implement these with regards to granularity of what to build. Typically the approach you take will depend on the target production environment.
How do you approach a DataPower project that needs to implement DevOps?
Usually it’s working out what your production system looks like and then working back to see how that affects your build and deploy process. I work with customers who often have diverse deployments of DataPower, while the high level steps will be similar in all projects (develop, build, test, deploy), how you implement them will depend on the environment. After that its usually about fitting the approach into the DevOps tooling the customer prefers.
Can you explain the “Shift left to reduce failure” concept in DevOps/GitOps in a DataPower project?
In this case DataPower is like any component of your architecture, adopting DevOps/GitOps should move your build, test,and deploy processes earlier in the development cycle (“left”) and make it more repeatable (and reusable) through automating those processes. The quicker you get to the testing of both your application and of your deployment processes, the quicker you identify bugs, which lowers to costs of fixing them. In my experience one of the things clients miss when automating deployments of DataPower is the externalisation of environment specifics settings (e.g. signing keys for tokens or payloads) and the sooner you find that the faster it can be fixed
How has DevOps changed with the move to container based deployments?
Before, you’d typically be building a package and externalizing all environment specific artifacts (hostnames, keys, certificates etc) and then be deploying them targeting a specific appliance. Now, your build process is likely to output oneor more config maps which are then applied to the DataPower container during deployment and externalizing cryptographic artifacts into secrets.
Why has GitOps gained prominence over the last few years?
DevOps grew in popularity because it fits so well with Agile which exploded in popularity. GitHub has gained mass adoption in the enterprise as a source code repository. When you bring those two things together you can see how GitOps has gained in prominence.
What are the anti-patterns of DevOps and/or GitOps?
Manual intervention- it’s very easy for DataPower developers and administrators to think “I’ll just tweak that parameter by hand”, but you are breaking one of the key tenants and setting yourself up for problems down the road.
DevOps removes IT operations- this is one of the most common misunderstandings I see. DevOps is about merging development and operations goals together to meet an organizations goals, not removing operations.
What are some of the core benefits of applying DevOps principles to DataPower projects?
DataPower is an incredibly rich security gateway and is often doing the heavy lifting (security wise) of a solution. Embracing DevOps moves DataPower (and therefore security) left which gives big cost savings as you get to security testing (often left till late in a project) much faster. The embracing of DevOps into DataPower automates deployment which typically eliminates configuration mistakes leading to more successful deployments. Finally, it makes DataPower like everything else in your infrastructure. DataPower is a fantastic tool but it shouldn’t be treated any differently to the rest of your solution, it should (and does) fit into your existing DevOps processes.