How Allbound Delivers on the Promise of DevOps with Automatic Monitoring

Software is not static. As soon as you roll out an update, someone requests a new feature. Even if everything works fine, an infrastructure upgrade can break your code, and resolving one issue can create another. End users deserve a seamless experience, services, and applications that work. From experience, I can tell you that the best way to provide continuous user satisfaction and continuous delivery of new features, all while ensuring quality and accelerating release cycles, is through the model of combined software development and IT operations, or DevOps.

In the last decade, DevOps has taken the software world by storm, but the approach can trace its route back to 1940s Japan, and the car manufacturer Toyota. Originally called “just-in-time production,” the Toyota Production System (TPS) was designed to eliminate waste and ensure quality by focusing on continuous improvement, respecting and developing people and partners, employing the appropriate resources to achieve the desired results, and creating a culture of learning. TPS catapulted Toyota to the number two position in the automotive world and has helped revolutionize the way companies around the world do business.

Today, DevOps can be described as a model that encourages communication, collaboration, integration, and automation between software developers and IT operations. DevOps teams are empowered with the autonomy to build, test, deliver, and support applications, and they come to have greater control over the production environment and a better understanding of the production infrastructure. This results in improved speed, quality of software delivery, and user satisfaction. 

The Road to Allbound

I’ve worked in software for 15 years and have developed everything from an investment bank’s backend system, mobile apps, IoT managed control rooms, to multi-tenant SaaS solutions. A big part of the reason why I’ve delivered on-prem and cloud-based applications on time and on budget is because I make it a top priority to assemble high-performing teams who release stable, high-quality products.

I joined Allbound in 2019, during a period of rapid growth for the company. Allbound offers a modern partner relationship management (PRM) solution. Our cloud-based platform is a complete ecosystem that simplifies channel management and increases partner engagement, and helps companies accelerate recurring revenues through channel partners. Our toolset includes portal access that delivers a partner-centric experience, a training module, an unlimited resource library, co-branded assets, and much more. 

We have locations in Scottsdale, Atlanta, and London, and I was hired to head the engineering department and expand our engineering capabilities at our office in Gurgaon, India. We wanted to develop a lot more features for our platform in order to stay competitive, and we needed to do it fast. We also wanted to make our product more scalable as our customers’ operations grew so they wouldn’t have to look for solutions elsewhere. To achieve these goals, I knew I needed to focus on DevOps.

Controlling Chaos with DevOps

To engineer a seamless product, you need an efficient coding workflow. That’s why it’s crucial to define your DevOps processes before you start building a team. I believe in putting together the toolbox first, and then finding people who know how to make the best use of these resources. After that, everything else falls into place.

Adopting a DevOps workflow helps me control the chaos. One of the pillars of this approach is the adoption of infrastructure as code. Infrastructure as a code is shareable, repeatable, and version controlled. It is easy to understand, and any developer who has access to the code and understands it will be able to modify it. If the person who wrote the code leaves the company, the team isn’t left helpless trying to figure out their secrets, and if the environment changes, there’s no need to rebuild from scratch. It is not dependent on a specific server or hardware configuration. 

Another pillar to this approach is to create a solid build and deployment pipeline. This resolves conflicts that arise when different team members are merging and committing code. The result is fewer bugs and shorter release cycles. When you commit code, you can automatically build it, perform unit tests, check code quality, and screen it for vulnerabilities. You can deploy with confidence frequently and don’t have to run two weeks of testing to make sure you haven’t broken anything.

The final pillar is containerization of the application to enhance the portability and efficiency of the code, and then using an orchestrator to support scaling and auto-healing. These three pillars have given us the agility and the accelerated release cycle that allows us to scale at the same speed as our customer's growth and demand. We can roll out new features, increase capacity, and address issues in a fraction of the time and cost it would have taken using a traditional application development workflow. But it hasn't come without a few bumps in the road. 

Protecting the Achilles Heel

The move to DevOps started before I arrived at Allbound. We were already in the process of containerizing our application. When I joined the company, I accelerated the transition by onboarding a group of skilled Kubernetes engineers to help complete the migration. 

Moving from an application running on a single server to a distributed piece of software running multiple containers can be challenging. A couple of tips: start with a lean and hardened base image, and manage your secrets wisely.

You also have to monitor your applications and infrastructure. Don’t make visibility an afterthought. If it’s not part of your Kubernetes migration plan, you’re basically asking for trouble. If you can’t see what’s going on beneath the surface, there’s no point in moving to containerized infrastructure at all. This is the Achilles Heel of Kubernetes, and to protect it, we needed a stellar application performance management (APM) solution.

More Insight into Our Infrastructure

Allbound has had great success with Instana as our chosen APM solution. It helps us understand how our constituent components are interacting with one another. I had never used Instana before I came to Allbound, and I was stunned by the level of insight the solution gave us into our cloud infrastructure.  

As soon as we installed Instana on our Kubernetes cluster, I could see our entire infrastructure on one of its easy-to-read dashboards. I could monitor the way we’d deployed our assets. I could pull up a map of our masters, our nodes, their pods, and all the replicas. More importantly, I could trace the source of our errors and pinpoint the root cause of errors in our applications. 

When a customer contacts us to report a problem, along with logs we use Instana to figure out whether it’s a database issue, a JavaScript error, or a fault with one of our other services. If there’s a major event change, we can spot it, too. 

Before adopting DevOps, we used historical data as one of our resource estimation tools. Using this approach, however, led to some incorrect assumptions. One of these was the conclusion that all our services are  CPU intensive. We saw this wasn’t true, however, when we compartmentalized the platform in Kubernetes and began using Instana to monitor the CPU, memory, and resource consumption of its constituent parts. We were then able to scale specific services and optimize system performance by allocating more memory to containers that needed memory, and by increasing the number of CPU cores for services that required more processing power.

High Visibility, Low Touch

Instana has given us the ability to measure customer experience in a quantitative way. We can monitor their pain points and proactively rectify any service degradation.

Instana is fully automated when it comes to setup, configuration, maintenance, and use. Once you’ve installed the Instana agent, it automatically starts discovering and instrumenting everything. The only extra configuring I’ve done is setting and modifying alerts. 

Configuring an alert is so easy that anyone on my DevOps team can do it. This means we can all spend more time on improving visibility and rolling out updates to our platform. 

Making Life Easy for DevOps

We are a global team, but Instana still has helped us sleep well. Kubernetes is fault-tolerant and self-healing, but if there is a problem it can’t handle, Instana will give my team more details to address the problem, and everyone can go back to their lives. 

Adopting DevOps and moving our platform to cloud-based Kubernetes infrastructure is helping Allbound innovate rapidly. We are growing our user base and extending the functionalities of our platform seamlessly. We recently launched enhanced Channel Insights, where users can quickly visualize how their channel program is growing by viewing partner engagement and pipeline activity. And there’s more to come. 

Instana has given us the visibility we need to fine-tune our application and maximize resource usage of our cloud infrastructure. It has given us the confidence to push out a better product at a higher frequency and has helped us deliver on the promise of DevOps. We’ve never had it better.