This article is based on an interview originally published by DevOps Online with Don Pinkster (Team Lead Infrastructure, Sqills) and Robin Breuker (Team Lead Software Development, Sqills). Sqills builds S3 Passenger, a software platform serving the passenger transport industry.
Introduction: DevOps as a Cultural Shift, Not Just a Toolset
For many organisations, DevOps starts as a buzzword and ends as a disappointment — usually because it is treated as a tooling problem rather than a cultural one. Sqills, a software solutions company focused on passenger transport, offers a concrete counterexample. By distributing ownership across small, autonomous teams and combining that culture with a move to AWS, they were able to scale internationally while keeping delivery velocity high and quality consistent.
Their experience illustrates three principles that DevOps practitioners hear often but execute rarely: teams owning what they ship, infrastructure becoming a service rather than a gatekeeper, and tooling being evaluated continuously rather than locked in permanently.
What the Teams Actually Do
Sqills is structured around small DevOps teams, each responsible for a specific set of microservices within the S3 Passenger platform. Pinkster’s infrastructure team has two primary mandates: keeping systems stable and driving infrastructure innovation — validating new concepts and bringing them into production. Crucially, the infra team also plays an internal advisory role, helping development teams think through infrastructure decisions rather than making those decisions for them.
Breuker’s software development team works on a defined subset of microservices. His role sits at the intersection of product ownership and technical leadership — working with engineers to design solutions, not just prioritise a backlog. As he describes it, genuine DevOps responsibility does not stop when a feature is built:
“DevOps goes beyond development. It means going beyond the things you are asked to build — making things reliable and scalable. You monitor what goes into production. The component may be finished, but how does it run? Does what we build behave according to our expectations, or is there fine-tuning to be done?”
Robin Breuker, Team Lead Software Development, Sqills
Cloud Migration: Why AWS and What It Unlocked
Reducing Latency for International Customers
Sqills chose AWS primarily because global cloud providers allow applications to be deployed in regions close to end users, reducing latency — a real concern for a platform serving passengers and transport operators across multiple countries. Proximity to the customer is not just a performance metric; it affects perceived reliability and, in time-sensitive transport scenarios, operational trust.
Infrastructure as Code and API-Driven Automation
For the infrastructure team, the cloud transition removed a significant manual burden. On-premises infrastructure required hands-on provisioning; AWS-native tooling enables infrastructure to be defined, versioned, and deployed through APIs. Combined with tools like Terraform and Ansible, the team can treat infrastructure as code — repeatable, reviewable, and auditable.
Pinkster describes the shift as a qualitative change in what infrastructure teams can accomplish:
“Being able to deploy infrastructure through an API is incredibly powerful. No more manual input — everything can be automated.”
Don Pinkster, Team Lead Infrastructure, Sqills
Managed Services as a Force Multiplier
Breuker highlights managed services as the other major gain. Every AWS-managed service that Sqills adopts is one less thing the development team has to build, operate, or patch itself. This frees engineering capacity for work that directly differentiates the product.
Migration Approach: Lift and Shift First, Optimise Second
Sqills followed a pragmatic two-phase strategy. Phase one was a straightforward lift-and-shift: moving the existing application to AWS without re-architecting it. This minimised risk during the transition and delivered cloud availability and regional flexibility immediately.
Phase two — still underway at the time of the interview — involves progressively adopting cloud-native services where they add genuine value, rather than forcing a wholesale rewrite upfront.
This approach is not without challenges. Pinkster notes that identity and access management required a complete rethink:
“We had to redefine access control. Who is allowed access to the servers? Who can launch servers? These are things that simply do not come up with an on-premises solution in the same way.”
Don Pinkster, Team Lead Infrastructure, Sqills
For development teams, the transition was largely transparent — services continued running — though there was an expected learning curve in understanding AWS-specific service behaviours and APIs.
How DevOps Changed Organisational Dynamics at Sqills
Distributed Ownership Enables Faster Scaling
Before adopting DevOps practices, infrastructure was a centralised function that deployed and hosted applications on behalf of development teams. Responsibility for running software in production sat with infra, not with the teams who built it. This is a common bottleneck pattern in pre-DevOps organisations.
At Sqills, DevOps adoption transferred ownership of components — including their production behaviour — to the teams that build them. The infrastructure team shifted from being a deployment function to being an internal platform team: providing tooling, monitoring capabilities, and guidance rather than operating services directly.
The organisational impact is significant. New teams can be added with a defined scope of responsibility without creating a proportional increase in centralised infrastructure work. Breuker frames it simply:
“DevOps meant that different development teams took responsibility for their own components. This allows Sqills to grow much faster — we can move quickly by adding new teams with their own set of responsibilities.”
Robin Breuker, Team Lead Software Development, Sqills
Tooling Philosophy: Right Tool for the Job, Always Re-Evaluated
Sqills deliberately avoids locking teams into a fixed toolchain. The guiding principle is selecting the best tool for the current context and continuously reassessing whether that choice still holds. Teams have autonomy over their preferred tools, provided they meet shared standards for observability and operability.
Current Tooling Stack
| Category | Tools Used |
|---|---|
| Development languages | Kotlin, Go |
| Monitoring & observability | Prometheus, New Relic |
| Error logging | Kibana, Sentry |
| On-call / alerting | PagerDuty |
| Infrastructure as code | Terraform, Ansible |
| Container orchestration | Kubernetes |
Terraform handles declarative infrastructure provisioning, Ansible covers configuration management, and Kubernetes orchestrates containerised workloads. Together these tools reinforce the team-ownership model: each team can provision, configure, and monitor their own services without depending on a central operations team for every change.
Security and Compliance: ISO and PCI-DSS in a DevOps Context
Sqills handles substantial volumes of passenger data, which creates real regulatory obligations. The company pursued and obtained the following certifications:
- ISO 9001 — quality management systems
- ISO 27001 — information security management
- PCI-DSS Level 1 — the highest tier of the Payment Card Industry Data Security Standard
The PCI-DSS certification is notable. Sqills does not directly process payment transactions — those flow through connected Payment Service Providers — but chose to pursue Level 1 certification anyway, treating it as a commitment to rigorous data security controls rather than a minimum compliance exercise.
In a DevOps context, compliance certifications like ISO 27001 and PCI-DSS are most effective when security controls are embedded into the delivery pipeline — automated scanning, access control policies enforced via IAM, and audit trails generated as a by-product of infrastructure-as-code deployments — rather than applied as a periodic audit overlay. Sqills’s use of API-driven infrastructure and centralised identity management on AWS creates a foundation for this approach.
Key Takeaways for DevOps Practitioners
- Ownership drives velocity. Distributing responsibility for production behaviour to the teams that build services removes bottlenecks and allows organisations to scale by adding teams rather than headcount in a central ops function.
- Infrastructure teams should become platform teams. The shift from “infra deploys things” to “infra provides tools and standards for teams to deploy their own things” is a concrete organisational change, not just a philosophical one.
- Lift-and-shift is a valid first step. Attempting to re-architect everything during a cloud migration increases risk. Moving first, then optimising incrementally, is a lower-risk path to cloud-native benefits.
- IAM complexity increases in the cloud. Access control that was implicit in physical network topology on-premises must be explicitly modelled in the cloud. Plan for this early.
- Compliance and DevOps are compatible. Automated, auditable infrastructure pipelines can make achieving and maintaining certifications easier, not harder.
- Evaluate your toolchain continuously. Technology changes fast enough that the best tool for a job two years ago may not be the best tool today. Build a culture of re-evaluation without creating churn for its own sake.
Original interview source: DevOps Online. Statements attributed to Don Pinkster and Robin Breuker are drawn from that interview.