From the trenches: A real-life experience in DevOps, Agile, CI/CD and containerization

Earlier this year, we decided to do a major update to the Axway Managed Cloud offering for API Management. This is a managed service offering of our API Management product that we run in our own AWS Cloud. We host it, manage it, maintain and upgrade it, monitor it and ensure that it is up and running per the SLAs. The customers just consume it as a service and are only responsible for administration inside the product.

Sounds familiar?

It should! With this Managed Cloud offering (and similar offerings based on our other products), we find ourselves very much in our customer’s shoes. The only difference is that instead of one or two environments, we are managing a large number of environments spread across multiple data centers throughout the world.

Late last year, the core product team released a new version of the API Management solution that included a containerized option for API Gateway and Manager. The Managed Cloud offering team saw this as an opportunity to dive deeper into the world of DevOps, CI/CD and containerization. They built a new and futuristic APIM Managed Cloud offering from the ground up. While establishing the project goals, we took more than a few pages from David Mckenna’s now-famous blog series “Keep CALMS and DevOps.”

First and foremost, we established a true “Dev + Ops” team by bringing together individuals from the core product development team (who had just finished creating the container-based version) and from the TechOps team (who have been running the existing Managed Cloud offering for years). This was huge! While the teams regularly met earlier, now working closely together the team members started developing a much better appreciation of each other’s challenges and viewpoints.

Next, we decided to create a single prioritized backlog for this new DevOps scrum team. We took the wish-lists from both sides, merged them into one, developed a unified prioritization scheme and used that to arrive at a unified and prioritized backlog based on business value and effort.

Now, it was time to decide the Agile methodology that we were going to use. Considering that the scrum team was newly formed, and members needed time to get to know each other, we agreed on Scrum with two–week sprints with a goal of eventually getting to one-week sprints.

We knew that Automation was going to play a key role and serve multiple goals in this new version. We felt that we had an opportunity to leverage automation in a strategic manner to not only reduce the time needed to deploy a new environment but also reduce the amount of manual intervention needed thereby freeing up resources and allowing them to shift their focus from “urgent and repetitive” to “important and strategic” work. While there are several automation tools available today, our team chose a combination of Jenkins, Helm, Terraform for their needs.

Similarly, we felt that we had a huge opportunity to lay down a futuristic Architecture and leverage that to serve multiple goals such as high availability and resilience, standardization, auto-scaling and optimal use of AWS resources and costs. Once again, having a DevOps team that included people familiar with the core product’s architectural design and people with experience in operating existing Managed Cloud environments was very helpful in making the right architectural and design choices.

Finally, we wanted to have good metrics both on our journey towards higher maturity as an Agile and DevOps team and on the product’s performance in the real world. For the product, we have implemented a small set of logging and monitoring tools to meet different requirements. On the other hand, we continue to regularly measure and retrospect on our team’s growth and maturity.

So, did we see any benefits?

We will soon be onboarding customers to this new and exciting version of the API Managed Cloud. However, we have already started to see the benefits of this approach. To share one concrete example: our team originally started to develop this new version of Managed Cloud offering based on v7.6.2 of the APIM product.  Fairly late in our release cycle, the core product team released v7.7. If we were using more traditional approaches and tools, then we would have most likely decided to stick with 7.6.2 and look at 7.7 at “some point in future.” However, within a matter of days, we were able to replace 7.6.2 with 7.7, test it out and keep moving with the rest of our plan. Now, that is something to be proud about for any team.

What’s next?

While this amazing journey has not ended by any means, we couldn’t wait to share what we have learned with you and to give our customers a helping hand in their own journey. To that end, we are starting this new blog series. Our team will be sharing blog posts to cover in detail, multiple topics that I have introduced above. We will also be sharing useful assets such as Helm Charts and reference architecture.

We invite all our APIM customers (particularly, those who manage their own APIM infrastructure on-premise or in a private cloud) to benefit from our learnings and to leverage the assets that we are sharing to plan and execute their own upgrades to v7.7 and to a container-based setup.