BetMakers is the coming together of a number of small companies with established products. The culture is of rapid change and rapid deployment. This comes with some risk, but the teams are reactive and can address issues quickly. They are also responsible for the whole stack, from product vision and design, through to infrastructure, deployment and support. They are already an informal DevOps culture, in the sense that DevOps is partly rooted in trying to discover why startups can run rings around larger more established companies.

DevOps is an attempt to reacquire that “agility” with a little “a”. Once a tech team starts to grow, that agility is easy to lose. A common pattern is the introduction of processes to cover more and more business concerns such as compliance, security, risk management, and so on. Add on the inevitable mistakes, that are responded to with more and more process. Requirements sign off, QA teams, separation of concerns, etc. All this is the perceived best practice. Hell, my son is being taught it all at university.

The term DevOps is often used to refer to automation of delivery, infrastructure as code, etc.. And, it is true that these are areas that have been massively influenced by DevOps. But DevOps is really intended to cover the whole value stream from idea through delivery and beyond into support and then the eventual retirement of the product. The whole enchilada.

So, now we’re growing we decided that we didn’t want to slide into the practices that would slow us and move us away from the rapid responsive capabilities we’ve always had - but we still want to be able to deliver more with a bigger team. DevOps fits that ideal.

On the first project being built this way we are focussing on the following ideals, and I’ll be writing a little on each over the coming weeks:

• Continuous Deployment, a fully automated build pipeline from commit to build to test to deployment
• Automated Acceptance Testing, using a strategy based on BDD which has been optimised to enable frontend, backend and the full stack to be tested in separate points in the process
• Monitoring, Metrics, Logging and Alerting built in from the start

I also will be covering aspects of our architectural choices:

• Micro Service Architecture, keep components simple and isolated
• Frontend framework
• Backend language, micro-service framework
• Infrastructure and database choices
• Security - Cert management, VPC, VPN, encryption in flight, at rest, etc.

And some thoughts on continuous improvement:

• Are there good dev team metrics? How should they be collected?
• Bottlenecks

Image by Pixabay