With companies generating more and more revenue through their APIs, these APIs also have become even more critical. Quality and reliability are key goals sought by companies looking for large scale use of their APIs, and those goals are usually supported through well-crafted DevOps processes. Figures from the tech giants make us dizzy: Amazon is deploying code to production every 11.7 seconds, Netflix deploys thousands of time per day, and Fidelity saved $2.3 million per year with their new release framework. So, if you have APIs, you might want to deploy your API from a CI/CD pipeline.
Deploying your API from a CI/CD pipeline is a key activity of the “Full API Lifecycle Management.” Sitting between the “Implement” and “Secure” phases, the “Deploy” activity encompasses every process needed to bring the API from source code to the production environment. To be more specific, it covers Continuous Integration and Continuous Delivery.
Continue reading “5 principles for deploying your API from a CI/CD pipeline”
Microservices Are Here, to Stay
A few years back, most software systems had a monolithic architecture and slow release cycle. In the recent years, there is a clear move towards Microservices architecture, which is optimized for scalability, elasticity, failure, and speed of change. This trend has been further enforced by the adoption of cloud and containers, which also enabled practices such as DevOps.
|Trends in the IT Industry
All these changes have resulted in a growing number of services to develop and an even bigger number of deployments to do. It soon became clear that the explosion in the number of deployments cannot be controlled using pre-microservices tools and techniques, and new ways have been born. In this article, we will see how Cloud Native platforms such as Kubernetes allow deployment of Microservices in high scale with minimal human intervention.
Continue reading “Microservices Deployments Evolution”
A couple of weeks ago, I mentioned that we (the Red Hat Inception Team) are building “a thing.” Given our own internal interest in the topic, you may be wondering why we chose a custom Release Engine over pre-baked tooling. There are many different reasons why we went in this direction; I’m going to cover four.
Why #1: There are many existing FOSS tools to automate portions of a release process, but there seems to be a tooling gap in tying them easily together.
Continue reading “Building a Continuous Deployment Engine”
We previously mentioned that Team Inception was focusing on making the deployment of packaged code a better situation for those in Red Hat IT. Here is a high-level overview of the work that we are doing:
Continue reading “Red Hat IT & Continuous Deployment”