10 Commandments Leading Our DevOps Journey in Kongsberg Digital

Anshul Lalit
Kongsberg Digital
Published in
15 min readJun 5, 2019

Last week, I had an interesting conversation with someone, and his final thoughts were, “DevOps is the answer, sure, now tell me the question?

It was a fair statement. With running anti-patterns around, things may look so melancholy and impervious at times that DevOps or any emerging trend for that matter becomes a whim for few companies and I have seen/heard my fair share of DevOps adoption failures.

It is the rule of life that once things become repetitive, overused, and old, they are replaced or pushed over to make way for newer, better, and more contemporarily designed and structured elements. Technology acts in a very similar fashion as well. As Gassmann Oliver put it in quite simple words in “Opening up the innovation process: towards an agenda,” technology starts, develops, persists, mutates, stagnates, and declines, just like living organisms. In the world of Information Technology, change happens frequently, and it happens fast.

DevOps is a culture; a culture that inclines towards growth, communication, and fast response, subsequently transforming the work environment into a much more productive one.

At Kongsberg Digital, this was no different. During our DevOps journey, we adopted several principal approaches, including our tools, processes, and most importantly, the culture. I believe DevOps is a culture; a culture that inclines towards growth, communication, and fast response, subsequently transforming the work environment into a much more productive one.

To us, DevOps didn’t merely mean to live in the cloud, adopt cool tools, and be done with it. One of the essential pillars has been our culture all this time. In this post, I would highlight and summarize each one of the commandments, helping us improve our DevOps journey and practices. Here is what we touch upon in this article:

1. The Tools
2. The Process
3. People
4. The Blueprint
5. Security First
6. Infrastructure Provisioning
7. Kongsberg Digital Cloud Delivery Model (KCDM)
8. Automation
9. Strategy for Scalability vs. Culture
10. Vision

We believe that each of these commandments is equally important, and it becomes highly critical success indicators for us to ensure organic growth to even qualify for DevOps success. Let’s begin.

1. THE TOOLS

When we started our journey, the DevOps tools world was overwhelming. We found that our challenges were unique to us, and we couldn’t have our creative developers tied down to a fixed set of tools. That would surely be a buzzkill at best. At the same time, it was possible to choose an ecosystem for a must-have standardization and collaboration to adopt the right tools for the job. Our objective in this area is to create a DevOps value chain, not just a delivery pipeline using an element of randomness. Let’s talk about some of the highlights.

The Development hub

Our background was heavily loaded from Microsoft centric tools, O365 and Team Foundation Server, hence Azure and Azure DevOps were something that fit right in. There are immense possibilities to integrate solutions, and the recent path-breaking adoption of open source by Microsoft helped us luminously at the right time. Azure as a PaaS services provider and Azure DevOps as our one-stop development hub were easy to integrate with our dev ecosystem and infrastructure flexibility primarily helping our code, git repos, IaC, CaC, CI/CD, automation, security, monitoring needs.

DevOps with Azure DevOps — Microsoft way

Azure DevOps helps us manage various aspects of a fully integrated development cycle, including project planning & management, sprint & backlog management, CI/CD, source control, and collaboration. With seamless O365 integration, it became our obvious choice.

There is a painful learning curve, sure, but in the end, it’s all worth it

Being said that, we have successfully migrated teams who swore by Jira and Confluence solutions. There is a sharp learning curve, sure, but in the end, it’s all worth it. We primary use Git for our version control (sorry, TFVC!), it just makes sense for distributed teams and adopting different flavors of branching models (Git Flow, Github flow and what not!).

Packages, Artifacts, and everything else

Our development teams have the freedom to choose what they think is suitable for the solution. Our feature teams define it. We strive to find better ways to work and optimize our solutions by encouraging prototyping and experimentation phases during project work. For example, our Digital Twin solution uses .Net Core with C#, Python for ML, and Kubernetes for containerization. The team started prototyping with Azure Service Fabric, but for ML models and other needs, they found Kubernetes to be a good fit.

A typical AKS CI/CD workflow in Azure DevOps

We deal with various binary types when it comes to our product lines, and CI. It was vital to ensure such binaries are consumed at a faster cadence with high availability and scalable system, ensuring support for various binary types like npm, NuGet, Docker images, PyPi, zip, MSI, and several other generic packages. JFrog artifactory SaaS offering is a great solution to handle our needs. It efficiently helps us to manage full artifact lifecycle, accelerate our development workflow, and integrate with our Azure AD.

Azure, our primary Cloud

Azure has been a critical enabler for our journey so far. From AI, machine learning, hyperscaling Database Solutions, Kubernetes services, IoT, Identity Management, and competent developer tools, it has everything so cleanly integrated with our development hub that it makes the job easier. Our developers get uber-cool tools to experiment with and learn new ways to optimize various Azure platform services. Our continuous focus is to promote Dev/Test capabilities on this platform to our ever-growing feature teams. One of the values of Kongsberg is Innovation, and we do drive innovation by providing such access and capabilities to our modern-day cloud-born developers to achieve cutting edge solutions by not limiting themselves to the legacy ways.

Then, there are some

It’s not possible to discuss the whole spectrum of our DevOps toolkit, but here is a glimpse on our most common or rather typical setup for our DevOps value chain:

DevOps Value Chain in Kongsberg Digital

2. THE PROCESS

Changing the running processes of our organization has been a challenge, given the various development practices centric towards legacy workflows, silos, bureaucratic gates, geo-boundaries, specific initiatives across projects, cultural integrations, etc. The good thing is that we wanted to change for good with mandated top-down support. We knew why we want to change, and most importantly, we identified our building and support blocks (Executive Management, Technical Leadership, etc.).

Our objective in KDI is to have a DevOps continuum

We also have a good transition happening towards cloud architectural needs as several teams plan to utilize micro-services architecture for more elasticity and scalability. Within a DevOps environment, developers and operators work together at the same pace, with similar goals and views in mind, which allow the delivered service to be quick and efficient. Our objective in KDI is to have a DevOps continuum that can help us overcome traditional development problems, evaluate and meet DevOps maturity phases, and encourage DevOps culture and tools.

So, how do we translate this in day to day operations for our feature teams? Probably it’s the right team to address why I keep referring our teams as “feature teams.” We believe in creating a shared space for our various teams and remove boundaries we often call as silos. To us, the best way is to align all essential roles in a single team and call that team a feature team, meaning this feature team has sole responsibility to architect, code, test, deliver, monitor and fix a solution following the philosophy, “You build it, you run it.

Day-to-day operations with Agile model in Kongsberg Digital

The complete translation of our strategy and process comes down to these feature teams working in a cohesive way eliminating legacy differences and personas of coders, testers, and operations. We decided to adopt a clean and lean Agile model, starting with some pilot projects and scale thereof. It was no rocket science, but the beauty was to stick to the Agile principles without promoting infamous “watergile” or “agilefall” metaphors.

3. PEOPLE

Not just word but a meaning to our journey. People should collaborate more, share common goals, and focus on improvements, and that’s precisely what we strive to do. We find a common way of looking at success rather than traditional team-centric values. “It works on my machine” is no longer an acceptable phrase in Kongsberg Digital. If it doesn’t work on any machine, the whole feature team takes responsibility to resolve that matter.

It works on my machine” is no longer an acceptable phrase in Kongsberg Digital

My favorite quote from Donovan Brown on this subject is, “It is imperative to realize that DevOps is not a product. You cannot buy DevOps and install it. DevOps is not just automation or infrastructure as code. DevOps is people following a process enabled by products to deliver value to our end users.

Trust is a huge component and DevOps as philosophy implicitly means that you trust your team to do necessary changes and expect something positive to happen. It is about empowering and decentralize success authority for a bigger picture. Hence creating a culture that is supportive of the ideals of such movement is crucial. We at KDI, enable our teams to facilitate open communication, identify responsibility, respect contribution, and build trust among teams.

4. THE BLUEPRINT

So, what do we do for all the fancy stuff around CI/CD and continuous everything? We research, experiment, innovate and adopt what works. For example, pipelines as code (YAML, no secret there), Microservices to avoid rigid frameworks & promote scalability, Azure Key vaults for app secrets, Azure dynamic variables for configuration management, App Insights for app performance, telemetry are some of those out of the box examples.

We ensure our automation coverage in form of the unit testing, automated pipelines, and build triggers facilitating CI/CD workflows, inbuilt security tests, collection of KPIs, telemetry, etc. There is so much to learn from Azure reference architecture to enable extensibility for such solutions. For example, something like the following architecture would help us to instrument a web application for telemetry, collection of such telemetry for our web app and monitor metrics associated with Azure services:

Instrumenting a web app for monitoring in Azure

Application development and stage deployment have more significant considerations in terms of service availability, scalability, security, and resiliency. There are some typical out-of-the-box proven architecture available out in the wild to attach success parameters to some solutions. Be it computer-aided engineering, working with Service Fabric, containers, Azure DevOps integration, API Management, or IOT.

A basic webapp showing proven architecture using Azure App Service and SQL DB

It becomes easy to extend this solution to support such web app for scenarios like improved scalability, multi-region deployment, and enable monitoring. Even in the context of multi-tenant architecture; things like customer enrollments, API Management, authorization, identity claims, access tokens, assertions, app secrets, customer AD federation, etc. become easy to comprehend at a glance.

Continuous technical debt assessment helps us keep the development cadence and manage inherent variability of flow based development practice

Similarly, approaches like using Feature Flags for our solutions is key to various success factors like A/B testing, TiP or even testing various configurations.

We practice keeping our technical debt being continuous assessed, backlogged, and prioritized in a sprint cycle. It helps us to keep the development cadence and manage the inherent variability of flow based development practice.

5. SECURITY FIRST

When it comes to cloud, it’s not the business alone that needs to exist on internet endpoint, the corporate intelligence, enterprise solutions, and cloud services are pretty much covered into this arena and it all comes with security as number one priority.

By introducing security governance practices, we strive to provide compliance and diligence before our solutions hit the production space. Having OWASP Security by Design Principles as our guiding path, we focus on maximizing our security coverage at design and development level. Our cybersecurity team works with feature teams and strive for compliance around such principles for designing secure systems.

We believe that Software architects must identify security issues as early as possible. The earlier a threat is discovered, the easier it is to mitigate it. We promote the usage of Microsoft’s threat modeling tool internally. One of the most significant advantages with this tool is that it provides detailed descriptions of how to mitigate the potential threats it identifies. Our feature teams have a dedicated role as “Security Champions,” and this role helps the team to understand, analyze, and validate such security concerns.

A typical Kongsberg Digital build pipeline shows SonarQube, Whitesource and Code Obfuscation tasks in use

Beyond this, we also focus on static and dynamic code analysis. We use tools like Sonarqube, Whitesource Bolt, and Burp suite for such practices, along with code obfuscation.

6. INFRASTRUCTURE PROVISIONING

Infrastructure as Code, Configuration as Code — let’s admit that it’s cool and functional when it comes to automation and immutability. We should be able to redeploy each time any change occurs effectively, and that’s what we try to adopt and promote within our feature teams. Using the robust Azure provisioning tasks within Azure DevOps, we can re-deploy our infrastructure needs during our CI/CD activities. It helps us keep infrastructure versioned in a dedicated and shared git repo for vanilla PaaS services, Virtual Machines, App Services, and whatnot, with secure gateways and NSGs configured for teams to be used. We are continuously improving our ways to optimize this area by introducing self-services, automated provisioning, Security as a Service, Build Signing as a Service, custom powerShell tools (pipeline integration) for some nifty tasks and even ChatOps.

We are excited about the future

The chase to find continuous improvements in this area would surely help our features teams for stronger configuration management, repeatable, and reliable deployments. We are excited about the future.

7. Kongsberg Digital Cloud Delivery Model (KCDM)

KCDM is a continuous delivery model curated for KDI keeping common concern areas and feasible DevOps progression in mind. KCDM helps us transform our organization with current, and future proof needs, to deliver secure software, at a faster cadence, with better, and predictable quality.

KCDM is a DevOps maturity model across various areas and defines maturity at different levels for feature teams during their DevOps journey. It is our way to ensure we don’t lead towards anti-patterns. KCDM is based on 5 key objectives:

Our strategy is towards DevOps maturity at scale, and not towards extreme DevOps

KCDM helps us define clear roles in our feature teams, like Scrum Master, Developers, Testers, Operations, Security Champions, Incident Handlers, Automation, etc. It helps us facilitate a formal team enrollment process to keep process integrity intact. It is essential to quote that our strategy is towards DevOps maturity at scale, and not towards extreme DevOps.

KCDM is a crucial model for us to ensure a constant focus on our DevOps journey. I would detail this model in my follow-up post.

8. AUTOMATION

Automation at KDI is matured over the years. At KDI, automation is not only used to supplement manual testing efforts but also in creating power utilities, app provisioning, auto-configuration, and infrastructure automation. Our automation frameworks provide efficient, repeatable, consistent, and reliable methods to perform various tasks.

Our App Automation Framework (AAF) and the custom-made Test Run Operation System (TROS) is a breakthrough in handling functional automation issues. It channelizes, controls, and monitors test executions and act upon the run-time conditions based on smart logic.

Under the Infrastructure Automation Area, we have recently started to explore this space to build and optimize various Ops workflows. The thought process is to maximize self-service models for our feature teams, reduce flaky behavior during CI/CD, to create autonomous teams.

These automation solutions are well integrated with Azure DevOps projects, strengthening the CI/CD pipelines, and increasing automation test coverage.

9. STRATEGY FOR SCALABILITY VS. CULTURE

DevOps is incredible, but for us, at KDI, it was not the matter of only making our pilot projects a success. As Peter Drucker says, “Culture eats strategy for breakfast.” so the obvious question was how to develop a strategy that aligns with culture shift and helps us scale our practices. We started reevaluating by following lean principles and remembered to foster trust between teams. To understand this concept better, I would highly recommend checking out “One Flow vs. Mass Production” experiment.

During such scalability across geo-locations, it is likely to face process waste and cultural challenges. It is a given that culture deals with people and people come with preconceived notions based on past experiences, and it’s not a piece of code to be refactored. People may not act the same way under similar circumstances. If you haven’t seen “How you make toast” TED talk by Tom Wujec, it’s a great insight for this topic, worth watching.

it is imperative for us to keep our strategy and culture walk hand in hand

We focused on cutting down some process waste (not process) to give our DevOps scalability a fair chance. We learned that it’s easy to get lost, so we made sure to document our best practices, how-to guides, references. We are still scaling, but we know that it would help us scale.

Our Guiding Path and Driving Path — hand in hand

For our KCDM vision to come true, it is imperative for us to keep our strategy and culture walk hand in hand. Based on design thinking model, we focus on ensuring that our values drive the strategic goals. Similarly, all short-term objectives to achieve those long-term goals are driven by practices, and team behavior drives tasks to achieve those objectives. An example of this behavior is as petite as conducting a daily standup and limiting it to a max 15 minutes slot, or review the scan results of Sonarqube and post significant findings in a product backlog.

10. VISION

Our economy has transformed from being a product based to service based. In some of our traditional product lines, we are now starting to move our offerings to the Cloud powered by our digital platform, Kognifai. Similarly, modern digital solutions from Kongsberg Digital, including Vessel Insight, Outsmart, and Digital Twin, ensure a robust beginning with cloud architecture and DevOps maturity. Within a DevOps environment, developers and operations work together at the same pace, with similar goals and views in mind which allow the service that is provided to the customer to be as quick and as efficient as possible and we believe that all of it is possible when we have a vision in tandem with our strategy & workforce.

Adopting DevOps into a business model can be admittedly scary at first, but the benefits far outweigh the risks

Most business models, products, and services are built around stability, and to achieve that, the business needs to be constant, to have a set of rules which would not be broken in any circumstances. A good, reliable business invests many resources in finding what works best for them and turn that into a routine. Logically, any change into that routine is like throwing a wrench into a well-oiled machine. However, growth demands change. Adopting DevOps into a business model can be admittedly scary at first, but the benefits far outweigh the risks. In this era when every business wants to output the product as fast as possible but also have it be very stable and reliable, teams far too often find themselves at an impasse trying to juggle between those two aspects. The first always contradicts the other, so finding the perfect balance is never an easy task, and that’s precisely what separates the elite from the run of the mill team members. However, hiring the elite is not always an option. That’s why DevOps fit into this picture perfectly. DevOps seeks to bridge those two very different aspects always to deliver optimal results, thus pushing the consistency standards higher. To continuously push towards excellence, we strive to keep our vision at the horizon. To dream is to achieve it.

Kongsberg Digital is a provider of next-generation software and digital solutions to customers within maritime, oil & gas and renewables & utilities with leading competence within the internet of things, smart data, artificial intelligence, and automation and autonomous operations. We do all this by ensuring a functional DevOps culture for our feature teams facilitating cutting edge solutions and autonomous streams. We continuously look for talent to contribute to our success and take it a notch up in areas like product advisory, solution architects, product management, IoT, Azure infrastructure engineering and frontend development. Want to work with one of the pioneer companies ensuring leading digital development and competence across Kongsberg? We would love to chat.

--

--

Anshul Lalit
Kongsberg Digital

Head of Development Technology & Transformation @ Kongsberg Digital | Speaker | Author | Mentor