Home Services Moving Product Development to DevOps
Moving Product Development
to DevOps

Kanda DevOps Practice

Kanda Software has been practicing agile and DevOps for ten years. Its development, test, release and monitoring practices are a state of the art. Kanda delivers software products quickly and with high quality, enabling its clients to focus on their strengths in other areas.

Not all companies are specialists in software development. Writing scripts for your IT environment is very different from writing business-critical software products.

Companies that depend on their software as an integral part of their business have vastly different needs from those of traditional enterprise IT shops. For a quarter of a century, Kanda has built products for software companies who are focused on getting your software to market faster and more reliably. Kanda is comfortable dealing with changing requirements, opportunity costs of delays, the risk of bugs and having to turn on a dime when the market dictates it.

If you want a company that has long-term developers who can write commercial-level code rapidly, that number shrinks by orders of magnitude.

Now, if you are working for a software company looking to increase your resilience and speed up your time to market, you reach the crux of the matter: Which of the companies that have good developers and professional testing staff can really impact your productivity, not put your corporate jewels at risk and save you significant amount of money in the process.

Kanda’s work is advancing our client’s business and product strategies. Over the past two decades, Kanda Software has been retained as a Software Development, QA, and Support & Maintenance outsourcer by many leading product and services vendors. Many of these companies have entrusted Kanda with the development, deployment, testing, and support of key parts of their state-of-the-art initiatives.

What is DevOps?

devops_kandaDevOps joins four practices that were previously intentionally separated by silos – Development, Staging, Release, and Operations. The walls between those practices were erected to separate skillsets necessary to conduct the practices as well as prevent the effects of a mistake in one practice from destroying the results downstream.

For example, a developer can break the entire build if not vetted by a release engineer, or a new build can bring down the server if not controlled by the Operations people. This triple line of defense came into conflict with the recent need of faster release schedule and smaller, non-monolithic sets of features being frequently made available to the users.

DevOps is a direct line from writing code to having end-users experience the results of that code with no time-consuming impediments. The silos are broken down to avoid delays and repeats in the process.

To achieve the smooth progress from code to the browser, DevOps needs to clear several hurdles:

  • AUTOMATION. The flow of code into production has to be supported by processes that take routine steps and run them autonomously. The goal is to automate as much as possible in the DevOps process.
  • SECURITY. Applications today must be secure. In traditional teams, the responsibility for security was never clear – it was spread throughout development, test, and operations. In reality, operations owned security because they were the last line of defense. DevOps ensures that the entire team is involved with security and protecting their application. There is no passing the buck.
  • DISCIPLINE. It is still possible to break the build or bring down the server with disastrous results. Speed has to live alongside reliability and performance.
  • FLEXIBILITY. Today’s DevOps are at the mercy of the constantly changing needs of the product itself. For example, jumping to Big Data requires rapid rethinking of all aspects of server management; Switching a development decision changes all the underlying delivery scripts.
  • TRAINING. To make things run smoothly each person on the team needs to understand the needs and technologies involved in every step of the way. Developers have to understand and participate in the building of the product and in ensuring that is operationally sound. They need to learn a variety of scripting languages and other tools and technologies involved in the continuous release process
  • OWNERSHIP. Perhaps the biggest obstacle in the path of DevOps success is expanding the horizons of individual team members. So it is not surprising that a programmer would rather be responsible for just the features that were assigned to her rather than product’s overall stability in the cloud. For DevOps as a process to succeed this attitude has to be shifted to the sense of ownership for the entire product, from beginning to end. As Kanda helps your team perfect the Automation, Discipline, Flexibility and Training areas of DevOps process you can work on instilling that sense of ownership in your team members so that the promise of DevOps – the fastest time to market possible – is fulfilled.
  • COST CONTROL. A significant part of the need for speed is to build and deploy software products that require less of a financial investment. DevOps enables this by eliminating organizational barriers and making the flow of software seamless.


About the journey

Kanda will work with you closely to analyze your hardware and environmental needs, analyze your product architecture (we are a custom product development company after all) and develop a plan that encompasses

  • Replace or update the current build and operating environment with the continuous DevOps process
  • Create scripts to manage your product submissions to the cloud and running your product on the cloud; just how do you move to continuous integration and continuous deployment.
  • Training your personnel in day-to-day use of the scripts and potential modifications
    Integration of Kanda’s DevOps personnel into your development process (if you so wish) for after the move
  • Changes/updates necessary to the product architecture to optimize the move to AWS
  • Step-by-step plan for moving over to AWS including contingency planning are roll-back if necessary

Once you are in agreement with the plan, Kanda can assist with its implementation as much (or as little) as you prefer. In that process we will:

  • Analyze your current application architecture and recommend changes or enhancements to make it cloud-ready.
  • Make those architectural changes and test for quality and cloud-readiness.
  • Prepare and maintain scripts for continuous integration/continuous deployment (CI/CD).
  • Set up an automated workflow for CI/CD including Kubernetes orchestration is desired.
  • Analyze code, including third-party libraries, for technical accuracy and security flaws.
  • Advise teams on DevOps and automated workflow best practices.
  • Monitor applications in production for availability, performance, and load.
  • Provide a team of specialists ready to diagnose application errors in production and get back to full performance with minimal downtime.

But wait, that’s not all! We can supplement your staff, and make recommendations on the types of cloud services that best meet your ongoing budget and technical and business goals.

Don’t repeat their mistakes! Part of our “DevOps on the Move” and “Agile DevOps” practices match your current bandwidth, data, messaging, VMs and other requirements against the many tiers of AWS pricing structure. We will point out the places that may seem benign but would cost you an arm and a leg if you move them “as is”. We will also suggest – and, if you wish, implement – workarounds and remedial actions.

AWS pricing is difficult to understand and apply effectively. Many clients who did not approach the subject carefully had a significant bill after they seemingly successfully moved over to the AWS. And we are talking tens and even hundreds of thousands of dollars of unplanned expenses. Not a small chunk of change.

AWS pricing is difficult to understand and apply effectively.

Many clients who did not approach the subject carefully had a significant bill after they seemingly successfully moved over to the AWS. And we are talking tens and even hundreds of thousands of dollars of unplanned expenses. Not a small chunk of change.

Don’t repeat their mistakes!

Part of our “DevOps on the Move” and “Agile DevOps” practices match your current bandwidth, data, messaging, VMs and other requirements against the many tiers of AWS pricing structure. We will point out the places that may seem benign but would cost you an arm and a leg if you move them “as is”. We will also suggest – and if you wish implement – workarounds and remedial actions.

Kanda AWS DevOps Practice gives you:

  • A solid plan for a painless and predictable move to DevOps practices under AWS – not as a one size fits all, but tailored specifically to the state of your release and hosting work now.
  • Implementation and testing the DevOps platform you will utilize once you are on AWS.
  • Optimization of the costs of using AWS, and the ability to adjust your product architecture to minimize those costs.
  • Integration of our DevOps personnel and/or assistance in training your people to keep DevOps running smoothly once you are up and running on AWS.

Kanda’s Integrated Agile DevOps under AWS


At first glance the term Agile DevOps looks like a combination of two fashionable terms, but the two processes are a natural fit.
DevOps is a streamlined cycle of Develop/Build/Deploy/Host/Repeat. The root of this cycle is development which today is largely done in Agile. So DevOps cycle has to coincide with the development’s Agile cadence, hence the Agile DevOps definition for Kanda’s ongoing DevOps practice for AWS.
As with many other new ways of doing things – from motor cars replacing the buggy to Uber supplanting taxi drivers – there are different approaches and rules that need to be clarified and solidified as the practice is taking shape.

There is a near-universal consensus that the DevOps approach, when done right, is superior to a more traditional siloed approach to delivering software, especially in the cloud. However, what exactly is meant by “done right” is far from universally accepted and is different for different software companies. Furthermore, the skills, processes and complexities of DevOps are heavily dependent on the configuration of your development and hosting environment. A Linux-based C++ product running on AWS requires a DevOps practice distinct from a C#.NET product running over SQL Server in Azure.

Over the last three years Kanda has taken all of these considerations into account to build and continuously improve our Agile DevOps practice so that it can offer the biggest impact to software companies that we work with.

Kanda’s Agile DevOps practice consists of:

  • Create the custom platform of scripts, orchestration, and defined processes to automate building your product, staging its submission into the cloud and reserving/managing cloud resources to optimize the runtime of your software.
  • Train your personnel in the use of the individual modules of the DevOps platform that they need to transform your environment from a silo-based approach to being an integral part of DevOps cycle.
  • Provide you with Only-As-Needed qualified and certified AWS DevOps professional of three types:
    • Architect(s). The architects define the initial DevOps platform and large-scale re-engineering of it when your product evolution requires.
    • DevOps General Practitioner(s). These are the professionals that are tightly integrated into your Scrum teams and do day-to-day adjustments to the build, test, deploy and operate scripts themselves or coordinate with your engineers on how best to change things to ensure smooth release and (when necessary) rapid roll-back
    • Cross-discipline Specialists. There are situations where questions posed by the cloud hosting and continuous integration require in-depth analysis and technical consensus. For example, there may not be a dedicated DBA on the project as the AWS provides the necessary data services but a serious bottleneck may develop requiring a rapid involvement of a data-savvy specialist. Kanda has these specialists and they can be rapidly brought in when you technologist or our DevOps personnel need them.

This is highly dependent upon your application, its infrastructure, and your business goals. If you have multiple applications, you may want to deliver multiple microservices. If your goal is to remain flexible, you want to look at containers such as Docker. Virtualization is part and parcel of a move to the cloud, so which is the best approach? And should you also be doing service virtualization during development? All of these approaches and much more have to be considered as a part of a DevOps approach to delivering software.

There are several advantages to utilizing Kanda’s Agile AWS Devops:

  • You only pay for what you need. You don’t have to hire a full-time person when you need less.
  • As part of our DevOps cycle we constantly monitor and optimize the AWS costs in addition to the scalability and response quality. It is easy to overpay on the cloud when thinking only about the quality of services, but with Kanda’s help you can optimize both.
  • Kanda’s Agile DevOps is tightly integrated with our AWS Hosting Monitoring and Remedial practice. If you choose to go with the latter you will sleep better at night yet any lessons you will derive from it will feed transparently back into your DevOps cycle.
  • Not least is our 25-year history of helping software companies develop and test their products. If any of the tasks identified in the DevOps architecture require modifications to your product stack we can help you accomplish it directly while minimizing the extra burden placed upon your in-house development and QA team

Kanda AWS Monitoring DevOps Integration

The good news is that AWS very rarely has outages. The philosophical news is when AWS crashes it is cost-prohibitive for most to have a fallback alternative.

The bad news is that there are still things that can go wrong. From DDS attacks to critical bugs to an often not-so-simple need to restart a service. Someone has to be watching over the product’s behavior 24/7. Kanda has provided our clients with a 24*7 Monitoring and Remedial services for over a decade and we have developed a very attractive SLA that lets many of our customers big and small get a good night’s sleep.

With the advent of AWS it has become clear to us that DevOps cycle can and should become an integral part of the Monitoring and Remedial operations:

  • Some of the issues and bugs discovered in the 24*7 cycle are attributable to the DevOps platform and need to be adjudicated rapidly in tandem with the DevOps personnel
  • Many aspects of the system’s performance, such as noticeable but not fatal delays in data retrieval operations are heavily dependent on the cloud management part of the DevOps platform. Yet blindly scaling up risks raising prices inordinately. So only by integrating monitoring and DevOps can you achieve the “real-time” optimized governance of your cloud resources
  • In the age of A/B testing, lull-time release schedules, and on-demand roll-backs there are many tasks that straddle the boundaries of DevOps and monitoring scripts. It is probably the monitoring team that should decide if a 2am rollout is justified or there is still too much traffic on the site. So combining the teams and integrating skillsets makes for a more productive, less error-prone resilient DevOps cycle.

The good news is that AWS and other cloud services provide the ability to monitor applications and report on outages, slow performance, and application failures. Kanda has the expertise to advise on which tools should be used with your applications, and how they should be applied.