DevOps as a Culture — set of Smartling workshops
My Managed services killed DevOps article in TechCrunch created a lot of controversy and sparked conversation. I’ve learned a lot as a result of the flurry of comments on the article — the most informative coming from anonymous posters ☺ That’s how it goes on the internets nowadays.
At Smartling, we put our money where our mouth is. Our engineering team started with a separate DevOps team like many other companies. Our DevOps team kicked serious ass. We were growing significantly as a company and the tech team was no exception. We run a modern development shop with a culture of ownership, continuous development, processes involving TDD, SOA, no separate QA team — all these characteristics fuse together to deliver a high-performance product that receives billions of pageviews and API requests. To maintain this ecosystem required providing internal support for the development teams, building deployment tools, and managing a ton of different software and virtual hardware and services. Smartling was growing like a weed, we were hiring quickly and constantly, and the DevOps team started to be overloaded with requests from every corner of the development team becoming the bottleneck. While that was happening, another trend was shaping up, which involved managed services. Because we started with AWS initially, we made the decision to avoid a lock in. While not specifically investing into going multi-cloud we kept the infrastructure clean. However, this became increasingly difficult over time. AWS became a dominant provider, and they started to build managed services that were incredibly convenient. Resistance became futile. Development time gains became impossible to ignore.
Since the DevOps team was overwhelmed with requests and the management of various hardware and services was becoming easier, we made the decision to switch to DevOps as a culture. Our savvy DevOps team organized and produced a set of workshops to get our developers familiar with AWS services and provide them with hands on training. And so we began shifting the team culture. As one might expect, some folks were happy with the change and some were grumpy; change can be challenging..
As a result, the development teams now own the virtual hardware and managed infrastructure for their services. They get paged when something goes wrong. And while no one likes getting paged, the developers are now empowered and accountable for fixing their code as quickly as necessary.
We decided to open our DevOps workshops up to teams who go through a similar transformation. We are still publishing them, this article will be updated when we get new workshops published.
Workshop #1:
Workshop #2:
Workshop #3:
Workshop #4:
Workshop #5:
